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:
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!
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.
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.
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.
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.
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.
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?
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.
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.
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).
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/.
So, I’ve been responding in alot of threads so I don’t know if I asked you this: Have you turned debug logging (in logger) on and watched events firing in the log?
Did you ever get anywhere with this. Still looks like alarm_type never updates, but the used code changes, but as you stated only when a new code is entered, so not much to trigger on with this lock if you dont have a lot of different codes being used each day
@david202 did you give up on this or did you ever figure it out? I’m facing the same situation with my BE369 and I’d rather not just simply replace the lock if I don’t have to.
Someone posted some useful templates, automations, etc just the other day on this. I’m using it for my FE599, which is an odd ball lock as well. Bascially it’s a workaround that works pretty great.
Set’s up a sensor using a template that changes based on a timestamp. That is then used to change an input_select. I set this up last night, and it’s working great.
I’m able to basically track if the lock is locked or unlocked and then who unlocked.
