Irrigation Unlimited Integration

It can directly control anything that responds to the HA turn_on and turn_off service calls. This is everything in the light and switch domains. If there is something else like a motorised valve that presents itself in the cover domain for example then use an automation to control it. More information and an example can be found in the documentation here.

I am guessing there is an adjust_time for the sequence in play - posting the log would help. In this case the duration: parameter for each zone is stretched or compressed to fit the new time. Try resetting any adjustments.

I’ve attached the logs below. I did n’t notice any time offsets on the zones.

2023-10-17 13:42:18.938 INFO (MainThread) [custom_components.irrigation_unlimited] EVENT [2023-10-17 13:42:14] controller: 1, zone: 4, state: 0
2023-10-17 13:42:18.938 INFO (MainThread) [custom_components.irrigation_unlimited] EVENT [2023-10-17 13:42:14] controller: 1, zone: 5, state: 1, data: 5.3.1.3.1
2023-10-17 13:43:23.436 INFO (MainThread) [custom_components.irrigation_unlimited] EVENT [2023-10-17 13:43:21] controller: 1, zone: 5, state: 0
2023-10-17 13:43:23.437 INFO (MainThread) [custom_components.irrigation_unlimited] EVENT [2023-10-17 13:43:21] controller: 1, zone: 8, state: 1, data: 8.3.1.4.1
2023-10-17 13:44:28.007 INFO (MainThread) [custom_components.irrigation_unlimited] EVENT [2023-10-17 13:44:28] controller: 1, zone: 8, state: 0
2023-10-17 13:44:28.008 INFO (MainThread) [custom_components.irrigation_unlimited] EVENT [2023-10-17 13:44:28] controller: 1, zone: 9, state: 1, data: 9.3.1.5.1
2023-10-17 13:45:39.065 INFO (MainThread) [custom_components.irrigation_unlimited] EVENT [2023-10-17 13:45:35] controller: 1, zone: 9, state: 0
2023-10-17 13:45:39.065 INFO (MainThread) [custom_components.irrigation_unlimited] EVENT [2023-10-17 13:45:35] controller: 1, zone: 0, state: 0

It’s the ‘Spring/autumn’ schedule firing but the time is supposed to be 12:25 yet the log has it running at 13:40. Something doesn’t add up. To fully understand I need the log going back to when the component was loaded like below.
2023-10-10 11:30:25.648 INFO (MainThread) [homeassistant.setup] Setting up irrigation_unlimited

thanks for the explanation, I will experiment this solution

would be great! I have already setup one such entity per switch. a timeout parameter would be interesting I think

An entity_id: parameter has been added to the check_back object. Code is available in the repository. Let me know how you get on.

I am using KNX (because its wired, super robust) and I really like the MDT switch actuators with current measurement which provide additional feedback.

https://www.mdt.de/en/products/product-detail/actuators/switch-actuators/switch-actuator-ami-current-measurement-series-03.html

A bit of an overkill but super robust.

Well done! Here what I checked. I simulated a non update of the returned state. With a delay of two seconds and retries set at 3, 3 sync errors have been triggered and one switch error. In order to make sure that the switch command is sent whenever a retry occurs, it has been manually switched off before it. The switch is indeed switched on.
However I’m wondering how can I make sure the switch on command is sent despite its On state. As off now nothing in the log makes me think it is done neither in the MQTT traffic. Any thoughts?

I also have a similar case - I am using KNX to switch, and KNX has a switch AND a state object:

pack_irrigation:
  knx:
    switch:
      - name: "G0272 Irrigation Lawn front of berms"
        address: "4/1/0"
        state_address: "4/1/1"

and then within the irrigation_unlimited:

  irrigation_unlimited:
    controllers:
      - name: Lawn Areas
        zones:
          - name: "G0272 Irrigation Lawn front of berms"
            entity_id: switch.g0272_irrigation_lawn_front_of_berms

with the following sequenc:

sequences:
          - name: "Run 1 - Mornings"
            schedules:
              - name: "October"
                time: "17:18" #my test time
                weekday: [mon]
                month: [oct]
            zones:
              - zone_id: 1

When the irrigation starts automatically and let’s say 2 minuntes into it I use a button or the HA UI to set switch.g0272_irrigation_lawn_front_of_berms = ‘off’ the controller is not affected at all, even though granularity is set to 30 seconds.

So the irrigation works properly but an “external” switching of the actual switch does not automatically switches of the zone 1 - it just keeps on running.

Can you please post how the check back object works?

Maybe I am missing something here?

I am not sure what happens under the hood exactly if you tell HA to turn on something it thinks is already on. It probably depends on the implementation within the domain.

Check back is intended to improve the reliability of switches in particular WiFi, ZigBee, ZWave, cloud based etc. that are prone to missing a beat now and then. It reexamines the switch after changing the state. If a discrepancy is found it will log a message and attempt to resync.

I have some zigbee switches that sometimes don’t respond to the on/off commands. They briefly appear in HA as the intended state but after a few seconds revert back to the original state. It seems the zigbee network reports back to HA the message was undeliverable and HA restores the original switch state. I have it configured to send an email if the switch causes a problem.

Thanks Robert for coming back so quickly.

I now understand “check_back” better, thanks.

I am not sure if irrigation_unlimited supports this functionality already or not. The way I think it should work is as follows:

  1. irrigation valves are switches. HA is a virtual representation of a physical/electronic/electric switch that controls the motor of the valve.

  2. Most switches (such as a rocker wall switch) incorporate the actual switching element with a physical / visual representation of the switch state in one element. for instance light is on if rocker wall switch is up, and off if down.

  3. KNX typically uses two group addresses, one for switching and one for state. This for instance makes sense if the actual switch on/off procedure can take time (long dimming off, switching a motor off, …) or if something is off due to a power failure even though that a device was not ‘actually’ switched off, or after reboot of KNX gateway. See this reference.

  4. In KNX language we refer to the actual ‘electronic switchgear’ as actuators. Most electronic geeks simply call it ‘relays’. More advanced KNX actuators even measure the current as additional confirmation that something is actually on or off (for instance a switch that is on, and its state that is on, only switches on a light if there is mains power and the DB board breaker has not tripped). Most actuators also have a manual switch on the actuator that triggers/toggles the switching. See this link to some common switch actuators in the KNX world.

  5. So, after a long introduction to switching, I am of the opinion that there might be a few use cases where an irrigation valve (relay, actuator, …) could be switch (at least off) independently from irrigation_unlimited controller doing that switch_off job. So my proposal is that if that is the case that, whilst for instance zone_1 is running and switch entity of zone_1 is being switched off that should be “known” by irrigation_unlimited and that trigger an off function.

  6. What is that off function? It could be a service call suspend by remaining run time of zone_1 (which means an external process can switch zone_1 on again and it continues running. Alternatively it could be service call adjust_time by negative remaining run time of zone 1, which means that zone is then “completed”.

Robert - I am happy to provide access to my KNX setup (or a replica setup, I can give you access to proxmox virtual environment with KNX if needed) or to do extensive testing and provide log files if needed, although I am pretty sure that KNX switches operate almost the same as other switches on HA.

Once again, thanks for such an amazing integration and your willingness to constantly upgrade it with user input.

Cheers
Martin

PS: If you prefer to log a bug request on github, let me know will gladly do.

From what I saw, it does nothing, that is it does not resend an On command, which somehow is understandable. So in order to correct a discrepancy between the logical state (button state) and the physical state (relay state), it would be necessary to send a double toggle command with a short delay between both. What do you think?

In other words check_back does not try to set the wanted state, but reports that state has not been set correctly. Am I right? Somehow this is saying the same thing as my post just above, isn’t?

Very interesting gear. What kind of KNX/IP interface or router are you using?

@kolia

I have used various KNX interfaces in the past.

Before deciding that Home Assistant is the rolls royce of home automation, I was quiet set on Gira, so I am using the Gira X1 as interface and Gira S1 as secure gateway/remote/VPN access.

Unfortunately, big mistake, as Gira cannot even deliver 1% of what HA can. The company is slow to respond to feature request and bugs, and their software does only work badly on Parallels (ie I am a Mac user).

On the other hand, KNX is a super robust network. When building a new home (which I have done a few times), then it is best to use wired KNX. It has never failed me, not even once. I run more than 130 devices using in access of +1,000 group addresses and the bus is extremely stabile.

What I like about KNX is that it runs over a paired cable, with auxillory power supply over a second pair. In addition, one could add wireless, TCP/IP backbone and even powerline (via existing electrical network) if need be.

Most of the KNX devices that I use are from a German company called MDT. I find them less expensive than most others, very well through through from a product feature / KNX programming point of view and yet mechanically/electrically very robust.

I mostly rely on actuators and sensors, and try to do as little of logical programming within the KNX network. It is not that great, and a software solution like HA on top of a KNX network does this much better. In addition, most KNX visual devices are not as great as HA in terms of flexibility and device range (since they are browser based, literally work anywhere and everywhere).

KNX devices are much more expensive than ie ESPHome based relays or sensors, but probably more robust mechanically and from an electric/power supply point of view. The KNX license is not cheap either, I think around EUR 1,000 for a cloud based license on ETS6. You will need the professional license very quickly, the home version is rather limiting.

Lastly, KNX community is not bad, but nothing compared to HA and ESPHome. Since I started of with HA, I am not looking back. I run a number of HA via Proxmox on Intel Nuc and love it.

1 Like

Thank you very much for the thorough information. Without any doubt if I was to refurbish a new house or build a new one, I would go this route. Whenever I can I choose wired connections, unfortunately in old houses it not always possible.

1 Like

@rgc99
Robert, I have added a proper issue on github for this.

Check back does try to set the state again but HA is preventing the message because it thinks it is already in that state. The only way would be as you suggest to toggle the switch.

I agree. Is it something you may consider?