I’ve only snatched a few minutes to look at this but I think the problem is that your switches don’t have the word ‘zone’ in them!
I look for a name with ‘zoneX’ you have ‘relayX’.
There are several ways around this…
I need to have a pattern to look for in switch names that I am sure will appear in everyone’s switch name.
So I can think of three options:
I ‘insist’ everyone (re)names their switches to include the string ‘zoneX’
I add extra checks to look for other possible strings, such as ‘relayX’
I just look for a digit (i.e 1, 2 ,3 … etc.)
There are pros and cons to all these solutions.
This would affect some people who would need to rename their switches (and I would need to update the documentation)
This would make clunky code and I would never be sure I had included every option
This would run the risk of someone using numbers inappropriately and also I am hoping to add changes soon that allow an unlimited (theoretically) number of zones so I’d have to search for double digit numbers and everyone would have to rename theirs to ‘01’, ‘02’, etc.
My preference is for option 1 but I am open to any other suggestions…
In NodeRed, I “simply” check each real names of my switches and then update the relative sensor.
The code should already know the number of zones defined and the switches real names (in input_text.irrigation_zoneX_switch_entity_id), so maybe another way is to do it per single zone, without caring of the zoneX, relayX or others in the switch name, even if wouldn’t be the best optimized way, but at least you don’t have to ‘insist’ on switches naming.
Yeah, I’d thought of that… An automation for every zone instead of one automation that checks all zones. Not the most optimized way but maybe it would be best that way…
I’ll think about it.
Whatever I do, I can’t work on this for a couple of days.
If you want to change your code in the meantime so that you get history data then in the automation you can change the action by replaceing all the
Probably, a fast way could be to adapt the naming of the switches to ‘zoneX’ or to modify that automation reflecting the switch naming.
If explained well, as you already did with the Readme and Prerequisites, should not be an issue…
Hello,
I just wanted to mention that the HowTo that you referenced is complete, the integration of your implementation according to it is ok, with the mention that for me all the browser_mod dialogs work in Win7, Android but not in Win10, but I think this is some problem with my browser/firewall/antivirus that I am still researching.
I found the way!!! Easy and without any issue and without any cons.
In the automation Irrigation Synchronise Sensor Zone Switches in the file garden_controller.yaml in the package folder, in the action of the automation just replace the actual - service: homeassistant.update_entity with this
- service: homeassistant.update_entity
data_template:
entity_id: >
{% if states('input_text.irrigation_zone1_switch_entity_id') in trigger.event.data.entity_id %}
sensor.irrigation_sensor_zone1_switch
{% elif states('input_text.irrigation_zone2_switch_entity_id') in trigger.event.data.entity_id %}
sensor.irrigation_sensor_zone2_switch
{% elif states('input_text.irrigation_zone3_switch_entity_id') in trigger.event.data.entity_id %}
sensor.irrigation_sensor_zone3_switch
{% elif states('input_text.irrigation_zone4_switch_entity_id') in trigger.event.data.entity_id %}
sensor.irrigation_sensor_zone4_switch
{% elif states('input_text.irrigation_zone5_switch_entity_id') in trigger.event.data.entity_id %}
sensor.irrigation_sensor_zone5_switch
{% elif states('input_text.irrigation_zone6_switch_entity_id') in trigger.event.data.entity_id %}
sensor.irrigation_sensor_zone6_switch
{% elif states('input_text.irrigation_zone7_switch_entity_id') in trigger.event.data.entity_id %}
sensor.irrigation_sensor_zone7_switch
{% elif states('input_text.irrigation_zone8_switch_entity_id') in trigger.event.data.entity_id %}
sensor.irrigation_sensor_zone8_switch
{% else %}
none
{% endif %}
And everything seems to be working.
It should be double checked by others, just to be sure it works for all…
I can’t believe I missed that!
Myabe my excuse can be that it was a case of looking at something for so long you end up having no idea what you are looking at…
But will this scale above 8 zones dynamically? Personally I’d rather opted for a “fixed” naming convention *zoneX and scale dynamically, than having to edit a bunch of code to adapt to different number of zones. My 2cents worth…
For the “is it raining / did it rain” - I still have an old Rainbird rainsensor which works like a switch/relay - I wired the common of my zone through it, so even it the cycle runs for some reason and it rained the valve solenoids cant turn on. The history tab will be a bit off, but the plants wont be drowned.
That’s a good question. In a word the answer is, no.
But…
It would be (as far as I know) impossible to write a system that dynamically adjusts completely to any number of zones using pure yaml (I am sure with some Python modules it would be possible) and to be honest when I wrote this I never even considered more than eight as that is all I wanted In fact I never expected this much interest in it because whilst Version 1 was used by a few people as far as I could tell there wasn’t much interest or activity in its development.
As it stands now, in order to extend it you have to at least add extra input_*. There may be other things but the only person I know who is actually doing this is @Athan. They have adapted the code and offered some suggestions for changes to make that adaptation simpler.
This change in particular is really a fix to a coding error that should never have been there in the first place and simply makes the history work as intended and restores the status quo.
I am very open to changes to make it scale to more zones and it would be great to make it as dynamic as possible but at the very least I do hope that at some point there will be documentation about what changes/additions are needed to implement this.
Hmm… if I understand correctly I don’t think it will because the History is based on the actual time that actual switch is on. If your Rainbird sensor stops the switch turning on then no ‘history time’ will be recorded.
There may be other things but the only person I know who is actually doing this is @Athan.
I have a repository that i forked from @klogg and keeping it updated with his latest changes. I have choose to have up to 16 zones. Keep in mind that i haven’t change the core code (except from the changes that i have already propose to Klogg), i just manually added the extra code that needed to support the zones.
Hi i have a issue with the updated item_cycle_start_time.yaml below, when i switch back to the previous version item_cycle_start_time.yaml all is working ok, and can’t work out why its not loading the new file and everything checks out ok in the HA logs ?
(and well done)!!
In fact I never expected this much interest in it because whilst Version 1 was used by a few people as far as I could tell there wasn’t much interest or activity in its development.
