inverter state incorrect

[Welle007]

Before you create an issue, make sure to update to the current version of modbus_sungrow.yaml

Describe the bug:
The inverter is always in standby modus. When the inverter tries to start it will be imediatly shutdown again.
The values seems to be incorrect from the system_state.
The issue occured since the latest fw update of the inverter. By disableing the modbus integration via unplug ethernet or changing ip of modbus in the secret yaml the inverter works without issues.

Your Sungrow inverter:

• Model: SH10RT-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.12.1

modbus_sungrow.yaml:

• Version/ time stamp : 2024-11-02 (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

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[fzenasni]

Same here, inverter falls back into shutdown since last firmware update and is not generating anything
I disabled the modbus proxy, started inverter from isolarcloud and now it stays on
SH10rt-v112 with sbr096

happy to help if you need logs or testing

[Welle007]

Just recognized that the code has hex values and ha has the dec values within the log.
So something else within the integration shuts down the inverter after it tries to startup. As a result there is no PV generation at all.
As mentioned the system runs fine without the integration.

[TCzerny]

Could you try do deactivate the automations:

• sungrow inverter state
• sungrow inverter enable/ stop input selector update

And try it again ?

Could be that register 13000 holds a different value than expected since the last FW update.

[ecdlguy]

Hi, after disabling

• sungrow inverter state
• sungrow inverter enable/ stop input selector update

the inverter does not shutdown anymore.
cheers, Thorsten

[Gnarfoz]

Could someone who's affected analyze what the inverter reports for input register 13000 during startup, then?
Looks like that must have changed for this to happen.

[fzenasni]

After disabling the two automations i stopped and started the inverter from isolarcloud
This is what I'm seeing in HA :

Not sure how to check the inverter logs via isolarcloud

[Gnarfoz]

I'm still confused how this can happen, @mkaiser.

Automation A (automation_sungrow_inverter_state_input_selector_update) triggers based on the status of sungrow_inverter_state, which is a template sensor that is fed by the "system state" Modbus input register 13000 and updates the input_select set_sg_inverter_run_mode according to the current status.

Automation B (automation_sungrow_inverter_state) triggers based on changes to the input_select set_sg_inverter_run_mode, and sets the holding register 13000 that stops or starts the inverter.

At first glance, this looks like a circular dependency, but it has never been a problem in the past. I had assumed that automation B does not get triggered by automation A's actions, but perhaps that is now the case?
Or the system state register is now available to read earlier than it used to be?

@fzenasni, can you check if the two automations that you disabled actually trigger when the problem occurs?
Go to Settings > Automations > find and click on the automation > click on Traces > There should be a dropdown at the top.

[TCzerny]

It seems that the 13000 registers sends/holds the value "shutdown" as a initial value during startup (like a placeholder) but the inverter is actually already in a different mode. The automation A will then trigger the update of the input_selector -> which then sends the shutdown command through modbus.

Food for thoughts....
I think the automation B should only send a modbus command if the sungor_inverter_state (13000) is different to what automation B would set... Then the automation B will do nothing even if the inverter is controlled through isolarcloud or anything else outside HA. A little condition in the automation B should do it.

[fzenasni]

I re-enabled the automations, and first stopped and started the inverter from HA, and it stayed on
Did the same think from isolarcloud and it stayed on, so no iterferrance from the automations, it seems !
Will follow up on the status of the inverter tomorrow

[mkaiser]

Thank you all for the good debugging so far.

One more thing comes into my mind is timing:

If the inverter switches its states, it will take a while (the set time interval) for the modbus register "system state" to be updated. In combination with the circular automations, things may break.

But on the other hand, the input selector is only updated via Automation A to "Shutdown", when the inverter_state is 'Stop' or 'Shutdown'. See here

There was a theory of fwittenfeld some threads ago (which I could find again), that the polling of the register while changing the running state causes problems. If this is the case, there won't be any real solution except waiting for sungrow to fix things and update their documentation.

Btw. does anybody have a updated register description? My latest is TI_20240924_Communication Protocol of Residential Hybrid Inverter-V1.1.5.pdf

@Gnarfoz: I have not been very active here lately. Thank you especially for your involvement here and answering so many questions! I really appreciate this! :)

[Gnarfoz]

Happy to help!

I don't know if there is a more recent register description. I got that one from Sungrow on 2024-10-12, and the file is dated 2024-09-24. Just like change logs for the actual firmware versions, Sungrow is rather silent about publicly documenting these technical things. It's all "need to know", "contact support", "attend a training", ... pretty annoying. At least the information is obtainable at all. Their latest stroke of genius is having Github nuke https://github.com/sungrow-firmware/firmware. 👎

There was a theory of fwittenfeld some threads ago (which I could find again), that the polling of the register while changing the running state causes problems. If this is the case, there won't be any real solution except waiting for sungrow to fix things and update their documentation.

As I understand it, the sequence is as follows:

1. Automation B (automation_sungrow_inverter_state_input_selector_update) starts due to sensor.sungrow_inverter_state (fed by sensor.system_state, which represents input register 13000) changing from any state to any state (the trigger does not specify).
2. The input_select.select_option action is executed for input_select.set_sg_inverter_run_mode. Based on the current state of sensor.sungrow_inverter_state at the time the template in the data section of the action is evaluated, the input_select is either set to Shutdown or Enabled. (BTW, that seems like it would result in the input_select being set to Enabled unnecessarily very often.)
3. The change to input_select.set_sg_inverter_run_mode's state triggers automation A (automation_sungrow_inverter_state). Its trigger also has no further conditions and will probably be triggered unnecessarily a lot.
4. Automation A only checks if input_select.set_sg_inverter_run_mode is set to Enabled and if yes, writes 0xCF (start) to holding register 13000. If not, it writes 0xCE (stop) to holding register 13000.

I don't even see a circular dependency here, since the original input is the input register 13000, while the ultimate output is holding register 13000. These are different things. Also, only automation B (indirectly) checks if the input register has changed, not how. It always runs its action, even if it's pointless. Similar for automation A, it feeds off the thing automation B manipulates, and always writes to the Modbus register, even if it's pointless.
I don't see how a timing issue / race condition would arise here, but that's the tricky bit about them: they're not as obvious as one would like... 😁

Leaving the big "why is this happening" question unanswered, I would nonetheless suggest to eliminate doing unnecessary things. In most cases, if not all, it should be possible to first confirm what we're about to do (Modbus write, select_option, etc.) would actually change something. Trigger IDs are probably worth looking at for this.

[fzenasni]

Had the issue again today

inverter state changes

as i understand it the automation can't handle the value 32768 ?

Sorry for the dutch logs

[Gnarfoz]

32768 is 0x8000 and is already handled by

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

Lines 2067 to 2068 in 4cc83ca

	{% elif ((states('sensor.system_state') |int) in [0x8000,0x0001]) %}
	Stop

:\

[pia21702]

Moin ich habe hier vielleicht was gefunden bei evcc
evcc-io/evcc#17461 (mit aktuellen Registern)
die haben auch diese Probleme nach den Update und schreiben das die Register geändert wurden
leider bin ich auch davon betroffen, ich kann nicht mal mehr den soc min max verändern.
vielleicht findet man da eine Lösung
mfg

[Gnarfoz]

They describe the exact same problems: we can't know which firmware you have, so how can we know which way to interpret the data?
(That is almost a textbook description of what a "breaking change" is...)

The only real way around this would be to offer multiple versions of the file, each suitable for only a specific subset of firmware versions.
A maintenance nightmare.

We could use Github actions to automate it, like the "second inverter" automation.
But I'm not sure if that's a can of worms we want to open. There already are other such things that could benefit from this approach, but with each thing we have a variation for, the number of versions would grow exponentially.

Maybe it is time for that file generator that's been on the to do list for so long. 😬

[Korsberg]

Hello, I am also experiencing issues with the inverter going into shutdown mode.

I shall start reading what yuo have reported here. hope for a solution ? ...

Mine does this and cannot receive charging from the solar panels or charge the battery. I never experienced this phenomenon with FW 95.01.
So far, shutting down the Inverter and battery has worked when I have restart it.
It has been in Running mode for about two weeks, and then it switches to shutdown mode without any reason.

I have an SH10RT-V112 SBR160
FW 95.03 in Inverter

[Korsberg]

i disabled the below ...

id: "automation_sungrow_inverter_state"
id: "automation_sungrow_inverter_state_input_selector_update"
and ..
input_select:
set_sg_inverter_run_mode:

Then i restarted Home assistant, and after that I did a 'Boot' from Isolarcloud app, then charging started. :-)
Im using "Force Charging" with setting SOC , start and end hour from Home asssistant

I will follow up my system during some days ...

[ulfben]

i disabled the below ...

id: "automation_sungrow_inverter_state" id: "automation_sungrow_inverter_state_input_selector_update" and .. input_select: set_sg_inverter_run_mode:

And when you say "disabled", do you mean from the Automations UI, or by deleteting / commenting the automations out of the mkaiser yaml?

[Korsberg]

In the yaml file 😏

[mkaiser]

Can someone confirm, if it is working / not working with the newest firmware?

[ulfben]

I am on the latest firmwares. With fwittenfelds edits, and removing the stuff Korsberg mentioned above, my plant has worked well for a week now! Of course, Im missing "run mode" in the UI but most (all?) other values look reasonable, the scripts all work and the inverters stay online without fuss.

[Gnarfoz]

The question is if @fwittenfeld's latest version works without removing the automations.

[mkaiser]

Oh yes. This was poorly formulated by me...

Can someone update to the newest git Version and include all automations again?

[lassej01]

Hi!
I have installed your latest version and also have latest firmware. And I also enabled the automations yesterday when i updated the yaml. It has worked for me so far. The symptom I had earlier was that it didnt recharge my battery during night with new firmware and the old yaml. But it did yesterday. (So it didnt go to a shutdown because of script problems)

[vzovko]

I updated to the newest git version and have the latest firmware. It is working fine so far. Inverter and battery are working as expected.