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

pnbruckner · July 10, 2018, 4:23pm

Unfortunately, I’m stumped. I can’t explain what you’re seeing. Sorry.

petro · July 10, 2018, 4:26pm

FYI when using filters in jinja, it doesn’t properly place the +00:00. It always uses +00:00 regardless of your timezone. It’s annoying, so I wouldn’t look at that.

EDIT: I’m refering to the datetime object that’s returned. I could be remembering wrong though…

I’m thinking of using strptime…

pnbruckner · July 10, 2018, 4:36pm

FWIW:

{{ now() }}
{{ utcnow() }}
{{ states.sensor.yr_symbol.last_changed }}
{{ now().time() }}
{{ utcnow().time() }}
{{ states.sensor.yr_symbol.last_changed.time() }}
{{ (now() - states.sensor.yr_symbol.last_changed).total_seconds()/60 }}
{{ (utcnow() - states.sensor.yr_symbol.last_changed).total_seconds()/60 }}

for me returns:

2018-07-10 11:33:11.666335-05:00
2018-07-10 16:33:11.666852+00:00
2018-07-10 15:31:00.416094+00:00
11:33:11.667905
16:33:11.668218
15:31:00.416094
62.187549616666665
62.18756251666667

I think this shows that now() returns a Python timezone aware datetime object in the local timezone, and utcnow() and last_changed return Python timezone aware datetime objects in UTC. And when two timezone aware datetime objects are subtracted, even if they are in different timezones, the result is correct.

This is why I can’t explain what @swoofz is seeing.

petro · July 10, 2018, 4:47pm

I guess i’m confused. Here you are posting this:

swoofz:

{{ 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

But then this is your screenshot:

Have you taken recent screenshots? Is that the correct rain sensor?

swoofz · July 10, 2018, 4:55pm

Yes that is the correct rain sensor, I only have 1 rain sensor.
I believe since the info on the graph is using HH:mm format then it round up the minute.

petro · July 10, 2018, 5:28pm

yes but your picture should match what’s stored in the object. That’s what doesn’t make sense. Have you cleared your cache and refreshed your browser?

petro · July 10, 2018, 5:37pm

NM, i Just noticed the 36 seconds at the top of the image. I’m confused as to what the problem is then. It appears as if everything is in order and working correctly. Your times are 7 hours apart, the objects match. What’s the problem?

petro · July 10, 2018, 6:23pm

22 - 14 is around 8am. your last update in utc is 12 am + your 7 hour offset is equal to about 8 am.

pnbruckner · July 10, 2018, 6:36pm

You can’t always assume the “xx hours ago” is the last time the state actually changed. In the picture, there are 20 hours from 12:37 AM to 10:08 PM. Sometimes the “xx hours ago” is how many hours ago HA was restarted. I see this all the time. In fact, you can see it in his second picture, where the start of the ‘off’ period was still 12:37 AM, yet the “xx hours ago” said “36 seconds ago”, because he had just restarted HA.

petro · July 10, 2018, 6:39pm

I understand that, I’m trying to understand what @swoofz’s problem actually is. Everything I see in this thread looks correct, except swoofz is saying it’s not. I think there is a disconnect here that I’m trying to root out.

swoofz · July 10, 2018, 6:39pm

my last changed was 12:36AM local time but somehow HA stored that in UTC, that’s the problem.

Having this issue, I’m thinking of publishing MQTT messages for last changed of on and off of the rain sensor in local time and refer that in the condition whenever needed.

Any thoughts? Thanks.

pnbruckner · July 10, 2018, 6:39pm

Yep. Totally agree.

petro · July 10, 2018, 6:41pm

@swoofz last changed does not mean last time it switched from wet to dry. it could have gone from dry to dry. Sensors do that, they report all the time. If they report the same state, it gets updated… The graph shows the state changes, not the updates.

swoofz · July 10, 2018, 7:01pm

so this was the automation I tried at 7am just to test the condition :

- alias: Test Condition
  trigger:
    platform: mqtt
    topic: 'home/OpenMQTTGWDev/433toMQTT'
    payload: '10839684'
  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

the automation above didn’t work while the fact that my sensor has been in off state since 12:36AM, around 6hrs past the last change from on to off until I tried the condition.

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

The result :

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

You can see that using the approach above, the difference from last changed to now() is only 1256 seconds or almost 21 minutes while the fact it should be around 6hrs. Last switch from on to off was at 12:36 local time but the value is store in UTC instead of local time.

any other way I can track the last change from on to off / wet to dry or the other way around without using last_changed? Thanks.

petro · July 10, 2018, 7:03pm

Right, but you restarted at 7 am right? So the last updated changed to 7am when you restarted. Just like when you restarted at 10:45pm and it changed:

swoofz:

{{ 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, 7:04pm

My point is, your automation will work if you leave it and it actually changes from x to dry and you don’t restart.

EDIT: Looking at the dev docs too, this statement is false too, so disregard that:

swoofz · July 10, 2018, 7:09pm

right, I did restart after each change of the code on automation.

So, HA didn’t refer to the actual last state change from on to off (12:36AM as shown in the graph) but will always refer last state change after restart?

petro · July 10, 2018, 7:17pm

Only with last_changed and last_updated.

You can use the history statistics to do this and ignore restarts:

Set it up to look for 2 hours behind for ‘off’. If the sensor is off for the full 2 hours, start the sprinkler.

Probably overkill. You could just leave it how you got it, it will only screw up for the first 2 hours after a restart… if no water was detected.

pnbruckner · July 10, 2018, 7:20pm

I think you’re getting fooled by the picture. I think that picture may leave out some details. E.g., when HA restarts, I think the sensor might be going to a state of ‘unknown’. It also may go from None to it’s real value at a restart. Try doing this from your ssh shell:

grep 'new_state=<state binary_sensor\.rain_sensor=' home-assistant.log

Or

grep -o 'new_state=<state binary_sensor\.rain_sensor=[^;]*' home-assistant.log

Hopefully that will tell you what’s really happening with the state of your sensor.

swoofz · July 10, 2018, 7:23pm

Thanks @petro, @pnbruckner , I’ll try to explore the history stats and hope can come up with a solution…