Read/Write WorkMode, MinSoC/MaxSoC and so on for H3-Systems

[abuesen]

Started with my question in issue #498 @canton7 and me figured out that there are holding-register readable and writeable on the H3 that assumable were not before.

System: H3-12.0-E - AUX
Firmware Master : 1.83, Slave : 1.03, Manager : 1.66

tested 41000-41017 with modpoll -m tcp -a 3 -1 -0 -r 41000 192.168.x.x
Success: 41000, 41007-41011. The answers seem plausible compared to "SinglePhase" and the FoxESS-Cloud
Fail: 41001-41006, 41012, 41013, 41015 (illegal address)
Strange: 41014, 41016 answers not plausible to "SinglePhase" documentation. 41015 is wrong value and 41016 gives e.g. '3789'

First I used "write register" service to set values, it worked. To test I then altered code in my local foxess_modbus and was able to build entities for select.fox_work_mode, sensor.fox_min_soc_on_grid and number.fox_min_soc_on_grid

Because of an error while reading multible registers after 41000 I had to invalidate some register, too.

I don't know how to pull, push and so on, so I give my changes here. Please put it in a beta the right way, I will test it.
If you want me to do tests on other register let me know.

entitiy_descriptions.py line1468ff

    ModbusSelectDescription(
        key="work_mode",
        address=[
            ModbusAddressSpec(models=[*H1_SET, KH], input=41000),
            ModbusAddressSpec(models=[*H3_SET], holding=41000) # new
        ],
        name="Work Mode",
        options_map={0: "Self Use", 1: "Feed-in First", 2: "Back-up"},
    ),

entitiy_descriptions.py line1570ff

    ModbusSensorDescription(
        key="min_soc_on_grid",
        addresses=[
            ModbusAddressesSpec(models=[*H1_SET, KH], input=[41011]),
            ModbusAddressesSpec(models=[*H3_SET], holding=[41011]) # new
        ],
        name="Min SoC (On Grid)",
        device_class=SensorDeviceClass.BATTERY,
        state_class=SensorStateClass.MEASUREMENT,
        native_unit_of_measurement="%",
        icon="mdi:battery-arrow-down",
        validate=[Range(0, 100)],
    ),
    ModbusNumberDescription(
        key="min_soc_on_grid",
        address=[
            ModbusAddressSpec(models=[*H1_SET, KH], input=41010),
            ModbusAddressSpec(models=[*H3_SET], holding=41011) # new
        ],
        name="Min SoC (On Grid)",
        mode=NumberMode.BOX,
        native_min_value=10,
        native_max_value=100,
        native_step=1,
        native_unit_of_measurement="%",
        device_class=NumberDeviceClass.BATTERY,
        icon="mdi:battery-arrow-down",
        validate=[Range(0, 100)],
    ),

inverter_profiles.py line 161ff

        InverterModelProfile(H3, r"^H3-")
        .add_connection_type(
            LAN,
            RegisterType.HOLDING,
            invalid_register_ranges=invalid_ranges.H3, # new
        )
        .add_connection_type(
            AUX,
            RegisterType.HOLDING,
            invalid_register_ranges=invalid_ranges.H3, # new
        ),

invalid_ranges.py appended
H3 = [(41001, 41002, 41003, 41004, 41005, 41006, 41013, 41015)]

The errormessage:

Logger: custom_components.foxess_modbus.modbus_controller
Source: custom_components/foxess_modbus/modbus_controller.py:221
Integration: FoxESS - Modbus (documentation, issues)
First occurred: 10:59:45 (1 occurrences)
Last logged: 10:59:45

tcp://192.168.x.x:502 3 - 5 failed poll attempts: now not connected. Last error: Error reading registers. Type: RegisterType.HOLDING; start: 41000; count: 12; slave: 3 from tcp://192.168.x.x:502: Exception Response(131, 3, IllegalAddress)

[abuesen]

Register 41014 is '1' if set 50Hz and results in TimeOut at 60Hz. Seems like broken or work in progress.

[canton7]

Oh amazing, thank you! Let me get those in, and a new beta out for you.

[abuesen]

charge times was tested with strategy periods disabled?

@TonyM1958
What are strategy periods and how to disable? Can't find them in modbus.map.

[TonyM1958]

Strategy periods or schedules are not accessible via modbus currently. They are set under work mode using the Fox app or Web site. They require a firmware upgrade before they can be used. This depends on the model of inverter.

[abuesen]

Is it another thing than the time-periods? See screenshot. In the web and in the app there are only Work Mode and two time periods, both disabled.
The system should be on the latest firmware. At the moment I have an account type "Enduser". So I can't update myself but I don't mind until now.

For my Inverter and software-version see my first porst: #503 (comment)

[canton7]

Yep, your manager firmware isn't new enough to support strategy periods, so this won't be the reason.

[abuesen]

Ok, thank you. I'll working on that this week ;-)
Never looked for firmware and releasenotes at FoxESS before.

[abuesen]

First try: Entites show up, no values at all.
Log (1) shows illegal adresses 41007+5. (Don't understand the linenumbers from log.)
With modpoll 41007-41011 give values.

Second try: I put '#' in froint of the lines with 41007, 41008, 41009 what should be near the same as I did before, but no values.
Log (2) complains about a binary sensor.

But after reloading foxess_modbus 1.8.2b2 the first error does not appear again. The second one stays. That is not what I expected. I'll reboot and revert to 1.8.1 to get a fresh start. Maybe not today.

Log (1):

Logger: custom_components.foxess_modbus.modbus_controller

Source: custom_components/foxess_modbus/modbus_controller.py:221
Integration: FoxESS - Modbus ([documentation](https://github.com/nathanmarlor/foxess_modbus), [issues](https://github.com/nathanmarlor/foxess_modbus/issues))
First occurred: 15:08:14 (1 occurrences)
Last logged: 15:08:14
tcp://192.168.100.7:502 3 - 5 failed poll attempts: now not connected. Last error: Error reading registers. Type: RegisterType.HOLDING; start: 41007; count: 5; slave: 3 from tcp://192.168.100.7:502: Exception Response(131, 3, IllegalAddress)

Log (2)
home-assistant_2024-01-13T16-26-19.691Z.log

Logger: homeassistant.components.binary_sensor
Source: helpers/entity_platform.py:573
Integration: Binärsensor (documentation, issues)
First occurred: 17:18:30 (1 occurrences)
Last logged: 17:18:30

rpi_power: Error on device update!
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 573, in _async_add_entity
    await entity.async_device_update(warning=False)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1214, in async_device_update
    await hass.async_add_executor_job(self.update)
  File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/rpi_power/binary_sensor.py", line 52, in update
    value = self._under_voltage.get()
            ^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'

[canton7]

Huh. That's annoying: I'm going to have to build some logic for polling registers individually...

[abuesen]

Strange, the rpi_power error persits now. I reverted to 1.8.1 and inserted the lines I did before. System-reboot but still this error.

[canton7]

I'm pretty sure that's nothing to do with foxess_modbus

[abuesen]

Right. Reason is the comment within the brackets '[...]' in entity_descriptions.py. I copied the '# new' from my post and it causess this error.
Now it looks like before 😃

[canton7]

Cool! I've released v1.8.2b3 which should be reading registers in the range 41007-41011 one-by-one. Can you give that a try please?

[abuesen]

Very nice: 1.8.2b3 works. 🎉

It starts and gives values for all entities. Now I have to check function.
Did it already for WorkMode, Min SoC on Grid and Min SoC.

Open for Max SoC and Currents, I have to look for other places to see this values.
Max SoC shows 75% what is strange because last days with sun it goes 100%.
Both currents show 26A what is plausible.

[abuesen]

annoing. The rpi_power error seems to raise on any syntaxerror in entities_description.py. Did not manage to add a Sensor for 44002 or 44002/44003.

Tried this at the end of the file, power_control_enable works, rpc_active_power doesn't

    ModbusSelectDescription(
        key="remote_power_control_enable",
        address=[ModbusAddressSpec(models=H3_SET, holding=44000)],
        name="Remote Power Control",
        options_map={0: "Disabled", 1: "Enabled"},
    ),
    ModbusSensorDescription(
        key="rpc_active_power",
        addresses=[ModbusAddressesSpec(models=H3_SET, holding=[44002])],
        name="RPC active Power",
        device_class=SensorDeviceClass.ENERGY,
        state_class=SensorStateClass.MEASUREMENT,
        native_unit_of_measurement="W",
        icon="mdi:home-lightning-bolt-outline",
        signed=True,
    )
]

[abuesen]

It seems in normal operation the valus of 44002/44003 and 44004/44005 are not set by the system. The values of 2/3 are still '0' and 4/5 alter somtimes. Cant see any systematic.
(Thank you for bringing signed int16 to my mind again. Stupid question.) 😆

The PV generates less than 100W at the moment. SoC is about 35%. The Load is feed by PV+battery.

1. Remote Power Control enabled.
   No power for the load any more. Battery is charging from PV.
2. Setting 44002 to '500'
   Inverter delivers 500W to the load feed from PV+battery.
3. Setting 44002 to '65035' (-501)
   Inverter consumes, battery is charing with about 675W what is a bit more than 501+PV, but the last digit is correct, alwas PV-power +1. The difference is alway 40W
4. Setting positve and negative values to 44003 are written and stored
   can't see an effect
5. Setting 44004 is possible with negative values only
   can't see an effect
6. Setting 44005 is not possible at all
   but it shows altering negative values. saw between -8 and -28, but only even numbers.

Seems nice on the first sight. Hopefully foxess cares for temperature and so on regardless of the external power control.

[canton7]

Take a look at #513 - I did some of my own investigation this morning.

[canton7]

I would be very surprised if rpi_power is related at all. I think it's randomly failing, and just happens to coincide with other things you're doing.

[abuesen]

Ok, you're much more advanced in this work than me of course. :-D
Feel free to give me tasks for the H3 if I can assist testing. There is no need of remote power control for my own usage.

[abuesen]

Read and write both Current and Max SoC works too. Did not test what happens on "wrong" values like more than 100% or high currents.

So in my opinion this peace works fine for H3. Of course we do not know about other 3-phase inverters and other firmware.

What about catching the "illegal adress" exception instead of the integration does not load?
Maybe it is possible to set the entities to "unavailiable" or set '0' or '999'|'666'

[abuesen]

good work, 110% not alowed by Write register and '50A' result in a slave error.

[peterw10]

I don't know if its helpful, here's the answer from FoxEss support I got:

"H3 Modbus-Protokoll Einstellung der Zwangsladung
Einstellung des 3-teiligen Registers in Folge, Einstellung 44000 auf 7, Einstellung 44001 für Steuerzeit, Einheit S(Sekunde), Einstellung 44002 für Leistung, Einheit W(Watt)"

[canton7]

Writing 7 to 44000 gives "Illegal Data Value exception response!", at least on my H1. The rest of it looks in like with #513.