Is this an update or the original that you noted earlier?
My previous note was a little premature, I had submitted to HACS but it had not been released yet.
Hi all!
I’ve found this component while looking for a “smart way” to automate my DIY irrigation system and I like it!!
My irrigation is based on an ESPHome with a display and manual controls for each zone (I like the approach to have also manual/physical control for some devices). The controller has 3 zones and a water pump control, and each zone has it’s own timer for manual controlling the valve and the pump.
To integrate this with HA I can set through a service call each zone timer before starting a “smart” irrigation program, so the progress of each run is on the controller side once it was started. When that zone finish I can continue with next one.
I’m wondering if there is a way to call the ESPHome service with each “Zone start” event in order to send the time calculated with this component and wait until the zone finish to continue with next one. Or maybe better, a configurable service to call when each zone must start.
Any advise to a way to get this will be appreciated.
And thank’s again for the contribution with this component!
Hi,
I use an ESPHome implementation to run my irrigation system. It exposes each zone/pump as a switch and I let this integration to turn on and off the switches.
I have one event that fires each time a zone is started. I can extend this to provide the expected run time. I am not sure how this will behave with the eco (water, wait, repeat) functionality and your ESPHome code. I can provide more information in this event based on your requirements.
But I would reverse your implementation to use the ESPHome as the driver to control HA by using service calls (https://esphome.io/components/api.html) trigger individual zones in HA and allow this integration to control your pump and zones when you start a zone manually. So each button fires a service call to HA to start the appropriate zone.
You can also read from HA to get remaining time etc to display on your screen, we may need to add some functionality to support this but is should not be to hard.
Cheers
Pete
Hi,
Here is some sample code (partially tested) that should set you on the right direction. The remaining attribute will be available in a few days with a new release that I am testing now. but you can use one of the zone remaining time attributes to test.
Note the text_sensor: and homeassistant.service: features that will allow you to integrate with this component.
substitutions:
devicename: esp_irrigation
friendlyname: Irrigation
maxruntime: 30min
sprinklericon: mdi:sprinkler
pumpicon: mdi:water-well
esphome:
name: $devicename
platform: ESP8266
board: d1_mini
wifi:
networks:
- ssid: xxxx
password: !secret wifi_pw
manual_ip:
static_ip: 192.168.1.110
gateway: 192.168.1.1
subnet: 255.255.255.0
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
i2c:
sda: D2
scl: D1
scan: True
id: bus_a
pcf8574:
- id: 'pcf8575_hub'
address: 0x20
pcf8575: True
# tested !
text_sensor:
- platform: homeassistant
id: remtime
entity_id: switch.test_irrigation
attribute: remaining
font:
- file: 'arial.ttf'
id: font1
size: 18
display:
- platform: ssd1306_i2c
model: "SSD1306 128x32"
reset_pin: GPIO00
address: 0x3C
lambda: |-
it.printf(0, 0, id(font1),"Rem %s", id(remtime).state.c_str());
binary_sensor:
- platform: status
name: $friendlyname Status
- platform: gpio
internal: true
pin:
pcf8574: pcf8575_hub
number: 8
mode: INPUT
inverted: true
filters:
# hold for half a second
- delayed_on_off: 500ms
on_press
- homeassistant.service:
service: irrigationprogram.run_zone #irrigation program service
data:
entity_id: switch.test_irrigation
zone: switch.dummy_2
switch:
- platform: template
name: $friendlyname Solenoid 01
id: solenoid01
icon: $sprinklericon
turn_on_action:
- switch.turn_on: relay01
- delay: ${maxruntime}
- switch.turn_off: relay01
turn_off_action:
- switch.turn_off: relay01
lambda: |-
if (id(relay01).state) {
return true;
} else {
return false;
}
- platform: template
name: $friendlyname Solenoid 02
id: solenoid02
icon: $sprinklericon
turn_on_action:
- switch.turn_on: relay02
- delay: ${maxruntime}
- switch.turn_off: relay02
turn_off_action:
- switch.turn_off: relay02
lambda: |-
if (id(relay02).state) {
return true;
} else {
return false;
}
- platform: template
name: $friendlyname Solenoid 03
id: solenoid03
icon: $sprinklericon
turn_on_action:
- switch.turn_on: relay03
- delay: ${maxruntime}
- switch.turn_off: relay03
turn_off_action:
- switch.turn_off: relay03
lambda: |-
if (id(relay03).state) {
return true;
} else {
return false;
}
- platform: template
name: $friendlyname Pump
id: solenoid04
icon: $pumpricon
turn_on_action:
- switch.turn_on: relay04
- delay: ${maxruntime}
- switch.turn_off: relay04
turn_off_action:
- switch.turn_off: relay04
lambda: |-
if (id(relay04).state) {
return true;
} else {
return false;
}
# Internal Relays
- platform: gpio
name: "relay 01"
id: relay01
interlock: &interlock_group [relay01, relay02, relay03]
pin:
pcf8574: pcf8575_hub
number: 0
mode: OUTPUT
inverted: true
restore_mode: ALWAYS_OFF
internal: true
- platform: gpio
name: "relay 02"
id: relay02
interlock: *interlock_group
pin:
pcf8574: pcf8575_hub
number: 1
mode: OUTPUT
inverted: true
restore_mode: ALWAYS_OFF
internal: true
- platform: gpio
name: "relay 03"
id: relay03
interlock: *interlock_group
pin:
pcf8574: pcf8575_hub
number: 2
mode: OUTPUT
inverted: true
restore_mode: ALWAYS_OFF
internal: true
- platform: gpio
name: "relay 04"
id: relay04
pin:
pcf8574: pcf8575_hub
number: 3
mode: OUTPUT
restore_mode: ALWAYS_OFF
internal: true
Hi @petergridge
Thank you very much for your updates and the sample code.
My approach for the irrigation system is a bit different. From a “fail safe” point of view I let HA doing the “smart” part of managing the schedule, irrigation time calculation based on the weather, and so on. But the “dumb task” of setting a relay state for a period of time is on the ESP side, so if HA fails for any reason, I think it could avoid getting waterfalls at home 
. Even the controller will work manually (with a preset timer) if HA is not available. My ESP controller is running fine for more than a year now.
But my concern now is on the “smart” part of the system, trying to get a more flexible way than an automation (what i’m using now) to schedule the irrigation by sending commands to the controller (Start a zone for certain time).
The component already have an event for “zone_turned_on” but I think it will require extra info, like the timer for the zone irrigation run, to use it with my ESP controller.
Thank you again for your time on this project! I hope my comments contribute to get even more flexible for others. But I understand if this is out of expected behavior.
Hi @adyannu
In that case you can try creating a series of home assistant sensors in the ESP to get the data you need from the HA front end. I am not sure if these persist when the HA connection is lost though.
I have have not had a flooding event on my system (2+ years) but the fail safe of the maxruntime is there just in case and with the api: set ESP will restart by default after 15 minutes if it loses connection to HA (and turn off your solenoids).
You can avoid this in your use case by adding reboot_timeout.
api:
reboot_timeout: 0
If you require more data in the event, provide me a list and I will see what I can add.
1 Like
Hi @petergridge,
I have seen that both the new V5 component and the respective card are available in HACS.
I have installed both, removing my V4… that was working perfectly. 
I have run the setup as described in the notes, using the old entities names, but I cannot see all the components in the card (e.g. last run, water, time, etc.). Do I miss anything to do?
Are the previous inputs in the configuration file to be kept or removed? Thank you.
By the way, can the card be customized? The V4 that I set up before was nicer (see my previous post). 
I also tried to reuse my personal card(s) making the appropriate changes and am running into the same issue with run times.
Everything else appears to be working:)
d
Hi @vic,
This is a new one, just when I thought I had seen most of the failure modes
Just going through the debug questions:
- Can you confirm that installed V5.1.19 for the control and V5.1.20 for the card
- Did you install using HACS or manually?
- Are there any errors in the log file
- Can you check the config flow to verify that the migration worked.
- Can you clear the cache on you browser and retry
I am working on a new version of the card now, trying to streamline it as I agree it is not the best. I am using the entities card as the base so that provides a few limitations, but if it can be modelled in the entities card I can replicate it. Happy for you to provide some ideas.
Cheers
Pete
Hi @petergridge,
thank you for the prompt feedback.
Here to your points:
- Confirmed: 5.1.19 for the component and 5.1.20 for the card
- Using HACS
- The only error I could find in the log is this one:
"...frontend_latest/app.c86c7218.js:850:0 Error: Failed to execute 'define' on 'CustomElementRegistry': the name "irrigation-card" has already been used with this registry". It appeared yesterday when I restarted HA the last time. No warnings on this component using standard traces are visible. - What do you mean for checking the config flow?
This is what I have done:- Removed the definition of the V4 component from the configuration file (I left the inputs definition though)
- Removed the card V4 from the dashboard
- Restarted HA
- Installed the V5 component and the V5 card from HACS
- Restarted HA
- Configured the V5 component in “Setting / Devices & Services” using the inputs entities from the configuration file (they have been suggested in the mask anyway )
- Configured the V5 card to point to the new component entity
- Restarted HA
- The cache was cleared. I do it always when I change something
Cheers
Thanks for the information.
You need to remove the Resouce (Dashboards settings) for the old card that was not installed by HACS. You can also delete the .js file from the www directory.
FYI you did not need to remove the old config it converts to config flow automatically.
I will update the install notes to reflect this issue.
Thanks for letting me know.
Cheers
Pete
Hi @petergridge,
thank you! I did it. It looks better now (see below).
A couple of questions still:
- is it possible to change the names/labels in the card?
- the “run days evening” at the moment is the same for all switches, why not to put it only at the top? Or do you plan to have a parameter per switch in the future?
Cheers
PS
Are you still looking for translations? in which languages?
1 Like
We have German and English, any other language will help extend the translations.
These are used in the config flow. I have considered translating the readme.md but that is a lot of text
For the card all the text is from the friendly name of the object so it is language independent and you can change it any time, i simply name my switches solenoid 1… and then set the friendly name lawn…
I am removing any additional hard coded text.
If your frequency is the same for all zones you can set it on the program definition instead of each zone and that will present as you wanted
Thanks for the feedback!
Everything seems OK now.
For the languages I have sent you a PM.
alpha 2 is available! 
Pre release of V5.2.0
Looking for help testing this release.
This is a big change under the covers I will release this as version 5.2.0 I think it warrants a major release status. There has been a lot of changes under the covers, every time I add more features I find better ways to structure the code. So I am sure you will find issues with this version.
Enjoy
Custom Control
Expanded config Flow to run of a menu for new programs.
- Migrate groups from the UI to Config Flow. Existing groups are automatically migrated to config flow groups can then be added or deleted in the config flow.
- If a zone is deleted or is changed to reference a different switch the affect groups will be deleted
and you will need to add a new group. - This change has allowed better controls and validation of the running of the program and facilitates improvements to the Custom Card
- Interlock - you can now turn off the interlock to let multiple programs run simultaneously. This is designed for large implementations where multiple independent irrigations are required. WARNING: be cautious where multiple programs referencing the same zone.
- Warnings raised in the log when a program is stopped by another program or service call.
- Additional attributes have been added to the event data for the start of a zone
event_type: irrigation_event
data:
device_id: switch.test_irrigation
action: zone_turned_on
zone: dummy_3
pump: null
runtime: 59
water: 1
wait: 0
repeat: 1
- Program/card reacts when a zone switch is turned off manually the zone turns off and the next zone in a running program will run.
- Refactored the watering timer to support:
- program level total runtime
- interactive changes to adjustment values, water/wait/repeat cycle configuration while a program is running
Custom Card
- Zones grouped into a single section. Assuming grouped zones have the same attributes. i.e. use the same input objects
- For large implementations where a single long card is not practical you can now provide a list of zones to show in a card, allowing multiple cards to be displayed for a single program
type: custom:irrigation-card-test
program: switch.test_irrigation
show_program: true
entities:
- switch.dummy_1
- switch.dummy_2
- Make the card more compact
- Display zones in the order they will run
- Removed any boiler plate text to improve presentation in languages other than English.
- Display relative time since a program was run on the card, e.g. 10 minutes, 1 day…
- Zone stop option provided on the card when a zone is running. If you stop a zone the remaining zones of a program will continue
Version 5.2.0-beta is now available.
A BIG thanks for the feedback on the alpha version it’s great to get help finding all the niggly bugs and ensuring the install process is working on an installation other than mine.
Thanks to @vic & @mituns for their help with the translations.
I will promote this to the production version in a few days assuming I don’t get any significant bug reports.
Please review the updated note on the GitHub repository/HACS.
I. currently don’t understand this feature. I had different programs in the past already and they did run independently and partly at the same time.
Do you really talk about programs or is it about zones? Later so normally runs sequentially and such a feature could change that. This would make sense to me, but for programs?
That’s the reason why I still didn’t translate this line, as I am not sure what it actually is for.
Similar for the monitor controller entity, I never used this feature and frankly I don’t understand what it is for.
I added translations for the two errors notes.
Karl
Hi Karl,
Here is some updated notes for the Interlock and Monitor, I have updated to documentation. Let me know if you think I need to expand on any of the other features.
Cheers
Pete
Interlock
Turn off running programs when a new program is started, this is the default.
Note Change this on all program configurations to get consistent behaviour.
With interlock enabled:
- If Program 1 and Program 2 have the same start time neither program will run and a warning is logged.
- If Program 2 starts while Program 1 is running Program 1 will be terminated and Program 2 will run, a warning will be logged.
With interlock disabled:
- If Program 1 and 2 overlap both programs will continue to run.
- If a running zone is started by the second program a warning is logged.
Monitor Controller Feature
If you have a binary sensor that indicates the status of the watering system hardware, you can use this to prevent this system from initiating watering until the system is active.
For example I use an ESPHome implementation to control the hardware that exposes a status sensor, should this lose power or connectivity to Wi-Fi the custom control will not initiate the watering. There will is also a visual indication on the custom card of the status of the controller.
Ok, I now understood the interlock, I will add the translation, for the monitoring as well.
However, I don’t see personally the use case. If the hardware lost connection, than the watering will not run anyway. So is this monitoring ‚just‘ for monitoring (well, ok, that’s what it says 
) so you can see that there was no watering and you can start it again later manually, or will it start the watering once the connection is back?