Listen to 'external' switch commands of solenoid valves

[evercape]

Is your feature request related to a problem? Please describe.
A longer explanation of this issue/feature request started off on the community forum, however, I feel it is better to develop this as a feature request here on GitHub.

Summary:
If a zone is switched off outside irrigation unlimited for instance by manually switching of the actuator, or by some external automation (power failure, pressure loss, ...) that switches of the underlying switch of an irrigation unlimited zone as per the switch entity, then the corresponding irrigation unlimited zone(s) should also be switched off or disabled.

One could start a longer discussion what switched off or disabled means which I have started to explain on the community forum.

Describe the solution you'd like
I suggest two things:

1. output entity_id from the zone object as attribute on the binary sensor of the zone object which will be helpful for using template automation to listen to events of the underlying switch.
2. synchronise the state of the underlying switch (definitely for the 'off' state) so that the binary_sensor of the zone at least switches off if the underlying switch is off.

Describe alternatives you've considered
Here is an alternative, which uses the newly added user static data from feature request 143:

irrigation_unlimited:
    controllers:
      - name: Lawn Areas
        zones:
          - name: "Front of Berms"
            entity_id: switch.g0272_irrigation_lawn_front_of_berms
            user:
              entity_id: switch.g0272_irrigation_lawn_front_of_berms
          - name: "Pool Kitchen"
            entity_id: switch.g0273_irrigation_lawn_between_pool_and_kitchen
            user:
              entity_id: switch.g0273_irrigation_lawn_between_pool_and_kitchen
        sequences:
          - name: "Run 1"
            duration: "00:10" 
            schedules:
              - name: "testing"
                time: "12:30"
                weekday: [wed]
                month: [oct]
            zones:
              - zone_id: 1
              - zone_id: 2

  automation:
    - alias: "Irrigation Integration Solanoid Off Trigger Cancel Irrigation Unlimited"
      description: When any solanoid is switched off, then cancel zone within Irrigation Unlimited
      trigger:
        - platform: state
          entity_id:
            - switch.g0272_irrigation_lawn_front_of_berms
            - switch.g0273_irrigation_lawn_between_pool_and_kitchen
          from: "on"
          to: "off"
      condition: []
      action:
        - service: irrigation_unlimited.cancel
          data:
            entity_id: >
              {{ states.binary_sensor | selectattr('attributes.user_entity_id', 'search', trigger.entity_id) | map(attribute='entity_id') | list }}
      mode: single

So the above automation basically listens to event where the state of any of the mentioned (underlying solenoid valve) switches changes from on to off, and then cancels the corresponding zone (binary_sensor) within irrigation unlimited.

Note that attributes.user_entity_id is a custom attribute which mirrors the object user->entity_id within the zone schema, which is basically passed through and was recently added.

Additional context
To make the above automation more handy, can I kindly request to add entity_id as an attribute to the zone binary_sensor which then eliminates the need to make it a custom user element.

Alternatively, could you please consider what options are available to integrate the above automation as either optional or default to irrigation unlimited?

I am aware that _ entity_id_ could be a list (ie multiple entities) and not sure how to deal with this from a group point of view, ie what if 4 switches under one entity, would it require to have all 4 of to cancel the zone.

In addition, there is the question of what does cancel mean - just cancel or also to adjust the time initially dedicated to this zone that is now off by reducing the time to zero ie service call adjust_time with negative remaining time left of the now switched off zone.

A lot of food for thought but I hope the above will help to resolve the use case scenario that I immediately have experienced.

Thanks,
Martin

[rgc99]

At the moment I think it is best left to an automation, after all it is what HA is good at. A few reasons for this; It is unclear what turning a wall switch off would mean - disable, cancel, pause and subject to interpretation. Turning it back even more confusing - enable, resume, manual run. It may not be a physical switch but a button on a card. As you mention what about groups, any one (OR) or all (AND). Never say never but it has too many loose ends.

Perhaps better to pursue pause/resume functionality giving the tools required to build the necessary automation. One thing however is you should turn off check_back: or it will change it back.

check_back:
  states: none

Regards
Robert

[evercape]

Hi Robert,

Thanks, have added the check_back: on controller level.

Do you think it is worthwhile to add the entity_id object from the zone schema to zone's binary_sensor as an attribute, similar to how you pass through the more parameters from FR143?

Thanks
Martin

[evercape]

Hi Robert,

Have added the switch entities in pull request.

Might come handy for others who us KNX a lot and want to further automate around that.

Closing this ticket now, as there isn't really much else required. Thanks again.