Binary Sensor last tripped time issue

Configuration
1

I’m having problems with the way that binary sensors are reporting their last tripped time. I’m getting the sensor data from the Envisalink panel, so not sure if the problem lies with that.

It appears that on the binary sensors, they will report the correct state, and when they are opened, the continually display last tripped time of 10 or 15 seconds even when they have been tripped for much longer.

The logbook and history will accurately show open and close events. But since the last tripped time seems to reset, I can’t do an automation that will take an action when the sensor has been triggered for x minutes or something similar to that.

Looking at the logs here, I opened the door at 20:34:06, and then left it open for a bit. Eventually I shut it around 20:50:00, but the panel does a pretty crappy job on reporting the closure (more on that later in the post). You can see that the last_tripped_time fluctuates between 10 and 15, even though the door never actually shut to cause the sensor to go to a closed state.

Is there anything that I can do to fix this? Is this a binary sensor issue, or maybe something with the envisalink configuration?

[homeassistant]$ cat home-assistant.log | grep 'carport_door='
2018-04-23 20:26:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=None, new_state=<state binary_sensor.carport_door=off; last_tripped_time=0, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:26:54.852033-04:00>>
2018-04-23 20:28:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=off; last_tripped_time=0, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:26:54.852033-04:00>, new_state=<state binary_sensor.carport_door=off; last_tripped_time=145, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:26:54.852033-04:00>>
2018-04-23 20:30:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=off; last_tripped_time=145, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:26:54.852033-04:00>, new_state=<state binary_sensor.carport_door=off; last_tripped_time=265, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:26:54.852033-04:00>>
2018-04-23 20:32:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=off; last_tripped_time=265, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:26:54.852033-04:00>, new_state=<state binary_sensor.carport_door=off; last_tripped_time=385, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:26:54.852033-04:00>>
2018-04-23 20:34:06 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=off; last_tripped_time=385, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:26:54.852033-04:00>, new_state=<state binary_sensor.carport_door=on; last_tripped_time=0, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>>
2018-04-23 20:34:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=on; last_tripped_time=0, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>, new_state=<state binary_sensor.carport_door=on; last_tripped_time=15, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>>
2018-04-23 20:40:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=on; last_tripped_time=15, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>, new_state=<state binary_sensor.carport_door=on; last_tripped_time=10, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>>
2018-04-23 20:42:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=on; last_tripped_time=10, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>, new_state=<state binary_sensor.carport_door=on; last_tripped_time=15, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>>
2018-04-23 20:46:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=on; last_tripped_time=15, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>, new_state=<state binary_sensor.carport_door=on; last_tripped_time=10, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>>
2018-04-23 20:48:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=on; last_tripped_time=10, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>, new_state=<state binary_sensor.carport_door=on; last_tripped_time=15, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>>
2018-04-23 20:52:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=on; last_tripped_time=15, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:34:06.365900-04:00>, new_state=<state binary_sensor.carport_door=off; last_tripped_time=125, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:52:54.775233-04:00>>
2018-04-23 20:54:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=off; last_tripped_time=125, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:52:54.775233-04:00>, new_state=<state binary_sensor.carport_door=off; last_tripped_time=245, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:52:54.775233-04:00>>
2018-04-23 20:56:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.carport_door, old_state=<state binary_sensor.carport_door=off; last_tripped_time=245, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:52:54.775233-04:00>, new_state=<state binary_sensor.carport_door=off; last_tripped_time=365, friendly_name=Carport Door, device_class=door @ 2018-04-23T20:52:54.775233-04:00>>

Here’s the relevant Envisalink configuration, if this could be the potential culprit. I have messed with zonedump_interval. The higher that is, the longer it takes for zone off/closed alerts to report. 120 is too high, and needs to be brought down (60 is default) but I think this may be something to do with the problem. It doesn’t always report every 120 seconds, sometimes it misses a checkin which can be seen from the logs.

envisalink:
  host: 192.168.3.10
  panel_type: HONEYWELL
  user_name: user
  password: user
  code: '1234'
  port: 4025
  evl_version: 4
  keepalive_interval: 60
  zonedump_interval: 120
  panic_type: Police
  zones:
    1:
      name: 'Fire'
      type: 'smoke'
    2:
      name: 'Front Door'
      type: 'door'
    3:
      name: 'Carport Door'
      type: 'door'
  partitions:
     1:
      name: 'Alarm'

Anyone have any advice here?

2

I think it has to do with the fact that the Envisalink module polls the status - it’s not a push from my ADT box.
For my system, this means that the doors and windows show open, closed, and /then open again even if I don’t do anything to them, especially if I have many of the doors/windows open at the same time

I am still kind of dissatisfied with the ‘real time aspect’ of this as well but having played around with it for hours/daysI have not found a solution.

What I’m doing now is, I’m mostly looking at an ‘overall’ sensor I have created:

    ready_to_arm:
      value_template: '{{ states.sensor.home_alarm_keypad.attributes["ready"] }}'
      friendly_name: Ready to Arm?

And I reduced looking at only a few sensors of when they were opened last - this gives me sufficient information at the moment. I’m not triggering anything of it anyway:

#######################################################################
    office_window_last_opened:
      friendly_name: Office Window Last Opened
      value_template:  >-
        {% set ow_uptime = states.binary_sensor.office_window.attributes["last_tripped_time"] | int %}
        {% set minutes = ((ow_uptime % 3600) / 60) | int %}
        {% set hours = ((ow_uptime % 86400) / 3600) | int %}
        {% set days = (ow_uptime / 86400) | int %}
        {%- if ow_uptime < 60 -%}
          Less than a minute ago
        {%- else -%}
          {%- if days > 0 -%}
            {%- if days == 1 -%}
              1 day
            {%- else -%}
              {{ days }} days
            {%- endif -%}
          {%- endif -%}
          {%- if hours > 0 -%}
            {%- if days > 0 -%}
              {{ ', ' }}
            {%- endif -%}
            {%- if hours == 1 -%}
              1 hour
            {%- else -%}
              {{ hours }} hours
            {%- endif -%}
          {%- endif -%}
          {%- if minutes > 0 -%}
            {%- if days > 0 or hours > 0 -%}
              {{ ', ' }}
            {%- endif -%}
            {%- if minutes == 1 -%}
              1 minute ago
            {%- else -%}
              {{ minutes }} minutes ago 
            {%- endif -%}
          {%- endif -%}
        {%- endif -%}
3

Ok, so it isn’t just me that is having the issue. You’ve got quite a bit of configuration there, and to be frank, I’m not really sure what you are trying to accomplish with it. It appears you are basing it off last_tripped_time (which is a relative field that doesnt get set properly), but based on what I see in the logs, I don’t see how that will work, since last_tripped_time is pretty much always inaccurate when the door/sensor is in fact open.

Can you somehow call the exact time that the sensor first tripped? Based on my log entries, looks like if you can call this time, and then do math based on the exact time it could work. Essentially if we grab that the door was opened at 20:34:00 and it is now 20:44:00, we can calculate that the door has been open for 10 minutes. Any thoughts on how to do that? Are those fields even accessible from the configuration?

open time provided in logs:

device_class=door @ 2018-04-23T20:34:06.365900-04:00

close time from logs:

device_class=door @ 2018-04-23T20:52:54.775233-04:00
4

I use envisalink 3 and 4 on two different HA’s. I tend to use trigger for automation and scripts but use last_changed for binary_sensors. This is one for a envisalink binary sensor that might work for you.

This script opens the garage only if the door leading to the garage hasn’t been open for 360 seconds. It tests whether we are arriving or leaving as we won’t be opening that door if we are arriving.

  open_garage_arrival:
    sequence:
      - condition: and
        conditions:
          - condition: state
            entity_id: binary_sensor.garage
            state: 'off'
          - condition: template
            value_template: '{% if states.binary_sensor.mud_room_door.last_changed  %}{{(as_timestamp(now())-as_timestamp(states.binary_sensor.mud_room_door.last_changed)) > 360 }}{% else %}True{% endif %}'
      - service: alarm_control_panel.envisalink_alarm_keypress
        data:
          entity_id: 'alarm_control_panel.home_alarm'
          keypress: '*74'
      - service: mqtt.publish
        data:
          topic: "rpi1/input_text/saythispi/state"
          payload: "I am opening the garage door"
      - service: logbook.log
        data_template:
          name: Garage
          message: RPi1**********open**********garage*********sciprt
5

This seems like it could be promising, but doesnt look like you can reference last_changed in a trigger. Am i missing something?

Or maybe I need an automation to call a script to do the condition? Seems like high overhead to constantly do that though.

6

You are correct, I’m working based on the last tripped time - which, BTW, seems to have a max. value that translates to something like 3 days and 19 hours if I remember correctly.

And this is what I display in my dashboard:
image

That’s sufficient for what I need.

If you want to show the time when e.g. your front door was last opened I could imagine the following approach:

  • create a datetime input variable for both actions, i.e. one for front_door_opened and one for front_door_closed
input_datetime:
  front_door_opened:
    name: Front Door Last Opened
    has_date: true
    has_time: true
  front_door_closed:
    name: Front Door Last Closed
    has_date: true
    has_time: true
  • push the current date and time to the respective variable whenever the door opens and closes
- alias: Front Door Last Opened
  trigger:
    platform: state
    entity_id: "YOUR ENVISIALINK SENSOR HERE"
# might be the other way round
    from: 'off'
    to: 'on' 
  action:
    - service: input_datetime.set_datetime
      data_template:
        entity_id: input_datetime.front_door_opened
        time: '{{ (as_timestamp(now()) | timestamp_custom("%H:%M:%S", true)) }}'
        date: '{{ (as_timestamp(now()) | timestamp_custom("%Y-%m-%d", true)) }}'
  • display these variables on your dashboard

Maybe you could extract if from the log file as well, not sure if it’s possible and if it would be any easier.

1 Like
7

This is helpful. Essentially, we’re storing the last opened time into input_datetime.front_door_opened. From there I would imagine you can reference that in an automation…

if now() - input_datetime.front_door_opened > 10 minutes, trigger automation.

if now() - input.datetime.front_door_opened < 10 minutes, ignore.

Just a matter of figuring out how to put that into an automation and I think that could work around this annoying problem with these binary sensors.

8

Take a look at what @will has to say here:

I could never get it to work as a trigger directly but it seems to work for him somehow, hope it does for you, too.

9

This is a template trigger for an automation that will trigger when the envisalink mud room door binary sensor has changed state 360 seconds ago.

automation:
  trigger:
    platform: template
    value_template:  {% if states.binary_sensor.mud_room_door.last_changed  %}{{(as_timestamp(now())-as_timestamp(states.binary_sensor.mud_room_door.last_changed)) > 360 }}{% else %}True{% endif %}
1 Like
10

That still doesn’t work. It appears that it triggers that automation the first time that envisalink is telling HA that a window is open, and its ignoring the code you’ve provided @RobDYI

  - alias: Window left open longer than 1 minute
    trigger:
      - platform: state
        entity_id: 
          - binary_sensor.office_windows
        from: 'off'
        to: 'on'
      - platform: template
        value_template: '{% if states.binary_sensor.office_windows.last_changed  %}{{(as_timestamp(now())-as_timestamp(states.binary_sensor.office_windows.last_changed)) > 60 }}{% else %}True{% endif %}'
    action:
    - service: notify.file1
      data_template:
        message: |
         {{now().strftime("%a %b %d %H:%M:%S %p")}} Windows has been open for a minute1
11

If I understand it correctly, the way you coded it, it treats your triggers as ‘or’ conditions, you might want to re-code it to make it an ‘and’ condition.

12 
  - alias: Window left open longer than 1 minute
    trigger:
      - platform: template
        value_template: '{% if states.binary_sensor.office_windows.last_changed  %}{{(as_timestamp(now())-as_timestamp(states.binary_sensor.office_windows.last_changed)) > 60 }}{% else %}True{% endif %}'
    condition:
      condition: state
      entity_id: binary_sensor.office_windows
      state: 'on'

This is just like state trigger for 1 minute.

13

@RobDYI - We are getting closer.

If I open the window, one notification takes place immediately upon opening the window, and then another notification happens after 60 seconds. Technically it’s a little after 60 seconds - at least 60 seconds plus the delay to get the next reading from the envisalink.

How do we get rid of the action notification from the initial state when we go from off to on? I only want this to take action when it has been open for 60 seconds.

14

and this doesn’t work?

- alias: Window left open longer than 1 minute
  trigger:
    platform: state
    entity_id: binary_sensor.office_windows
    to: 'on'
    for:
      minutes: 1
16

We are almost there, but it fires off alerts twice once the trigger happens. Might be a result of the zonedump_interval f the Envisalink, which is currently set to an interval of 15. I wonder if perhaps I need to adjust 300 seconds to be just over 300 or just under 300, since perhaps that is getting in the way here.

Here is my current automation code.

  - alias: Window left open longer than 5 minute
    trigger:
      - platform: state
        entity_id: 
          - binary_sensor.office_windows
        from: 'off'
        to: 'on'
        for:
          minutes: 5
      - platform: template
        value_template: '{% if states.binary_sensor.office_windows.last_changed  %}{{(as_timestamp(now())-as_timestamp(states.binary_sensor.office_windows.last_changed)) > 300 }}{% else %}True{% endif %}'
    condition:
      condition: state
      entity_id: binary_sensor.office_windows
      state: 'on'
    action:
    - service: notify.file1
      data_template:
        message: |
         {{now().strftime("%a %b %d %H:%M:%S %p")}} Windows has been open for 5 minutes!!

Log file (relevant lines):

2018-04-25 09:22:40 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.office_windows, old_state=<state binary_sensor.office_windows=off; last_tripped_time=36325, friendly_name=Office Windows, device_class=window @ 2018-04-24T23:17:46.365349-04:00>, new_state=<state binary_sensor.office_windows=on; last_tripped_time=0, friendly_name=Office Windows, device_class=window @ 2018-04-25T09:22:40.756377-04:00>>

2018-04-25 09:27:39 INFO (MainThread) [homeassistant.components.envisalink] Envisalink sent a zone update event. Updating zones…

2018-04-25 09:27:39 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.office_windows, old_state=<state binary_sensor.office_windows=on; last_tripped_time=10, friendly_name=Office Windows, device_class=window @ 2018-04-25T09:22:40.756377-04:00>, new_state=<state binary_sensor.office_windows=on; last_tripped_time=15, friendly_name=Office Windows, device_class=window @ 2018-04-25T09:22:40.756377-04:00>>

2018-04-25 09:27:41 INFO (MainThread) [homeassistant.core] Bus:Handling <Event logbook_entry[L]: name=Window left open longer than 5 minute, message=has been triggered, domain=automation, entity_id=automation.window_left_open_longer_than_5_minute>

2018-04-25 09:27:41 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=automation.window_left_open_longer_than_5_minute, old_state=<state automation.window_left_open_longer_than_5_minute=on; last_triggered=2018-04-24T22:25:17.068872-04:00, friendly_name=Window left open longer than 5 minute @ 2018-04-24T21:55:58.141402-04:00>, new_state=<state automation.window_left_open_longer_than_5_minute=on; last_triggered=2018-04-25T09:27:41.204928-04:00, friendly_name=Window left open longer than 5 minute @ 2018-04-24T21:55:58.141402-04:00>>

2018-04-25 09:27:52 INFO (MainThread) [homeassistant.components.envisalink] Envisalink sent a zone update event. Updating zones…

2018-04-25 09:27:52 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.office_windows, old_state=<state binary_sensor.office_windows=on; last_tripped_time=15, friendly_name=Office Windows, device_class=window @ 2018-04-25T09:22:40.756377-04:00>, new_state=<state binary_sensor.office_windows=on; last_tripped_time=10, friendly_name=Office Windows, device_class=window @ 2018-04-25T09:22:40.756377-04:00>>

2018-04-25 09:27:52 INFO (MainThread) [homeassistant.core] Bus:Handling <Event logbook_entry[L]: name=Window left open longer than 5 minute, message=has been triggered, domain=automation, entity_id=automation.window_left_open_longer_than_5_minute>

2018-04-25 09:27:52 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=automation.window_left_open_longer_than_5_minute, old_state=<state automation.window_left_open_longer_than_5_minute=on; last_triggered=2018-04-25T09:27:41.204928-04:00, friendly_name=Window left open longer than 5 minute @ 2018-04-24T21:55:58.141402-04:00>, new_state=<state automation.window_left_open_longer_than_5_minute=on; last_triggered=2018-04-25T09:27:52.309112-04:00, friendly_name=Window left open longer than 5 minute @ 2018-04-24T21:55:58.141402-04:00>>

17

I think all you need is this

- alias: Window left open longer than 5 minute
  trigger:
    platform: state
    entity_id: binary_sensor.office_windows
    to: 'on'
    for:
      minutes: 5
   action:
     - service: notify.file1
       data_template:
         message: |
          {{now().strftime("%a %b %d %H:%M:%S %p")}} Windows has been open for 5 minutes!!
18

I think this finally works.

This is pretty annoying though, since I spent so much time troubleshooting this for such a stupidly small issue in the automation code.

I was using this as reference:
https://community.home-assistant.io/t/left-open-automation/3688

Only difference that really had to be done was instead of saying "state: ‘on’ " I needed to use "to: ‘on’ " to account for the way that the Envisalink doesn’t use last_tripped_time properly.

Thanks for all the help from everyone!

19

Although, I would like to be able to alert on multiple windows being opened for 5 minutes independent of others.

If I change it from

entity_id: binary_sensor.office_windows

to

entity_id: 
- binary_sensor.office_windows
- binary_sensor.guest_windows

it will require that both the office_windows AND guest_windows are opened for 5 minutes. How do i automate this where it will view it as an OR condition instead of an AND condition?

20

I thought triggers are normally ‘or’ by default, maybe it has to do with your ‘for 5 minutes’ entry.

First thing I would try is to use:

entity_id: binary_sensor.office_windows, binary_sensor.guest_windows

Or, it might be as simple as:

    - entity_id: binary_sensor.office_windows
      to: 'on'
      for:
        minutes: 5
    - entity_id: binary_sensor.guest_windows
      to: 'on'
      for:
        minutes: 5

If neither works you might want to take a look here:

Originally, I was thinking about doing something similar but then I noticed the odd behavior I described above, i.e. when I have many windows/door open the Envisalink reports them as being closed for a while and then being open again without the windows/doors having been touched at all. If that happens in your setup as well it might screw with your automations.

Would be interested so see how it goes, though.

21

I know this is a little off topic based on the final solution but since something I wrote earlier was mentioned, I thought I chime in.

It is inconsistent and I’ve moved away from using it because it works fine with some states and not with others but you really don’t know which state it will work with.

For example, using it with the sun state, the now() comparison works great and has been for two months.

This works fine:

{{ (( as_timestamp( states.sun.sun.attributes.next_dusk ) | int ) - 180) < ( as_timestamp( now() ) | int ) }}

However, when I went to build a data/time drop down selection that would then be used to take my Nest out of vacation mode, now() didn’t work. I ended up having to create a date_time sensor as outlined under Time & Date.

This is what I used to trigger my Nest out of vacation mode:

{{ ( states.input_datetime.nest_away_end.attributes.timestamp | default(0) | int | timestamp_custom("%Y-%m-%d, %H:%M", True) ) == states.sensor.date__time.state }}

It is hard to guess what exactly is going because I am not familiar with the source code.