mkaiser / Sungrow-SHx-Inverter-Modbus-Home-Assistant

Sungrow SH Integration for Home Assistant for SH3K6, SH4K6, SH5K-20, SH5K-V13, SH3K6-30, SH4K6-30, SH5K-30, SH3.RS, SH3.6RS, SH4.0RS, SH5.0RS, SH6.0RS, SH5.0RT, SH6.0RT, SH8.0RT, SH10RT, SH5.0RT-20, SH6.0RT-20, SH8.0RT-20, SH10RT-20, SH5.0RT-V112, SH6.0RT-V112, SH8.0RT-V112, SH10RT-V112, SH5.0RT-V122, SH6.0RT-V122, SH8.0RT-V122, SH10RT-V122, SH4.6R
305 stars 79 forks source link

automation_sungrow_inverter_start_stop_input_selector_update causes a starting inverter to stop #125

Closed paulhomes closed 1 year ago

paulhomes commented 1 year ago

I merged in the changes in commit c3758920ba156dde06710a228caa0ace108c8763 into my Home Assistant config and found my SH10RT inverter would keep stopping after being restarted. I watched the state changes in sg_inverter_state and it would go from Stop to Standby and then back to Stop. It looks like the problem is in the new automation_sungrow_inverter_start_stop_input_selector_update automation. Any sensor.system_state value other than 0x0040 Running (such as Standby) changes the input_select set_sg_start_stop_mode to Stop which is then picked up by the automation_sungrow_inverter_start_stop automation and stops the inverter. After I disabled the automation_sungrow_inverter_start_stop_input_selector_update automation I was able to start my inverter again.

mkaiser commented 1 year ago

oh that is a serious issue.

Commented the lines for the Automation as a "quick fix"

I am not sure how to handle this:

Just automation-update the menu to "Start", when the inverter state is "running", else "do nothing"?

paulhomes commented 1 year ago

I was thinking something like that: Start when it is running, Stop when it is stopped, and do nothing otherwise, so the other states don't end up potentially triggering another state change. Of course there are a bunch of other states such as "Forced mode" 0x0800, which my inverter was in after I started it today, so should that update the menu to "Start" too to reflect a type of running? Would that then trigger another start request and, when already in forced mode, would it do nothing? Could it end up in an endless start request loop?

Perhaps the automation_sungrow_inverter_start_stop automation that sends the start/stop request to register 13000 should only send a start request then the menu selection has changed to Start and the current state is a stopped state. Likewise only send a stop request when the menu selection has changed to Stop and the current state is one of the running states? What do you think?

mkaiser commented 1 year ago

sounds good.

Additionally, I will rename "Start / Stop" to "Enabled / Shutdown". Then it should become more clear

Only if the "sungrow inverter state" is "stopped" the input select is updated to "shutdown" All other states including the "forced " mode fall under "enabled"

input selection behaviour:

So everything should be covered, right?

input_select: set_sg_inverter_run_mode: name: Inverter mode options:

  • "Enabled"
  • "Shutdown"`

    • id: "automation_sungrow_inverter_state" alias: "sungrow inverter state" description: "Enables/ stops the inverter" trigger:
  • platform: state entity_id:
    • input_select.set_sg_inverter_run_mode condition: [] variables: sg_start: 0xCF sg_stop: 0xCE action:
  • service: modbus.write_register data_template: hub: SungrowSHx slave: !secret sungrow_modbus_slave address: 12999 # reg 13000 value: > {% if is_state('input_select.set_sg_inverter_run_mode', 'Enabled') %} {{sg_start}} {% else %} {{sg_stop}} {% endif %} mode: single

    • id: "automation_sungrow_inverter_state_input_selector_update" alias: "sungrow inverter enable/ stop input selector update" description: "Updates enable/ stops input selector" trigger:
  • platform: state entity_id:
    • sensor.system_state condition: [] action:
  • service: input_select.select_option target: entity_id: input_select.set_sg_inverter_run_mode data: option: > {% if is_state('sensor.sungrow_inverter_state', 'Stop') %} "Shutdown" {% else %} "Enabled" {% endif %} mode: single
paulhomes commented 1 year ago

Thanks, that sounds good to me.

mkaiser commented 1 year ago

fixed - thank you for debugging :)

paulhomes commented 12 months ago

No worries, thanks for making this wonderful resource available!