[Bug]: "ZCS Azzurro inverter reporting spikes in consumption/battery/production values that revolve around the magic 65535 integer
#1229
Comments
|
Same issue with Solax. Since 2025.1.8. Downgraded and its fine again. |
|
@manuelmrmorgado yep, had to downgrade to Looking at the diffs: 2025.01.6...2025.01.8 I think the biggest offender may be The diff of PyModbus is massive though: pymodbus-dev/pymodbus@v3.7.4...v3.8.3 |
|
Same Issue with Sofar
|
|
SolaX X3 G4 here. I have spikes all over the place. Spikes are short (around 10 Seconds), one polling interval maybe. |
|
Same here for me with Solax X3 G4. Downgrade back to 2025.1.6 solves the Issue |
|
No problems with the magic number but sometimes the total generated power, lets say 2000kWh in the inverters lifetime, is read as 0 and then back to normal. So Homeassistant has these values |
|
Yeah, in cases where a homeassistant-solax-modbus/custom_components/solax_modbus/plugin_sofar.py Lines 2962 to 2973 in 84a6b1b I wonder if this is roughly where this "unavailable" should be emitted: Does anyone know the correct SQL manipulation to reset these metrics? I saw that metrics store a |
That is the solution. In the longer term it's no longer recommended to use the LSE-3 due to the rising number of issues. See also the Sofar FAQ. Please consider switching to an RS485 Adaptor. I switched to RS485 last weekend and no issues anymore with the latest integration version. Updating values is possible without wrong error return codes and happens in a few seconds instead of minutes. |
@cschlipf do you mean that you switched to a different hardware? If so, which? |
|
I am using the Waveshare USB Adaptor. In my case this is directly connected to EVCC and EVCC is providing a ModBus proxy for Home Assistant to connect to via ModBus TCP. See also the Installation Guide. |
|
I don't know if this #1238 (comment) will help users with the LSE-3 or not? But I have released 2025.02.1 which changes the timeout to 10. In case anyone is unsure on how to edit the files locally. |
|
@wills106 I can try jumping between I don't see any code (in the diff) that renders a timeout into |
|
Nope, we're back at having spikes:
Reverting to I really believe a failed read should not emit a numeric value (current behaviour) |
|
Could you share the equivalent of this: On the SolaX X3 Mic inverters we are using ignore read error on some problematic registers. homeassistant-solax-modbus/custom_components/solax_modbus/plugin_solax.py Lines 6815 to 6829 in 6779c25 I want to try this on Sofar, but I need to see how the blocks are formed. |
I found these relevant-ish logs from the 07:00~08:00 local time, where the readings where all brokenHere's the block you asked for instead, @wills106 - this probably leaks my serial number, but not that worried :D |
Is it just these you get spikes on, or random each time? |
|
It looks like there are:
Here's the list of what's affected/when:
This is what it looks like, graphed:
|
|
Another data point: I just checked, and I still had the Azzurro ZCS integration loaded. The Azzurro ZCS integration shows these value changes: I'm now wondering:
That said, it now at least seems to be that "unavailable" != "wrong reading": different problems, according to this timeline. |
The read errors are coming from the same block of registers "Electric Power (0x0680-0x06BF)" Could you try 2025.02.2b1 |
|
Giving it a spin, thanks in advance! |
|
I sadly have to report that Today's situation, after letting
There was a spike that lasted few seconds around
These values all jumped together: there is some sort of correlation. If I "zoom out" over the entire day, I can see how many other stats tend to have these momentary jumps:
It should suffice to say that my inverter certainly didn't reach 13872°C 😅 The jumps in statistics seem to affect every numeric measurement. During the period of 09:30~17:30 of 2025-02-24 (while the system was rolled back to |
|
Meanwhile, back to Looking at the diff since then ( 2025.01.6...2025.02.2b1 ) I see a couple of relevant details: -from pymodbus.payload import BinaryPayloadBuilder, BinaryPayloadDecoder, Endian
+from .payload import BinaryPayloadBuilder, BinaryPayloadDecoder, EndianIs that a typo, or some Pythonism that I am not familiar with?
PyModbus errors in upstream?I've also skimmed pymodbus-dev/pymodbus@v3.7.4...v3.8.3 , and the diff is too big for me to understand without domain knowledge: I'm wondering if there's a sensible way to check intermediate versions on my setup? For example, trying Alternatively, I'm pinging @janiversen just to see if the graphs / blips in the comment above say anything to them (they might already have seen issues like this, so it's worth asking, before running blindly) |
|
Why are you pinging me ? I have nothing to do with that component, nor an opinion on what HA does or not does. |
|
Hey @janiversen: sorry, it was really just for an opinion on "spiky values": did pymodbus become more reactive to quick reactive/spiky changes? Is that something you've observed in pymodbus in general? Is that normal / something that should be handled downstream? That's really all I wanted to ask, sorry: feel free to unsubscribe/ignore. |
|
Pymodbus works, just run our test suite, but to me it seems like a number of integrations (or maybe only modbus) was upgraded without adapting the code. Pymodbus 3.7 -> 3.8 have at least one change that should have been marked as a breaking change in HA. |
|
If there is a problem in pymodbus, please open an issue there, with a pymodbus debug log, showing the problem, otherwise it is impossible to help....but please remember pymodbus is not the only item in the chain if e.g. the component using pymodbus do not do proper error handling you might have random values. |
|
What are you current read interval settings? Please list all services that access the LSE-3 at the same time |
Yeah, I poked to get some potential wisdom on known/seen behaviors: not assuming there's an issue there, but rather something that people have already "seen", and being a maintainer of very popular OSS projects myself, that sometimes leads to "yeah, this is common case XYZ" outcomes :-)
The component is configured as such (via GUI):
No other services: everything else was shut down. |
|
Now that's already a lot of load for the LSE-3. There is a reason, why the polling intervals are split up like this. Unless you have a specific reason, why you need this, reduce the polling interval to 15/30/60. If that does not help, try again at 30/60/120. Should be good enough for most typical automations. |
|
Giving it a shot, thanks, but beware that timeouts don't seem to be in any logs 🤔 Note: used defaults, so no major reason for these values. |
I have added in I have also increased the timeout form 10 to 15.
payload decoder has been temporary moved into this custom component while we look at implementing |
|
@wills106 deploying your changes and giving it a spin: likely having more info in 12~16h. Thanks in advance for the quick iterations you are cranking out here! |
|
I report an additional problem. I have some automations that manipulate the values: It happened twice that the passive_mode_grid_power value is set to 65535 instead of 0, probably in conjunction with a spike like those reported (the automation was triggered when the storage SOC shows a spike at 0, at 2:36 this morning). I'm trying to install 2025.02.2b2. By(t)e |
|
@wills106 reporting from my installation: zero spikes of any kind since my last comment 20h ago. Everything is running smooth as butter 💪 Below are just some details that can help further, but I think Log findings since
|
|
Thanks @Ocramius for the feedback. Even though you have these errors in your log, does the Integration still carry on functioning? |
Just released 2025.02.2b3 which should correct that error. |
Yes, it works :-)
Seems not: I have regular data flowing through.
Upgrading now / letting it run for another night 🚀 EDIT: also, ko-fi delivered ☕ |
|
Note that ist normal with the LSE-3. That is because of the wrong return codes that it returns. |
Hopefully now I have some form of
I also want to relook into the amount of |
|
One more thing: the message only comes as response to write requests. Note that if you have enabled battery read out, then this is involving a write request to send the battery ID to the inverter. @Ocramius - did you enable battery red out? Note that because of this problem with the LSE-3 battery read out does not work with the LSE-3. |
|
Nope, battery readout is disabled 😁 |
|
Current status: everything operating normally. No spikes in any statistics. Logs do show a lot of small crashes, roughly every 2 minutes (current long polling interval): The above are just examples taken from various addresses read failures. I'd say (and it's just intuition, not proof) that the LSE-3 is really struggling, whenever a batch of reads comes in. I've set the read offsets to That said, IMO we can close here, and we can move such a discussion to a new issue. |
|
Hopefully when we look at reducing the amount of This is also why I was hesitant about adding in the option to poll registers at different speeds. As then can fragment read groups as well. |
|
Closing here meanwhile: let's call this "done" with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Since 2025-01-14, which corresponds to the #1222 fix, I have numerous spikes in reported power consumption values.
Screenshots below mostly show the symptom in the HA dashboard.
I've since adjusted these spikes via manual statistics adjustments in HA, but I noticed that these spikes seem to suspiciously revolve around the magic
65536(16 bit max integer) value.I've observed such spikes also before 2025.01.8, but I'm wondering what may have changed, that might have caused an increase in these outliers.
I'm wondering how I may help further, with debugging such issues 🤔
Integration Version
2025.01.8
Homeassistant core version
2025.1.2
Inverter brand
ZCS Azzurro (sofar)
Plugin used
EDIT: unsure about correct value: configured as
"sofar" via GUI under/config/integrations/integration/solax_modbus`Serial prefix
ZM2ES060
Connection Method
TCP/Ethernet via LSE-3 LAN stick Logger
Detailed Error Log
Additional context
No response
The text was updated successfully, but these errors were encountered: