Automation trigger on state update but not change (for lock automation)

david202 · April 1, 2018, 3:00am

I have a Schlage FE599 lock and I’m having issues triggering when a particular user code is used. I have a Schlage Connect as well and I can trigger based on user codes there because it uses different messages.

My issue is that the state of the related alarm type and level are updated but they don’t change. I’ve looked around here and found a few similar threads related to trigger on update vs state change, but nothing concrete (or indications it’s currently unsupported in HA). It seems that force_update might do what I’m looking for, but either that applies to MQTT only or I’m not configuring it correctly. I’m hoping to avoid a time based (30s/minute) trigger to get more reasonable latency. Does anyone have any suggestions on how to solve or work around this?

I can create a sensor that does what I want, but it never updates correctly:

- platform: template
  sensors:
    test_door_code:
      friendly_name: 'Test Code'
      value_template: >-
        {% if as_timestamp(now()) - as_timestamp(states.sensor.schlage_fe599gr_wireless_door_lock_alarm_level.last_changed) < 5 and is_state('sensor.schlage_fe599gr_wireless_door_lock_alarm_type', '16') %}
          {{ states.sensor.schlage_fe599gr_wireless_door_lock_alarm_level.state }}
        {% else %}
          0
        {% endif %}

petro · April 2, 2018, 1:05pm

What’s not updating correctly?

Just looking at your if statement, you may want to reverse the order. It depends on what you want to take precidence, ‘sensor.schlage_fe599gr_wireless_door_lock_alarm_type’, ‘16’ or …ast_changed) < 5.

If the first portion of your if statement is false, it won’t evaluate the second part. I’m not sure if it will change your sensor, but it may make it more in line with what you expect.

Also, if you aren’t seeing state changes, last_changed won’t do anything because it’s based on the last time the state changed.

david202 · April 2, 2018, 1:25pm

Thanks for the input. Let me clarify: it works fine in the template editor when I manually trigger it (ie, it shows a non-zero number for five seconds after the lock is operated and then returns 0 after 5 seconds). The issue is that the lock sends the same message every time a user code is used but doesn’t send any other updates to alarm level/type between these messages. When a new message is received, it does update the last_changed timestamp but doesn’t trigger a state change. I can also see the last_changed value update in the GUI. It seems my sensor is simply not revealuating when the last_updated value changes and is again less than 5 seconds.

Looking through the docs, it seems force_update would do exactly what I want, but I’m not sure how to enable that for the alarm value and type.

petro · April 2, 2018, 1:30pm

Can you point me to the docs that reference force_update? I’m not familiar with that and I’d like to help.

david202 · April 2, 2018, 1:55pm

Here’s where I found reference to force_update: https://dev-docs.home-assistant.io/en/master/api/entity.html. No idea if it applies or not.

I’m very familiar with Z-Wave and happy to help on that side but pretty new to HA. Thanks for the help!

petro · April 2, 2018, 2:04pm

Are you sure you are looking at the correct attribute? Also, I have a few z-wave devices that don’t post updates to the UI, I had to create template features. I didn’t bother dealing with last updated. I just passed the state to a template sensor with information I cared about.

Example:

I have a door sensor that returns 22 if open and 23 if closed. This didn’t update to the ui either. So I created a template sensor that just did that:

  main_door_hindge: # MAIN DOOR SENSOR #
    value_template: >
      {% if is_state('sensor.main_door_t_access_control_9_9', '23') %}
        closed
      {% elif is_state('sensor.main_door_t_access_control_9_9', '22') %}
        open
      {% else %}
        closed
      {% endif %}

So could you just make a sensor that reflects what you expect without this 5 second rule:

value_template: >
  {% if is_state('sensor.schlage_fe599gr_wireless_door_lock_alarm_type', '16') %}
    {% if states.sensor.schlage_fe599gr_wireless_door_lock_alarm_level.state == 'x' %}
      Unocked
    {% else %}
      Locked
    {% endif %}
  {% else %}
    Armed
  {% endif %}

Then you build automations off those state changes. It should update during any numerical change.

Also, note that I just made up a bunch of crap for this, your real template will be different based on the values you find.

david202 · April 2, 2018, 2:52pm

I have sensors that work like that and can trigger automations correctly.

The issue is handling the slightly different implemention on this lock. For example, everytime I enter my code at the lock, it sends a message with type = 16 and level = 1. If I come back and enter my code again an hour later, it sends the exact same message again. No other messages are sent between those code operations to change the level or type (I’ve confirmed this with a Z-Wave sniffer as well). The only item I can see that changes in HA is the last updated time. I can only get automations like you listed above to work if I enter an different code at the lock that generates a message like type = 16 and level = 2.

I’ll work on it more later today, open to other ideas as well. Thanks for the help!

petro · April 2, 2018, 2:55pm

Have you tried changing the reporting type of the lock in the z-wave configuration? Some devices by default don’t work with Hass and require a configuration change to properly show state changes.

david202 · April 2, 2018, 3:00pm

I had to add the controller to the 2nd association group on the lock to get any updates when codes are used (again, seemingly specific to this lock). I’ll look into the reporting type.

david202 · April 4, 2018, 1:37am

I looked into reporting type - and I found this page: https://www.home-assistant.io/docs/z-wave/device-specific/. It seems that the reporting type defines the method to turn generate a sensor state (ie, using basic set or alarm values). I don’t think that applies here since I’m not using a sensor but rather the raw alarm type/level values. Is there some other documentation on reporting type?

I double checked the messages sent from the lock with a Z-Wave sniffer (which are only sent once I configured the association groups correctly) as well.

Any other input on how I could enable force_update? I seem to keep coming back to that as the “right” way to do this since I can’t find a way to trigger a state change when the lock sends the same message every time my code is used.

petro · April 4, 2018, 1:46am

Adjusting the sensor state could signal home assistant to update the overall state of the device. At that point in time, you would perform your automation to look at the devices attributes. I’m not saying that this will 100% work, but trying it isn’t going to harm anything. Worse case scenario is that you have to exclude the device and factory reset it.

david202 · April 4, 2018, 2:48am

How can I adjust the sensor state? For that device, I don’t see any option to configure the sensor state.

petro · April 4, 2018, 11:46am

The reporting type should do that in the zwave configuration. Just because the documentation only calls out motion sensors does not mean other devices have the same issues. Home assistant is running a 2+ year old version of open zwave, there are many issues with it related to devices and how they report. I would start by changing the reporting type until you get positive feedback from Home Assistant.

david202 · April 4, 2018, 1:28pm

Interesting that HA is running such an old version of OpenZWave. Didn’t know that. Wonder if there is a way to upgrade and run a newer version…

The docs imply that the reporting type is a device setting (ie, a Z-Wave configuration parameter). Is that correct, or is there a setting to change that in the HA Z-Wave configuration?

petro · April 4, 2018, 3:39pm

Nope, I believe the hold up is either OpenZwave or HA integrating it. We have to wait for the dev’s.

petro · April 4, 2018, 3:41pm

It is a device setting and you should have access to it from the configuration page in home assistant, if you are running Hass.io. I don’t know where it is for hasbian, but I would assume it’s in the same place.

david202 · April 5, 2018, 2:50am

I don’t see anything about reporting type for this device in the Z-Wave settings. Note: I’m not running Hass.io. Here’s what I see in settings for this device:

Node value just lets me rename the entities for alarm type/level and locked status.
Associations have been configured so the lock is in association group 2 (which is needed on this one get unsolicited alarm reports from the lock).
Node config options is empty because OpenZWave seems to have a poor device database record for this device - but there’s nothing really useful in the exposed config parameters anyway.

david202 · April 5, 2018, 3:20am

I found a few pull requests related to force_update and I’m trying to sort out what was implemented/changed and whether or not it can be enabled for these sensors (alarm type and level).

https://github.com/home-assistant/home-assistant/pull/5705 (closed in favor of #5844 below)
https://github.com/home-assistant/home-assistant/pull/5844

I’ll update if I find anything useful.

petro · April 5, 2018, 11:36am

It would be config parameter. Use that drop down. If the device has a reporting option, it will be there:

david202 · April 6, 2018, 3:01am

I was afraid of that. This device does not have an option to change the reporting type - however I don’t think it would help anyway - the device is already sending alarm reports, which appears to be the preferred method for HA based on this page: https://www.home-assistant.io/docs/z-wave/device-specific/.