System state De-rating Running

[mtrekker]

I did deploy succesfully Sungrow-SHx-Inverter-Modbus-Home-Assistant with SH15T over WiNet Ethernet port. 2 days later I noticed that system state is "De-rating Running" and no export was taking place. I also have deployed WiNet Extractor with Mosquitto broker, so basically 2 different Sungrow clients running at the same time.

Any idea what does De-rating mean ?

[mtrekker]

Also, should I be worried about these errors ?

2024-10-29 12:00:22.132 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_charging_start_power_input_slider_update] sungrow inverter update battery charging start power input slider update: Error executing script. Invalid data for call_service at pos 1: Invalid value for input_number.set_sg_battery_charging_start_power: 655350.0 (range 0.0 - 1000.0)
2024-10-29 12:00:22.133 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_charging_start_power_input_slider_update] Error while executing automation automation.sungrow_inverter_update_battery_charging_start_power_input_slider_update: Invalid value for input_number.set_sg_battery_charging_start_power: 655350.0 (range 0.0 - 1000.0)

2024-10-29 12:00:10.301 ERROR (MainThread) [homeassistant.components.modbus.modbus] Pymodbus: SungrowSHx: Error: device: 1 address: 5740 -> pymodbus returned isError True
2024-10-29 12:00:10.404 ERROR (MainThread) [homeassistant.components.modbus.modbus] Pymodbus: SungrowSHx: Error: device: 1 address: 12999 -> pymodbus returned isError True

[Gnarfoz]

• Battery forced charge discharge command: stop
• EMS mode: self-consumption
• Export power limit mode: "it depends"
• Set export power limit: Unless your grid connection says otherwise 15 kW seems correct.
• Set forced charge discharge power: something "sane" like 1000, probably. It only does anything if force command is "charge" or "discharge" and "EMS mode" is "forced mode". You should change the maximum value in the YAML file to 11520 (maximum continuous charge/discharge power of SBR192. See https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant/blob/main/modbus_sungrow.yaml#L2476 + the SBR192 data sheet).
• Set max battery charge power: Probably something conservative like 3000 W? You should set the maximum of this to 11520. as well, see https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant/blob/main/modbus_sungrow.yaml#L2482.
• Set max battery discharge power: Definitely lower this to at most 11520 W. And adjust the maximum in the YAML file at https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant/blob/main/modbus_sungrow.yaml#L2488.
• Set max SoC: unless you have a very specific reason, set this to 100%. Setting it to anything lower will prevent battery balancing.
• Set min SoC: 5% is OK.
• Set reserved SoC for backup: 5% is OK if you don't want to keep a reserve for power outages. Otherwise, adjust per your needs. Sungrow recommends 20% in summer, 50% in winter, but I personally find that excessive. Depends on the size of your PV array and how often and how long you have power outages.

[Gnarfoz]

I'm not sure how you ended up with battery charging start power and battery discharging start power at 655350 but those should also be something low like 0 - 100 W. Depends on how power you want to "waste" to accommodate the inertia/slowness of the EMS to adapt to swings in load/production.
Or that's a display issue of some kind. 655350 ((2^16-1) * 10) seems suspicious.

[mtrekker]

Thanks @Gnarfoz

I am still getting errors below, sensor battery_charging_start_power is reporting ~655,350 and I am not sure about correct min/max settings.

I would like to charge battery on demand via HA integration but none of inputs worked for me. How to achieve forced battery charging ?

set_sg_battery_charging_start_power
set_sg_battery_discharging_start_power

2024-10-30 07:57:31.039 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_charging_start_power_input_slider_update] sungrow inverter update battery charging start power input slider update: Error executing script. Invalid data for call_service at pos 1: Invalid value for input_number.set_sg_battery_charging_start_power: 655350.0 (range 0.0 - 1000.0)
2024-10-30 07:57:31.040 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_charging_start_power_input_slider_update] Error while executing automation automation.sungrow_inverter_update_battery_charging_start_power_input_slider_update: Invalid value for input_number.set_sg_battery_charging_start_power: 655350.0 (range 0.0 - 1000.0)
2024-10-30 07:57:31.294 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_discharging_start_power_input_slider_update] sungrow inverter update battery discharging start power input slider update: Error executing script. Invalid data for call_service at pos 1: Invalid value for input_number.set_sg_battery_discharging_start_power: 655350.0 (range 0.0 - 1000.0)
2024-10-30 07:57:31.295 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_discharging_start_power_input_slider_update] Error while executing automation automation.sungrow_inverter_update_battery_discharging_start_power_input_slider_update: Invalid value for input_number.set_sg_battery_discharging_start_power: 655350.0 (range 0.0 - 1000.0)

[mtrekker]

Forced charging question is resolved by reviewing documentation once more and adjusting erroneous thesholds :)

But the question of charging_start_power/discharging_start_power remains, I did modify YAML and set it to 655350. After that I am able to use forced charging, prior to that the slider reverted itself to "Self-consumption mode" from "Forced mode".

[Gnarfoz]

You could try setting those values to sane values via iSolarCloud or the local WiNet-S interface.

[mtrekker]

Would like to get the addresss 12999 (System state) related error resolved. Is it model related error and current modbus_sungrow.yaml is not simply able to handle it ?

2024-11-05 09:02:06.658 ERROR (MainThread) [homeassistant.components.modbus.modbus] Pymodbus: SungrowSHx: Error: device: 1 address: 12999 -> pymodbus returned isError True

[Gnarfoz]

The interpretation of the values in register 13000 (address 12999) would happen in modbus_sungrow.yaml, in the template sensor defined at:

Sungrow-SHx-Inverter-Modbus-Home-Assistant/modbus_sungrow.yaml

Line 2024 in 4cc83ca

- name: Sungrow inverter state

And it has a fallback to cover any unknown states.

However, your error message is from pymodbus itself, which is what powers the Home Assistant Modbus integration, for which this project is a configuration file. If pymodbus says there's an error, that means your inverter is not responding or responding with an error. See also
https://github.com/home-assistant/core/blob/3858400a6f89f04942bb859bb7437a775b0a9f0f/homeassistant/components/modbus/modbus.py#L396

What does your installer say about this, anyway?
Derating means you're probably exceeding some limit. Either from the grid side (i.e. your energy company might be lowering your system's output, if that's set up that way), or perhaps your panels are way oversized?

[mtrekker]

Panels are ~18kWh, inverter is configured to support 15kWp. Since the state of Derating became present just after I deployed "Sungrow-SHx-Inverter-Modbus" and it resolved after I adjusted some of the limits related to errors seen in the home-assistant.log then could it be the cause ?

I am not seeing anywhere that the production could have hit the PV or grid limits.

[Gnarfoz]

If it's not the inverter itself doing it (other factors might be bad ambient conditions like temperature, humidity?), and your inverter is not set up to be limited on demand by your power company / grid operator, then you probably need professional support.
Also, "Dispatch running" should probably never appear in normal circumstances unless your system is being controlled externally by your grid operator.
Can you match any of these statuses to things displayed in iSolarCloud?

Less likely: You have an inverter that reports wildly different operating states than others'. You could check with something like mbpoll, but I have no reason to assume that would yield different results.

Even less likely: This project / configuration changing your inverter's settings on its own. I just don't see how.

[mtrekker]

State was changed to De-Rating again. All I did was I turned EMS mode to self-consumption and turned off forced charging. Tried to restart inverter (set_sg_inverter_run_mode=shutdown/enabled) but the state didn't change to "Dispatch Running". This is the default state to my knowledge.

[Gnarfoz]

The default would just be "running".

[mtrekker]

Probably will need to contact official support then. "Dispatch Running" was the initial state when the inverter was set up and since then it has been so.

State descriptions from iSolarCloud:

[Wolkenstuermer]

Just have the same issue, since i've upgraded (and uncommented on my side) the whole EMS Code from yaml.

[Gnarfoz]

Upgraded what, the file from this project or your inverter? What did you uncomment? The parts related to the EMS registers in this file are not commented out by default.

[mtrekker]

Connected via modpoll and read back concerned registers causing integration errors with my SH15T-V11. There are 2 battery charging/discharging start power errors mentioned earlier: #393 (comment)

Does modboll returned register values indicate that modbus_sungrow.yaml needs to be adjusted ? Could it be causing the Derating state ?

Sungrow-SHx-Inverter-Modbus-Home-Assistant/modbus_sungrow.yaml

Line 3023 in 4cc83ca

value: "{{ states('input_number.set_sg_battery_charging_start_power') |float /10 |int}}"

Sungrow-SHx-Inverter-Modbus-Home-Assistant/modbus_sungrow.yaml

Line 3056 in 4cc83ca

value: "{{ states('input_number.set_sg_battery_discharging_start_power') |float /10 | int}}"

modpoll -r 33148 -c 2 -u -m tcp 192.168.168.10

-- Polling slave... (Ctrl-C to stop)
[33148]: 1060
[33149]: 65535

[mtrekker]

The state "Derating running" seems to be related to inverter's Feed-In Limitation settings.

Feed-in Limitation = disabled
Feed-in Limitation for Each Phase = enabled
Feed-in Limitation Value value = 0

As soon as I enabled Feed-In Limitation (which disabled limitation for each phase) and set Feed-In limitation value to 15 then the state does not become "Derating running" any more. The Feed-In settings must have changed when SG support was troubleshooting Smartmeter inconsistency. My grid numbers do not match with Smartmeter numbers.

[apassi]

@Gnarfoz Thank you, actually i found already a way to adjust the feed-in setting with local access, and made some bash script to execute the requests with websocket and curl. So there is no need for the cloud. :)

[Gnarfoz]

Interesting! Would you be open to share your scripts as a Gist or something?

[apassi]

np, my script is now here:
https://github.com/apassi/sg-power-limit

That is very raw POC script, which uses the bash, curl, jq, and the login (to aquire the token) needs to made by the websocket, the uwsc and the expect applications.
If there is another admin accounts during the execution, those are kicked out, it seems that only single admin account is allowed to be logged in.

One what i didnt found from the winet-s UI, is the installed power plant size. That i had to define with android app with local access. The script will then set the feedin definition of the percent of this power plant definition. For example if the plant is 1kw, the 10% of it is 100w.
I also found, that country setting of the device will change the menu items. Maby this could affect.

[Gnarfoz]

BTW, the WiNet-S includes a facility to record the Modbus traffic on its RS485 interface. With a script like that, it should be pretty easy (well, relatively, at least) to figure out which registers are changed when you run your script. According to the Modbus register spec, it should be holding register 31222:

https://github.com/Gnarfoz/Sungrow-Inverter/blob/main/Modbus%20Information/TI_20240924_Communication%20Protocol%20of%20Residential%20Hybrid%20Inverter-V1.1.5.pdf

[apassi]

I made some very quick 10min. test with RS485, but based on some documentation, the WiNet-S cannot be connected when the RS485 is connected, and the RS485 was totally silent. I didnt give it another change.

I found the register uses the register 31222, but i think there is another register where the same effect can made. It just uses some other value type. If either of these two is changed, the change will reflect and change the value both of them.

The 31222 register was found from the winet-s web ui, from the websocket traffic. I tried to update the value throught websocket, like the browser does it, but at some reason that didnt never work. I think the reason could be the uwsc application and some websocket framing, incompatibility, but then i found the setParam http post request from some other project from internet, and that was able to make to update.

[mtrekker]

Now I would like to resolve 2 sensors. Could it be that WiNet-S2 does not produce metrics for LAN ? Or could it be the modbus component ?

I was not able to find the source that produces these sensors.

1. sensor.battery_charging_start_power
2. sensor.battery_discharging_start_power

[mtrekker]

Tried local access also and no such settings exist.

But home-assistant.log has errors related to applying slider values.

2024-11-13 17:38:08.824 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_charging_start_power_input_slider_update] sungrow inverter update battery charging start power input slider update: Error executing script. Invalid data for call_service at pos 1: expected float for dictionary value @ data['value']
2024-11-13 17:38:08.824 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_charging_start_power_input_slider_update] Error while executing automation automation.sungrow_inverter_update_battery_charging_start_power_input_slider_update: expected float for dictionary value @ data['value']
2024-11-13 17:38:08.827 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_discharging_start_power_input_slider_update] sungrow inverter update battery discharging start power input slider update: Error executing script. Invalid data for call_service at pos 1: expected float for dictionary value @ data['value']
2024-11-13 17:38:08.828 ERROR (MainThread) [homeassistant.components.automation.sungrow_inverter_update_battery_discharging_start_power_input_slider_update] Error while executing automation automation.sungrow_inverter_update_battery_discharging_start_power_input_slider_update: expected float for dictionary value @ data['value']

[mtrekker]

Concerning register 33148 was added to Communication Protocol ver 1.1.0. But it looks like there is no register 33149 published. Could it be that handling register 33148 needs to be adjusted ?

Communication Protocol

[Gnarfoz]

Yes, it's an undocumented register, as it says right above the sensor:

Sungrow-SHx-Inverter-Modbus-Home-Assistant/modbus_sungrow.yaml

Line 1630 in 4cc83ca

#undocumented sensor (reverse engineered by some guys of photovoltaikforum.com and forum.iobroker.net )

I don't think adjustments are necessary, since your mbpoll clearly indicates that the inverter reports 0xFFFF / 65535.
As I said in my previous comment, your inverter firmware does not have this feature, that's why it does not show up in iSolarCloud, either.
Check in iSolarCloud if there's a new version available.

P.S.: Not that it makes a difference for this topic, but there's a slightly more up to date version of the Modbus register spec here: https://github.com/Gnarfoz/Sungrow-Inverter/blob/main/Modbus%20Information/TI_20240924_Communication%20Protocol%20of%20Residential%20Hybrid%20Inverter-V1.1.5.pdf

[mtrekker]

Latest FW update had no impact on battery charging start power. This register is still read-only. Nor did this setting became available on iSolarCloud.

2024-11-15 08:41:23.680 ERROR (MainThread) [homeassistant.components.modbus.modbus] Pymodbus: SungrowSHx: Error: device: 1 address: 33148 -> Exception Response(134, 6, SlaveFailure)

FW update caused forced charge discharge power to become 0. This setting is also not available on iSolarCloud. This is pretty cumbersome because forced charging would not work after update unless I pay attention to all known involved settings...

[Gnarfoz]

This register is still read-only. Nor did this setting became available on iSolarCloud.

That sounds more like this register does not exist for your device, then. Perhaps it will be added later.