total_dc_power over a million watts

[TomMarg]

Using the latest version everything works perfect but every once in a while the total_dc_power is listed as over a million watts. Typically it happens on cloudy days when the sun comes out but I do not yet know how to ignore those values but they make the charts unreadable.

wanted to report this behavior.

Model: SH-10.RT v112]

• The inverter is connected via (mark one)

  • LAN (internal port)
  • [] WiNet-S (LAN)
  • [] WiNet-S (WLAN)

• Are you using a Modbus Proxy (mark one)

  • [] yes
  • [] no
  • I don't know what that is

Home Assistant version:

• Version: 2024.4.4

modbus_sungrow.yaml:

• Version/ time stamp : [e.g. 2023-09-08] (see header of the file)
• I ensured to use the most recent version

** Inverter Firmware Status:**

• [] I made sure that the newest firmware is installed via the installers account

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[Gnarfoz]

Some forums suggest it's just a communication issue, but I've also only started noticing this recently. I'm not on the most recent YAML file, so I'd say it is not directly related to this project itself. Possibly Home Assistant related. Or just bad luck and badly shielded network cables. 🫤

[Skrotax]

Having the same issues on Total dc power, Load power and Meter active power.
MPTT1&2 power and Meter A-B-C active power is showing normal.

[Gnarfoz]

I've resorted to deleting such excessive values from the database, but it's pretty clear that it's not just bad cables. It's also quite unlikely to be this project, because it "just" uses the default Home Assistant Modbus integration to do the actual work.
Total DC power and load power are straight Modbus sensors with no helpers/templates in between. Meter active power uses a template sensor to filter out the edge case when the power grid is not available.

I wonder how it could be possible that this is related to the change to async library calls in the Modbus integration, but those changes fit the timeline.

[Skrotax]

I just added a max_value to Total DC sensor (I have a SH8.0RT - 8000W) in modbus_sungrow.yaml.
Not a solution to the issue, but history graph will hopefully be readeable.

[Gnarfoz]

Yeah, it could help avoid polluting the statistics with wrong data. Too bad max_value replaces the excessive value with the max_value instead of just omitting it, that'd be even cleaner...

If you have a battery and more DC power installed than your inverter's rated AC limit (e.g. SH10RT with 15 kWp), you should set such limits to the higher number. When there's free capacity in the battery, the inverter will send the DC directly to the battery, increasing "total DC power" above the AC limit.

I ran a query in the database to check which entities have shown the problem - I'm not sure there's any pattern:
sensor.total_active_power
sensor.reactive_power
sensor.load_power
sensor.meter_active_power_raw
sensor.total_direct_energy_consumption
sensor.total_dc_power

Limits on a "total energy" value are going to have to be preeetty high...

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[RafAustralia]

could you please post your register code for that part and I will have a look, I do not want to say what I have in mind but I suspect it is a coding error, not because of you or anyone other than sungrow making a mess of their protocol. No promises but I can try... and by the way the number you are seeing means the register is MAXING OUT, it is not a random number

cheers

[Gnarfoz]

The sensors are very boring, they are unmodified from what's in the repo: https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant/blob/main/modbus_sungrow.yaml

This only started being visible when Home Assistant's pymodbus package was switched to async library calls, leading to an increase in "temporal resolution" of about 10x -- before, these errors were simply hidden because the sync approach was slower.
It's an issue with the device itself. See home-assistant/core#119649

Also, it's not maxing out (it's none of the various 2³², 2³²-1, 2³¹, etc. numbers). The exact numbers vary, and they're just garbage.
The solution native to Home Assistant would probably be to use an outlier filter sensor on top of these sensors but I haven't tried it yet. I'm still living with the min_value / max_value "solution". It still pollutes the data, but less than without it.

[RafAustralia]

Hi Christian Firstly – I am just a guy who has no electrical engineering background, nor code education either so I am nowhere near you or mkaiser’s level of knowledge… … You will have to forgive me some things which may not make sense to you at times… I just started doing this by accident… I just make things work and share if they do… see what you guys think… So I thought that one way to tackle these rubbish translations would be to look at the way these get sent and received via various devices. I have read a bit about ins and outs of modicon convention and took interest in that part. At times it could down to one device swapping “pairs” of code around (swap:word or swap:byte or both) and I have found some registers values came good after playing with these a bit. Again this is just something I have toyed with a bit and hence why I wanted to see which register that was to compare with mine… I am slowly merging the latest mkaiser code into mine as we continue to chat, then I will test it , and then I will apply it to my second inverter (dual hybrid here) 😊

[Gnarfoz]

I applaud your motivation! :-) Don't be discouraged if some things turn into a bit of a discussion... it's rare that one participant already has all the correct answers at the beginning.

[RafAustralia]

Hey Christian. Not discouraged at all. Love this evolution, after all more we help each other more we get to work properly. My journey with sungrow was quite spontaneous and intense to date but I have to say they have been extremely kind and patient. Beyond any expectations. Just the tech data I got was 1000x any manufacturers duty to a customer. And we became good friends in a process. Btw. Ive added mkaiser on discord and happy if u wish to say hi, if u r on there too. My id : raf_t_aud Sometimes its easier to demonstrate things there as I truly suck with posting on github…. Hahaha. This place is complex. Takes a while to get used to. Message ID: ***@***.***>

[Gnarfoz]

I think using the Github website instead of posting via email would make it a bit easier to work with. :-)

[RafAustralia]

Agreed totally. Will get there eventually (maybe not tonight). Need to recharge batteries. Lol Message ID: ***@***.***>

[Mercur85]

Hello together,

anything new here?
I have a Sungrow SH20T installed and just set up HA recently.
Yesterday I started with the Modbus integration (I used the integration file from mKaiser - thanks to him - and added some thingks like the MPP3) through the WiNet S2 Dongle. I knew already that there are some issues with that like not seeing the MPPT3 values. I just wanted to give it a try as I have the Firmware version .27 installed, which is to my knowledge not officially released (but the sungrow support installed it on my inverter). Result is that MPPT3 was still not available. :(

Anyhow I had already order an RS485 to ETH converter and installed it today morning.
Unfortunately I do see now at least one odd number, which might be related to this topic.

After the switch the sensor.total_direct_energy_consumption has changed from 859,3 kWh to 429.490.176,0 kWh. Is this a know issue?

By the way the value is still showing correctly in the iSolarCloud. :)

[Gnarfoz]

It's not something this package can fix, the inverter is actually reporting these crazy values.
However, I'm not sure if this is the same problem. At least, I hadn't seen it on statistics sensors like that one before.

The only thing this package could do would be to wrap everything in filter sensors and use the outlier filter?
Sadly, the range filter has the same problem as min_value and max_value it clamps the bad value to the limit instead of discarding the bad value altogether.

[Tabis83]

After months of running stable and reliable, suddenly I see Gigawatts of load in Home Assistant.

Home Assistant 2024.8.0
2x Sungrow Sh10rt-20
1x Sungrow 9.6kwh Battery

The modbus yaml has not been changed since August.

Unfortunately it's not just short peaks, it constantly reads these extreme values since hours.

I am wondering if Sungrow maybe changed a data type and I got a firmware update... I think I could check the current firmware via the WiFi dongle but I don't know which firmware was installed before.🙈

[bsc76]

After the switch the sensor.total_direct_energy_consumption has changed from 859,3 kWh to 429.490.176,0 kWh. Is this a know issue? !

I have exactly the same issue. Same odd number (Exactly the same number!) and I also use a RS485 converter (waveshare)for my SH20T.
Could you solve the issue somehow?

[RafAustralia]

Hi there.

I do have my mppt3 read correctly and without issues but I do need to make a note here that I do not use winet s2. My gear is connected via logger 1000a (which in itself is hard to make work on HA) but it likely reads differently.

I do know how to “cheat” and get u the mppt3.
it is to install add on called winet extractor.
it operates via mqtt and can deliver many sensors read direct from winet. And better. Cleaner.

It is likely that a lot of your error reads are just rubbish numbers / bad reads by winet’s own inability to translate properly.

Finally if u like u can send me ur modbus file I can see if i can see any errors in it.

Hope that helps

[Gnarfoz]

After the switch the sensor.total_direct_energy_consumption has changed from 859,3 kWh to 429.490.176,0 kWh. Is this a know issue? !

I have exactly the same issue. Same odd number (Exactly the same number!) and I also use a RS485 converter (waveshare)for my SH20T. Could you solve the issue somehow?

The number is actually pretty common - it's 2³¹-1, the maximum value a signed 32-bit integer variable can accommodate. The number is simply "as large as it can be".

Apart from that, I don't think there is much to be done at this point. Someone could try and chase down Sungrow about it, to figure out if they consider it a bug, known behavior, bad cabling, or something else.
Regardless of their answer: it is the inverter reporting these numbers. Not much this integration can do about it. Suggestions have been peppering every Modbus sensor with min_value and max_value parameters, or wrapping all Modbus sensors in outlier filter sensors. You can read about it earlier in this issue's comments.
I've tried both. Min/max values still pollutes the statistics, since the bad values are not eliminated, just capped.
Outlier filter should work (I haven't verified, since I haven't noticed one of these excessive values in a few months now, but I also haven't checked often), however if I understand the documentation correctly, it would require using window_size: 2 which would dramatically slow down Home Assistant startup if outlier filters were to be used for every sensor.

@RafAustralia the MPPT3 issue was solved in a firmware update some time ago. @bsc76 is even using a RS485 adapter, which never had this problem in the first place. So, these are unrelated topics. :-)

[RafAustralia]

@Gnarfoz
Yo Christian. Been a while.

These just popped up in my inbox today directly.
I was just responding to them as they came this morning.

Sorry I was not following previous solutions.

The truth is. I have 2x T (25+15) type inverters and I have just about all of these sensors (except of two I do not use) working without issue hence why I wanted to see the modbus files to compare what I could find to be different and in that way perhaps offer some help.

Raf