Add optional "volume_entity" to a zone for tracking/controlling based on volume #131
Comments
|
This is along the lines of issue #101. It would be great to be able use either volume or time as a base. Not sure how to monitor the volume 'ticks' or consumption. Maybe a notification mechanism for each unit of water used much like a water meter. Any thoughts on this? |
|
I currently track water volume for each zone with the following code. There is one physical meter (sensor.556) that never resets And automation. Irrigation_unlimited watering uses sequences, hence there is only one watering at a time. Each time a sprinkler is on is resets its corresponding virtual meter, and when the sprinkler goes to off the value of the virtual meter is sent to the input_number of corresponding water circuit. |
|
@Kolia56 Thank you for the suggestion, that could definitely work as I already maintain total volume per zone run independently from irrigation_unlimited via pyscripts but I fear with upwards of 12 zones on two independent controllers the solution could become pretty cumbersome and difficult to maintain. @rgc99 One way I could see this managed in irrigation_unlimited would be as followed:
|
|
Sorry to be a bit tardy. I am travelling across the Kimberley on a spot of vacation. Will follow up on this in due course. |
|
I would like to gather some sensor sample data in a text file. This would be used feed the data to the test framework. Not exactly sure how to implement this but that is where we need to start. Perhaps this article might help to harvest the data we need. Probably a csv file with datetime stamp and state value on each line. More data the merrier. Also a variety of systems byhyve, taplink and whatever anyone else can provide would be great. Rather than polling I think tracking the entity state change would be the way to go. Don't then have these agonising decisions about polling too much or too little. |
|
I'm quite ready to volunteer on this matter. However I'm not too sure to understand what is the kind of sensor from which data is needed. Could you elaborate a bit further? Thank you |
|
The idea is to capture data from the water usage sensor. This will write a file notify:
- name: irrigation_sensor_log
platform: file
filename: irrigation_sensor_log.txt
timestamp: True
automation:
- alias: Write Irrigation Sensor Data
trigger:
- platform: state
entity_id: sensor.556
action:
- service: notify.irrigation_sensor_log
data:
message: "{{ trigger.to_state.state }}" |
|
Thanks for the code, I had no idea of the existence of notify/platform: file. Code is in place. How may days do you wish? |
|
Yeah, only learned about file platform a few days ago myself. I think a day would be enough but also the Irrigation Unlimited log file so I can see the on/off events that overlap with the water sensor log. |
|
We'll have to wait a bit, we had 3 rainy days, so no watering data, HA Smart Irrigation has decided on its own;) I am expecting some data tomorrow. I added the state of the various sprinkler switches in the code in order to get everything in one file. |
|
This is a first try. Watering was decreased to 17% of the nominal time hence the short watering times. You'll notice that except for the first one, switch on state is not logged. This is due I think to the two events arriving at the same time closing one valve opening the next one. I'm pretty sure if a 1" delay is set, it will be logged. I changed the config for the next run with such a delay. In the meantime you have to consider that each off state is followed by another on state. For instance when switch.562 is set to off switch.564 is set to on. |
|
Please find some more data |
|
Thanks, can I also get the current matching configuration. Also was there any adjustment in play? |
|
Here it is. Sequence 1 / night was indeed adjusted. |
|
The timestamp is a bit inconvenient as it is in UTC while the config is in local time. Took a guess local time was GMT+2 and things seemed to line up. It would better to turn off the timestamp in the notify and add it manually in the automation message. notify:
- name: irrigation_sensor_log
platform: file
filename: irrigation_sensor_log.txt
timestamp: False # <=== Change this
automation:
- alias: Write Irrigation Sensor Data
trigger:
- platform: state
entity_id: sensor.556
action:
- service: notify.irrigation_sensor_log
data:
message: "{{ now().isoformat() }}; {{ trigger.to_state.state }}" |
|
Indeed this is GMT+2. I made the modification. How many days of data do you wish? |
|
At the moment just a single sequence run would be great. |
|
There's an initial draft in the repository. It's collecting the sensor information and displaying in a "volume" attribute in the zone i.e. binary_sensor.irrigation_unlimited_c1_z1. Add the following to the configuration: zones:
- name: "Zone 1"
volume:
entity_id: sensor.556
...As you use a common sensor it might be easier to do: all_zones_config:
volume:
entity_id: sensor.556Please check it out and see if the volumes on the zones tally to what you expect. |
|
I made a first quick test with zone_id: 8. Volume attribute reports 9 liters which is exactly my figure. Well done! We shall wait until tomorrow morning (GMT+2 as you know) to get a complete cycle. |
|
After a complete night cycle I confirm that all volumes data are correct. |
|
Great, now we have the volume monitoring accurate I would like to lock in a test. I need a new irrigation_sensor_log file with the updated timestamp, expected volume results for each zone, any adjustment in play and config if it has changed. This will help moving forward that changes do not effect these readings. |
|
ok I will prepare that. To make sure I understand correctly, could you clarify what you are expecting in regards to "expected volume results for each zone". Are you after the watering nominal volume for each zone when there is no adjustment (i.e. 100%)? |
|
No, as you would have calculated including the adjustment. The idea is to replay that one night sequence run every time there is a code change. |
|
ok I see, so you want to make sure there is no code regression, when a code change is made. So I wait till you let me know there is a need for a new test. In the meantime I added the adjustment figure in the log file. |
|
I think the code is fine. Would like to get an updated log file and complete the test unit for the volume metering. Could you also post the data collection automation. I will put all of this in the repository and we can move on. Would it be useful to have a |
I think From the above post I can see that this has been provisionally implemented and tested on all zones/each zone. May I also suggest to add it on controller entity (in a similar way as switch entities are available there too). From an alarm point of view, Use case scenario as you suggest to disable zone/controller if pressure drops below certain threshold parameters that could be part of the irrigation_unlimited yaml configuration. |
Here is the log file Here is te code automation
|
I do have a pressure sensor as well, so integrating this into Irrigation unlimited is certainly nice to have. |
|
I have taken the sample from 13-Oct 22:00pm through 14-Oct 04:00. These are the volume readings |
Hi Robert, I just got back from vacation and going through your many updates. Thanks for continuing on those. With regards to #142, you say in the above comment that there is a freeze possible. Can you please advise how I can stop/freeze a running sequence (or all) and then continue/unfreeze them? Documentation 7.1 has a toggle but it only enables and disables a zone/sequence/entity etc. On another note, documentation 7.2 also talks about enable/disable/toggle whereas I think it should read suspend instead. It would be amazing to better understand how I can achieve the pause/continue or freeze/unfreeze scenario as explained in #142. Thanks |
|
Hi Martin, Sequences now have an associated entity i.e. It's more of a freeze because the state remains as is. If it is on it will remain so until another Code is ready for release. Feel free to update from the repository and let me know of any issues. |
Have posted testing results here: |
|
When your system has woken up from hibernation I would like to test out the volume limit functionality. Add a |
ok I will let you know when it is done |
|
So it has been tested on one circuit from 14, which is the easiest to woken up from hibernation. Freezing period will be behind us mid May. |
|
Thanks for the testing and your kind comments. I do want to get some more testing data but will wait until May when your system is unfrozen. |
|
Thanks for the detailed information.
Could you let me know what kind of testing scenario you'd like? Since the freezing season seems to be behind us, I started to wake up the system, so I may perform tests sonner than expected.
Excerpt of irrigation configuration controllers:
- name: "Controleur 1"
all_zones_config:
show:
timeline: true
allow_manual: true
volume:
entity_id: sensor.556
# duration: "0:10:00"
volume_scale: 1000
flow_rate_scale: 60
flow_rate_precision: 1 |
|
I really can't explain the flow rate results. If you could capture the sensor data it would help a lot. I can then replay it into my test system. |
|
I did not have time so far experiment what you are looking for. I think it will be around May 10th.
Could you elaborate a bit. I do have a pressure sensor as well and at some point in time I was thinking to drive pump speed depending on the pressure. It turns out that the system that sends the value to HA is not smart enough to send the value when it changes outside a certain window. So I have to poll it very often which is not effective. |
|
As far as flow rate is concerned, the figure is way out when the consumption is low. In the below case binary_sensor.irrigation_unlimited_c1_z7 reports 8 liters (10 minutes) and flow rate 8.6 liters/min
2024-05-10T17:17:15.194961+02:00;switch.ev_id10 (Vanne un carré); on
2024-05-10T17:17:29.507447+02:00;sensor.556 (Consommation grand puits); 277.214
2024-05-10T17:18:50.123945+02:00;sensor.556 (Consommation grand puits); 277.21500000000003
2024-05-10T17:20:11.065546+02:00;sensor.556 (Consommation grand puits); 277.216
2024-05-10T17:21:32.108511+02:00;sensor.556 (Consommation grand puits); 277.217
2024-05-10T17:22:53.047588+02:00;sensor.556 (Consommation grand puits); 277.218
2024-05-10T17:24:14.365606+02:00;sensor.556 (Consommation grand puits); 277.219
2024-05-10T17:25:35.392383+02:00;sensor.556 (Consommation grand puits); 277.22
2024-05-10T17:26:56.104188+02:00;sensor.556 (Consommation grand puits); 277.221
2024-05-10T17:27:15.437472+02:00;switch.ev_id10 (Vanne un carré); off
I noticed that reported volume is wrong in the following condition: when the cycle ends, if for any reason, physical switch is not in sync with its logical counterpart, volume does not increment anymore whereas it should until physical switch is back to off. I do use check_back option. I will shortly perform the volume limitation test. I'll keep you posted. |
|
I found a problem with the flow rate calculation. It was using the initial sensor reading as part of the average. This reading would have occurred at some time before the current on state. Only readings taken within the current on state should be used for the flow rate. The initial value will flush out as it passes through the SMA window (10 readings) and the average will correct itself. This means for the first 9 litres it will be skewed. |
|
Ok that is good to know. As already reported I will install a dedicated flow rate meter. It will add more accuracy to the flow rate measurement. Would you consider adding an option to use such a device in the configuration ? It would need an option in order to set the resolution of the meter which vary depending on devices. Mine for instance is 96 impulses per liter. |
|
This might be done already. Try this setting for the volume scale: all_zones_config:
volume:
volume_scale: 0.01041667
volume_precision: 8It's 1 / 96. |
|
Thank you, I will test that as soon as the new sensor is installed |
|
Hello Robert, |
|
The volume limit works in parallel with the time. The valve is turned off when either the limit is reached or the duration is expired. If you want just volume then the duration could be set to a ridiculously large number. This could be a problem in the event of a malfunction in the metering system. It could be good to use time as a maximum as it's the only reliable constant we have (sorry Einstein). |
Your investment in such an extension is even more incredible knowing that.
This was my guess. The reason I'm was asking is due to the fact that I had an issue with the following configuration. With the volume instruction uncommented the last 3 zones switched on at the expected time but never never went off (zone 2 did switch off). I double checked that the switch entity never got the off command. In other words the hardware behind it is not responsible. irrigation_unlimited:
controllers:
- name: "Controleur 1"
all_zones_config:
show:
timeline: true
allow_manual: true
volume:
entity_id: sensor.556
# duration: "0:10:00"
volume_scale: 1000
flow_rate_scale: 60
flow_rate_precision: 1
zones:
- name: Test
zone_id: "1"
# entity_id: switch.562
enabled: false
entity_id: switch.ev_id1
maximum: "00:50:00"
- name: Café François
zone_id: "2"
# entity_id: switch.562
entity_id: switch.ev_id2
maximum: "00:50:00"
- name: Serre
zone_id: "3"
# entity_id: switch.564
entity_id: switch.ev_id3
maximum: "00:35:00"
- name: If Cour carrée
# entity_id: switch.565
entity_id: switch.ev_id4
zone_id: "4"
maximum: "00:20:00"
- name: Pare-terre Julie
zone_id: "6"
# entity_id: switch.569
entity_id: switch.ev_id6
maximum: "00:50:00"
- name: Deux carrés
zone_id: "9"
# entity_id: switch.713
entity_id: switch.ev_id9
- name: Un carré
zone_id: "10"
# entity_id: switch.714
entity_id: switch.ev_id10
maximum: "00:30:00"
- name: Petits fruits
zone_id: "11"
# entity_id: switch.715
entity_id: switch.ev_id11
maximum: "00:50:00"
- name: Haie - Céanothe - Fleurs
zone_id: "12"
# entity_id: switch.716
entity_id: switch.ev_id12
maximum: "01:00:00"
- name: Pommiers
# entity_id: switch.717
entity_id: switch.ev_id13
zone_id: "13"
maximum: "00:50:00"
- name: Haies pelouses
zone_id: "14"
# entity_id: switch.718
entity_id: switch.ev_id14
maximum: "00:45:00"
- name: Haie du fond
zone_id: "15"
# entity_id: switch.719
entity_id: switch.ev_id15
maximum: "01:00:00"
- name: Tilleul
zone_id: "16"
# entity_id: switch.720
entity_id: switch.ev_id16
maximum: "00:50:00"
- name: Bordure pelouse
zone_id: "17"
# entity_id: switch.720
entity_id: switch.ev_id17
maximum: "00:40:00"
- name: Circulaire pelouse
zone_id: "18"
# entity_id: switch.720
entity_id: switch.ev_id18
maximum: "01:00:00"
- name: Circulaire statue
zone_id: "19"
# entity_id: switch.720
entity_id: switch.ev_id19
maximum: "01:00:00"
sequences:
- name: nuit
enabled: true
schedules:
- name: 1
time: "22:00"
schedule_id: "s1"
delay : 15
zones:
- zone_id: "2" # Café François (id2)
duration: "00:30"
# volume: 200
- zone_id: "3" # Serre et autres (id3)
duration: "00:15"
- zone_id: "6" # Pare-terre Julie (id6)
duration: "00:30"
- zone_id: "9" # Deux carrés (id8)
duration: "00:25"
- zone_id: "10" # Un carré (id9)
duration: "00:18"
- zone_id: "11" # Petits fruits (id10)
duration: "00:40"
- zone_id: "12" # Haie - Céanothe (id11)
duration: "00:40"
- zone_id: "13" # Pommiers (id12)
duration: "00:25"
- zone_id: "14" # Haies pelouse (id13)
duration: "00:20"
- zone_id: "4" # If cour carrée (id4)
duration: "00:10"
- zone_id: "15" # Haie du fond (id15)
duration: "00:25"
- zone_id: "16" # Tilleul - Cerisier (id16)
duration: "00:25"
- zone_id: "17" # Bordure pelouse
duration: "00:15"
# volume: 130
- zone_id: "18" # Pelouse (id7)
duration: "00:20"
# volume: 400
- zone_id: "19" # circulaire statue
duration: "00:20"
# volume: 457
- name: jour
enabled: true
duration: "00:05"
delay: "02:25"
repeat: 3
schedules:
- name: 2
time: "12:00"
schedule_id: "s2"
zones:
- zone_id: 3 |
|
I'm afraid there is a sneaky bug related to volume management. Here is the case. As double check, I made a new run without volume limit as per the configuration above, without a glitch as always since I'm using it. If my memory is correct, a while ago I made a quick test with volume limit activated on one zone and a schedule for one zone. It was ok. I'm wondering whether watering schedule crossing midnight is having an effet. Just a guess. Let me know how I can help. |
|
I forgot to post the log which seems to me it explains what is going wrong |
|
I got to the bottom of it. When the limit is reached it calls |
|
Thank you, test done and ok. Looking closely at the logs, I'm wondering why in some cases a valve is set to On before the current running one is set to off, despite the 15 seconds delay. Have a look at 2024-07-16T23:22:57.064424+02:00 and 2024-07-17T00:33:03.059803+02:00 for instance log |
|
Can you post the automation for generating the log. |
|
Here it is. You'll notice that there has a change in using notify to a file automation:
- id: b9b8ca5f-216a-4b2b-8892-8e47f8c28e69
alias: Irrigation Write sensor Data
trigger:
- platform: state
id: ev
entity_id:
- switch.ev_id2 # Kfé François
- switch.ev_id3 # Serre
- switch.ev_id4 # Salle Claudine (If)
- switch.ev_id5 # Cuisine grande maison (non installé)
- switch.ev_id6 # Pare terre Julie
- switch.ev_id7 # ex Pelouse
- switch.ev_id9 # Deux carrés
- switch.ev_id10 # Un carré
- switch.ev_id11 # Petits fruits
- switch.ev_id12 # Haie - Céanothe et fleurs
- switch.ev_id13 # Pommiers
- switch.ev_id14 # Haies pelouse
- switch.ev_id15 # Haie du fond
- switch.ev_id16 # Tilleul & Cerisier
- switch.ev_id17 # Bordure pelouse
- switch.ev_id18 # Circulaire pelouse
- switch.ev_id19 # Circulaire statue
- platform: state
id: others
entity_id:
- sensor.556
- input_text.smart_irrigation_id7_adjust_time
condition:
- condition: template
value_template: >
{{has_value("sensor.556")}}
action:
- choose:
- conditions:
- condition: trigger
id: ev
sequence:
- service: notify.send_message
target:
entity_id: notify.irrigation_sensor_log
data:
message: >
{{ now().isoformat() }};{{ trigger.entity_id}} ({{trigger.to_state.name}}); {{trigger.to_state.state }}; Consumption: {{states('sensor.water_meter_' ~ trigger.entity_id.split('_')[1] ~ '_std')}}
- conditions:
- condition: trigger
id: others
sequence:
- service: notify.send_message
target:
entity_id: notify.irrigation_sensor_log
data:
message: >
{{ now().isoformat() }};{{ trigger.entity_id}} ({{trigger.to_state.name}}); {{trigger.to_state.state }}
notify:
- name: irrigation_sensor_log
platform: file
filename: irrigation_sensor_log.txt
timestamp: False
homeassistant:
allowlist_external_dirs:
- "/config" |
|
Given that the triggers occur so close to each other there may be a concurrency issue. Perhaps experiment with the mode, my choice would be |
|
I did the experiment. Still sometimes a valve is set to on before the previous in the playlist is set to off. As a reminder there is a 15" delay between each irrigation phase. Have a look at the last irrigation sequence. HA interface reports exact same values as the log here below. Have a look at 2024-07-29T02:24:47.072847 log |
|
Curious, the events are 15 seconds apart just the wrong way around. Perhaps it is triggering on an attribute change rather than a state change. Take a look at state triggers. From the documentation: 
On another topic are you able to help here? |
|
The reloading should be fixed now. |
Thanks |
I think I discovered the reason. It turns out that the ethernet relay board that drives valves, sometimes when it receives a switch off command, makes the web interface crashing even if the relay is indeed switched off. This fools Home Assistant. I know that is device does not like to drive coils that probably generate a spike that makes the unit rebooting. I could wired a capacitor, but room to do so for the 15 valves is scarce, the other solution is to replace the unit by a more robust one that I already have in hand. Check back is not the solution because the relay is already in the expected state. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the solution you'd like
It would be nice if a zone was able optionally able to track water usage, as many sprinkler controllers or hose end controllers that can integrate with home assistant provide a separate entity that provides either/or 'current flow rate' or 'current volume used'. For an initial implementation I would imagine the data would only be provided as informational and tracked along with historical runtime data. Eventually it would be great to also allow scheduling 'duration' to use water volume instead of time, for example: Run zone1 at 5:00 for 100 gallons, (with optional timeout).
Describe alternatives you've considered
Currently I have custom netdaemon code integrated for managing volume related usage for my sprinklers, if there is interest on this I would be happy to start looking at coming up with a sample PR if you have any suggestions on where/how this would be best handled.
Curious if there is any interest for something like this
The text was updated successfully, but these errors were encountered: