Runing latest dev snapshot, still not able to get lock user code status from Vera

geekifier · November 1, 2019, 12:59pm

I have Home Assistant set up to use my Vera Edge as a Z-wave bridge.

I am having a terrible time trying to get detailed lock status attributes to appear in Home Assistant. I pulled the latest DEV Docker image, which should include this PR from @colohan : https://github.com/home-assistant/home-assistant/pull/27043, as well as pyvera 0.3.6. Build is tagged with 0.102.0.dev20191031.

Based on the PR description, I should be able to pull last_user_id, last_user_name, and low_battery attributes.

However, this is all that I am getting:

{'battery_level': '100', 'Vera Device Id': 3, 'low_battery': 0, 'friendly_name': 'Front Door'}

I can never get the user_id, or any other way of determining that the lock was unlocked with a keypad.
My use case is having a valid keypad unlock trigger a disarm of the security system, since I can then assume it’s an authorized entry. But, I don’t want an unlock using the deadbolt knob to do the same.

Anyone had any luck with this? The lock I am using is Schlage ~~FE469NX~~ BE469NX. I can see that within Vera itself, the sl_UserCode variable does update with the last unlock pin index, though it seems that it also stays set at that value when unlocked using the manual knob.

Edit: I just noticed something even weirder. The attributes appear to populate briefly when HA is restarted, however those might be just dummy values, as despite programming in a test user code at position #2, it was still showing changed_by: 1.

colohan · November 2, 2019, 12:58am

I don’t have that lock (I have KwikSet locks) so I’ve never tested that. But I can tell you what the code is doing, so you can start debugging and seeing if you can fix things up to work with your lock too.

Vera appears to communicate who unlocked a lock in one of two ways – a useful way and a useless way. The useless way is the sl_UserCode variable. This is useless because if you use the HTTP API you never know when that variable is set – so all you know is that “sometime in the past, this user unlocked the lock”. This is not useful if what you want to know is “for the most recent unlock, was it done via this PIN?” It doesn’t tell you. (If you are coding in Lua on the Vera itself you can watch for the variable being overwritten – but there is no way of doing that via the HTTP API.)

The useful way: Vera publishes a stream of “alerts”, which are events which happened on the Vera, with timestamps. For my lock (at least), a DL_USERCODE alert is published every time a user enters a PIN in the lock which results in it opening. So that is what this patch I created pipes through to HomeAssistant. It sounds like this isn’t working for your lock, so you need to know whether it is the Vera which is not generating the info you need, the pyvera plumbing it through wrong, or HomeAssistant interpreting it wrong.

To see the alerts on the Vera, go to http://VERA_IP_ADDRESS:3480/data_request?id=status&output_format=xml. Look for the section at the bottom called <alerts>. On mine, there is a series of alerts that look like this:

<alerts>
<alert PK_Device="35" Room="4" DeviceName="Garage Lock" DeviceType="urn:schemas-micasaverde-com:device:DoorLock:1" PK_Alert="25653746242" LocalDate="2019-10-03 15:56:37" EventType="4" SourceType="4" Argument="0" Filesize="0" Severity="3" LocalTimestamp="1570143397" Code="DL_USERCODE" NewValue="UserID="1" UserName=""" Description="Garage Lock" Users="" Server_Storage="" Key="" Icon="" PK_Store="0"/>
<alert PK_Device="35" Room="4" DeviceName="Garage Lock" DeviceType="urn:schemas-micasaverde-com:device:DoorLock:1" PK_Alert="25653748362" LocalDate="2019-10-03 15:56:45" EventType="4" SourceType="4" Argument="0" Filesize="0" Severity="3" LocalTimestamp="1570143405" Code="DL_LOCK_BUTTON" NewValue="1" Description="Garage Lock" Users="" Server_Storage="" Key="" Icon="" PK_Store="0"/>
<alert PK_Device="35" Room="4" DeviceName="Garage Lock" DeviceType="urn:schemas-micasaverde-com:device:DoorLock:1" PK_Alert="25654180722" LocalDate="2019-10-03 16:21:34" EventType="4" SourceType="4" Argument="0" Filesize="0" Severity="3" LocalTimestamp="1570144894" Code="DL_USERCODE" NewValue="UserID="3" UserName=""" Description="Garage Lock" Users="" Server_Storage="" Key="" Icon="" PK_Store="0"/>
<alert PK_Device="35" Room="4" DeviceName="Garage Lock" DeviceType="urn:schemas-micasaverde-com:device:DoorLock:1" PK_Alert="26043919772" LocalDate="2019-10-22 14:47:47" EventType="4" SourceType="4" Argument="0" Filesize="0" Severity="3" LocalTimestamp="1571780867" Code="DL_LOCK_BUTTON" NewValue="1" Description="Garage Lock" Users="" Server_Storage="" Key="" Icon="" PK_Store="0"/>
<alert PK_Device="35" Room="4" DeviceName="Garage Lock" DeviceType="urn:schemas-micasaverde-com:device:DoorLock:1" PK_Alert="26044392832" LocalDate="2019-10-22 15:16:44" EventType="4" SourceType="4" Argument="0" Filesize="0" Severity="3" LocalTimestamp="1571782604" Code="DL_USERCODE" NewValue="UserID="1" UserName=""" Description="Garage Lock" Users="" Server_Storage="" Key="" Icon="" PK_Store="0"/>
<alert PK_Device="35" Room="4" DeviceName="Garage Lock" DeviceType="urn:schemas-micasaverde-com:device:DoorLock:1" PK_Alert="26044506662" LocalDate="2019-10-22 15:22:19" EventType="4" SourceType="4" Argument="0" Filesize="0" Severity="3" LocalTimestamp="1571782939" Code="DL_LOCK_BUTTON" NewValue="1" Description="Garage Lock" Users="" Server_Storage="" Key="" Icon="" PK_Store="0"/>
</alerts>

The DL_USERCODE events are the ones which you are looking for. If those are present in your output (and formatted like the ones I show here), then your next step is to figure out why they are not getting passed on by pyvera.

Chris

geekifier · November 2, 2019, 2:40am

Wow @colohan, thanks so much for your very detailed (and helpful) response!

Thank you for explaining what’s happening behind the scenes, I will attempt to follow the trail and see what I can find out regarding this specific lock.

So far, I was able to locate those lock-related alerts using that XML dump. It seems pretty detailed, including separate events for the lock button being pressed, PIN unlock, and also specifying which PIN was entered at the keypad. I guess it looks promising, at least at the source (Vera).

<alerts>
<alert PK_Device="3" Room="0" DeviceName="Front Door" DeviceType="urn:schemas-micasaverde-com:device:DoorLock:1" PK_Alert="26240456332" LocalDate="2019-11-01 15:30:38" EventType="4" SourceType="4" Argument="0" Filesize="0" Severity="3" LocalTimestamp="1572636638" Code="DL_USERCODE" NewValue="UserID="1" UserName="Master"" Description="Front Door" Users="" Server_Storage="" Key="" Icon="" PK_Store="0"/>
<alert PK_Device="3" Room="0" DeviceName="Front Door" DeviceType="urn:schemas-micasaverde-com:device:DoorLock:1" PK_Alert="26240829452" LocalDate="2019-11-01 15:52:37" EventType="4" SourceType="4" Argument="0" Filesize="0" Severity="3" LocalTimestamp="1572637957" Code="DL_USERCODE" NewValue="UserID="2" UserName="Test"" Description="Front Door" Users="" Server_Storage="" Key="" Icon="" PK_Store="0"/>
</alerts>

And just to confirm, pyvera subscribes to those events by polling Vera’s API, correct? Vera itself should not be posting anything to Home Assistant? I am asking, because there are some firewall implications, since I have Vera on another VLAN, and behind a firewall. But as long as HA/pyvera is requesting data from Vera, then it’s all allowed and should work just fine.

colohan · November 2, 2019, 3:02am

I’d have to dig through the pyvera source again to recall how it works, but I believe pyvera makes long-running http requests to the Vera, and the Vera just appends data to the responses when new alerts come in. So if your Home Assistant can open port 3480 on the Vera via HTTP, it should just work.

Chris

chasut · November 2, 2019, 2:46pm

FYI, I am seeing the same behavior with the same lock. Only difference is that both my HA and locks are on the Same VLAN.

Happy to help if i can. I am really looking forward to having this info in HA. @colohan, can’t thank you enough for your work on this.

BTW, i had been dismissing this a bit because i had not seen the bump in PyVera to 0.3.6 in the HA change logs. Does that get pulled in the background? Or perhaps i just missed it.

colohan · November 2, 2019, 3:11pm

One annoying thing I noticed while implementing this – Vera publishes the state of the lock (locked vs unlocked) as a variable, while it publishes the use of PIN codes as alerts.

I assumed that if someone used a PIN code to open the lock, then both the variable change and alert would come through at the same time (as they seem to do with my lock setup). But perhaps with other locks there is some lag between when Vera announces the lock is unlocked, and the PIN code alert comes through? I’m not sure how well the code would handle that case.

colohan · November 2, 2019, 3:16pm

FYI – my first experiments with Home Assistant used the Vera as a zwave controller (since I already owned one, why not use it?). But I’ve since replaced it with an Aeotec Z-Stick, and it has been somewhat easier to setup and use than the Vera. I now just use my Vera just in my garage (which has proven challenging for me to get a reliable z-wave signal to from my house).

geekifier · November 3, 2019, 1:41am

Reading the forums, I see half of the people complaining about runing Vera, and praising the Aeotec Z-stick, and the other half complaining about issues with the Aeotec stick, and staying they had better luck using commercial controllers .

Back to the original issue, I cloned the pyVera repo, which had some Python scripts in the ./examples/ folder, namely device-listener.py.

Running that script, it seems that it’s getting lock values, though the Python object dump has some weird escape characters in it. I am not sure if that’s expected, or whether some of the key names are actually garbled. However, it looks like the alerts object/map is an empty set.

# hopefully I am not pasting my escaped door codes here...

# unlock via Vera

Front Door_3 values: {u'comment': u'', 'categoryName': u'Doorlock', u'parent': u'1', u'altid': u'2', u'configured': u'1', u'subcategory': 0, u'batterylevel': u'99', u'id': u'3', u'room': 0, u'category': 7, u'locked': u'0', u'pincodes': u'<VERSION=3>11\t1,1,2019-11-01 15:22:28,2019-11-01 15:38:23,****,Master;\t2,0;\t3,0;\t4,0;\t5,0;\t6,0;\t7,0;\t8,0;\t9,0;\t10,0;\t11,0;\t12,0;\t13,0;\t14,0;\t15,0;\t16,0;\t17,0;\t18,0;\t19,0;\t20,0;\t21,0;\t22,0;\t23,0;\t24,0;\t25,0;\t26,0;\t27,0;\t28,0;\t29,0;\t30,0;\t', u'commFailure': u'0', u'name': u'Front Door', u'state': u'1'}
Front Door_3 alerts: []

# lock via Vera

Front Door_3 values: {u'comment': u'', 'categoryName': u'Doorlock', u'parent': u'1', u'altid': u'2', u'configured': u'1', u'subcategory': 0, u'batterylevel': u'99', u'id': u'3', u'room': 0, u'category': 7, u'locked': u'1', u'pincodes': u'<VERSION=3>11\t1,1,2019-11-01 15:22:28,2019-11-01 15:38:23,****,Master;\t2,0;\t3,0;\t4,0;\t5,0;\t6,0;\t7,0;\t8,0;\t9,0;\t10,0;\t11,0;\t12,0;\t13,0;\t14,0;\t15,0;\t16,0;\t17,0;\t18,0;\t19,0;\t20,0;\t21,0;\t22,0;\t23,0;\t24,0;\t25,0;\t26,0;\t27,0;\t28,0;\t29,0;\t30,0;\t', u'commFailure': u'0', u'name': u'Front Door', u'state': u'1'}

# some time later (not immediately)

Front Door_3 alerts: []
Front Door_3 values: {u'comment': u'', 'categoryName': u'Doorlock', u'parent': u'1', u'altid': u'2', u'configured': u'1', u'subcategory': 0, u'batterylevel': u'99', u'id': u'3', u'room': 0, u'category': 7, u'locked': u'1', u'pincodes': u'<VERSION=3>11\t1,1,2019-11-01 15:22:28,2019-11-01 15:38:23,****,Master;\t2,0;\t3,0;\t4,0;\t5,0;\t6,0;\t7,0;\t8,0;\t9,0;\t10,0;\t11,0;\t12,0;\t13,0;\t14,0;\t15,0;\t16,0;\t17,0;\t18,0;\t19,0;\t20,0;\t21,0;\t22,0;\t23,0;\t24,0;\t25,0;\t26,0;\t27,0;\t28,0;\t29,0;\t30,0;\t', u'commFailure': u'0', u'name': u'Front Door', u'state': u'-1'}
Front Door_3 alerts: []
Front Door_3 values: {u'comment': u'', 'categoryName': u'Doorlock', u'parent': u'1', u'altid': u'2', u'configured': u'1', u'subcategory': 0, u'batterylevel': u'99', u'id': u'3', u'room': 0, u'category': 7, u'locked': u'1', u'pincodes': u'<VERSION=3>11\t1,1,2019-11-01 15:22:28,2019-11-01 15:38:23,****,Master;\t2,0;\t3,0;\t4,0;\t5,0;\t6,0;\t7,0;\t8,0;\t9,0;\t10,0;\t11,0;\t12,0;\t13,0;\t14,0;\t15,0;\t16,0;\t17,0;\t18,0;\t19,0;\t20,0;\t21,0;\t22,0;\t23,0;\t24,0;\t25,0;\t26,0;\t27,0;\t28,0;\t29,0;\t30,0;\t', u'commFailure': u'0', u'name': u'Front Door', u'state': u'-1'}
Front Door_3 alerts: []
Front Door_3 values: {u'comment': u'', 'categoryName': u'Doorlock', u'parent': u'1', u'altid': u'2', u'configured': u'1', u'subcategory': 0, u'batterylevel': u'99', u'id': u'3', u'room': 0, u'category': 7, u'locked': u'1', u'pincodes': u'<VERSION=3>11\t1,1,2019-11-01 15:22:28,2019-11-01 15:38:23,****,Master;\t2,0;\t3,0;\t4,0;\t5,0;\t6,0;\t7,0;\t8,0;\t9,0;\t10,0;\t11,0;\t12,0;\t13,0;\t14,0;\t15,0;\t16,0;\t17,0;\t18,0;\t19,0;\t20,0;\t21,0;\t22,0;\t23,0;\t24,0;\t25,0;\t26,0;\t27,0;\t28,0;\t29,0;\t30,0;\t', u'commFailure': u'0', u'name': u'Front Door', u'state': u'-1'}

When the listener is first started, the Initial values: section is populated with all the relevant fields, including alerts. But any subsequent alerts only show up as an empty set []. This seems to replicate the behavior I see, where I see the values populate in HA upon start, but then they quickly disappear once the lock state changes again.