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)
  • [X] LAN (internal port)
  • [] WiNet-S (LAN)
  • [] WiNet-S (WLAN)

• Are you using a Modbus Proxy (mark one)
  • [] yes
  • [] no
  • [X] 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)
• [x] 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[bot]]

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 https://github.com/home-assistant/core/issues/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.