Check_back object with manual switching of actuators syncing UI zone objects

[evercape]

Hi Robert,

I am possibly not fully understanding the check_back object. You recommended at some point that I set it to states:none.

What I am trying to do is the following:

1. Someone either presses the physical switch on the KNX actuator, or a KNX logic switches the corresponding irrigation actuator group address 1/1/0 state to 'on' without any interference with UI objects
2. UI's zone entity, in this case binary_sensor.irrigation_unlimited_c1_z1 should then automatically switch to 'on', ie be in sync.

Can you please advise if that is somehow already working? The way I understand the documentation 5.10, this is a one way operation ie UI-->sync-->physical switches. However, it appears that it does not "work" the other way around, ie physical switch-->sync-->UI. Could you pls kindly confirm if my assumption is correct?

Happy to provide logs, but I think the issue is pretty clear from the above explanation and below sample config.

If it does not work as a bi-directional synchronisation (yet), then I should be able to sync the state by carrying the entity ID as user attribute and run some HASS automation. What do you recommend?

thanks, Martin

(simplified) KNX and UI Yaml config:

pack_irrigation:
  knx:
    #SWITCH IRRIGATION VALVES
    switch:
      #LAWNS
       - name: "Irrigation KNX Actuator with manual switching capability"
        address: "1/1/0"
        state_address: "1/1/1"

irrigation_unlimited:
    history:
      span: 7
    refresh_interval: 5
    controllers:
      - name: Verges Road
        enabled: true
        check_back:
          states: none
        zones:
          - name: "Irrigation KNX Actuator with manual switching capability"
            entity_id: switch.irrigation_knx_actuator_with_manual_switching_capability
            user:
              entity_id: switch.irrigation_knx_actuator_with_manual_switching_capability

[evercape]

I been thinking about this a bit today. First of all, the last parameter entity_id do you think I need to consider this, since KNX uses state_addresses as in above code sample?

Secondly, I am wondering if the check_back object only allows one directional synchronisation, as one side has to be master and the other the slave.

So I am pretty convinced that in my setup (no slow signee, funny acting wifi switches) UI will always be able to correctly switch KNX, however, there might be the odd scenario where KNX may be switched without UI "knowing about it" which is obviously not great since for instance the recording/history stats will be out of sync.

Maybe someone has a similar scenario? Or any other thoughts on this? Thanks

[rgc99]

The check_back functionality is to improve the reliability of switches. The type of switches of concern are wireless or cloud based such as Wifi, ZigBee, ZWave etc. After changing the entity_id's state it is examined to see if it actually changed and attempts to resynchronise. It is a one way process. In your case the switches have a very high reliability and this functionality is of little benefit.

What about a button press that triggers an automation that in turn calls a manual_run service call. Knowing how long is the problem but if it was very large and then cancelled when the switch was turned off.