intermitent NPU-errors on Senec 2.0

[spamferkel]

I'm experiencing intermittent "NPU-Errors" on my Senec V2.0. In most cases NPU-Error-state last only for a minute. My solar-contractor guessed it's a problem with the communication board and opened a senec-support-ticket.

Here's what they say (german original, english translation at the bottom):

...
wir haben eine technische Überprüfung an der Anlage durchgeführt.
Dabei haben wir festgestellt, dass die Open.API Schnittstelle der Anlage überdurchschnittlich häufig vom Kunden abgefragt wird und dies zu einem sporadischen Ausfall der Netzwerkplatine (NPU) führt. Dieser Kommunikationsausfall der Netzwerkplatine liegt meist nur ca. 5-10min an. Anschließend startet die NPU einen automatischen Neustart der Schnittstelle und löst somit den anstehenden NPU Fehler auf. Während des NPU-Fehlers, wird der Betrieb der Anlage nicht eingestellt. Dieses Verhalten wiederholt sich bei dieser Anlage in sporadischen Zyklen. Ein Hardwaretausch der NPU-Platine würde leider nur temporär helfen, da nicht von einem Hardwaredefekt auszugehen ist.
Wir haben dieses Fehlerbild nun der Embedded-Entwicklungsabteilung übergeben und arbeiten an einer Lösung. Kurzfristig können wir Ihnen bzw. den Kunden leider nur anbieten, die Anfragenmenge der Schnittstelle zu reduzieren bis wir eine Lösung für dieses Verhalten entwickelt haben.
Für eventuelle Rückfragen stehen wir Ihnen gern zur Verfügung. Bitte antworten Sie direkt auf diese Mail. Dankeschön.
...

english translation:

...
We conducted a technical inspection of the system.
We discovered that the system's Open.API ​​interface is being queried by the customer with an above-average frequency, leading to a sporadic failure of the network interface board (NPU). This communication failure on the network interface board usually only lasts about 5-10 minutes. The NPU then automatically restarts the interface, thus resolving the pending NPU error. During the NPU error, the system does not stop operating. This behavior repeats itself in sporadic cycles on this system. Unfortunately, replacing the NPU board would only provide temporary relief, as a hardware defect is not suspected.
We have now submitted this error pattern to the Embedded Development Department and are working on a solution. In the short term, we can unfortunately only offer you or the customer a reduction in the number of interface requests until we have developed a solution for this behavior.
We are happy to answer any questions you may have. Please reply directly to this email. Thank you very much.
...

Are there any suggestions how often we cloud poll the api? My update interval ist set to 5sec. I'm changing it to 10 secs for now and see if that makes a difference...

[marq24]

First of all - I am sorry - for what ever reason I don't received notifications about new Questions...

Interesting reply - since I have a SenecV3 I have nothing comparable... But I assume, also the V2 have an internal webserver, and a own GUI, that you can access in the local network? Right?

What I am curious about - when you open this internal website and open the developer tools of the Browser, you could see (in the Network-tab of the Developertools) how frequent the Build-In WebApplication is making requests (to the lala.cgi)... For my SenecV3 System I can see, that there are every 500-800ms a new request to the lala.cgi... which must be handled by the NPU...

It's the Webbrowser which makes these frequent requests - no internal component - so this must also go through the NPU...

So IMHO when Senec support "speculates" that you have a 3'rd party tool running that generates a overload of the NPU interface, then my reply would be, that you have an "always on" tablet in your living room, which have the build-in web-frontent open - the System MUST be able to handle the load generated by itself.

IMHO having a HA integration running (with update interval >=5 sec) should not generated more load, on the overall system, then having the build-in WebClient open... [again, this statement based on my observation how frequent the WebApp generates requests]...

So when you use BrowserDevTools to see the internal update frequency - and then I suggest, to use a five times "slower" update interval then the Senec local Application is using...

[spamferkel]

Thank you for your answer. You are right about the update frequency. It's even more frequent. I'm seeing requests every 45ms having the webinterface open... Senecs answer is some sort of lame excuse i guess.

[marq24]

So the "next" time you hear such a thing, that you might have external device requesting your SENEC Hardware, then the answer is always OF COURSE I do have a tablet with the Webinterface open 24/7. If a system can't take the load it's creating by itself I would call this "bad design" - aka just crap...

[spamferkel]

btw chaning the update interval to 10 secs made a difference. My HA is not recognizing as much NPU errors, but i guess thats due to the reduced update frequency and the integration is simply missing the moments when the SENEC-lala.cgi is not responsive... :D
ICMP-pings are continuous even between the times when the NPU error is present. I've read in some forum posts that the NPU-error is quite common and becomes more and more frequent as time progresses until the board finally dies.

[bobthebuilder4711]

I feel like the big difference here is that running the main web page means polling 6 values and the integration is always polling everything it can.

Even if you switch to the "Information" tab, you don't have access to information about the individual battery packs or the MPPTs. The V2 doesn't even have its own PV input.

The question is if the load on the NPU can be reduced by polling only those information that one really wants.

If I deactivated the sensor.seneclocal_enfluri_net_power_p1 for example, would the integration stop polling that value?

[marq24]

you might like to create "feature" request ? Basically the integration tries to request only the active entities... but there are for sure areas, where more data is requested, then actually been shown...

But comparing the integration with the "build-in" client it's still that IMHO the web-app is generating 5-10 times more requests then the integration does...

[marq24]

@bobthebuilder4711 - I just did some additional ' research'... here my local WebGUI request constantly this data from the system:

That are 3 requests, that are requested in a constant sequence...

req1_senec = {"PV1": {"POWER_RATIO": "", "POWER_RATIO_L1": "", "POWER_RATIO_L2": "", "POWER_RATIO_L3": "",
                     "MPP_VOL": "", "MPP_CUR": "", "MPP_POWER": "", "MPP_AVAIL": "",
                     "INTERNAL_MD_AVAIL": "", "INTERNAL_MD_MODEL": "", "INTERNAL_MD_VERSION": ""},
             "WIZARD": {"MAC_ADDRESS_BYTES": ""},
             "BAT1OBJ1": {"TEMP1": "", "TEMP2": "", "TEMP3": "", "TEMP4": "", "TEMP5": "", "S": "", "P": "", "Q": "",
                          "SW_VERSION": "", "SW_VERSION2": "", "SW_VERSION3": "", "I_DC": ""},
             "PWR_UNIT": {"POWER_L1": "", "POWER_L2": "", "POWER_L3": ""},
             "BAT1": {"CEI_LIMIT": "", "SPARE_CAPACITY": ""},
             "BMS": {"NR_INSTALLED": ""},
             "WALLBOX": {},
             "GRIDCONFIG": {}
             }

req2_senec = {"PM1OBJ1": {"FREQ": "", "U_AC": "", "I_AC": "", "P_AC": "", "P_TOTAL": ""},
             "PM1OBJ2": {"FREQ": "", "U_AC": "", "I_AC": "", "P_AC": "", "P_TOTAL": ""},
             "ENERGY": {"STAT_STATE": "", "STAT_HOURS_OF_OPERATION": "", "GUI_BAT_DATA_POWER": "",
                        "GUI_BAT_DATA_VOLTAGE": "", "GUI_BAT_DATA_CURRENT": "", "GUI_BAT_DATA_FUEL_CHARGE": "",
                        "GUI_HOUSE_POW": "", "GUI_INVERTER_POWER": "", "STAT_LIMITED_NET_SKEW": ""},
             "SYS_UPDATE": {"NPU_VER": "", "NPU_IMAGE_VERSION": ""}
             }

req3_senec = {"WIZARD": {"GUI_LANG": "", "FEATURECODE_ENTERED": "", "ZEROMODULE": "", "SETUP_NUMBER_WALLBOXES": "",
                        "CONFIG_LOADED": ""},
             "LOG": {"USER_LEVEL": "", "USERNAME": "", "LOG_IN_NOK_COUNT": ""},
             "RTC": {"WEB_TIME": ""},
             "FEATURES": {},
             "BMS": {"WIZARD_STARTDETECTION": "", "WIZARD_CONFDETECTION": "", "WIZARD_RESDETECTION": "",
                     "WIZARD_TIMEOUTDETECTION": "", "WIZARD_FINISHEDDETECTION": ""}, "IPU": {"VERSION": ""}

and here is the default data requested by the latest Version of the integration - once every 5 seconds...

req_integ = {'BAT1': {'SPARE_CAPACITY': ''},
             'ENERGY': {'GUI_BAT_DATA_CURRENT': '', 'GUI_BAT_DATA_FUEL_CHARGE': '', 'GUI_BAT_DATA_POWER': '',
                        'GUI_BAT_DATA_VOLTAGE': '', 'GUI_GRID_POW': '', 'GUI_HOUSE_POW': '', 'GUI_INVERTER_POWER': '',
                        'LI_STORAGE_MODE_RUNNING': '', 'SAFE_CHARGE_RUNNING': '', 'STAT_STATE': '', 'STAT_HOURS_OF_OPERATION': ''},
             'LOG': {'LOG_IN_NOK_COUNT': '', 'USER_LEVEL': ''},
             'PM1OBJ1': {'FREQ': '', 'I_AC': '', 'P_AC': '', 'P_TOTAL': '', 'U_AC': ''},
             'PM1OBJ2': {'FREQ': '', 'I_AC': '', 'P_AC': '', 'P_TOTAL': '', 'U_AC': ''},
             'PV1': {'MPP_CUR': '', 'MPP_POWER': '', 'MPP_VOL': '', 'POWER_RATIO': '', 'POWER_RATIO_L1': '',
                     'POWER_RATIO_L2': '', 'POWER_RATIO_L3': ''},
             'PWR_UNIT': {'POWER_L1': '', 'POWER_L2': '', 'POWER_L3': ''},
             'TEMPMEASURE': {'BATTERY_TEMP': '', 'CASE_TEMP': '', 'MCU_TEMP': ''}}

I don't see, that the integration could cause an extended overload at the Senec System ?!

[marq24]

@spamferkel please update to https://github.com/marq24/ha-senec-v3/releases/tag/2025.7.4 -> hopefully this fix the issue... that finally BMS data will be requested again

[spamferkel]

@marq24 thank you. Amazing work! Fix confirmed.

[spamferkel]

update: it worked directly after updating the integration and restarting HA. Then i went ahead and enabled a few other BMS values (SOH, Current, Voltage and Cycles for Moudles B and C) and it stopped working again...

[marq24]

give it some moments/or another restart... always check, if in the logged query (to the lala.cgi) the 'BMS' is included

[spamferkel]

values came back after re-enabling senec_bms_cell_volt_a1... and values stayed after disabling senec_bms_cell_volt_a1 again.

[bobthebuilder4711]

After almost exactly 2 days with the interval set to 1 second, this is the first time I've seen a gap:

Senec told spamferkel: "This communication failure on the network interface board usually only lasts about 5-10 minutes." So I'm guessing that was such an event.

I'm now going to change the interval to 2 seconds and see where that leads me.

[marq24]

In the past years - since I am working on this integration I have used 5 sec - sometimes with 'NPU-Fehler' - nevertheless I have recently (last Friday) reconfigured my local SENEC to update only every 30 seconds and deactivated the wabapi totally...

Additionally (with the latest release) I have disabled the enfluri & mpp sensors - since I have not used this data anyhow... And even with all these things my SENEC.HomeV3 is not running stable/rely able... I'll get Isolationstest, Selbsttest Fehler, Keine Kommunikation Ladegeraet, Fehler: Ladegeraet, Abschaltung Lithium and other stuff like that - Last NPU-Fehler was at the 11.07.2025...

[bobthebuilder4711]

Our V2.1 is currently in 50% mode and we've already signed the forms to replace it with a V3 with LFP packs. I can only hope that the coming V3 is at least as "reliable" as the current V2.1.

That's why I'm testing these short intervals while I still can. Don't know how fast they're going to make the switch.

But I'm also relying on a fast update interval since I'm controlling another battery and our EV charger based on how much excess goes into the grid and how much the senec is charging. So 30 seconds would be way too far apart. With that high of an interval it also doesn't make sense to use riemann integrals.

and deactivated the wabapi totally...

It was your choice to get in on this wild goose chase with the ever changing App Api. Polling mein-senec.de has been working all that time. The part with the missing data making the numbers jump up and down could have been avoided simply by memorizing the values on the first day of the year (or even month) and then counting only from there. But it also hasn't happened again since I switched back to senecweb2mqtt.

Additionally (with the latest release) I have disabled the enfluri & mpp sensors

I only even switched to your integration because the SSD of my last HA instance died without any backup and I wanted everything to function again fast.

If you're taking out those sensors then I think I will switch on the local polling of my senecweb2mqtt mod again since I need to be able to look at the individual phases every so often to identify problematic devices.

I'll get Isolationstest, Selbsttest Fehler, Keine Kommunikation Ladegeraet, Fehler: Ladegeraet, Abschaltung Lithium

Sounds like you need to force your seller to take back the whole battery and reimburse you if they can't fix that.

[marq24]

But I'm also relying on a fast update interval since I'm controlling another battery and our EV charger based on how much excess goes into the grid and how much the senec is charging. So 30 seconds would be way too far apart. With that high of an interval it also doesn't make sense to use riemann integrals.

I totally agree - that's why I only use the data of the power-meter - since only then I am independent... and in the meantime I have switched over to evcc to do all the things that should be done before sending energy into the grid...

and deactivated the wabapi totally...

It was your choice to get in on this wild goose chase with the ever changing App Api. Polling mein-senec.de has been working all that time. The part with the missing data making the numbers jump up and down could have been avoided simply by memorizing the values on the first day of the year (or even month) and then counting only from there. But it also hasn't happened again since I switched back to senecweb2mqtt.

I don't have any doubt, that mein-senec.de polling works for you - be happy with the situation - at end I just can strongly advice not to make yourself dependent from this data - IMHO it's just a question of time, that SSO will be introduced in the web-portal as well - breaking the current functionality.

Additionally (with the latest release) I have disabled the enfluri & mpp sensors

I only even switched to your integration because the SSD of my last HA instance died without any backup and I wanted everything to function again fast.

If you're taking out those sensors then I think I will switch on the local polling of my senecweb2mqtt mod again since I need to be able to look at the individual phases every so often to identify problematic devices.

Something I really don't understand is, why you are so negative - at least I read this between the lines. I have disabled the enfluri & mpp sensors in my home assistant installation. The only change in the integration is, that once these sensors are disabled this data-section will not be requested from the senec lala.cgi to reduce the load if the data is not consumed anyhow.

I'll get Isolationstest, Selbsttest Fehler, Keine Kommunikation Ladegeraet, Fehler: Ladegeraet, Abschaltung Lithium

Sounds like you need to force your seller to take back the whole battery and reimburse you if they can't fix that.

Funny! - This process is "ongoing" - but quite difficult since I will be ghosted. I only can speculate about the reasons.

[bobthebuilder4711]

I have disabled the enfluri & mpp sensors in my home assistant installation.

Then actually write that. Just to refresh your memory what you wrote up there:

Additionally (with the latest release) I have disabled the enfluri & mpp sensors

How else should I read that other than that you've disabled the enfluri and mpp sensors with the latest release, so for everybody?

Same as with you suggesting in the issues that I should take a closer look into the sources concerning polling mein-senec.de. The way that reads it's suggesting that I should look into it to then present a solution. Why even say that if you don't want a solution when it was clear from my comment right before that that I already have a working solution? I even included a screenshot of the accu import curve within my HA instance...

I wouldn't be "so negative" if you actually wrote in the first place what you then add in bold later.

Apart from that I'm not even negative. I'm merely stating my reasons for what I'm doing.

I'm going to keep the local stuff of the integration running and will see if it really takes 8 days for the NPU to kick the bucket again.

[marq24]

How else should I read that other than that you've disabled the enfluri and mpp sensors with the latest release, so for everybody?

exactly - that's your interpretation (which might be influenced by an overall mindset), that this had been done for everybody... which is obviously not the case. But I also agree, that a simple 'my' instead of 'the' (enfluri & mpp sensors) would had been much simpler to understand - fair point.

Apart from that I'm not even negative. I'm merely stating my reasons for what I'm doing.

nevertheless - let's just press the 'reset/flush' button... at least that's my interpretation from this line

[cliveontoast]

I get the NPU errors every now and again.
I'm polling my senec v2 every 1 second, and it happily works for long periods of time between NPU errors.. say 1 day.. to 2 months between NPU errors. For me, the NPU errors can last 30 minutes or 4 hours.

Usually i turn off the battery at the wall and turn it on again, fixes the problem.

[marq24]

wow - 1 sec that's really really fast - I am using 30 sec here - since for me faster update interval does not have any more/less value - controlling devices with the available PV power are anyhow much slower...