[SOLVED] Strategies for unknown device?

Thanks for great input! The official documentation doesn’t say anything about the wake up command, but I see that the openHab documentation on the device mentions 3 clicks and I’ve found that it works. I still have the problem though, that no matter how many times I wake it up (which I can see on the last woke up time in openHab), it doesn’t seem to transmit the manufacturer information needed to configure the device.
Could it be that some devices doesn’t transmit a NIF? I’ve added POPP and Aeon labs battery devices and no trouble at all with those.

The device needs to be in direct range of the controller when initialising. If it is, then please get a debug log so we can see what is happening.

The device is next to the controller.
What roughly am I looking for in the log?
The log looks almost identical for when a successful device discovery happens. Could it be some security related issue? This below stood out, “Unsupported command class” (I figure “application update request” is what I want working)

Unsupported command class
2019-06-23 18:49:24.021 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 18 00 49 84 0E 12 04 07 01 5E 85 59 55 86 72 5A 73 98 9F 6C 7A 80 84 71 5A 
2019-06-23 18:49:24.023 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationUpdate[73], type=Request[0], dest=14, callback=132, payload=84 0E 12 04 07 01 5E 85 59 55 86 72 5A 73 98 9F 6C 7A 80 84 71 
2019-06-23 18:49:24.023 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationUpdate[73], type=Request[0], dest=14, callback=132, payload=84 0E 12 04 07 01 5E 85 59 55 86 72 5A 73 98 9F 6C 7A 80 84 71 
2019-06-23 18:49:24.024 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-06-23 18:49:24.024 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 0
2019-06-23 18:49:24.024 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: null
2019-06-23 18:49:24.024 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=14, callback=132, payload=84 0E 12 04 07 01 5E 85 59 55 86 72 5A 73 98 9F 6C 7A 80 84 71 
2019-06-23 18:49:24.025 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 14: Application update request. Node information received. Transaction null
2019-06-23 18:49:24.025 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Unsupported command class COMMAND_CLASS_TRANSPORT_SERVICE
2019-06-23 18:49:24.025 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Unsupported command class COMMAND_CLASS_SECURITY_2
2019-06-23 18:49:24.025 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Unsupported command class COMMAND_CLASS_SUPERVISION
2019-06-23 18:49:24.025 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 14: Application update - no transaction.
2019-06-23 18:49:24.026 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-06-23 18:49:24.026 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-06-23 18:49:24.277 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Is awake with 1 messages in the queue
2019-06-23 18:49:24.278 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Start sleep timer at 2500ms
2019-06-23 18:49:24.278 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 14: Node Status event - Node is AWAKE
2019-06-23 18:49:25.529 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: WakeupTimerTask 1 Messages waiting, state SECURITY_REPORT
2019-06-23 18:49:25.994 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 08 00 04 00 0E 02 84 07 7C 
2019-06-23 18:49:25.996 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 02 84 07 
2019-06-23 18:49:25.997 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 02 84 07 
2019-06-23 18:49:25.997 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-06-23 18:49:25.997 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Application Command Request (ALIVE:SECURITY_REPORT)
2019-06-23 18:49:25.997 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Commands processed 1.
2019-06-23 18:49:25.997 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@5bc5c468.
2019-06-23 18:49:25.997 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-06-23 18:49:25.998 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-06-23 18:49:25.998 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

The device does talk to the controller, but since it’s not identified I can’t use it yet in OpenHab. Below is a movement detected

2019-06-23 19:02:51.759 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 04 00 0E 09 71 05 00 00 00 FF 07 08 00 77 
2019-06-23 19:02:51.762 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 09 71 05 00 00 00 FF 07 08 00 
2019-06-23 19:02:51.763 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 09 71 05 00 00 00 FF 07 08 00 
2019-06-23 19:02:51.763 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-06-23 19:02:51.763 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Application Command Request (ALIVE:SECURITY_REPORT)
2019-06-23 19:02:51.763 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-06-23 19:02:51.763 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: SECURITY NOT required on COMMAND_CLASS_ALARM
2019-06-23 19:02:51.764 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2019-06-23 19:02:51.764 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: NOTIFICATION report - 0 = 0, event=8, status=255, plen=0
2019-06-23 19:02:51.764 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = BURGLAR (0)
2019-06-23 19:02:51.764 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Commands processed 1.
2019-06-23 19:02:51.764 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@603f9145.
2019-06-23 19:02:51.764 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-06-23 19:02:51.764 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-06-23 19:02:51.764 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-06-23 19:02:51.765 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

There is no wakeup message being received - until the device is awake, the binding cannot communicate with the device. If it can’t talk to the device, then it can’t work out what services it supports, or what device type it is.

Please post logs either as attachments/links or use code fences so that it’s more readable (I’ve edited your posts to fix this).

Hi Daniel and welcome to the OpenHAB community!

I believe this is the documentation for the device in question?
link to pdf document
At the bottom of the last page there is a troubleshooting section that does include instructions on how to manually put the device into inclusion mode which is the same as saying ‘wake up’ the device.

Here is a link to a thread I started a while back about OpenHAB friendly motion sensors. In this thread, you can read about my trials and tribulations getting several brands of battery powered motion sensors working. Some needed woken up numerous times. Feel free to add your review of your sensor to the thread after we get it going

1 Like

Hi! Thanks for all great input and thanks for fixing the post.
I’ve gone through the logs and looked more in detail. From what I can understand from the logs, the node does wake up but when it’s asked for information the controller gets nothing back. The log below is heavily pruned so I hope I got in the relevant lines. Could it be that it needs to be securely included somehow? Or would there be any other reasons why it doesn’t respond with any data (see last log line)?

16:21:29.627	 - NODE 14: Node Status event - Node is AWAKE
16:21:29.627	 - NODE 14: Commands  1.
16:21:29.628	 - NODE 14: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandCl
16:21:34.743	 - NODE 14: TID 250: Timeout at state WAIT_DATA. 3 retries remaining.
16:21:34.743	 - TID 250: Transaction CANCELLED
16:21:34.743	 - NODE 14: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
16:21:34.744	 - NODE 14: notifyTransactionResponse TID:250 CANCELLED
16:21:34.749	 - Transaction SendNextMessage 0 out at start. Holdoff false.
16:21:34.750	 - Assembled message buffer = 01 09 00 13 0E 02 84 08 25 16 56
16:21:34.750	 - NODE 14: Sending REQUEST Message = 01 09 00 13 0E 02 84 08 25 16 56
16:21:34.752	 - Message SENT
16:21:34.753	 - Transaction SendNextMessage started: TID 310: [WAIT_RESPONSE] priority=Immediate, requiresResponse=true, callback: 22
16:21:34.753	 - Receive Message = 06
16:21:34.754	 - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
16:21:34.754	 - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
16:21:34.754	 - lastTransaction null
16:21:34.754	 - Received msg: ACK
16:21:34.754	 - ZWaveReceiveThread queue empty
16:21:34.754	 - Transaction SendNextMessage 1 out at start. Holdoff false.
16:21:34.755	 - TID 250: Transaction event listener: DONE: CANCELLED ->
16:21:34.755	 - NODE 14: Node Init response (1) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@1a3a5f39
16:21:34.755	 - NODE 14: No data from device, but it was ACK'd. Possibly not supported? (Try 1)

Why prune the log? I’m not really sure I understand it and generally speaking really short logs like this are very difficult to use as there is no context. What happens before this? The device seems to be awake, but why? Is the binding sending something? It seems so, but maybe it’s timing out. It’s really very difficult to use this sort of log - sorry.

It’s unlikely - secure devices normally allow basic functions, such as discovery, to be undertaken without security. Again though, I’m really guessing with no information.

Inclusion and wakeup are normally very different things. Maybe this device works differently, although the manual doesn’t say that wakeup is the same as inclusion.

To be clear - wakeup is a very specific message that a device sends. Another message that also works as a wakeup is a NIF - inclusion is not really related here.

Ok, I just think there were lots of log lines. Attaching the complete log for what I hope is the relevant time frame.
Thanks for clearifying the inclusion and wakeup concepts.
logOpenHab.txt (24.4 KB)

Sure, but I can very easily filter this down. I normally deal with logs that are 10 to 20MB - you log file is still only 24k, so I don’t think it’s too big :slight_smile:

It’s still pretty hard to tell what is happening. Your log starts with the fact that the device is awake, but I still don’t know why.

The whole log looks like this -:

So the binding is trying to send security requests - maybe the device was securely included, but I’m still left guessing a bit really.

Can I suggest to exclude the device, and re-include it. This time, please ensure that debug logging is on, and please provide the complete log.

I see, you have log reading tools :slight_smile: That makes it easier.
I just caught the whole wakeup-discovery sequence in the attached log.
I’ll try to do a exclude and re-include as well.

SP816-awake-discovery.txt (27.7 KB)

Hi, again. I did a full log of exclude and re-include. The exclude and re-include is done with an Aeotec Z-stick Gen5 detached.
I managed to get in a broken-pipe exception in the log as well. Don’t know if it’s a bug.
Node 10 is also a SP-816. The re-included node 14 is now node 16.
I had to zip the log but change the ending to pdf of log to be able to attach it. Sorry :frowning: … so change it to zip and unzip.

SP816-node10-node14-node16-openhab.pdf (169.4 KB)

Yes, you can also use them. It’s linked from the binding documentation and is available here -:
https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer

Anyway, it looks like this device is not responding to the first request it makes in the initialisation. Ironically, that request is the node information frame - the device does send this as the wakeup which is quite normal, but the binding initialisation doesn’t use this as it has a procedure it follows that needs to work for all devices.

It looks like it doesn’t therefore complete this stage of the initialisation sequence, but it’s unclear why the device isn’t responding to this command.

Since the NIF is sent when you wake the device, you could try performing the wakeup repeatedly so that the binding receives a NIF while it’s requesting one - that would hopefully make it move to the next stage. Of course it may not respond to other requests as well so maybe there’s something else up somewhere, but it’s worth a try.

Since the NIF is sent when you wake the device, you could try performing the wakeup repeatedly so that the binding receives a NIF while it’s requesting one - that would hopefully make it move to the next stage. Of course it may not respond to other requests as well so maybe there’s something else up somewhere, but it’s worth a try.

It actually worked to wake the device by tripple-clicking it repeatedly. When the log is turned on I can see that the clicking pace is right (since too fast triple-click doesn’t wake it up).

It seems as if this device doesn’t really conform to the communication standard if I understand you correctly.

Thanks for all the help!! :smile:

Just a note on the triple-clicking. I had another exactly the same device to add and tried to replicate the successful device configuration. It’s really hard to replicate. I noticed that the USB Z-stick can is put into inclusion mode when searching the inbox which removes the need to physically remove the stick in the adding process.
So what seemed to work this time was, remove SP816 from the network, put the Z-stick in inclusion mode using OpenHAB:s search function, remove the batteries of the SP816, put in the batteries (enters autoinclusion mode), tripple click the tamper-button repeatedly.

However, one problem remains. Even though the device is configured, none of the channels work (no events are generated in openHAB). I can see in the debug log that there are messages coming from the device put they are not picked up by OpenHAB. Any guess on how this could be? I have had no problems configuring other devices.

Log on message:

2019-06-25 10:05:32.417 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 04 00 10 09 71 05 00 00 00 FF 07 08 00 69 
2019-06-25 10:05:32.419 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=16, callback=0, payload=00 10 09 71 05 00 00 00 FF 07 08 00 
2019-06-25 10:05:32.420 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=16, callback=0, payload=00 10 09 71 05 00 00 00 FF 07 08 00 
2019-06-25 10:05:32.420 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-06-25 10:05:32.420 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Application Command Request (ALIVE:REQUEST_NIF)
2019-06-25 10:05:32.420 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-06-25 10:05:32.420 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY NOT required on COMMAND_CLASS_ALARM
2019-06-25 10:05:32.420 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 16: Received COMMAND_CLASS_ALARM V4 NOTIFICATION_REPORT
2019-06-25 10:05:32.421 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 16: NOTIFICATION report - 0 = 0, event=8, status=255, plen=0
2019-06-25 10:05:32.421 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 16: Alarm Type = BURGLAR (0)
2019-06-25 10:05:32.421 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-06-25 10:05:32.421 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2019-06-25 10:05:32.421 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter processing NOTIFICATION
2019-06-25 10:05:32.421 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter NOTIFICATION event is 8, type OnOffType
2019-06-25 10:05:32.421 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter processing NOTIFICATION
2019-06-25 10:05:32.422 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter NOTIFICATION event is 8, type OnOffType
2019-06-25 10:05:32.426 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Commands processed 1.
2019-06-25 10:05:32.426 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1e4e4c5d.
2019-06-25 10:05:32.426 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-06-25 10:05:32.426 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-06-25 10:05:32.427 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-06-25 10:05:32.427 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

Hi Andrew! Thanks for the feedback! I was looking for a wakeup section in the manual, so I missed that it was in the troubleshooting section. The Nexa manual (rebranded Evergreen) wasn’t clear on how to wake it up.
Anyhow, once I get this device working properly I’ll certainly share my experience about it. It seems it’s not the easiest device to configure. The device is now configured but only the battery-channel is available to OpenHAB (no alarms) which is a bit weird.

that is it

Have you linked items to all the channels?
Anyhow, as you see and Bruce before you from the other thread, it can be a little tricky getting the battery powered zwave devices working, but I have found them to be rock solid once configured.

Thanks for input! Yes, the channels are all linked. All other battery devices have worked like a charm compared to this SP-816. I’ve now managed to make them useful by configuring them to send an ON/OFF command to a peer node which I in turn can listen to that node’s events. This I configured using the Paper UI so it obviously can talk configuration to the device.

It seems I’m getting closer to solving this. It seems that this device must be included securely for it to be successfully identified by OpenHab. For a Aeotec Z-stick Gen5 that means that it must remain in the USB-port when including and inclusion mode on the Z-stick must be All Devices.

However, one problem still remains… I still get no communication on the channels. What get is this:

2019-11-03 09:47:26.159 [ERROR] [mmandclass.ZWaveSecurityCommandClass] - NODE 34: Error decapsulating security message

java.security.InvalidKeyException: No installed provider supports this key: (null)

	at javax.crypto.Cipher.chooseProvider(Cipher.java:892) ~[?:?]

	at javax.crypto.Cipher.init(Cipher.java:1248) ~[?:?]

	at javax.crypto.Cipher.init(Cipher.java:1185) ~[?:?]

	at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.generateMAC(ZWaveSecurityCommandClass.java:501) ~[227:org.openhab.binding.zwave:2.5.0.M1]

	at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.getSecurityMessageDecapsulation(ZWaveSecurityCommandClass.java:303) [227:org.openhab.binding.zwave:2.5.0.M1]

	at org.openhab.binding.zwave.internal.protocol.ZWaveNode.processCommand(ZWaveNode.java:1233) [227:org.openhab.binding.zwave:2.5.0.M1]

	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:485) [227:org.openhab.binding.zwave:2.5.0.M1]

Any ideas on what above means and how to solve it? I get that the key is missing, but why and how to fix it? There’s a network key in the configuration.