feat: Add power and voltage to Deye TOU programs

[sofkaski]

Added definitions for maximum allowed discharge power and voltage condition of time-of-use (TOU) to deye_sg04lp3.yaml inverter definition.

Power values for 6 programs are available from registers 154 - 159 and voltages from registers 160 - 165.

~Added also a definition for a switch that tells if TOU programs are in use (register 146).~

The SOC values for programs are already included. SOC or voltage is used based on battery control mode (inverter_battery_operation_mode, voltage or capacity).

[sofkaski]

Visualization of added entities with simple cards:

YAML of the latter markdown card:

``` type: markdown content: >+ | **Start time** | **Grid charge** | **Power** | {{ states('select.inverter_battery_operation_mode') }} | |:----------- |:--:|:--------:|--------:| | {{ states('time.inverter_program_1_time') }} | {{ states('switch.inverter_program_1_grid_charging') }} | {{ states('number.inverter_program_1_power', with_unit=True) }} | {{ states('number.inverter_program_1_voltage', with_unit=True) }} | | {{ states('time.inverter_program_2_time') }} | {{ states('switch.inverter_program_2_grid_charging') }} | {{ states('number.inverter_program_2_power', with_unit=True) }} | {{ states('number.inverter_program_2_voltage', with_unit=True) }} | | {{ states('time.inverter_program_3_time') }} | {{ states('switch.inverter_program_3_grid_charging') }} | {{ states('number.inverter_program_3_power', with_unit=True) }} | {{ states('number.inverter_program_3_voltage', with_unit=True) }} | | {{ states('time.inverter_program_4_time') }} | {{ states('switch.inverter_program_4_grid_charging') }} | {{ states('number.inverter_program_4_power', with_unit=True) }} | {{ states('number.inverter_program_4_voltage', with_unit=True) }} | | {{ states('time.inverter_program_5_time') }} | {{ states('switch.inverter_program_5_grid_charging') }} | {{ states('number.inverter_program_5_power', with_unit=True) }} | {{ states('number.inverter_program_5_voltage', with_unit=True) }} | | {{ states('time.inverter_program_6_time') }} | {{ states('switch.inverter_program_6_grid_charging') }} | {{ states('number.inverter_program_6_power', with_unit=True) }} | {{ states('number.inverter_program_6_voltage', with_unit=True) }} | title: Time of use visibility: - condition: state entity: switch.inverter_time_of_use state: 'on' ```

[davidrapan]

Hi @sofkaski! Thank you for your PR just...

For those power and voltage as they are configurable they should have something like:

configurable:
  min: 38
  max: 61
  step: 0.1

'configurable:' contains values after scaling. 'range:' contains values before scaling and are more like failsafe that we got good data from the inverter.

Values from 'range:' can be used for 'configurable:' when 'scale: 1' (Means when you don't provide min and max in configurable it will use those from range).

Do you think you can try to make the adjustments?

And that "Time of use programs" sensor is bit more complicated and uses all 8 bits and each representing on/off switch for particular day from Monday-Sunday so I'm really not sure how efficiently and in a good way that could be translated into HA world... :/

Anyway really glad for the PR. Nice to see someone put hands on the work. 😊 Cheers!

[sofkaski]

Thanks for the review, I'll push fixes soonish.

[sofkaski]

And that "Time of use programs" sensor is bit more complicated and uses all 8 bits and each representing on/off switch for particular day from Monday-Sunday so I'm really not sure how efficiently and in a good way that could be translated into HA world... :/

You are right that the register 146 has encoded both weekdays for system-work-mode-1 and also the bit that tells if TOU programs are in use. I tested it in my system and the latter is encoded in the lowest bit of the register (all weekdays + TOU on = 255 and all weekdays + TOU off = 254)

Given that my intention was to capture only that information for this switch I should look only that lowest bit.

[davidrapan]

And that "Time of use programs" sensor is bit more complicated and uses all 8 bits and each representing on/off switch for particular day from Monday-Sunday so I'm really not sure how efficiently and in a good way that could be translated into HA world... :/

You are right that the register 146 has encoded both weekdays for system-work-mode-1 and also the bit that tells if TOU programs are in use. I tested it in my system and the latter is encoded in the lowest bit of the register (all weekdays + TOU on = 255 and all weekdays + TOU off = 254)

Given that my intention was to capture only that information for this switch I should look only that lowest bit.

So you are telling me that highest bit turns all days on and off? Even when you don't touch the other?

[sofkaski]

And that "Time of use programs" sensor is bit more complicated and uses all 8 bits and each representing on/off switch for particular day from Monday-Sunday so I'm really not sure how efficiently and in a good way that could be translated into HA world... :/

You are right that the register 146 has encoded both weekdays for system-work-mode-1 and also the bit that tells if TOU programs are in use. I tested it in my system and the latter is encoded in the lowest bit of the register (all weekdays + TOU on = 255 and all weekdays + TOU off = 254) Given that my intention was to capture only that information for this switch I should look only that lowest bit.

So you are telling me that highest bit turns all days on and off? Even when you don't touch the other?

I think that it is the lowest bit that turns all programs off. Then bits 2-8 are for weekdays so that Sunday is bit 8. (I turned Sunday off and the resulting register value was 127). Turning the TOU off from Deye UI does not touch programs. Once you enable it again the old values are there.

[davidrapan]

Oh yeah I did mean the lowest sorry! Nice then! That really means it is usable even in this limited functionality, okay, thanks!

[sofkaski]

I ended up proposing here a new parser type 11 for bit fields that is used to pick up single bit encoded values.

I fixed definitions and rebased on top of your latest main.

Time of use switch history from my system:

I toggled the time of use a couple of times from Deye cloud UI.

[sofkaski]

I could not find a nice representation for selected weekdays captured from the register. I wonder if we should capture the weekdays when the TOU program is in use as switches like time_of_use_monday, time_of_use_tuesday, ... ? It is a bit clumsy, but the information would be available.

[davidrapan]

Hi!

For reading the single bit isn't just the mask feature enough though? What bothers me more is how to write that single bit cause it should be R/W item. When i was trying to write that single bit it lost the weekdays information though...

[sofkaski]

Hi!

For reading the single bit isn't just the mask feature enough though? What bothers me more is how to write that single bit cause it should be R/W item. When i was trying to write that single bit it lost the weekdays information though...

Ah..yes. I was looking this shortsightedly only from the reading point of view. To be able to write the bit back we need to preserve its location.

[davidrapan]

You know what? Let's split this PR and remove from this one changes to the Time of Use and keep here only the added Programs X voltage and power sensors so i can merge those as they are no brainers and let's then discuss that Time of Use further in new PR.

What do you think?

[sofkaski]

You know what? Let's split this PR and remove from this one changes to the Time of Use and keep here only the added Programs X voltage and power sensors so i can merge those as they are no brainers and let's then discuss that Time of Use further in new PR.

What do you think?

Sounds good. I'll fix the PR to contain only the power and voltage. I'll push it soonish.

[sofkaski]

I fixed the PR.

Time of Use is now as it was in the main branch (= on + all weekdays on, off +all weekdays off)