The enable/disable/toggle shims are not in the pyscript file. These are small pieces of code that convert for example ‘1.1 Zone1’ living in an input_select control into ‘binary_sensor.irrigation_unlimited_c1_z1’ and then call the actual service. They are just helpers sitting between the lovelace card and the integration. There is an updated pyscript/irrigation_unlimited_service_shim.py file in the repository which contain the new shims.
Irrigation valves
I would like to know what the community is using to control their irrigation valves. This topic has been discussed a bit but more is needed. It’s not a perfect world out there and hardware, software, communication or power failure could leave your valve in a permanent on state. Bottom line is a kill switch is needed at the relay in case a turn on signal is received and that’s the last message received…
I am building a zigbee network and use relays combined with a count down module as a dead man switch. Asterion is working on an ESP8266 based relay designed for irrigation valves here. Would like to hear about other solutions.
Your integration is great. I use the card for enabling and disabling zones but I was wondering if there is a way to disable or enable a sequence in the frontend as well. Thanks, Nathan
Hi Nathan, At the moment you can only enable/disable controllers and zones. What you could do as a work around is to adjust the sequence time to zero. I will put it on the feature list which is probably not that hard to do but like the controllers and zones it should persist across HA restarts which complicates things a tad. Enjoy.
When a cycle starts, I have a 2 relay output board switching mains on a 24vac TX and dosing pump
Shortly after that a 5 relay output board switches power to one of the Hunter solenoid valves.
Im using the Always off restore mode just to force the GPIO’s off on bootup.
Hope that helps.
I like the idea of a timer as a backup to shut down outputs I might add that too.
RESTORE_DEFAULT_OFF (Default) - Attempt to restore state and default to OFF if not possible to restore.
RESTORE_DEFAULT_ON - Attempt to restore state and default to ON.
RESTORE_INVERTED_OFF - Attempt to restore state inverted from the previous state and default to OFF.
RESTORE_INVERTED_ON - Attempt to restore state inverted from the previous state and default to ON. > * ALWAYS_OFF - Always initialize the pin as OFF on bootup.
ALWAYS_ON - Always initialize the pin as ON on bootup.Text
Hey there,
Still messing with schedules and still can’t seem to get exactly what I’m after.
I need a sequence as the water pressure will only handle on zone on at a time.
I have 9 zones and would like 3 sequences, Summer, Winter, and the rest.
Inside these, some zones would be on every day, and some 2 or 3 days a week. Checking config, the below won’t work.
I was trying to put just the day under the individual zone and start time, month, etc under the schedule.
Further to the previous post. Just in case this does not go far enough then create three sequences with one schedule each. This will allow complete control over all aspects of the sequence including which zones to run, order, durations, delays, repeats etc. Still want more then create a sequence for each month of the year. This example reverses the order in Spring/Autumn for no good reason and exludes a zone in Winter.
Here is an updated compact card using the timeline feature in the latest release. Similar requirements to the original without logbook-card and card-mod but requires hiu-element
I think the integration is broken in the new HA environment.
Logger: homeassistant.components.sensor
Source: custom_components/wundergroundpws/sensor.py:551
Integration: Sensor (documentation, issues)
First occurred: 8:19:32 AM (1 occurrences)
Last logged: 8:19:32 AM
Error while setting up wundergroundpws platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/wundergroundpws/sensor.py", line 390, in async_setup_platform
await rest.async_update()
File "/config/custom_components/wundergroundpws/sensor.py", line 551, in async_update
with async_timeout.timeout(10, loop=self._hass.loop):
TypeError: timeout() got an unexpected keyword argument 'loop'
after a long rime i just wanted to thank you for all that improvments. i have your component setup and it is now possible to get everything controlled by manual runs - thank you!!
Thank you for the feedback and good to hear it is working well for you. If you haven’t already, try out the new html status card from the current release 2022.3.0. One that note I am looking for someone to help convert it to a ha-card. I am nearing the limits of the HTML-Jinja2 and want to take it further.
The idea is to make the card ‘active’ where you can click on the items (controller/zone/sequence) to perform actions on them. For example, add buttons at the relevant locations on the card or even make the icons active to toggle the enabled status. When you click the item icon it would toggle the enable status by making the appropriate service call. Same concept for the manual run, click on a zone or sequence to start it up.
A few more ideas in store but would speed things up greatly by someone with ha-card/JS/HTML experience. Please let me know if someone reading this can knock one up.
I think about replacing my manufacturer control box with some switches and your integration and read you github-page and this thread. But either I didn’t see the answers to the questions below or didn’t understand till now. Would be great, if you can blow away the fog in my mind.
In my old control box I had e.g. a program/schedule which runs the zones a,b and c each after another. But there, I was able to start this program/schedule manually, so zones a,b and c runs outside the schedule. Possible here somehow?
Setup same as above. Run started for a,b,c each after another, either per schedule or manually as in first topic. Assume a is currently running. Then I was able to press a next button, a was stopped/rest ot time skipped and b started. Same is b is running and then c is starting or c is ended if c is running befire. Possible here somehow?
As I look for such manuel states, I found this in this part here. But the used services shim_manual_run and shim_cancel are not in the documentation, aren’t they?
As the times ar defined in yaml. Where are they stored, if I adjust via adjust_time. And how long last this adjustments? Until reboot?
In zone objects, you have the parameter zone_id, required later as reference in sequence zone objects. But you are not using this attribute in any of the examples and only the “list-order”. Why? Currently, I’m struggling with the objects, as I can only partly see in the docs (and only try to understand via examples), which are optional and which are mandatory parameters.
I was struggling with something and I think I have figured it out, but maybe I am wrong. I was looking to show the timeline for all my 20 zones… When I looked at the sample below, it shows me that I would enter the ‘all_zones_config:’ under ZONES: but when I put the three lines in my YAML, it errors.
When I read the documentation, I think it was supposed to go under the CONTROLLERS: no? I was just looking at the example under the Timelines section of documentation.
Thanks in advance.
I have to tell you, for the longest time, I was a bit envious of this add on, but I did not connect the dots that I could control my HydraWise Controller using this add-on sending in manual switches to my controller. Once I made the connection, I spend the morning getting this all integrated. I have to admit that I am still trying to figure out the sequences vs. schedules and how they will all nest, but I think I am close. I may have another question for you on my strategy on building my sequences, but let me first play with it. LOVE IT - awesome job. If I get this working, I will be thanking you more appropriately for building this.
irrigation_unlimited:
controllers:
zones:
all_zones_config: # <= Add these three lines <─┐
show: # <= to the configuration <─┤
timeline: true # <= for all zones <─┘
entity_id: “switch.my_switch”
show: # <= Add these two lines to the <─┐
timeline: true # <= configuration for individual zones <─┘
schedules:
- time: “06:00”
duration: “00:20”