The monitoring fits best where the frequency is set using the number of days model, lets use 3 days as an example. So if the controller is inactive and the program runs the last ran time would be updated and the system would wait another 3 days resulting in 6 days between watering events. If the program does not run, and the system is active again the program will run at the next runtime after the system is active, missing, hopefully, only one day of watering. This is to make it as robust as possible if you are away from home and not aware that the system was offline. I do have a to-do to monitor the individual switches that represent the zones in case they go offline, this will be a better implementation that does not need the additional sensor exposed.
The interlock is really a failsafe, in case someone (lets say the non techo person of the house) alters the start time of a program with the some unexpected result e.g. not enough pressure to water correctly, over watering⊠I agree it is typically not a problem, but itâs a feature now that can be controlled, prior to this it was a poorly documented default.
Hi, when installing from HACS (new install), i get âNo matching entities foundâ to âStart time entity*â and others. Do I have to define the entities in configuration.yaml first ?
You need to define the entities that allow you to control the features you want. I did tinker with creating these programmatically but it was not consistent with the way HA was travelling and I abandoned that path.
I have have moved away from defining the helpers in YMAL and create them via the Helpers tab in the Settings, Devices and services paged, I find it easier and there is no need to restart HA when you add new ones.
I would recommend you create.
For the program:
Input_datetime for the program start time (time only)
Input_boolean to support the toggling of the configuration in the custom card
Input_boolean to support the enabling/disabling of the program
For each Zone:
Input_number to provide the duration of the watering cycle
Input_select to define the frequency you want the zone to run, you can do this on the program if you want and save a few entities but I have different frequencies on some zones
This will get a basic setup running, have a read of the notes on GitHub and try a few of the other features.
Hi guys.
Iâm having some issues configuring the component.
I want to add more programs, and I canât find how to do it. I can only set the program up with different zones, but I want different programs so I can be more specific with the time and days.
Any idea?
In the past, it seems that it was done by .yaml, but I canât find the .yaml file either.
Any help would be much appreciated
You can add more instances of the integration. From the âsettingsâ/âdevices and servicesâ menu option click âadd integrationâ and search for âirrigation controllerâ select the integration to add it and configure using the config flow process. Irrigation-V5/README.md at main · petergridge/Irrigation-V5 · GitHub
HA is generally moving away from YAML for the configuration, it has introduced the config flow model that provides for a UI based configuration, generally a better experience for users. The yaml is hidden away in the .storage hidden folder. But that is best left alone.
Hi, is there any way I get rid of run_freq tab of each zones I declare in config? I have to mention not any of zones has run_freq declared, I left it blank when I config them; beside this It keep showing up. I also tried to edit switch.py but no success
Hi @petergridge, thanks for the well done fix update, youâre the man; great work by the way. I just have one more question, as input_select freq interval, I set up in option like bellow:
â1â, â2â represent the days interval to start? because seems like is not working for me.
Only this option is working: * â[âMonâ,âTueâ,âWedâ,âThuâ,âFriâ,âSatâ,âSunâ]â
Amazing Work. @petergridge Is there any special trick to make the Inter Zone Delay Work? For me, it seems to do nothing. It simply stops one zone and goes to the next one. Even the total counter does not consider it.
In the example below I have a delay of 5min and 3 zones (each with 5min also).
For me this is relevant because Iâm setting this up to take advantage of the photovoltaic quarter cycle counting system.
Hi @Magno, the delay is measured in seconds not minutes, try 300 for the value. You are correct though, I do need revisit the program runtime to include the delay. The initial use case was for small delay so it was implemented in seconds. I also should update the documentation to reflect this
Hi @petergridge is it posible the âlast_ranâ result to be added as an option for zone config? It may be displayed also on Program Data as an option. I would like to be not shown on card tfor each zone.
thanks
Hi all
Is this possible to add the next runtime info ?
Other question :
Iâd like to link this integration with real mete information (last rain and next daily rain) to compute if I have to launch irrigation or not. Not a problem for that because I can use rain_sensor features.
Is it possible to have the rain_sensor for program ? I have a lawn programm with 4 zones and itâs more simple to use rain_sensor with the program it-self instead of create one entity rain_sensor by zonesâŠ
Other question.
If my frequency is set to 3 days.
so the D day, my rain_sensor decide to not turn of irrigation, whatâs is the next runtime ? Tomorrow or in 3 days ?
My question is about this runtime calculation.If my lawn need water each 3 days and ifâs raining a litle, probably that the lawn donât need at D day irrigation but maybe tomorrow and not in 3 days.
What do you think about that ?
On my old jeedom domotique, I writed a script wich compute at each runtime start irrigation if there is a need of irrigation.
If Yes, OK , launch irrigation and then compute next runtime time with the frequency.
If No, no Irrigation, and report next runtime time to tomorrow.
As this in case of rain, irrigation starttime is compute each day with rain history sensor and daily rain forecast.