Glitches on energy after NOAH2000 was offline over night

[vandecook]

Used Version: 2.1.0
Homeassistant Addon: Yes
FW Noah2000: 16.15.09.4019

After installing the new firmware Version 16.15.09.4019 on my Naoh2000 I recognise glitches in the montly and yearly energy information sent using MQTT. See picture below.

Following values are effected by glitches

• energy month
• energy year

As an example PV energy month

I guess this happens, when the battery goes online in the morning. It was around 08:00 on 28th Dec. 2025. Logs of some time befor and after are attached.

energy_glitches_251227_2038-251228_0900.zip

Maybe you can see something. Otherwise I have to create a helper sensor, for correct calculation.

BR Roland

[nixo2]

I believe this is related to the new Growatt firmware, not to GroBro itself.
GroBro is essentially only forwarding the data it receives from the device.
It appears that after the battery wakes up in the morning, it needs a certain amount of solar power input before it starts reporting correct values. Until that point, the data seems to be incomplete or inconsistent.
Other users have noticed the same behavior, and this topic is currently being discussed in various PV forums as well.
Therefore, the most appropriate point of contact for this issue would likely be Growatt support, as it seems to be firmware-related behavior on the device side rather than an integration problem within GroBro.

[nixo2]

Side note: I would also recommend masking or anonymizing the serial numbers of the Growatt devices in the screenshots.
These identifiers are device-specific and publicly visible screenshots could potentially be misused.

[vandecook]

thanks. modified. forgot to mask the serials.

On the issue itself. I think there can be implemented an algorithm to indentify such a pattern and discard or replace it with an valid one?

[nixo2]

I would personally consider it problematic to “correct” values that originate directly from the Growatt device.
The correct place to fix this is on the Growatt / firmware side. GroBro’s strength, in my opinion, is providing unmodified, transparent data from the device.
Introducing heuristics to fix or replace “wrong” values in GroBro opens an endless discussion: future firmware versions might introduce new patterns, and GroBro would then have to continuously adapt and guess what is correct.
In this specific case, I also consider the shown data field to be relatively unproblematic, since it corrects itself after a short time.
If needed, I think it’s better that users handle such corrections in their own data processing or visualization layers.
But of course, the final decision is up to the maintainer.

[robertzaage]

In my opinion @nixo2 is right. We should focus on a correct and complete register mapping with support for additional message types. Especially if Growatt continues to introduce changes with new firmware versions.

If someone has the time to develop heuristics for a broken message detection I could imagine an extra option to enable it. But I wouldn’t correct those garbage messages, just drop them.