Add optional "volume_entity" to a zone for tracking/controlling based on volume

[irakhlin]

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

[rgc99]

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?

[Kolia56]

I currently track water volume for each zone with the following code. There is one physical meter (sensor.556) that never resets
Definition of helpers

utility_meter:
  water_meter_id2:
    name: Consommation eau kfé francois
    source: sensor.556
    unique_id: "water_meter_id2"
    tariffs: 
      - "std"
  water_meter_id3:
    source: sensor.556
    name: Consommation eau Serre
    unique_id: "water_meter_id3"
    tariffs: 
      - "std"
  water_meter_id4:
    source: sensor.556
    name: Consommation eau Haie rue
    unique_id: "water_meter_id4"
    tariffs: 
      - "std"
  water_meter_id5:
    source: sensor.556
    name: Consommation cuisine grande maison
    unique_id: "water_meter_id5"
    tariffs: 
      - "std"
  water_meter_id6:
    source: sensor.556
    name: Consommation eau pare terre Julie
    unique_id: "water_meter_id6"
    tariffs: 
      - "std"
  water_meter_id7:
    source: sensor.556
    name: Consommation eau Pelouse
    unique_id: "water_meter_id7"
    tariffs: 
      - "std"
  water_meter_id8:
    source: sensor.556
    name: Consommation eau deux carrés
    unique_id: "water_meter_id8"
    tariffs: 
      - "std"
  water_meter_id9:
    source: sensor.556
    name: Consommation eau un carré
    unique_id: "water_meter_id9"
    tariffs: 
      - "std"
  water_meter_id10:
    source: sensor.556
    name: Consommation eau petits fruits
    unique_id: "water_meter_id10"
    tariffs: 
      - "std"
  water_meter_id11:
    source: sensor.556
    name: Consommation eau Haie - Céanothe et fleurs
    unique_id: "water_meter_id11"
    tariffs: 
      - "std"
  water_meter_id12:
    source: sensor.556
    name: Consommation eau Pommiers
    unique_id: "water_meter_id12"
    tariffs: 
      - "std"
  water_meter_id13:
    source: sensor.556
    name: Haie Charme Hêtre pourpre
    unique_id: "water_meter_id13"
    tariffs: 
      - "std"
  water_meter_id14:
    source: sensor.556
    name: Consommation non utilisé
    unique_id: "water_meter_id14"
    tariffs: 
      - "std"
  water_meter_id15:
    source: sensor.556
    name: Consommation eau haie du fond
    unique_id: "water_meter_id15"
    tariffs: 
      - "std"
  water_meter_id16:
    source: sensor.556
    name: Consommation eau Tilleul
    unique_id: "water_meter_id16"
    tariffs: 
      - "std"

input_number:
  water_id2:
    name: Consommation eau Kfé François
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id3:
    name: Consommation eau Serre
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id4:
    name: Consommation eau Haie rue
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id5:
    name: Consommation cuisine grande maison
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id6:
    name: Consommation pare-terre Julie
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id7:
    name: Consommation eau Pelouse
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id8:
    name: Consommation eaux deux carrés
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id9:
    name: Consommation eau un carré
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id10:
    name: Consommation eau petits fruits
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id11:
    name: Consommation Haie Céanothe et fleurs
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id12:
    name: Consommation eau Pommiers
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id13:
    name: Consommation Haie Charme Hêtre pourpre
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id14:
    name: Consommation eau TBD
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id15:
    name: Consommation eau haie du fond
    min: 0
    max: 10000
    step: 1
    mode: box
  water_id16:
    name: Consommation eau Tilleul
    min: 0
    max: 10000
    step: 1
    mode: box

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.

  - id: 670d8578-9b95-4538-89ff-3334ec429495
    alias: Arrosage Consommation de chaque circuit      
    description: ""
    # trace:
    #     stored_traces: 30    
    trigger:
      - platform: state
        entity_id:
          - switch.562
          - switch.564
          - switch.565
          - switch.566
          - switch.568
          - switch.569
          - switch.713
          - switch.714
          - switch.715
          - switch.716
          - switch.717
          - switch.718
          - switch.719
          - switch.720
    variables:
      indexes:
        562: "id2" # Kfé François
        564: "id3" # Serre
        565: "id4" # Haie rue
        568: "id5" # Cuisine grande maison
        569: "id6" # Pare terre Julie
        566: "id7" # Pelouse
        713: "id8" # Deux carrés
        714: "id9" # Un carré
        715: "id10" # Petits fruits
        716: "id11" # Haie Céanothe et fleurs
        717: "id12" # Pommiers
        718: "id13" # Haie Charme Hêtre pourpre
        719: "id15" # Haie du fond
        720: "id16" # Tilleul - Cerisier
      id: "{{trigger.entity_id.split('.')[1]}}" # entity index (id1, id2, ...)
      entity: "{{indexes.get(id, 'unknown')}}"
    condition: "{{ entity != 'unknown' and trigger.from_state.state != 'unavailable' }}"
    action:
      - choose:
        - conditions:
            - condition: template
              value_template: >
                {{states(trigger.entity_id) == "on"}}
          sequence:
            - service: utility_meter.reset
              data: {}
              target:
                entity_id: 
                  - '{{"select.water_meter_" ~ entity}}'
                  - select.water_meter_arrosage
        - conditions:
            - condition: template
              value_template: >
                {{states(trigger.entity_id) == "off"}}
          sequence:
            - service: input_number.set_value
              data:
                value: >
                  {{states("sensor.water_meter_" ~ entity ~ "_std") | round(3)}}
              target:
                entity_id: "input_number.water_{{entity}}" 
    mode: queued
    max: 20

[irakhlin]

@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:

• Every controller would have a integration created/controlled sensor created for example: "controller 1 current zone volume"
• An optional boolean value on the controller would allow me to set the controller to function in "volume set mode" instead of the current "time set mode"
• If volume set mode is configured, every zone in the controller would need to have an additional entity provided on top of the current switch entity, this entity would need to either provide "total volume of current watering"(preferred) or a "current rate of flow" value.
• Some zone devices for example my byhyve and my taplink devices already provide an entity sensor that amounts to "total volume of current watering run" in gallons or liters, I imagine that most would. If this type of sensor is provided irrigation_unlimited would simply be able to poll the value at a configurable time interval (say default 10s-30s) until the desired set volume in a sequence is met.
• For the zone devices that only have GPM/LPM flow rate value, irrigation_unlimited would poll this flow rate at a set time interval, say 10 seconds, and take the average of say 6 readings to update the controllers "current zone volume" value and use this as the cutoff, the times and values here being just examples.
• I think it would still be important to set a default and configurable fail safe shutoff time per zone run. For example one of my zone values flow rate sensors was clogged with debris and temporarily stopped updating flow rate and thus volume. Maybe this value is configurable and adjustable, for example if irrigation_unlimited has historical data of at least one previous run for a zone this value is set to 2x the time of the previous 10 or so runs. (just an idea).

[rgc99]

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.

[rgc99]

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.

[Kolia56]

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

[rgc99]

The idea is to capture data from the water usage sensor. This will write a file irrigation_sensor_log.txt in the config directory with the sensor data.

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 }}"

[Kolia56]

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?

[rgc99]

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.

[Kolia56]

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.

[Kolia56]

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.
Let me know whether the log file format could be improved to help processing on your side.
We'll have to wait till Saturday night (UTC+2) to grad another sequence.
irrigation_sensor_log.txt

[Kolia56]

Please find some more data
irrigation_sensor_log-1.txt

[rgc99]

Thanks, can I also get the current matching configuration. Also was there any adjustment in play?

[Kolia56]

Here it is. Sequence 1 / night was indeed adjusted.
For the 26: 69%
For the 27: 58%
For the 28: 46%

irrigation_unlimited:
  controllers:
    - name: "Controleur 1"
      all_zones_config:
        show:
          timeline: true
        allow_manual: true
        # duration: "0:10:00"
      zones:
        - name: Café François
          zone_id: "1"
          entity_id: switch.vanne_atelier_gui
          maximum: "00:45:00"
        - name: Serre
          zone_id: "2"
          entity_id: switch.vanne_maison_journalier_gui
          maximum: "00:30:00"
        - name: Pelouse
          zone_id: "3"
          entity_id : switch.vanne_jardin_devant_gui
          maximum: "01:10:00"
        - name: Deux carrés
          zone_id: "4"
          entity_id: switch.vanne_deux_carres_gui
          maximum: "00:45:00"
        - name: Un carré
          zone_id: "5"
          entity_id: switch.vanne_un_carre_gui
          maximum: "00:30:00"
        - name: Petits fruits
          zone_id: "6"
          entity_id: switch.vanne_petits_fruits_gui
          maximum: "00:50:00"
        - name: Haie - Céanothe - Fleurs
          zone_id: "7"
          entity_id: switch.vanne_haie_gui
          maximum: "01:00:00"
        - name: Pommiers
          zone_id: "8"
          entity_id: switch.vanne_pommiers_gui
          maximum: "00:30:00"
        - name: Pare-terre Julie 
          zone_id: "9"
          entity_id: switch.vanne_buanderie_grande_maison_gui
          maximum: "00:45:00"
        - name : Haies pelouses
          zone_id: "10"
          entity_id: switch.718
          maximum: "00:45:00"
        - name: If Cour carrée
          entity_id: switch.vanne_salle_claudine_gui
          zone_id: "11"
          maximum: "00:20:00"
        - name: Haie du fond
          zone_id: "12"
          entity_id: switch.vanne_haie_fond_gui
          maximum: "01:40:00"
        - name: Tilleul
          zone_id: "13"
          entity_id: switch.vanne_tilleul_gui
          maximum: "00:40:00"
      sequences:
      - name: nuit
        schedules:
          - name: 1
            time: "22:00"
            schedule_id: "s1"
        delay : 1
        zones:
          - zone_id: 1 # Café François
            duration: "00:30"
          - zone_id: 2 # Serre et autres
            duration: "00:20"
          - zone_id: 9 # Pare-terre Julie
            duration: "00:30"
          - zone_id: 4 # Deux carrés
            duration: "00:30"
          - zone_id: 5 # Un carré
            duration: "00:20"
          - zone_id: 6 # Petits fruits
            duration: "00:30"
          - zone_id: 7 # Haie - Céanothe
            duration: "00:40"
          - zone_id: 8 # Pommiers
            duration: "00:20"
          - zone_id: 10 # Haies pelouse
            duration: "00:25"
          - zone_id: 11 # If cour carrée
            duration: "00:10"
          - zone_id: 12 # Haie du fond
            duration: "00:30"            
          - zone_id: 13 # Tilleul - Cerisier
            duration: "00:30"    
          - zone_id: 3 # Pelouse
            duration: "00:40"        
      - name: jour
        duration: "00:05"
        delay: "02:25"
        repeat: 3
        schedules: 
          - name: 2
            time: "12:00"
            schedule_id: "s2"
        zones:
          - zone_id: 2

[rgc99]

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 }}"

[Kolia56]

Indeed this is GMT+2. I made the modification. How many days of data do you wish?

[rgc99]

At the moment just a single sequence run would be great.

[rgc99]

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.556

Please check it out and see if the volumes on the zones tally to what you expect.

[Kolia56]

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.

zone_id: 8
index: 7
enabled: true
suspended: null
status: off
schedule_count: 0
schedules: 
adjustment: 
current_schedule: null
percent_complete: 0
next_schedule: 1
today_total: 4
timeline: 
- start: '2023-10-04T21:56:07+00:00'
  end: '2023-10-04T22:07:43+00:00'
  schedule_name: '1'
  adjustment: '%58.0'
  status: scheduled
- start: '2023-10-03T21:56:07+00:00'
  end: '2023-10-03T22:07:43+00:00'
  schedule_name: '1'
  adjustment: '%58.0'
  status: scheduled
- start: '2023-10-02T21:56:07+00:00'
  end: '2023-10-02T22:07:43+00:00'
  schedule_name: '1'
  adjustment: '%58.0'
  status: scheduled
- start: '2023-10-01T21:56:07+00:00'
  end: '2023-10-01T22:07:43+00:00'
  schedule_name: '1'
  adjustment: '%58.0'
  status: next
- start: '2023-10-01T08:44:40+00:00'
  end: '2023-10-01T08:48:40+00:00'
  schedule_name: Manual
  adjustment: ''
  status: history
- start: '2023-09-30T21:55:53+00:00'
  end: '2023-09-30T22:07:29+00:00'
  schedule_name: '1'
  adjustment: '%58.0'
  status: history
- start: '2023-09-29T21:35:53+00:00'
  end: '2023-09-29T21:45:29+00:00'
  schedule_name: '1'
  adjustment: '%48.0'
  status: history
- start: '2023-09-28T21:31:53+00:00'
  end: '2023-09-28T21:41:05+00:00'
  schedule_name: '1'
  adjustment: '%46.0'
  status: history
- start: '2023-09-27T21:55:53+00:00'
  end: '2023-09-27T22:07:29+00:00'
  schedule_name: '1'
  adjustment: '%58.0'
  status: history
- start: '2023-09-26T22:17:53+00:00'
  end: '2023-09-26T22:31:41+00:00'
  schedule_name: '1'
  adjustment: '%69.0'
  status: history
- start: '2023-09-25T20:35:53+00:00'
  end: '2023-09-25T20:39:29+00:00'
  schedule_name: '1'
  adjustment: '%18.0'
  status: history

volume: 0.009
icon: mdi:valve-closed
friendly_name: Pommiers
next_adjustment: %58.0
next_name: 1
next_start: 2023-10-01T23:56:07+02:00
next_duration: 0:11:36

[Kolia56]

After a complete night cycle I confirm that all volumes data are correct.

[rgc99]

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.

[Kolia56]

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%)?

[rgc99]

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.

[Kolia56]

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.

[rgc99]

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 flow_rate attribute on the zone? It would be simply volume / duration, probably displayed in seconds. Thinking it could be used in an automation for an alarm (low/no water flow etc.) or a graph.

[evercape]

Would it be useful to have a flow_rate attribute on the zone? It would be simply volume / duration, probably displayed in seconds. Thinking it could be used in an automation for an alarm (low/no water flow etc.) or a graph.

I think flow_rate is definitely a good idea and in seconds.

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, pressure might be another common attribute to consider. I built a complex water filtering and supply system at our holiday house and have used water pressure sensors like this one.

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.

[Kolia56]

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.

Here is the log file
irrigation_sensor_log.txt

Here is te code automation

  - id: 670d8578-9b95-4538-89ff-3334ec429495
    alias: Arrosage Consommation de chaque circuit
    description: "Consommation chaque circuits et vérification état logique/physique
      de chaque relais vis à vis de la commande"
    trace:
        stored_traces: 40  
    trigger:
      - platform: state
        entity_id:
          - switch.562
          - switch.564
          - switch.565
          - switch.566
          - switch.568
          - switch.569
          - switch.713
          - switch.714
          - switch.715
          - switch.716
          - switch.717
          - switch.718
          - switch.719
          - switch.720
        id: valve_switch

    variables:
      indexes:
        562: "id2" # Kfé François
        564: "id3" # Serre
        565: "id4" # Haie rue
        568: "id5" # Cuisine grande maison
        569: "id6" # Pare terre Julie
        566: "id7" # Pelouse
        713: "id8" # Deux carrés
        714: "id9" # Un carré
        715: "id10" # Petits fruits
        716: "id11" # Haie Céanothe et fleurs
        717: "id12" # Pommiers
        718: "id13" # Haie Charme Hêtre pourpre
        719: "id15" # Haie du fond
        720: "id16" # Tilleul - Cerisier
      id: "{{trigger.entity_id.split('.')[1]}}" # entity index (id1, id2, ...)
      entity: "{{indexes.get(id, 'unknown')}}"
      var: "{{trigger.from_state.state}}"
    condition: "{{ entity != 'unknown' and (trigger.from_state.state == 'on' 
      or trigger.from_state.state == 'off') and has_value('sensor.556')}}"      
    action:
      - choose:
        - conditions:
            - condition: template
              value_template: >
                {{states(trigger.entity_id) == "on"}}
          sequence:
            - service: utility_meter.reset
              data: {}
              target:
                entity_id: 
                  - '{{"select.water_meter_" ~ entity}}'
                  - select.water_meter_arrosage
        - conditions:
            - condition: template
              value_template: >
                {{states(trigger.entity_id) == "off"}}
          sequence:
            - service: input_number.set_value
              data:
                value: >
                  {{states("sensor.water_meter_" ~ entity ~ "_std") | round(3)}}
              target:
                entity_id: "input_number.water_{{entity}}"
        default:
          - delay:
              hours: 0
              minutes: 0
              seconds: 2
              milliseconds: 0
    mode: queued
    max: 20

Would it be useful to have a flow_rate attribute on the zone? It would be simply volume / duration, probably displayed in seconds. Thinking it could be used in an automation for an alarm (low/no water flow etc.) or a graph.
Without any doubt. I already have done this with another automation using a derivative sensor. However it is a bit tricky because the derivative sensor is updated only when there is new data. In other words it never resets to 0

  - trigger:
      - platform: time_pattern
        seconds: /15
    sensor:
      - name: Grand puits index timed
        unique_id: grand_puits_index_timed
        state: >
          {% set sensor_value = states('sensor.grand_puits_index_en_litres') | float %} 
          {{ 0.001 * (this.state | float(0) == sensor_value) + sensor_value }}
        state_class: measurement
        unit_of_measurement: "l"

[Kolia56]

From an alarm point of view, pressure might be another common attribute to consider. I built a complex water filtering and supply system at our holiday house and have used water pressure sensors like this one.

I do have a pressure sensor as well, so integrating this into Irrigation unlimited is certainly nice to have.

[rgc99]

I have taken the sample from 13-Oct 22:00pm through 14-Oct 04:00. These are the volume readings [0.128, 0.121, 0.060, 0.071, 0.030, 0.058, 0.095, 0.056, 0.134, 0.045, 0.031, 0.072, 0.671].
These are the flow rates I get per hour do they seem correct? [0.284, 0.403, 0.133, 0.158, 0.1, 0.097, 0.158, 0.124, 0.357, 0.3, 0.069, 0.16, 1.118].

[Kolia56]

Based on the same file I made the computation and confirm all your figures. I coud not check with my water meters because I was unaware that input_numbers that store the various values are not stored in statistics, only sensors and binary sensors are. So if you wish, I may include template sensors that will be feeded by these input_numbers and statistics will be available. I may also send these values to influxDB that is already set-up. Let me know.

[rgc99]

No problem, it's new code and if it is wrong we can fix it, just keep an eye on them. The flow rate changes have been added to the repository. The numbers were very small when expressed as a per second value so they are currently per hour. I feel volume and flow rate need a scale parameter to allow conversion to other units. I find various irrigation products in litres/second or minute or hour, gallons/minute or hour. A sensor that was only available in gph could be converted to lps for example. It might help to harmonise the system.

[Kolia56]

Yes I agree a scaler parameter would help in order to cope with various situation. Anyhow, high resolution is needed in case small quantities of water are used especially when using drip lines. I keep both system running in parallel, I’m about to define template sensors based on the volume attribute and will send all this stuff to influxDB. I will update to the last repository shortly.

[Kolia56]

I just installed the latest cut with flow_rate. I tested if on one circuite so far. Value seems ok, I need to perform a test on a more heavy consumption circuit to make sure. However when there is no more water consumption, I noticed it never resets . I considered that after 15 seconds of no counter increment (i.e. 1 liter) it can be set to 0.

[rgc99]

A volume limit function has just been added. Bit of journey through some FR's. First stop was #139 to make sequences their own entity. Not quite finished here with more attributes to be exposed but set the foundation for moving forward. Next to 'skip' a sequence zone and #142 which is more of a freeze than a pause but the main thing here was to make runs more flexible from from their immutable status. Now finally returning here with a volume: parameter being added to the sequence zone. It acts as a limit and when reached will move onto the next zone in the list.

The new sequence entity shows the entire volume consumed for the last run. Flow rate on the zone is now a moving average from the last 10 readings but still doesn't reset. It means in the off state it shows the last flow rate average. I would like this to be the seed value for the next run.

  controllers:
...
      all_zones_config:
        volume:
          entity_id: sensor.556
          volume_scale: 1000 # Convert to litres
          volume_precision: 0 # Whole units only
          flow_rate_scale: 60 # Litres per minute
          flow_rate_precision: 1 # Round to one decimal place
...
    sequences:
...
        zones:
          - zone_id: 1 # Café François
            duration: "00:30"
            volume: 111.0 # Stop when 111 litres is reached
          - zone_id: 2 # Serre et autres
          ...

How are the cows?

[Kolia56]

Thank you for all these new additions. My irrigation system is winterized hence I will not able to perform tests before April or beginning of May. I’m wondering whether flow rate reset will be implement or not. It is not a major issue on my side since beside the water meter there is a pressure sensor that will report any leak when all solenoid valves are closed.

« I would like this to be the seed value for the next run. » : what do you have in mind?

[evercape]

and #142 which is more of a freeze than a pause

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
Martin

[rgc99]

Hi Martin,

Sequences now have an associated entity i.e. binary_sensor.irrigation_unlimited_c1_s1. There is an experimental service call pause on this new entity. Turned out to be more of a freeze rather than a pause. First call will pause and the second call will resume, toggle like behaviour. There are no other options on this service call, just send it to the entity.

It's more of a freeze because the state remains as is. If it is on it will remain so until another pause service call is issued. In my mind a pause should turn off any running zones (including master) and wait.

Code is ready for release. Feel free to update from the repository and let me know of any issues.

[evercape]

Hi Martin,

Sequences now have an associated entity i.e. binary_sensor.irrigation_unlimited_c1_s1. There is an experimental service call pause on this new entity. Turned out to be more of a freeze rather than a pause. First call will pause and the second call will resume, toggle like behaviour. There are no other options on this service call, just send it to the entity.

It's more of a freeze because the state remains as is. If it is on it will remain so until another pause service call is issued. In my mind a pause should turn off any running zones (including master) and wait.

Code is ready for release. Feel free to update from the repository and let me know of any issues.

Have posted testing results here:

[rgc99]

When your system has woken up from hibernation I would like to test out the volume limit functionality. Add a volume: parameter to the sequence -> zones. It should stop when the limit is reached.

[Kolia56]

When your system has woken up from hibernation I would like to test out the volume limit functionality. Add a volume: parameter to the sequence -> zones. It should stop when the limit is reached.

ok I will let you know when it is done

[Kolia56]

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.
It does set the valve to off whenever the volume limit is reached.
I noticed that volume limit has no impact on manual start, which is fine I guess. Volume limit has to be set in m3.
I noticed also that the volume sampling period is may be a bit to big, for instance it steps from 0.01 to 0.017 directly. No big deal though.
If you find room in the companion card, it would be nice to have this capping value reported as well
It has been said already numerous times but I think it is worth to say it again, this addon is really a must for large installation, very easy to use and very flexible. I prefer not to think at what I would have to do in terms of automation.
Kudos to you and thank you
On top of the counter I will shortly setup a flow rate meter which resolution is 97 pulses per liter (the water counter has a resolution of 1 pulse per liter). I will use it to drive the inverter that powers up the pump in order to adjust AC frequency, hence the pump flowrate when a water circuit is open. The idea is to have the pump always on when water is drawn in order to avoid to many start and stops. Notice that a water buffer is already in the circuit in order to limit that effect. Currently the frequency is statically adjusted based on the circuit that draws the water. The goal is to achieve a fully dynamic adjustment.

[rgc99]

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.
The volume limit should work on a manual run provided it was a sequence. Volume monitoring is not implemented on a standalone zone. The volume sensor has a volume_scale: parameter to convert into any units you would like such as barn-megaparsec.
The volume sensor is not polled so there is no sampling period. The sensor is instead tracked so when it changes a notification is issue by HA (more like an interrupt system). The size of the step would most likely be the interaction between the sensor and HA. Maybe the sensor implementation polls the hardware, I think the default polling period in HA is 30 seconds. Sometimes you can add a scan_interval: to the sensor configuration to adjust the sample interval.
I recently put in a variable speed pump. It monitors the water pressure and adjusts the speed to keep it constant. From a single drip line to a large sprinkler it works great. No more pump start/stops.

[Kolia56]

Thanks for the detailed information.

I do want to get some more testing data but will wait until May when your system is unfrozen.

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.
I have a side question regarding flow rate computation. Here below screenshot shows 8 liters for 3 minutes (which is correct), that is 160 litters/hour or roughly 2.66 liters/min. However 17.4 is reported. How it comes?
Thank you

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

[rgc99]

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 am looking to harvest some more sensor data where a few zones have volume limits and it is triggered. The first, last and a middle zone in a sequence would be good.

[Kolia56]

I did not have time so far experiment what you are looking for. I think it will be around May 10th.

I recently put in a variable speed pump. It monitors the water pressure and adjusts the speed to keep it constant. From a single drip line to a large sprinkler it works great. No more pump start/stops.

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.
This is why I may go for the flow rate meter which has a quite high resolution. Value transmission to HA will occur only when there is a change.
I don't know whether there would be a benefit to implement the algorithm directly in irrigation unlimited.

[Kolia56]

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

Log data when flow rate is low

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.

[rgc99]

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.

[Kolia56]

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.

[rgc99]

This might be done already. Try this setting for the volume scale:

      all_zones_config:
        volume:
          volume_scale: 0.01041667
          volume_precision: 8

It's 1 / 96.

[Kolia56]

Thank you, I will test that as soon as the new sensor is installed