Rain Sensor Not Expected Behavior

[ds7771]

I was waiting for appropriate conditions to test this. I just had some rain conditions come through, but the program did not follow expected behavior. Although the rain sensor was "on" in each zone, the scheduled program was not prevented from running those zones. (The manual program was also not prevented from running, although that is expected behavior).

My rain sensor is a threshold binary sensor. The input is sensor.openweathermap_rain, with the threshold set to trigger an "on" value when openweathermap rainfall is above 0.

[petergridge]

Hi,

The rain sensor will only impact scheduled runs of the program. For my purposes I want to a manual run to execute the zones unless I have specifically turned a zone off i.e. frequency is 'off' or zone is disabled.

My reasoning is I have made a choice to run the zone/program. One use case, I have accidentally wet my rain sensor (while washing the car) and the irrigation did not run.

I have tested V5.2.7 and it is preventing the run of a zone for me with the rain sensor on with a scheduled execution.

A couple of questions so I can debug your issue:

• what version are you running?
• do you have an 'ignore rain' object defined?
• can you send a screenshot of a zone configuration.

One thing you can do to test this is to add a input_boolean and/or a template boolean_sensor to mimic the rain sensor. If you have named days as you frequency you can set the run day as 'Sun' for example then just change the time and program will start as a scheduled execution.

This is the code I used to test this issue:

input_boolean:
  program_rain:

template:
  - binary_sensor:
      - name: rain_sensor_binary
        state: "{{ is_state('input_boolean.program_rain', 'on') }}"

I also have sample yaml in the repository that creates all the objects to create 3 test zones that just operate template switches that you can use to mimic your entire configuration by creating a test program.

There is also the Irrigation controller: run_simulation service you can run that emulates running a program, in version 5.2.7 this only mimics a manual run, but I have just added the ability to set manual or scheduled as an option. I will release this in 5.2.8. Look in the log for the results, it is easier to read if you load the full log.

Have a look at the OpenWeatherMap History custom control, using this and the watering adjustment feature we can use the recent observations and forecast rainfall to adjust how much watering is required rather than a boolean is it currently raining. https://github.com/petergridge/openweathermaphistory

[ds7771]

Hi - I am a bit stumped here. Its not working for me in 5.2.8, 5.27 or 5.26

I did configure a template binary sensor per your sample code. I also tried using various input.boolean and other binary.sensor helpers and template sensors as the rain sensor, but none of them seem to work.

To keep the testing simple, I ended up blowing up the integration, reboot, reinstall, and then I only configured a single Zone.

Please let me know what I can do to help you with debugging?

Here is a sceneshot of my single zone:

Here is the irrigation_event log, that is reported from a scheduled run, with the rain sensor on/true

Here are the logs from running the simulation service

2023-06-04 09:15:10.762 WARNING (MainThread) [custom_components.irrigationprogram.switch] Irrigation Program: Planters Program: 2023-06-04 09:15:10.770 WARNING (MainThread) [custom_components.irrigationprogram.switch] Grouped zones to run: sprinkler_driveway_planters 2023-06-04 09:15:10.774 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] ---------------------------- 2023-06-04 09:15:10.777 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Zone: sprinkler_driveway_planters 2023-06-04 09:15:10.778 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Should run: True 2023-06-04 09:15:10.779 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Last Run time: 2023-06-03T21:18:00.006390-04:00 2023-06-04 09:15:10.781 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Run time: 900 2023-06-04 09:15:10.784 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Water Value: 15.0 2023-06-04 09:15:10.786 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Wait Value: 10.0 2023-06-04 09:15:10.787 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Repeat Value: 1 2023-06-04 09:15:10.789 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Rain sensor value: True 2023-06-04 09:15:10.790 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Ignore rain sensor Value: False 2023-06-04 09:15:10.791 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Run frequency Value: None 2023-06-04 09:15:10.793 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Flow Sensor Value: None 2023-06-04 09:15:10.794 WARNING (MainThread) [custom_components.irrigationprogram.irrigationzone] Adjuster Value: 1

[petergridge]

Hi, I have found the issue, I have a line of code out of order and it only becomes apparent if there is no run frequency helper set on the program or zone, I believe most people have that feature enabled so it has not cropped up previously.

I will have a fix out shortly.

[ds7771]

Nice catch! You’re correct, the rain sensor works perfectly when a frequency is added to the zone in my instance. Looking forward to the fix.

[petergridge]

I really need to spend some time learning how to automated some of the testing, there are so many options now that testing is difficult.

I have a couple of issues to resolve around next run time before I put out a new release, hopefully I get those sorted soon.

[petergridge]

Just a note you can put frequency at the program level, all zones run at the same frequency, it is also allows you to turn off the program when out of the watering season.

[petergridge]

I noticed a couple of things when looking at your configuration:

1. interzone delay is set at the program level. As you have only one zone and this feature puts a short delay between zones, you don't really need it. It is there to support a few instances where the solenoids did not behave well. this delay is in seconds
2. you have the zone delay reused for the wait feature of a eco cycle. This is measured in minutes not seconds. you also do not have the repeat object defined so it is not being used by the program, My pots are happy with a much shorter watering time when running a 5, 1 minute cycles with a 1 minute wait, the water soaks in well without running out the bottom of the pot.
3. I personally do not use the enable program/zone settings my preference is to use the frequency option as I vary the frequency as the watering seasons change. If you add Off as an option to the frequency this is the same as turning the program off, if you only have one zone you only need to set it at the program level. But you can have a different frequency for different zones so pots every day and lawn once or twice a week but the program starts at the same time.

[petergridge]

5.2.9 is Beta now available. Can you let me know if this is ok and we can close off this issue.

Cheers Pete

[ds7771]

Hi - my rain sensor works as expected now, in 5.2.9, without the need for the run frequency helper. Thanks for making this fix!

I did remove the delay from my zone configuration. Thanks for pointing out that it is in minutes and I was not using it for the intended purpose.

For clarity, I prefer a toggle to enable each zone because my wife sometimes likes to switch off the flower planters during a manual or scheduled run, depending on what condition they look like. It's more intuitive for her to visualize an on/off toggle switch.

I dont need the run_frequency drop down because I am integrating your scheduler with another HACS integration that performs evapotranspiration calculations: https://github.com/jeroenterheerdt/HAsmartirrigation

The ET program titrates the watering rate and frequency for me automatically on a daily basis depending on the calculated moisture requirement, rather than according to a set schedule.

I integrated this into your scheduler through a script that updates and replaces the input_number with the value of the daily watering duration that is outputted from the ET calculation, converted from seconds to minutes. The script is automated to run whenever the ET calculation event is fired:

service: input_number.set_value data: value: >- {{ (states("sensor.smart_irrigation_daily_adjusted_run_time") | float / 60) | round(0) }} target: entity_id: input_number.water_dining_room_side

I know, it's a bit convoluted, but its the way I make it work. If you have any interest in the ET integration, you could consider allowing the watering duration to be taken from either a sensor or input_number -- which would provide maximum flexibility.

[petergridge]

I can make the change to accept a sensor input. But at this time it will still expect minutes not seconds.

[ds7771]

Sure, a sensor would be helpful. For me, allowing a sensor directly would avoid the need for using an automation to update input_number from a sensor output. Thanks!

[petergridge]

Hi, I have added sensor support as requested in version 5.2.10. Please let me know how it goes and if you have any issues.

If this is a clean build I will promote to the main release

Cheers Pete

[ds7771]

Sensor works perfectly, thank you! No issues at all with using minutes. I created a template sensor which reads from an attribute of the ET sensor that reports state in minutes. Using that template sensor in place of input_number does the trick for me.