I’d like to get two Neo-coolcam Z-Wave PIR sensors added to the database because they currently show up as unknown device.
OpenHAB tells me “the database must be updated and you should raise an issue to get this addressed” but doesn’t explain where I should raise an issue. I also couldn’t find any better guidance online, which is why I am filing this here.
I have two different types of these:
One with device manufacturer 600, version 0.0, id 4227 and type 3.
The other is device manufacturer 600, version 0.0, id 4237 and type 3.
(the id is different between these two)
I believe that is all the info you need to add it to the database. Let me know if I need to provide anything else.
I looked and both devices appear to be in the DB. As battery devices they may need to be wakened again (or a few times) to be recognized. There could be more information if you set the Zw binding to debug prior to pressing the button.
EDIT you can search the DB directly from here. The numbers are in hex, so mfg 0x0258 and 4227 (0x1083) and 4237 (0x108d)
Thanks. That does lead to more questions than answers though:
Does that mean the error message is wrong?
Why does OpenHAB not recognize the device if it already has all the information needed to recognize it?
I’ve left them on for two days now and pressed the buttons repeatedly but they are still Unknown Devices.
I have many z-wave devices. If I turn on debugging, I get an unreadable amount of messages from all these devices, with no obvious way to filter the ones I should be looking at for more information. A quick glance over these messages shows they are terse and cryptic, suggesting one needs advanced knowledge of the z-wave plugin to make sense of them. Is there some page explaining what they mean, which messages I should be looking for and how to interpret them?
Assuming all the others and the controller work? What version of OH? What model of Z-stick?
Besides the log viewer, you could either attach a log file or put some lines in code fences (</> icon) here and I could take a look. To limit the file size, set the binding to debug, press the button (read manual - it could be three quick presses to wake), then set back to INFO after 20 seconds.
On a first pass I’d look for the device to show it is awake and what stage initialization is in and that the timer is started. Something like
2023-01-10 14:05:45.697 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Is awake with 0 messages in the queue, state IDENTIFY_NODE
2023-01-10 14:05:45.699 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - awakeMax for this Timer Task 20 in 0.5 second intervals
2023-01-10 14:05:45.699 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Start sleep timer with 500ms interval
2023-01-10 14:05:45.700 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 4: Node Status event - Node is AWAKE
Everything works, except these new devices aren’t identified.
OpenHAB 4.3.5 release build
OpenHAB provides no details about the stick type, other than “Z-Wave USB Stick with Serial Interface”, so I don’t know what you want to know. lsusb says “Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB”
I got the below (filtered for node 207, which I pressed the buttons on). I wasn’t sure if I got everything correctly, so I tried again but for some reason I do not appear get any messages now. I’ll try some more if you find the below isn’t helpful
15:57:21.811 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 9
15:57:22.194 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@3c182cd3
15:57:22.195 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Bump transaction 1561 priority from Controller to Immediate
15:57:22.196 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Adding to device queue
15:57:22.196 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Added 1561 to queue - size 9
15:57:22.213 DEBUG org.openhab.binding.zwave.handler.ZWaveThingHandler NODE 207: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
15:57:22.214 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: CANCEL while sending message. Requeueing - 2 attempts left!
15:57:22.215 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Adding to device queue
15:57:22.216 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Added 1561 to queue - size 9
15:57:22.218 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: TID 1561: Transaction not completed
15:57:22.311 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF count 10
15:57:22.479 DEBUG org.openhab.binding.zwave.handler.ZWaveThingHandler NODE 207: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
15:57:22.480 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: CANCEL while sending message. Requeueing - 1 attempts left!
15:57:22.482 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Adding to device queue
15:57:22.483 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Added 1561 to queue - size 9
15:57:22.486 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: TID 1561: Transaction not completed
15:57:22.742 DEBUG org.openhab.binding.zwave.handler.ZWaveThingHandler NODE 207: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
15:57:22.743 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Retry count exceeded. Discarding message: TID 1561: [CANCELLED] priority=Immediate, requiresResponse=true, callback: 0
15:57:22.743 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: TID 1561: Transaction completed
15:57:22.744 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: notifyTransactionResponse TID:1561 CANCELLED
15:57:22.745 DEBUG org.openhab.binding.zwave.handler.ZWaveThingHandler NODE 207: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
15:57:22.746 DEBUG org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer NODE 207: Node Init response (0) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@4df328eb
15:57:22.811 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 11
15:57:23.312 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 12
15:57:23.812 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 13
15:57:24.312 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 14
15:57:24.812 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 15
15:57:25.313 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 16
15:57:25.813 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 17
15:57:26.313 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 18
15:57:26.814 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 19
15:57:27.315 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: WakeupTimerTask 0 Messages waiting, state REQUEST_NIF count 20
15:57:27.316 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: Maximum Awake time period reached, state REQUEST_NIF count 20, messages 0
15:57:27.318 DEBUG org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveWakeUpCommandClass NODE 207: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
15:57:27.320 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: SECURITY not supported
15:57:27.321 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: Command Class COMMAND_CLASS_WAKE_UP is NOT required to be secured
15:57:27.326 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@7ee9fe35
15:57:27.328 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Bump transaction 1562 priority from Immediate to Immediate
15:57:27.333 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Adding to device queue
15:57:27.336 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Added 1562 to queue - size 9
15:57:27.339 DEBUG org.openhab.binding.zwave.handler.ZWaveSerialHandler NODE 207: Sending REQUEST Message = 01 09 00 13 CF 02 84 08 25 97 16
15:57:27.364 DEBUG org.openhab.binding.zwave.internal.protocol.serialmessage.SendDataMessageClass NODE 207: sentData was not placed on stack.
15:57:27.367 DEBUG org.openhab.binding.zwave.handler.ZWaveThingHandler NODE 207: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
15:57:27.367 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: CANCEL while sending message. Requeueing - 2 attempts left!
15:57:27.369 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Adding to device queue
15:57:27.370 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Added 1562 to queue - size 9
15:57:27.372 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: TID 1562: Transaction not completed
15:57:27.620 DEBUG org.openhab.binding.zwave.handler.ZWaveSerialHandler NODE 207: Sending REQUEST Message = 01 09 00 13 CF 02 84 08 25 98 19
15:57:27.631 DEBUG org.openhab.binding.zwave.internal.protocol.serialmessage.SendDataMessageClass NODE 207: sentData was not placed on stack.
15:57:27.634 DEBUG org.openhab.binding.zwave.handler.ZWaveThingHandler NODE 207: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
15:57:27.635 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: CANCEL while sending message. Requeueing - 1 attempts left!
15:57:27.637 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Adding to device queue
15:57:27.638 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Added 1562 to queue - size 9
15:57:27.640 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: TID 1562: Transaction not completed
15:57:27.886 DEBUG org.openhab.binding.zwave.handler.ZWaveSerialHandler NODE 207: Sending REQUEST Message = 01 09 00 13 CF 02 84 08 25 99 18
15:57:27.904 DEBUG org.openhab.binding.zwave.internal.protocol.serialmessage.SendDataMessageClass NODE 207: sentData was not placed on stack.
15:57:27.906 DEBUG org.openhab.binding.zwave.handler.ZWaveThingHandler NODE 207: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
15:57:27.907 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Retry count exceeded. Discarding message: TID 1562: [CANCELLED] priority=Immediate, requiresResponse=true, callback: 153
15:57:27.908 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: TID 1562: Transaction completed
15:57:27.908 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: notifyTransactionResponse TID:1562 CANCELLED
15:57:27.910 DEBUG org.openhab.binding.zwave.handler.ZWaveThingHandler NODE 207: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
15:57:27.911 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveNode NODE 207: Went to sleep TIMEOUT_WAITING_FOR_CONTROLLER
15:57:28.919 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@3c182cd3
15:57:28.920 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Bump transaction 1563 priority from Controller to Immediate
15:57:28.921 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Adding to device queue
15:57:28.922 DEBUG org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager NODE 207: Added 1563 to queue - size 9
That is inconclusive. First it is best not to filter, messages without the node number can be important. Second the log started 4.5 seconds after the button was pressed.
Also the state Request_NIF doesn’t refer to the initialization steps. Not sure what to advise except try again.
I’m having problems figuring out how the log viewer works. It seems to not run in real-time; messages’ timestamps suggest they come in only a few hundreds of seconds apart at random intervals but new lines appear in the viewer with what appear to be regular intervals and clearly a lot slower than that. I’ll give it another try in a bit.
Assuming you are talking about the UI version. I’m old school. When you set the binding debug, the items will appear in the openhab log. You can then load that into the Zwave log viewer referenced above. (non-ZW messages are ignored). Your first snippet just shows this.
I appreciate the patience in trying to help me. I am running into several issues:
I wasn’t to find out how to grab anything useful using the UI. I ended up grabbing the relevant log directly from /var/log/openhab/openhab.log. I’m surprised the UI isn’t more intuitive and helpful with this, but at least that issue is resolved.
I collected logs multiple times, and tried to confirm they contained messages from the problematic devices. Surprisingly, I couldn’t find any, unlike the first time.
Z-Wave debug logs for 20 seconds on my system are about ~1Mb. I cannot copy+paste more than 100Kb in a message. As a new user, I am apparently not allowed to upload attachments here either.
Once I have some more time, I will try again to collect relevant logs. Hopefully that problem will resolve itself at some point.
I haven’t yet got a solution for the log size. I will see if I can get some of the more noisy devices to shut up a bit. There is a multi-sensor that appears to report sensor readings at least once a second, which makes little sense given that it’s only supposed to report information once a minute at most. I’m not sure if this is a bug in the device, or if the settings on the device itself are somehow not what OpenHAB reports them to be.
…and it magically started working as expected for no obvious reason for all but one device.
I finally got a relevant message in debug logs, by accident because it wasn’t one of the devices for which I pressed the wake up button. But since the logs contained a luminescence report, I assumed OpenHAB must be able to figure out what the device does. I went to the Thing config and sure enough; 4 out of 5 of these devices are no longer unknown devices.
I’ll see about getting a log for the final problematic device. Hopefully that’ll help figure out why this doesn’t magically work immediately but took a few days.
That likely explains your troubles. All the traffic probably blocked the initialization of the devices. The binding limits the messages to a device but can’t do anything if devices are overloading the controller. If the initialization doesn’t get far enough the wakeup time won’t get set and they will never wake up to finish configuration, hence the button presses suggestion (for battery nodes). But even then, it takes a couple of seconds to get going again and the incoming traffic could keep blocking it.
I have heard a guideline that the ZW limit is about 10 frames a second, so reducing noisy devices is a good idea. (I actually use 1 frame a second as a guideline.) The is no limit (AFAIK) to what the ZW viewer can handle. Load your debug openhab.log for 2-3 minutes and look for the green RXs. Depending on what else is in the openhab log, you can separate the ZW to a separate log like I do. See the very bottom of that post.
One random tip; on energy devices never use the % change for devices that can go to zero. There are msec changes of stray energy around zero. That and button presses should help get the last device configured. Good luck
Assuming buggy devices and mis-configurations are a common enough problem that are hard to diagnose for the average user, it might be a good idea for automatic warning and reporting in OpenHAB.
This could be either individual devices sending more messages than makes sense for their device type (i.e. per-device type acceptable tx/s limits). Such limits would be determined based on experience and some users may cross the limit on purpose for special use-cases.
It could also be all devices combined sending more messages than the protocol is expected to handle gracefully. (i.e. total acceptable tx/s limit). This would be a hard-limit imposed by hardware/firmware/software.
I have no idea how much effort creating such checks takes and how big of a demand there is, so this might be a lot of work to help resolve a problem that hardly ever happens.
