Configure the inverter

[lindehoff]

Hi, First of all, thank you so much for this, I just got an SH8.0RT and this integration is awesome.

I have a feature request, is it possible to set parameters over Modbus? If so it would be great if we could set parameters like:

• Force charging
• Disscharge Weekday/weekend

[mkaiser]

thanks ;)

I just figured out to write to modbus holding registers, so this will be definitivly do-able for me in the future

For sure I can make some kind of a selector to change the battery management mode between "force charge / discharge / auto".

I am currently not sure how to map the timing-related modbus functions available to a usable-Homeassistant UI. What do you expect for a time scheduled operation?

[lindehoff]

This sounds great. I have a couple of scenarios when I want to "force" the invert to different operational modes:

1. When electricity is very cheap I want to force change the battery form the grid
2. When I'm charging my EV I want to tell the inverter not to drain the battery, no-discharge
3. When grid electricity is very cheap I want to tell the inverter not to use the battery, same as above (no-discharge)
4. When I can sell at a high price I want to tell the inverter to not change the battery (Not sure this is possible)

So I don't need to have to set specific time/date/schedule, that can be done in Home assistant. Instead we only need to be able to tell the inverter:

• Force charge battery from grid
  • It would be Verny nice if we can set Max. charge current (13067) since I saw it can easily max out the main fuse If this is set when the household is consuming a lot of energy as well.
• Don't charge battery
• Discharge battery
• No discharge battery (Not sure if possible)
  • We might be able to use Max. SOC (13058) to achieve this?

If we have these the we can use home assistant to build the "smartness"

[mkaiser]

committed here in branch "testing": https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant/tree/testing

currently it is more a proof-of concept. I was able to force charge / discharge. Will push in to main branch, if someone can confirm it to be working.

To activate a "force battery charge", look at the "EMS" section of the dashboard (right side) and configure the red-circled entries

There are still some issues, please let me know, if you have anyone has suggestions:

• Battery capacity modbus register always returns 0
• After setting an input value via GUI/slider, it will take some seconds (depending on scan_interval) until the corresponding modbus register is updated
• After restart the slider values are different from the actual set values
• Modbus Register "Battery Charge Discharge Power", addr 13052, does not behave as declared in the datasheet. For my SH10RT the register value is set in W, not in % (as datesheet says)
• I don't know how to use hexadecimal values in the writeModbus routines. Currently it looks like this, but this is ugly.... ` # 0xAA: 170 Charge

  0xBB: 187 Discharge

    # 0xCC: 204 Stop (Default)
    # don't know how to compare the integer values in hexadecimal format in following decoder statement...
    value: "{% if is_state('input_select.set_sg_battery_charge_discharge_cmd' , 'Stop (default)') %} 204
    {% elif is_state('input_select.set_sg_battery_charge_discharge_cmd' , 'Force charge') %} 170
    {% elif is_state('input_select.set_sg_battery_charge_discharge_cmd' , 'Force discharge') %} 187
    {% else %} 204 {% endif %}"  `

~Martin

[lindehoff]

Looks very promising, I have don som small tests and everything seams to work. We can calculate the battery kWh capacity with Holding registry 13057, like so:

      - name: Battery capacity Ah
        slave: !secret sungrow_modbus_slave
        address: 13056
        input_type: holding
        count: 1
        scan_interval: 600
        data_type: uint16
        swap: word
        precision: 0
        unit_of_measurement: "Ah"
        device_class: energy
        state_class: total_increasing
        scale: 1

And the create a template sensor:

      sungrow_battery_capacity_kwh:
        friendly_name: "Battery capacity kWh"
        unit_of_measurement: kWh
        device_class: energy
        value_template: >-
          {{ ((states('sensor.battery_capacity_ah') | int(default=0) / 1000 * 240) / 1000) | round(1) }} 

[mkaiser]

totally missed the other battery capacity register in sungrows register map. The datasheet does not meantion the sh10 support for register 13058.... I just requested an updated protokoll description from sungrow. Maybe they have updates, bringing more light into this :)

In your emplate you used the factor 240. Does this correspond to your current battery voltage?

[lindehoff]

It works for my SH8.0RT so I would imagine it works for SH10.0RT. The 240 factor is the voltage going from the battery and in my house its around 230-250. So I get 15.7 kWh and the battery should be 16 kWh so close enough.

[bjeanes]

I just requested an updated protokoll description from sungrow

TI_20211231_Communication Protocol of Residential Hybrid Inverter_V1.0.23_EN.pdf

Here is 1.0.23, which is at least newer than the one mentioned in README, but may not be latest. I am also waiting to hear back from SunGrow on latest version.

[bjeanes]

• I don't know how to use hexadecimal values in the writeModbus routines.

Wrap the hex in template braces, like {{ 0xaa }} to force Python to evaluate it to a number:

[Svanmark]

Hi, nice work! I was just testing forced charging using the integration from testing branch. It seems to work well with SH10.0RT. Following the progress.

[Bullischorsch]

committed here in branch "testing": https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant/tree/testing

Hi, thanks a lot for your work! I use your code since some months and now see this expansion. Unfortunately is doesn't work for me. The new entities under EMS are not available, the older ones are still there. Do I have to reload something? Or has the inverter to be in a special mode? Currently it is in "Netzunabhängiger Modus".

Georg

[Bullischorsch]

committed here in branch "testing": https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant/tree/testing

Hi, thanks a lot for your work! I use your code since some months and now see this expansion. Unfortunately is doesn't work for me. The new entities under EMS are not available, the older ones are still there. Do I have to reload something? Or has the inverter to be in a special mode? Currently it is in "Netzunabhängiger Modus".

Georg

Solved this issue. I renamed the config file in the integrations subdir and restarted HA, afterwards the new configured items where loaded. Seem to be some caching thing.

[FlyHigh-Swe]

Looks very promising, I have don som small tests and everything seams to work. We can calculate the battery kWh capacity with Holding registry 13057, like so:

I am not sure if I am doing something wrong here or misunderstood something. When I read register 13057 (13056 in the code) I get the value 65535 and when I apply the same calculation (Ah to kWh) I also get 15.6 but my battery is actually 9,6Kwh.

I also have the SH8RT but suspect I get an error code when reading the registry. I am using a modbus addon in node red to test this but all other values return the same values as this integration so I doubt that the issue is in Node Red.

[FlyHigh-Swe]

committed here in branch "testing": https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant/tree/testing

currently it is more a proof-of concept. I was able to force charge / discharge. Will push in to main branch, if someone can confirm it to be working.

Its working very good for me also using a SH08RT. The automation to change to forced mode etc works excellent from the dashboard. And thank you for developing this awesome integration!

(I am actually using node red for writing Modbus data at the moment since all other automations is there but I would never have understood how to do it if it wasn't for your code!)

[mkaiser]

• I don't know how to use hexadecimal values in the writeModbus routines.

Wrap the hex in template braces, like {{ 0xaa }} to force Python to evaluate it to a number:

thanks! That was really helpful - incorporated that in the last commit :)

[mkaiser]

hmm

still cannot figure out, why I can't read the two registers

  - name: Battery type
    slave: !secret sungrow_modbus_slave
    address: 13054 # 13055
    input_type: holding
    count: 1
    data_type: uint16
    swap: word
    precision: 0
    scan_interval: 60

and

• name: Battery capacity Ah slave: !secret sungrow_modbus_slave address: 13056 input_type: holding count: 1 scan_interval: 600 data_type: uint16 swap: word precision: 0 unit_of_measurement: "Ah" scale: 1

result is always 65535 on my SH10.RT

any ideas?

[bjeanes]

@mkaiser that register is not used/available on the SH#RS/RT inverters. It only applies to the SH#K inverters, like SH3K6, etc

See https://www.photovoltaikforum.com/core/attachment/235914-ti-20211231-communication-protocol-of-residential-hybrid-inverter-v1-0-23-en-pdf/ to lookup that register address (13057, it's 13056 here because the protocol address is -1 from the documented address in all cases)

[mkaiser]

bjeanes, you are right with the not supported registers :)

hopefully my inner confusion just ended...

@ FlyHigh-Swe

your SH8RT has also no support for the register 13057 (like my SH10RT).

So it is expected, that the register read will return 0xFFFF / 65535.

Therefore the equation ('sensor.battery_capacity_ah') | int(default=0) / 1000 * 240) / 1000) | round(1) }}

will always return 15,7284 (65535 / 1000 *240 /1000)

[mkaiser]

new update in testing branch

@FlyHigh-Swe, @lindehoff : added (secret / hidden / reverse engineered) register for the battery capacity - no need for a template any more :)

I guess all requests in this issue are satisfied - please open a new one, if I missed something :)

brief changelog

• removed non SH*-supported registers, because I cannot test them...
• Added Battery capacity and setting charge/discharge battery power (See issue #13)

[mkaiser]

closing issue. Battery capacity for non SH10RT is still an issue, but that should be in another thread