Automation Condition using rain sensor value for the last certain period?

swoofz · July 9, 2018, 6:31pm

Hi,
I’m trying to setup an automation for my sprinkler system which incorporate a simple rain sensor as reference for condition.

I want to set an automation to trigger the sprinkler at specific timing (2hrs before sunrise) with condition that there have been no rain for the last 2 hours.

This is the automation I currently use without the condition and it’s been working great :

  - alias: Sprinkler Morning Schedule
    trigger:
      platform: sun
      event: sunrise
      offset: '-02:00:00'
    action:
      - service: switch.turn_on
        data:
          entity_id: switch.Sprinkler_1          
      - delay: 
          minutes: 3
      - service: switch.turn_off
         data:
           entity_id: switch.Sprinkler_1

But when I add condition below it didn’t work.

  - alias: Sprinkler Morning Schedule
    trigger:
      platform: sun
      event: sunrise
      offset: '-02:00:00'
    condition:
      condition: state
      entity_id: binary_sensor.rain_sensor
      state: 'off'
      for:
        hours: 2
    action:
      - service: switch.turn_on
        data:
          entity_id: switch.Sprinkler_1          
      - delay: 
          minutes: 3
      - service: switch.turn_off
         data:
           entity_id: switch.Sprinkler_1

Any idea on how can I achieve this? Thanks!

pnbruckner · July 9, 2018, 6:48pm

Can you elaborate on what you mean by “it didn’t work”? Did it just not turn on the sprinkler when it should have (i.e., 2 hours before sunrise when binary_sensor.rain_sensor had been ‘off’ for at least two hours)? If so, did you verify (via history or whatever) that binary_sensor.rain_sensor was indeed ‘off’ for at least two hours at that time? Was there some sort of error reported somewhere?

Without more information to go on, it’s kind of hard to say. What you have at least looks right (although, I’ll admit, I haven’t tried to use a state condition with for: before.)

swoofz · July 9, 2018, 7:20pm

The sprinkler just not turn on as usual after I add the condition part in the automation script.
Since I haven’t install the rain sensor outdoor and only turn it on inside my room then it’s definitely off all the time and couldn’t find any error in the log.

For investigation purpose, I changed the trigger to specific mqtt message.

alias: Test Condition
trigger:
platform: mqtt
topic: ‘home/MQTTGW/433toMQTT’
payload: ‘10839684’
condition:
condition: state
entity_id: binary_sensor.rain_sensor
state: ‘off’
for:
minutes: 5
action:
- service: switch.turn_on
  data:
  entity_id: switch.Sprinkler_1

with config above, the automation was not triggered at all, but if I took out the for minutes part as below it worked.

alias: Test Condition
trigger:
platform: mqtt
topic: ‘home/MQTTGW/433toMQTT’
payload: ‘10839684’
condition:
condition: state
entity_id: binary_sensor.rain_sensor
state: ‘off’
action:
- service: switch.turn_on
  data:
  entity_id: switch.Sprinkler_1

any thoughts ? Thanks !

oliverdog · July 9, 2018, 7:52pm

Try changing the time format to:

For: “01:00:00”

where “hh:mm:ss” by the way…

pnbruckner · July 9, 2018, 8:06pm

Please always format your code so we can see it properly.

My suspicion is that for: might require the entire state of the entity to not change for that amount of time, including attributes. But since you specified state: as well, I’m not so sure. I’d have to experiment or read code to be sure.

But, since you say the entity is ‘off’, confirmed by the automation working when for: was removed, here’s an alternative that might work:

  - alias: Sprinkler Morning Schedule
    trigger:
      platform: sun
      event: sunrise
      offset: '-02:00:00'
    condition:
      condition: template
      value_template: >
        {{ is_state('binary_sensor.rain_sensor','off') and
           (now() - states.binary_sensor.rain_sensor.last_changed).total_seconds()
           > 2 * 60 * 60 }}
    action:
      - service: switch.turn_on
        data:
          entity_id: switch.Sprinkler_1          
      - delay: 
          minutes: 3
      - service: switch.turn_off
         data:
           entity_id: switch.Sprinkler_1

swoofz · July 10, 2018, 12:34am

Tried this and still not working…

Noted on the formatting… tried your suggestion but still it didn’t work, it worked after i removed the condition part…

swoofz · July 10, 2018, 1:01am

Tried to validate the scripts through Template menu as follow :

Binary sensor state : {{ states.binary_sensor.rain_sensor.state }}
Is state off : {{ is_state('binary_sensor.rain_sensor','off') }}
Last Changed : {{states.binary_sensor.rain_sensor.last_changed }}
Time now : {{ now() }}

Time difference : {{states.binary_sensor.rain_sensor.last_changed - now()}}

Time difference in seconds : {{ (now() - states.binary_sensor.rain_sensor.last_changed).total_seconds()}}

Condition :
{{ is_state('binary_sensor.rain_sensor','off') and (now() - states.binary_sensor.rain_sensor.last_changed).total_seconds() > 2 * 60 * 60 }}

and here’s the result, note the timezone difference…

Binary sensor state : off
Is state off : True
Last Changed : 2018-07-10 00:36:14.380060+00:00
Time now : 2018-07-10 07:57:10.929243+07:00

Time difference : -1 day, 23:39:03.450182

Time difference in seconds : 1256.549959

Condition :
False

pnbruckner · July 10, 2018, 1:35am

It might be a little unexpected/confusing, but the two datetimes are just reported in different timezones. The first (+00:00) is basically UTC, and the second is local (+07:00). Or at least I’m assuming your local timezone is +7:00.

The issue is the difference between now (7:57:11 local) and last_changed (7:36:14 local) is only 1256.5 seconds, which is less than 21 minutes, not 2 hours.

I think you should look at the history of your binary_sensor.rain_sensor. It must be changing to ‘on’ more often than you expect.

swoofz · July 10, 2018, 6:21am

thanks for pointing that out, yes my local timezone is +7. I’m still at the office and will check as soon as I get home.

I remembered this morning when I tested your suggested config, when I click the rain sensor icon I can see that the sensor was in off state for hours, more than 2 hours I believe.

The question for me is, why last_changed is in UTC while now() is in my local time. If I remember correctly, 00:36 was the time I changed the sensor status to off by taking the sensor out of a glass filled with water,so if it was correct then last_changed should be in +7 timezone instead of UTC. But I’ll give another try tonight.

Just wondering if any other timezone setup need to be done in order to have a consistent timing across time & date variables? Thanks.

pnbruckner · July 10, 2018, 12:15pm

It really doesn’t matter how the time is reported/printed. What matters is what time it corresponds to in your local timezone. 00:00:00+00:00 is equivalent to (i.e., the same time as) 07:00:00+07:00. That’s just how “timezone aware” datetimes work.

E.g., if you enter the following in the Template Editor:

{{ now() }}
{{ utcnow() }}
{{ now().timestamp() }}
{{ utcnow().timestamp() }}

You’ll see that the local (in my case, -05:00) and UTC times are equivalent (i.e., they have the same UNIX timestamp.):

2018-07-10 07:12:22.462230-05:00
2018-07-10 12:12:22.462519+00:00
1531224742.462717
1531224742.463359

What’s important is that the timezone set in your configuration.yaml file agrees with the timezone set in the OS.

swoofz · July 10, 2018, 3:26pm

Hi,
If you see the picture below, the sensor has been in off state (dry) since July 10 2018 12:37 AM my local time (+7) no change on the state since then

RainSensorStatus

the code we used :

{{states.binary_sensor.rain_sensor.last_changed }}

leads to following result :

Last Changed : 2018-07-10 00:36:14.380060+00:00

if it’s in UTC then it should be :

Last Changed : 2018-07-09 17:36:14.380060+00:00

This then make a huge difference to the logic.

Last time I changed the state of the sensor was before I went to sleep, I didn’t change the state at all after woke up, only change the condition as you suggested. I tried this morning around 7AM that should have been giving time difference more than 2 hrs as expected on the logic.

This is the setting on my OS :

timezone setting in configuration.yaml :

Any idea ? Thanks !

pnbruckner · July 10, 2018, 3:38pm

Is this the OS of the system running Home Assistant? When I said the timezone of the OS, that’s what I meant. So you’re running HA on Windows?

swoofz · July 10, 2018, 3:47pm

aaahh sorry for that, I run HA in raspberry… check it just now and timezone has been set properly

restart HA and check the sensor again :

RainSensorStatus_afterchecktimezone

petro · July 10, 2018, 3:47pm

I’ve heard of problems running ha on windows…

@swoofz what do you get when you try these:

{{ as_timestamp(states.binary_sensor.rain_sensor.last_changed) | timestamp_local }}
{{ as_timestamp(states.binary_sensor.rain_sensor.last_changed) | timestamp_utc }}

swoofz · July 10, 2018, 3:51pm

Sorry for the mistake on the screenshot earlier, I’m running HA on raspberry pi not Windows…

This is what I got :

{{ as_timestamp(states.binary_sensor.rain_sensor.last_changed) | timestamp_local }}
{{ as_timestamp(states.binary_sensor.rain_sensor.last_changed) | timestamp_utc }}

2018-07-10 22:45:35
2018-07-10 15:45:35

petro · July 10, 2018, 3:54pm

So I missed that last post about you fixing it in your OS. Everythings good now? You should mark @pnbruckner’s post as a solution.

swoofz · July 10, 2018, 3:55pm

Nope, I didn’t change / fix anything the screen shot above only showing the existing set timezone.
In my previous post I attach the screenshot of sensor status. It has been in off since 00:37 AM local time (+7) not in UTC.

petro · July 10, 2018, 4:00pm

Everything in the history graphs comes from the database. I believe the database is stored in UTC, but there is a chance it’s stored in your local timezone. You should try to clear the cache and refresh the page.

If that doesn’t work, then the information in the history database is stored in local and there is no way to change it. Delete the history database file and it will correct itself from here on forward.

pnbruckner · July 10, 2018, 4:16pm

swoofz:

If you see the picture below, the sensor has been in off state (dry) since July 10 2018 12:37 AM my local time (+7) no change on the state since then

the code we used :
{{states.binary_sensor.rain_sensor.last_changed }}
leads to following result :
Last Changed : 2018-07-10 00:36:14.380060+00:00
if it’s in UTC then it should be :
Last Changed : 2018-07-09 17:36:14.380060+00:00 

There is definitely something wrong somewhere. Starting with the picture, as I understand it, the datetimes are displayed in your local timezone. So, accordingly, last time it changed was 12:37 AM (local), and the picture was captured at 10:08 PM (local.) But then you display states.binary_sensor.rain_sensor.last_changed, and it reports ~12:37 AM, BUT IN UTC, NOT LOCAL! (Note that the “+00:00” suffix means UTC.) And, you’re right, it should be ~ 17:36 the day before (i.e., 7 hours earlier) if reported in UTC.

It does look like you have HA and Raspbian configured for the same timezone, so something is screwy. Try doing this from your ssh into your pi:

ls -l /etc/*time*

What do you get?

Actually, you might want to check out this article, or Google for Linux timezone yourself. Unfortunately timezone setting on Linux has gotten a bit complicated.

swoofz · July 10, 2018, 4:21pm

This is the first issue I encountered with logic related to date time object, my HA has been running on pi for several months with no issue. So deleting the database would be my last resort.

this is what i got :

pi@hassbian:~ $ ls -l /etc/*time*
lrwxrwxrwx 1 root root 32 Jul 10 22:43 /etc/localtime -> /usr/share/zoneinfo/Asia/Jakarta
-rw-r--r-- 1 root root 13 Jul 10 22:43 /etc/timezone

10:43PM was the time I checked the config and confirmed that everything has been properly setup.