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://********:*********@127.0.0.1:8080/rest/things/zwave%3Adevice%3Ab2db3e6576%3Anode14/config", "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…