Setting Zwave 914TRL Touchpad Electronic Deadbolt user codes in Openhab3

Hi, I only just now started setting up OpenHab 3.4 after running 2.5 for some time (life prevented me from tackling the migration until now). I am working through most of the breaking changes just fine, but cannot get the same functionality out of my kwikset deadbolt as I was in 2.5. I was using curl in my rules to set/unset user codes in 2.5 like this:

val String updateResponse = executeCommandLine("/bin/sh@@-c@@/usr/bin/curl -o /dev/null -s -w \"%{http_code}\" --connect-timeout 10 --max-time 10 -X PUT --header \"Content-Type: application/json\" --header \"Accept: application/json\" -d \"{ \\\"usercode_code_" + item_name + "\\\": \\\"" + door_Code + "\\\" }\" \"http://localhost:8080/rest/things/zwave:device:512:node14/config\"",10000)

Sorry I know it’s ugly all jammed into one line, but the point is it was working. Upon doing this the logging would show something like this:

2023-02-16 09:03:36.949 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:512:node14' has been updated.

2023-02-16 09:03:36.957 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=usercode_code_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]

2023-02-16 09:03:38.611 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:512:node14' has been updated.

2023-02-16 09:03:38.615 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[]]

Now, in Openhab3+ the commandLine syntax has changed and Basic Authentication has been added to the REST API, so I thought it might be easier to change this to a sendHttpPutRequest like this:

val String jsonData = "{ \"usercode_code_" + item_name + "\": \"" + door_Code + "\", \"node_id\": 14 }"
val updateResponse = sendHttpPutRequest("http://********:*********@", "application/json", jsonData, 10000)

I am getting a response, but it is just echoing the deadbolt thing back to me (which might be useful here for troubleshooting too?), like this:

{"channels":[{"linkedItems":["Door_Lock"],"uid":"zwave:device:b2db3e6576:node14:lock_door","id":"lock_door","channelTypeUID":"zwave:lock_door","itemType":"Switch","kind":"STATE","label":"Door Lock","description":"Lock and unlock the door","defaultTags":[],"properties":{"binding:*:OnOffType":"COMMAND_CLASS_DOOR_LOCK"},"configuration":null},{"linkedItems":["Door_Lock_Alarm"],"uid":"zwave:device:b2db3e6576:node14:alarm_number","id":"alarm_number","channelTypeUID":"zwave:alarm_number","itemType":"Number","kind":"STATE","label":"Alarm [Deprecated]","description":"Provides the raw alarm value","defaultTags":[],"properties":{"binding:*:DecimalType":"COMMAND_CLASS_ALARM"},"configuration":null},{"linkedItems":["Door_Lock_Alarm_Raw"],"uid":"zwave:device:b2db3e6576:node14:alarm_raw","id":"alarm_raw","channelTypeUID":"zwave:alarm_raw","itemType":"String","kind":"STATE","label":"Alarm Raw","description":"Provides alarm parameters as json string","defaultTags":[],"properties":{"binding:*:StringType":"COMMAND_CLASS_ALARM"},"configuration":{}},{"linkedItems":["Door_Corridor_Battery"],"uid":"zwave:device:b2db3e6576:node14:battery-level","id":"battery-level","channelTypeUID":"system:battery-level","itemType":"Number","kind":"STATE","label":"Battery Level","description":"Battery level as a percentage (0-100%)","defaultTags":["Measurement","Energy"],"properties":{"binding:*:PercentType":"COMMAND_CLASS_BATTERY"},"configuration":{}}],"statusInfo":{"status":"ONLINE","statusDetail":"NONE"},"editable":true,"label":"Z-Wave Node 014: 914TRL Touchpad Electronic Deadbolt","bridgeUID":"zwave:serial_zstick:b2db3e6576","configuration":{"config_31_1_10000000":1,"config_40_1_wo":0,"config_31_1_01000000":0,"config_31_1_00100000":1,"node_id":14},"properties":{"zwave_class_basic":"BASIC_TYPE_ROUTING_SLAVE","zwave_class_generic":"GENERIC_TYPE_ENTRY_CONTROL","zwave_frequent":"true","zwave_neighbours":"1,5,6,7,8,9,12,13,15,17","modelId":"914TRL","zwave_listening":"false","zwave_version":"3.37","manufacturerId":"0090","manufacturerRef":"0001:0001","dbReference":"283","zwave_deviceid":"1","zwave_nodeid":"14","zwave_lastheal":"2023-02-16T08:51:47Z","defaultAssociations":"1","vendor":"Black \u0026 Decker","zwave_routing":"true","zwave_beaming":"true","zwave_secure":"false","zwave_class_specific":"SPECIFIC_TYPE_SECURE_KEYPAD_DOOR_LOCK","zwave_devicetype":"1","zwave_manufacturer":"144"},"UID":"zwave:device:b2db3e6576:node14","thingTypeUID":"zwave:kwikset_914trl_00_000"}

With Debug level logging for Zwave set I am getting the following log:

2023-02-16 09:55:08.859 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Configuration update received

2023-02-16 09:55:08.863 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Configuration update set usercode_code_2 to 11111 (String)

2023-02-16 09:55:08.866 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Error getting ZWaveUserCodeCommandClass

2023-02-16 09:55:08.868 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Configuration update ignored node_id to 14 (BigDecimal)

The inserted codes will not work. I also don’t see a place to set the user codes in the Deadbolt Thing in the Main UI like there was in PaperUI. One other curious thing I see is that the deadbolt is not ‘secure’ (zwave_secure = true) in Openhab3.4 whereas it was in 2.5. Is this possibly why the logging above says

NODE 14: Error getting ZWaveUserCodeCommandClass

and I cannot set the user codes? I thought the secure inclusion was mostly handled by the Zwave stick/device itself and didn’t have to be redone? When I switch back to my 2.5 install it is still shown as secure. Will doing secure inclusion again for the 3.4 install fix this? If that is the answer, is it going to ‘break’ the secure inclusion in 2.5 (I am switching back to it via sd card swap when I’m not actively working on getting 3.4 working)? Sorry that was a long slew of questions, Thanks!

EDIT: I actually just now tried the simple act of locking/unlocking the lock (I know it should have been first thing, but it seemed too basic to even check when the channel appeared and everything), which doesn’t work either. It logs:

2023-02-16 10:20:38.609 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Command received zwave:device:b2db3e6576:node14:lock_door --> ON [OnOffType]

2023-02-16 10:20:38.612 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 14: Command class COMMAND_CLASS_DOOR_LOCK not found

2023-02-16 10:20:38.615 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: No messages returned from converter

So this further makes me think secure inclusion has to be redone…

When you upgraded, did you recreate your Zwave controller thing or did you migrate the Thing as it was? If the former, did you ensure that the Network Security Key is the same? If not, than yes, you’ll need to reinclude the devices, or change the key on the Zwave controller Thing.

If the keys are the same between 2.5 and 3.4, I doubt reinclusion is the root problem.

Yes, if you did reinclude it with a different network security key in 3.4, it will break 2.5.

1 Like

Thank you! I figured it was something like that. Now that I know what to search for I see what you are talking about. I started from scratch (well, new openhabian installation, but reusing items, rules, sitemaps, etc… as much as possible), so yes the zwave network key must be different. I will copy it over and try that. Again, thanks for always being willing to help someone out!

EDIT: To anyone who might find this useful. Copying the network key over, restarting openhab, and then reinitializing the deadbolt Thing worked!