In the UI - look at the thing properties.
Iām noticing that the 108D isnāt always setting the switch to OFF after 120 seconds. Not sure why, since it seems to happen intermittently. Iāll try to do some debugging soon. Turning the switch ON seems to happen correctly.
@billias are you seeing something similar, perhaps?
@jphab Do you also have Habmin? if so you can click on Thing and under attributes you will see the Type / ID. I think there it shows the exact Device ID which can help us identify.
Do you know what version of Z-wave binding you run? 2.4.0? 2.5.0?
If you installed it from the UI then which version of openhab?
The type and ID and firmware version are shown in this image - zwave_deviceid and zwavedevicetype (note these are shown in decimal in PaperUI) - so this is 0003:1083, and firmware version is 3.97 (at the bottom of the image).
Form HABmin
Iām using the 2.4.0 binding (the stable release). Installed it from the Paper UI.
I didnāt klnow that.
Based on ID description i suspect this is 2.4.0 or not the latest 2.5.0.
Yes, iām using 2.4.0 binding.
We havenāt made any changes for this device, which can impact itās function on your version.
We will need some help to debug the device behaviour. Can you enable debug logging and upload your log in regards to this device?
Try 2-3 suggestions:
1.Enable PIR detections (parameter 4)
2. I see the parameter you posted and the instability. What is the param 8 value?
3. Also PARAM 5 is it correct?
4. To enable proper luminance reports I would suggest to set also param 9 to the luminance difference you want (I use a low value of 5)
DebugLOG.txt (11.4 KB)
This is a part of the log file. But if i click on the button to wake it up i doesnāt react any more. I will restart OH and send the logfile again.
does the led blink on wake up? if no then I suggest a heal and wakeup
parameter 4: set to enable - pending now
parameter 5: is set to 100 (default)
parameter 9: is set to 100 (default)
Param 9 can make sensor slower as it doesnāt update luminance, my values are more aggressive. but it is up to you to play around.
Param 5 is the threshold to enable the association triger
Do you have the device associated on a group?
@chris @billias as mentioned before Iām still running into an issue whereby the switch randomly doesnāt turn off after the specified interval.
I did some debug logging and it appears there is some data coming in:
2018-12-23 20:06:19.382 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 25 01 01 60 AE
2018-12-23 20:06:19.385 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=1, callback=37, payload=25 01 01 60
2018-12-23 20:06:19.982 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 04 30 03 00 0C
2018-12-23 20:06:19.985 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-12-23 20:06:19.987 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Application Command Request (ALIVE:REQUEST_NIF)
2018-12-23 20:06:19.990 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0
2018-12-23 20:06:19.992 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: SECURITY not supported
2018-12-23 20:06:19.995 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 25: Received COMMAND_CLASS_SENSOR_BINARY V0 SENSOR_BINARY_REPORT
2018-12-23 20:06:19.997 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 25: Sensor Binary report, type=Unknown, value=0
2018-12-23 20:06:20.000 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2018-12-23 20:06:20.003 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SENSOR_BINARY, value = 0
2018-12-23 20:06:20.006 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Commands processed 1.
2018-12-23 20:06:20.009 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1a1d791.
2018-12-23 20:06:20.011 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-12-23 20:06:20.013 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
However, the switch in OpenHab doesnāt get set to OFF.
For reference, this is what the log looks like when the sensor is triggered (so which turns the switch to ON):
2018-12-23 20:10:02.957 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 04 00 19 09 71 05 00 00 00 FF 07 08 00 60
2018-12-23 20:10:02.966 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 09 71 05 00 00 00 FF 07 08 00
2018-12-23 20:10:02.972 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 09 71 05 00 00 00 FF 07 08 00
2018-12-23 20:10:02.977 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-12-23 20:10:02.978 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0A 00 04 00 19 04 30 03 FF 0C 2C
2018-12-23 20:10:02.982 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Application Command Request (ALIVE:REQUEST_NIF)
2018-12-23 20:10:02.984 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 04 30 03 FF 0C
2018-12-23 20:10:02.987 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-12-23 20:10:02.992 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: SECURITY not supported
2018-12-23 20:10:02.996 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 25: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2018-12-23 20:10:02.999 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 25: NOTIFICATION report - 0 = 0, event=8, status=255, plen=0
2018-12-23 20:10:03.004 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 25: Alarm Type = BURGLAR (0)
2018-12-23 20:10:03.007 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-12-23 20:10:03.012 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-12-23 20:10:03.016 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 25: Alarm converter processing NOTIFICATION
2018-12-23 20:10:03.020 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 25: Alarm converter NOTIFICATION event is 8, type OnOffType
2018-12-23 20:10:03.024 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Updating channel state zwave:device:9c1948c3:node25:alarm_motion to ON [OnOffType]
2018-12-23 20:10:03.030 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Commands processed 1.
2018-12-23 20:10:03.033 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@fd55b1.
2018-12-23 20:10:03.037 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
So it looks like turning on the switch causes a COMMAND_CLASS_ALARM message to be triggered, but turning off the switch causes a COMMAND_CLASS_SENSOR_BINARY.
The strange thing is, sometimes the switch does turn off correctly. In those cases it doesnāt send a SENSOR_BINARY, it sends an ALARM again! That message looks like this:
2018-12-23 20:12:48.544 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 19 0A 71 05 00 00 00 FF 07 00 01 08 7D
2018-12-23 20:12:48.550 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 0A 71 05 00 00 00 FF 07 00 01 08
2018-12-23 20:12:48.558 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 0A 71 05 00 00 00 FF 07 00 01 08
2018-12-23 20:12:48.561 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-12-23 20:12:48.564 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Application Command Request (ALIVE:REQUEST_NIF)
2018-12-23 20:12:48.569 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-12-23 20:12:48.572 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: SECURITY not supported
2018-12-23 20:12:48.577 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 25: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2018-12-23 20:12:48.581 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 25: NOTIFICATION report - 0 = 0, event=0, status=255, plen=1
2018-12-23 20:12:48.594 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 25: Alarm Type = BURGLAR (0)
2018-12-23 20:12:48.597 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-12-23 20:12:48.599 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-12-23 20:12:48.602 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 25: Alarm converter processing NOTIFICATION
2018-12-23 20:12:48.603 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 25: Alarm converter NOTIFICATION event is 0, type OnOffType
2018-12-23 20:12:48.606 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Updating channel state zwave:device:9c1948c3:node25:alarm_motion to OFF [OnOffType]
2018-12-23 20:12:48.609 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Commands processed 1.
2018-12-23 20:12:48.611 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1d56fec.
2018-12-23 20:12:48.613 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-12-23 20:12:48.620 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
This behaviour is baffling me, but then Iām not a ZWave expert by any means. Any ideas what could be causing this?
No really. Iām not sure how we can easily reconcile this since it seems that neither the binary sensor, nor the alarm are consistent. I canāt see any easy way to combine the two so if both options have problems, then I donāt see a way out. 
Hmm, Iāll just add a virtual switch in between with an expire setting. But there definitely seems to be something buggy going on in these new devices, indeed.
@RoyJacobs Is the on/off switch assigned to an association group?
What is your Param 3 value? -1/0/255?
The on/off switch is not explicitly assigned, but the default association should work right? And I guess if this was incorrect I wouldnāt receive any messages?
Param3 was set to -1. I tried setting it to 255, but this is apparently the same as -1 (at least thatās what the parameter reverted to, not sure if this is stored as a byte inside the device or something).
Can you try 99?
If you associate the switch to group 2 then the switch should receive On/Off through basic (as per manual). And I do not know if Z-wave binding can control this command
This can be a device firmware prob.
Also what is your Lux level the moment you try to go on OFF setting? can it be higher than your Param5 value causing this?
Chris can help us with my thoughts