How is state cached?

[ProfDrYoMan]

Hi,

just want to understand if things are the same they where in the old integration.

Assume:
I set a switch to on via service switch.turn_on or via device turn on.
If the switch is already on, is that data packet sent over the air again (rising duty cycle) or not?

In the old integration it was sent again which did lead to a lot "check if state is same as new_state and only set if not same set it" in automations.

I would love to get rid of them.

If paket is still sent that might be a possible enhancement to use the feedback state (which is also available in HMIP at least) to avoid extra data packets sent over the air.

[SukramJ]

Old and new integration work nearly identical, but here i'll describe the current state of the new integration.

The CCU sends batches of updates, and if the value for a parameter changes, then this value will be refreshed in HA.
this is a one to one relation for a switch, but could also be a one to many relation in the case of hvac_mode and preset_mode for climate entities, where multiple parameters could be required to "calculate" the value in HA. This could lead to multiple state updates for these one to many entities, but these are rare.

The same happens, when a value is changed in the HA UI or by a HA service. On value will be sent for a switch, but multiple values are possible for siren, cover, climate, light, ....
Before HaHomematic 2023.1.7 multiple values were sent in individual calls (set_value) to CCU.
Starting with HaHomematic 2023.1.7 calls that change multiple value, collect these values per channel and send only on call (put_paramset) per channel. The majority of multi-calls change only values on one channel, so only one put_paramset is sent to CCU.

Changes values are always sent to the CCU, and the result (callback from CCU) will be displayed in the UI. We don't change values of local entities with the outgoing service call!

[ProfDrYoMan]

Ok. Thanks for the info.

Changes values are always sent to the CCU, and the result (callback from CCU) will be displayed in the UI. We don't change values of local entities with the outgoing service call!

I understand that you only change the local state by the result of the callback. Sounds reasonable and leads to some glitching e.g., when changeing the temperature with the climate dial UI.

But even if the new value is the same as the actual value it is sent out to the device.
Why? If there is no change, why waste duty cycle?

Example: switch_therme_ausgang_x. In this case I need to check if already in that state to save duty cycle. And I should normally do that everywhere I set something. I was already thinking of writing a generic script to do so and then thought better to ask how this is done and why no state check before.

alias: "Steuerung: Heizung"
description: ""
trigger:
  - platform: state
    entity_id: sensor.heizung_leistung
condition: []
action:
  - repeat:
      count: "8"
      sequence:
        - choose:
            - conditions:
                - condition: template
                  value_template: >-
                    {{ (8 - repeat.index | int) < trigger.to_state.state | int
                    }}
                - condition: template
                  value_template: >-
                    {{ states("switch.therme_ausgang_" ~ repeat.index) != "off"
                    }}
              sequence:
                - service: switch.turn_off
                  data:
                    entity_id: "{{ \"switch.therme_ausgang_\" ~ repeat.index }}"
            - conditions:
                - condition: template
                  value_template: >-
                    {{ (8 - repeat.index | int) >= trigger.to_state.state | int
                    }}
                - condition: template
                  value_template: >-
                    {{ states("switch.therme_ausgang_" ~ repeat.index) != "on"
                    }}
              sequence:
                - service: switch.turn_on
                  data:
                    entity_id: "{{ \"switch.therme_ausgang_\" ~ repeat.index }}"
          default: []
        - delay:
            hours: 0
            minutes: 0
            seconds: 1
            milliseconds: 0
mode: queued
max: 10

[SukramJ]

But even if the new value is the same as the actual value it is sent out to the device.
Why? If there is no change, why waste duty cycle?

KISS and nobody cared except you.

[ProfDrYoMan]

Keep it simple stupid. Hmm.

I don't see it that way. Now you impose it to the user to take measures to keep the duty cycle high.
In the case above it's 8 devices from which in most cases 7 get set/unset although not needed.

Another example:

Setting the week program on a heating group.
Every time I switch to "Out of House" I set the week program of ALL heating groups to "OOH".
If I would NOT check the actual state of each of these week program settings for all 5 heating groups, ...

I can see spikes in my duty cycle due to that, going up > 50% sometimes. I got 43 HM/HMIP devices in complete. 584 Entities.

Is the effort for

Does it really change the state?
Yes: Change it
No: Ignore

so high?

Remark: Yes there might be side effects which I do not see right now.

[SukramJ]

Side effects and complexity:

The relation between could be even more complex:

• You send on parameter A and receive an update over parameter B, commonly used for climate.
• It is required to send cover level (identical level or not) to change level_2
• You need to disable one parameter (e.G BOOST_MODE ) to enable another parameter (e.g. AUTO_MODE)

It's not that i don't get your point, but it's not that simple.

[ProfDrYoMan]

Ok. I see that this adds complexity due to things are coupled.

Solution for me: Write a "do only when needed" script for switch and light and use these scripts to avoid duplicating the effort in many automations. Not the nicest thing, but better than nothing.

[SukramJ]

This is not generalizable on homematic parameters so service like set_device_value are out of scope.
If we only talk about higher level HA services like climate.set_preset_mode we could think about not to send a new preset if the new preset is the old one.
Maybe my first assumption was too complicated.

[ProfDrYoMan]

Yes, I seems you misunderstood due to my recently reported bug on set_paramset.

I want to see something like that by default:

alias: Set Switch
sequence:
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ (states(entity_id) != 'on') and (value == 'on') }}"
        sequence:
          - service: switch.turn_on
            data: {}
            target:
              device_id: "{{ entity_id }}"
      - conditions:
          - condition: template
            value_template: "{{ (states(entity_id) != 'off') and (value == 'off') }}"
        sequence:
          - service: switch.turn_off
            data: {}
            target:
              device_id: "{{ entity_id }}"
mode: queued
icon: mdi:toggle-switch-variant-off
max: 20

Same for light, and week_program and ...

Not the complex thing you mentioned.

[SukramJ]

A light turn_on could have around 5 arguments to consider.

[SukramJ]

The state changed started by another Ha instance is no issue. Thats why we wait for the callback to update data.

[ProfDrYoMan]

For light, I see. I only have on/off as light.x in HA which is mapped to a (power) switch in HA. So in the end these are switches for hahomematic.

[SukramJ]

On which devices do you have problems with the dutycycle?

[ProfDrYoMan]

On none especially.
It is only that I did program many things in loops which might then set devices into a state which they are already in.
As above the 8 switches which control my heater and also a mentioned the week-programs on multiple heater groups (in HMIP) which then might trigger the devices in the group.

If I don't take special care there is a huge overhead of useless packets "ten-fold" of the needed.

[ProfDrYoMan]

https://github.com/danielperna84/hahomematic/releases/tag/2023.2.2

Avoid backend calls if value/state doesn't change
If an entity (e.g. switch) has only one parameter that represents its state, then a call to the backend will be made,
if the parameter value sent is not identical to the current state.
If an entity (e.g. cover, climate, light) has multiple parameters that represent its state, then a call to the backend will be made,
if one of these parameter values sent is not identical to its current state.

Thanks!

It seems I can get rid of a lot of special handling in my automations and will see a decline in DC.

[SukramJ]

You need to activate beta: Right click on the integration -> redownload. Then you could mark beta.

[SukramJ]

--> in HACS

[ProfDrYoMan]

Did it. Build a script which switched off two switches (as said, I do not have any lights in HMIP) 100 times with a 1 sec wait in between.

DC did not change.

I could test the same with the climate week-program? It should also keep DC low? First asking, then trying.

[SukramJ]

Yes, climate should work too. Only siren and lock are not covered.

[ProfDrYoMan]

And I tried, without waiting for your answer. :) DC does not change. => This is great. Now I can ignore if a automation might change the state useless to the already existing. Great. Did disable the extra check on some automations already. Waiting for the release to then change all.