Well, they did it again - a new HA Core release causing "warning" - no functional change - ah await - I just used the opportunity to implement a prefix for the logging output.

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in GitHub yet - please do so. This is the simplest and cheapest possibility to honor the work.

Another day - another update?

Basically this is a roll back of the previous update from yesterday, since in the meantime HA Core has released the new version 2026.10.4 which include a global fix for the response header size issue caused by a changes at GitHub. You can find details in the HA Core PR#188329

[2026/10/26] UPDATE
Looks like that GitHub has reverted the change that caused the response header size to exceed 8KiB (when request a file from a release) - This made all efforts (& patches) created since the 23'rd of October obsolete. Have it been useless? Well IMHO this is not a case - this incident (a simple change at GitHub can break the complete software-delivery-supply-chain) is a nice indicator how dependent ecosystems have became from each other.

Too many updates?

I have to admit that I am quite unsure how to handle situations like the current one caused by the change at GitHub - breaking all update processes for all HA users. I am quite confident that some other integration developers are a bit more relaxed when it comes to the situation that there is an breaking issue.

My personal expectation is, that when something breaks that a fix/patch/solution (at least a response) should be provided as soon as possible, even if the own code is not responsible for the issue itself. And how fast is as soon as possible? For me this is less then 24h. Of course there are situations where I do not meet my own 24h-resolution-time expectation - but the 24 in marq24 is an commitment (and not just two random digits in a user name).

I was surprised (this morning) to see that a new HA version has been released - of course if I would knew this 24h earlier, I would not have invested the time to create nine HA integration updates (trying to explain the current situation and the root cause for the release) - might be I should switch to marq48 (but that's already in use by someone else) - so here he is, my alter ego: Mañana, Mañana Matthias, @marq72 - follow him if you would prefer less updates.

Version number jump?

You might have noticed that the version number of this release (the final digit) has just jumped to 2016.10.7. There’s no secret behind this, and you haven’t missed anything important — I simply wanted all of my HA integrations to have the same version number to make things easier for me; it’s as simple as that.

Adjusted configuration integration setup

With the release yesterday I have rolled out also a new Integration type for local communication via open.API (on port 4424). Looks like the hope that we (@nename0 and I) had, that this interface might be also provided by V4/E4/P4 systems has not been fulfilled.

So it had been time to clean up the initial setup of the integration. In the first step you will be asked what SENEC.System you want to configure and then based on this initial selection the currently known working integration types will be offered:

SENEC V2.x

• LAN access via lala.cgi
• WEB access via none-public-API mein-senec.de/App

SENEC V3

• LAN access via lala.cgi
• LAN access via open.API (read-only)
• WEB access via none-public-API mein-senec.de/SENECapp
• LAN access to the build in inverters (if wired) (read-only)

SENEC V4/E4/P4

• WEB access via SENEC.Connect (read-only)
• WEB access via none-public-API mein-senec.de/SENECapp

Open for experiments?

As SENEC V2/V4/E4/P4 you still can try the experiment if the LAN access via open.API would work for your system - simply select the SENEC.Home V3 hybrid/SENEC.Home V3 hybrid duo in the initial integration setup step and then you can try to configure/use the Local/LAN via OpenAPI: https accessible over port 4424 (experimental)

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

_If you haven't starred this integration in GitHub yet - please ...

Workaround release

At the 23.10.2026 GitHub as rolled out a change causing a issue in the GitHub API client implementation of HACS - this HACS issue affects all integrations or custom cards that make use of

hacs.json

...
"zip_release": true,
...

Even if my initial commit message was different - I can not blame HACS for the issue! - GitHub decided to increase the Content-Security-Policy header up to 9217-byte on release downloads, exceeding aiohttp's default 8190-byte response-header limit. So who you want to blame? GitHub, aiohttp, HACS or the integration?

With this workaround release the "zip_release": true, will be removed from the hacs.json - which should allow you to update the integration via HACS without the need waiting for an appropriate handling of zip_release after the changes made @ github. So no need to wait for the release of HACS PR#5644 & HACS PR#5649 which is IMHO anyhow in question since HACS will be migrated into HA as default marketplace with HA 2026.11.

I apologize – some of my recent reactions have been inappropriate

Perhaps it’s part of a midlife crisis, or maybe it’s because another summer has come to an end—or perhaps it’s simply the weather or the state of global affairs on our planet.

I currently maintain nine different HA (Home Assistant) integrations, and on some days, I find myself feeling overwhelmed by one issue or another.

I’m only human, after all—and humans make mistakes. My apologies.

also I am forded (since I am too stupid to use git appropriate) to include the changes of the recent pre-release...

LOCAL.OpenAPI - all credits go to @nename0

This new LOCAL.OpenAPI access has been discovered by @nename0 - thanks for your hard work!

When this PR #241 arrived this morning I was totally surprised. I started with a short research and could not find a lot of information about the existence of this additional open port 4424 on a SENEC V3 - but it looks like, that this exist at least since 2022.

There is a tiny portion of hope left, that this local OpenAPI access is also available for other SENEC Systems. Might be on different ports - might be with (slightly) different endpoints?

Experiment for E4 (V4|P4)

Currently it's unknown, if other then V3 SENEC devices will also support this local https interface - if yes this would be a great news for all of you who prefer LAN over WAN. At least there is a report from Ich-h4lt that the port 4424 is not open on his P4.

So it would be cool, if a E4 owner could try this... During the initial setup phase the system tries to reach the port 4424 on the specified host/IP - if this does not respond no further action will be performed. So trying the integration setup is IMHO quite a low risk to harm your system. But again this is just my opinion. Please only try yourself, if you feel comfortable to do so.

Why this OpenAPI still have value (at least IMHO)

Since we can't prohibit automated firmware updates of our systems, it could be (I don't want to start new rumors - I am just talking about the technical possibilities) that the lala.cgi access will be removed or technically restricted or what ever in the future (of course without prior notice).

While in theory this also could happen to the newly discovered OpenAPI endpoint, there are 3'rd party Systems like JUNG Visu Pro or ASKOHEAT+ that actually depend from this OpenAPI.

So at least I would consider this as possible local fallback solution - which his highly welcome as an alternative to the web stuff.

Bypass possible forced MFA setup request when access mein-senec.de

If you have not already configured MFA with your mein-senec.de account then you will be forced (at least that happens to me) to configure MFA before you will be able to continue to access mein-senec.de (which would be required in order to allow the OpenAPI communication).

SENEC would not be SENEC, if there would not be a way to bypass this MFA 'enforcement' -> login in a second browser tab to https://sso.senec.com/realms/senec/account and surprise, surprise...

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

[![Github Stars](https://img.shields.io/github/stars/marq24/ha-senec-v3?style=for-the-badge&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgdmlld0JveD0iMCAwIDE2IDE2Ij48cGF0aCBzdHlsZT0iZmlsbDojY2NjY2NjIiBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiI+PC9wYXRoPjwvc3...

LOCAL.OpenAPI - all credits go to @nename0

This new LOCAL.OpenAPI access has been discovered by @nename0 - thanks for your hard work!

When this PR #241 arrived this morning I was totally surprised. I started with a short research and could not find a lot of information about the existence of this additional open port 4424 on a SENEC V3 - but it looks like, that this exist at least since 2022.

There is a tiny portion of hope left, that this local OpenAPI access is also available for other SENEC Systems. Might be on different ports - might be with (slightly) different endpoints?

Experiment for E4 (V4|P4)

Currently it's unknown, if other then V3 SENEC devices will also support this local https interface - if yes this would be a great news for all of you who prefer LAN over WAN. At least there is a report from Ich-h4lt that the port 4424 is not open on his P4.

So it would be cool, if a E4 owner could try this... During the initial setup phase the system tries to reach the port 4424 on the specified host/IP - if this does not respond no further action will be performed. So trying the integration setup is IMHO quite a low risk to harm your system. But again this is just my opinion. Please only try yourself, if you feel comfortable to do so.

Why this OpenAPI still have value (at least IMHO)

Since we can't prohibit automated firmware updates of our systems, it could be (I don't want to start new rumors - I am just talking about the technical possibilities) that the lala.cgi access will be removed or technically restricted or what ever in the future (of course without prior notice).

While in theory this also could happen to the newly discovered OpenAPI endpoint, there are 3'rd party Systems like JUNG Visu Pro or ASKOHEAT+ that actually depend from this OpenAPI.

So at least I would consider this as possible local fallback solution - which his highly welcome as an alternative to the web stuff.

Bypass possible forced MFA setup request when access mein-senec.de

If you have not already configured MFA with your mein-senec.de account then you will be forced (at least that happens to me) to configure MFA before you will be able to continue to access mein-senec.de (which would be required in order to allow the OpenAPI communication).

SENEC would not be SENEC, if there would not be a way to bypass this MFA 'enforcement' -> login in a second browser tab to https://sso.senec.com/realms/senec/account and surprise, surprise...

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

Comparing integration downloads with granted GitHub stars

+1600 Downloads vs. 131 Stars making a ratio of 8% If you haven't starred this integration in GitHub yet - please do so. This is the simplest and cheapest possibility to honor the work.

HACS will be part of HA core

With this update some small adjustments will be released in order to better fit/match the upcoming changes in HA 2026.11

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

Same procedure as every month

This happens almost every month - a new HA release generates:

blablabla... This will stop working in Home Assistant 2027.8.0, please create a bug report blablabla

Please update to this release to get rid of this message.

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

Adjust Senec local _icmax value range

3'rd try to fix the max-bound issue Werner has reported...

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

Adjust Senec local _icmax value range

2'nd try to fix the max-bound issue Werner has reported...

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

(De)Synchronized ICMAX Local->WebAPI

In #234 it has been requested to decouple the SenecLocal and SenecOnline ic_max values - since I do not have a Senec Wallbox I can't really judge, if this is reasonable or not - but since it was requested by @WernerSlabon I have full confidence, that this is valid.

Also with this release I have 'tried' to fix the max-bound issue Werner has also reported...

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA

SENEC.Connect added Wallbox support

Lousy weather in NRW this weekend - so I have added the missing wallbox support for the SENEC.Connect implementation of this integration... Of course there had been some surprised during the implementation: again the API just provide a list of objects that must be iterated in order to get the information actually what wallbox is at which index. Well since I don't have a Senec x4 System I'll keep my fingers crossed, that this will work.

Please consider supporting me

Thanks to those who have already supported me in the past weeks or month that is highly appreciated! To the other users: I am putting quite an amount of energy and passion into this integration. Perhaps you could give yourself a little push (if you can afford it) and become a sponsor.

If you haven't starred this integration in Github yet - please do so - TIA