I think we can close here. Thanks for the new binding. Now it works well.
External sensor is useless but this is by design 
Can you provide the log with the received messages, and/or provide the xml?
Here are the logs and the xml from node
Timestamp in log:
door/window magnet sensor open:
2017-05-30 21:16:27.100 [ItemStateChangedEvent ] - DoorSensor03 changed from CLOSED to OPEN
door/window magnet sensor closed:
2017-05-30 21:17:16.360 [ItemStateChangedEvent ] - DoorSensor03 changed from OPEN to CLOSED
external switch open:
2017-05-30 21:17:37.511 [ItemStateChangedEvent ] - DoorSensor03 changed from CLOSED to OPEN
external switch closed:
2017-05-30 21:18:14.673 [ItemStateChangedEvent ] - DoorSensor03 changed from OPEN to CLOSED
tamper open:
2017-05-30 21:18:50.601 [ItemStateChangedEvent ] - DoorSensor03_Sabotage changed from OFF to ON
tamper closed:
2017-05-30 21:19:19.965 [ItemStateChangedEvent ] - DoorSensor03_Sabotage changed from ON to OFF
node6.xml (8.7 KB)
openhab.xml (43.6 KB)
Looking at the XML, there are 3 alarms showing as being supported -:
<alarms>
<entry>
<alarmType>BURGLAR</alarmType>
<alarmState>
<alarmType>BURGLAR</alarmType>
<reportedEvents>
<int>3</int>
</reportedEvents>
</alarmState>
</entry>
<entry>
<alarmType>ACCESS_CONTROL</alarmType>
<alarmState>
<alarmType>ACCESS_CONTROL</alarmType>
<reportedEvents>
<int>22</int>
<int>23</int>
</reportedEvents>
</alarmState>
</entry>
</alarms>
The alarms 22 and 23 if I remember correctly are the door open/closed notifications, so this doesn’t seem to have one for the external switch. The manual seems to indicate that there might be a way to differentiate them although the manual I found states it uses event FE which I thought had a special meaning in the protocol so this might not be standard.
Looking at the log though, it seems the device isn’t using these messages a lot of the time - it is often using BASIC commands…
It looks like you are right:
in both times the device send event 23 by opening door/window or external switch:
Alarm converter NOTIFICATION event is 23, type OpenClosedType
in both times the device send event 22 by closing door/window or external switch:
Alarm converter NOTIFICATION event is 22, type OpenClosedType
So we cannot seperate which one triggeres the event. very sad.
I search for a solution to connect an external binary sensor for breaking glass to the door/window sensor to detect this too. My thought was to use the external switch for this, but with this result I cannot seperate the events. very sad. documentation from vision is wrong.
I have another door/window sensor from Fibaro which has an external switch too. I will try this one, if it works better.
I think all is done here,
thanks a lot.
Hi chris,
i come back to this. I opened a ticket at vsison and they send me this overview:
This means that it should be possible to separate the events. But I cannot see this in the debug log of the zwave protocol.
Where to find in the log “Alarm Event”? With this event type in combiantion with “Alarm Level” I can separate which sensor is triggered.
Alarm Event 0x02 ==> door/windows contact (status 0x00 or 0xff)
Alarm Event 0x03 ==> tamper switch contact (0xff)
Alarm Event 0xfe ==> external contact (status 0x00 or 0xff)
It is logged in the log.
If I remember correctly, FE is not a valid event - I think it means “no more events”.
Ok,
but I think vision uses it not for “no more events” but to detect external switch. Can you implement this? If yes, I can separate tamper switch from external switch and reed switch. Would be very helpful. With this solution I can use the door/window sensor with an additional binary sensor too and separate the events.
Maybe CO or CO² sensor or flood sensor or glas break sensor. All these external sensors are working as binary contact and can then connected to the external switch.
Hi chris,
do you see a change to implement a way to detect external switch for this device?
You wrote that 0xfe indicates “no more events”.
from Vision:
Alarm Event 0xfe ==> external contact (status 0x00 or 0xff)
If no, I will not spend more time with this device and try another one form a different supplier.
It’s problematic to do this since FE means “no more events”.
ok, so we do not go forward with this. makes the game too difficult.
Thanks a lot.
Hi!
I have the same door/window sensor. Is this binding still available for downloading? Sorry, but I’m a beginner. How to add this binding for openhab2?
Regards,
automasjon
use the normal zwave binding. Sensor is included. But additional open/close binary sensor cannot be used unindependent to the magnet sensor. Works in parallel
I have five of these and something is not working properly. They’ve been included on my z-wave network for days.
I remove the cover, which I assume is “alarm_burglar” and I get:
2018-01-18 20:43:17.828 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-01-18 20:43:17.841 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Application Command Request (ALIVE:DONE)
2018-01-18 20:43:17.844 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 28: Starting initialisation from DONE
2018-01-18 20:43:17.848 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Incoming command class ALARM
2018-01-18 20:43:17.854 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: Received ALARM command V2
2018-01-18 20:43:17.857 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: Process NOTIFICATION_REPORT V2
2018-01-18 20:43:17.860 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: NOTIFICATION report - 7 = 255, event=3, status=255
2018-01-18 20:43:17.862 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: Alarm Type = BURGLAR (7)
2018-01-18 20:43:17.867 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-01-18 20:43:17.869 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2018-01-18 20:43:17.876 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Updating channel state zwave:device:cab10335:node28:alarm_burglar to ON [OnOffType]
2018-01-18 20:43:17.884 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=28, callback=255, payload=1C 02 84 08
i put the magnet next to the device, which I assume is “sensor_door” I get:
2018-01-18 20:44:12.721 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Application Command Request (ALIVE:DONE)
2018-01-18 20:44:12.723 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 28: Starting initialisation from DONE
2018-01-18 20:44:12.728 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Incoming command class BASIC
2018-01-18 20:44:12.730 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 28: Received Basic Request
2018-01-18 20:44:12.732 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 28: Basic Set sent to the controller will be processed as Basic Report
2018-01-18 20:44:12.734 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 28: Basic report, value = 0x00
2018-01-18 20:44:12.738 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-18 20:44:12.740 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 0
2018-01-18 20:44:12.743 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=28, callback=1, payload=1C 02 84 08
2018-01-18 20:44:12.773 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Application Command Request (ALIVE:DONE)
2018-01-18 20:44:12.775 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 28: Starting initialisation from DONE
2018-01-18 20:44:12.779 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Incoming command class ALARM
2018-01-18 20:44:12.781 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: Received ALARM command V2
2018-01-18 20:44:12.783 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: Process NOTIFICATION_REPORT V2
2018-01-18 20:44:12.784 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: NOTIFICATION report - 7 = 0, event=2, status=255
2018-01-18 20:44:12.786 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 28: Alarm Type = BURGLAR (7)
2018-01-18 20:44:12.790 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-01-18 20:44:12.791 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2018-01-18 20:44:12.797 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Updating channel state zwave:device:cab10335:node28:alarm_burglar to ON [OnOffType]
2018-01-18 20:44:12.804 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=28, callback=1, payload=1C 02 84 08
The XML file is:
<node>
<deviceClass>
<basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>
<genericDeviceClass>BINARY_SENSOR</genericDeviceClass>
<specificDeviceClass>ROUTING_SENSOR_BINARY</specificDeviceClass>
</deviceClass>
<homeId>0xf67d3453</homeId>
<nodeId>28</nodeId>
<version>4</version>
<manufacturer>0x109</manufacturer>
<deviceId>0x102</deviceId>
<deviceType>0x2001</deviceType>
<listening>false</listening>
<frequentlyListening>false</frequentlyListening>
<routing>true</routing>
<security>false</security>
<beaming>true</beaming>
<maxBaudRate>40000</maxBaudRate>
<nodeInformationFrame>
<commandClass>ALARM</commandClass>
<commandClass>ASSOCIATION</commandClass>
<commandClass>BATTERY</commandClass>
<commandClass>MANUFACTURER_SPECIFIC</commandClass>
<commandClass>SENSOR_BINARY</commandClass>
<commandClass>VERSION</commandClass>
<commandClass>WAKE_UP</commandClass>
</nodeInformationFrame>
<supportedCommandClasses>
<entry>
<commandClass>ASSOCIATION</commandClass>
<associationCommandClass>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
<maxGroups>1</maxGroups>
</associationCommandClass>
</entry>
<entry>
<commandClass>ALARM</commandClass>
<alarmCommandClass>
<version>2</version>
<instances>1</instances>
<versionSupported>2</versionSupported>
<alarms>
<entry>
<alarmType>BURGLAR</alarmType>
<alarmState>
<alarmType>BURGLAR</alarmType>
<reportedEvents/>
<outer-class reference="../../../.."/>
</alarmState>
</entry>
</alarms>
<v1Supported>true</v1Supported>
<isGetSupported>true</isGetSupported>
</alarmCommandClass>
</entry>
<entry>
<commandClass>WAKE_UP</commandClass>
<WakeUpCommandClass>
<version>2</version>
<instances>1</instances>
<versionSupported>2</versionSupported>
<targetNodeId>1</targetNodeId>
<interval>3600</interval>
<minInterval>600</minInterval>
<maxInterval>604800</maxInterval>
<defaultInterval>3600</defaultInterval>
<intervalStep>200</intervalStep>
<lastWakeup>2018-01-19 01:31:47.895 UTC</lastWakeup>
<isGetSupported>true</isGetSupported>
</WakeUpCommandClass>
</entry>
<entry>
<commandClass>VERSION</commandClass>
<versionCommandClass>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
<libraryType>LIB_SLAVE_ROUTING</libraryType>
<protocolVersion>3.52</protocolVersion>
<applicationVersion>4.84</applicationVersion>
</versionCommandClass>
</entry>
<entry>
<commandClass>SENSOR_BINARY</commandClass>
<binarySensorCommandClass>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
<isGetSupported>true</isGetSupported>
<types/>
</binarySensorCommandClass>
</entry>
<entry>
<commandClass>MANUFACTURER_SPECIFIC</commandClass>
<manufacturerSpecificCommandClass>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
<initSerialNumber>false</initSerialNumber>
<deviceManufacturer>265</deviceManufacturer>
<deviceType>8193</deviceType>
<deviceId>258</deviceId>
</manufacturerSpecificCommandClass>
</entry>
<entry>
<commandClass>NO_OPERATION</commandClass>
<noOperationCommandClass>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
</noOperationCommandClass>
</entry>
<entry>
<commandClass>BATTERY</commandClass>
<batteryCommandClass>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
<batteryLevel>100</batteryLevel>
<batteryLow>false</batteryLow>
<isGetSupported>true</isGetSupported>
</batteryCommandClass>
</entry>
<entry>
<commandClass>BASIC</commandClass>
<basicCommandClass>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
<isGetSupported>true</isGetSupported>
</basicCommandClass>
</entry>
</supportedCommandClasses>
<securedCommandClasses/>
<associationGroups>
<entry>
<int>1</int>
<associationGroup>
<index>1</index>
<associations>
<associationMember>
<node>1</node>
<endpoint>0</endpoint>
</associationMember>
</associations>
</associationGroup>
</entry>
</associationGroups>
<nodeNeighbors>
<int>1</int>
<int>2</int>
<int>3</int>
<int>5</int>
<int>6</int>
<int>9</int>
<int>11</int>
<int>12</int>
<int>13</int>
<int>14</int>
<int>19</int>
<int>20</int>
<int>26</int>
<int>27</int>
</nodeNeighbors>
<lastSent>2018-01-19 01:31:48.247 UTC</lastSent>
<lastReceived>2018-01-19 01:31:48.371 UTC</lastReceived>
</node>
My Items file has:
Contact FF_Foyer_Entry_Sensor "Foyer Entry [%s]" <door> (FF_Foyer, Door) {channel="zwave:device:cab10335:node28:sensor_door"}
Number FF_Foyer_Entry_Battery "Foyer Entry Battery [%d %%]" <energy> (FF_Foyer, Status) {channel="zwave:device:cab10335:node28:battery-level"}
Contact FF_Foyer_Entry_Tamper "Foyer Tamper [%s]" <siren> (FF_Foyer, Status) {channel="zwave:device:cab10335:node28:alarm_burglar"}
Any thoughts? I’m running openHAB 2.3.0 Build #1188. I’ve removed and re-added the things using habmin and PaperUI a few times. Not luck
The device is in the database twice with different vendors, first we need to find out which one you have:
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/713
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/105
1 Like
Can you please post item config and z-wave settings related accociation settings
I would assume that it is the Vision entry 105 because that’s who I believe to be the OEM for MonoPrice which is where I purchased it.
@HomeAutomation The item config was included in my post. HAbmin indicates that it is associated to only one device, openHAB controller.
From your xml file the device is supporting the sensor_binary, but that one is not configured in the database.
The Zipato does have it in the config, don’t know if that makes the difference …
Correct - based on the XML you sent me, this is the one.
I’ve added the sensor_binary channel, although really if the current alarm channel (using the ACCESS_CONTROL notification) isn’t actually being sent, then it probably should be removed, and the sensor_binary should be sensor_door).
Normally in these situations where a device can send different commands, there is a parameter that controls what command class is used, but here (apparently!) there are no such parameters (that we know of!).
Thank you for the update. I grabbed the latest build and then removed and readded the device using HABmin. I then updated the items file to include a item and associated it to the new channel. Should I have done anything additional to apply the changes?
Contact FF_Mud_Entry_Sensor "Mud Entry [%s]" <door> (FF_Mud, Door) {channel="zwave:device:cab10335:node23:sensor_door"}
Number FF_Mud_Entry_Battery "Mud Entry Battery [%d %%]" <energy> (FF_Mud, Status) {channel="zwave:device:cab10335:node23:battery-level"}
Switch FF_Mud_Entry_Tamper "Mud Tamper [%s]" <siren> (FF_Mud, Status) {channel="zwave:device:cab10335:node23:alarm_burglar"}
Switch FF_Mud_Entry_Binary "Mud Entry Binary [%s]" <door> (FF_Mud, Door) {channel="zwave:device:cab10335:node23:sensor_binary"}
I’m new to these logs so I’m not really sure what to make of everything but my interpretation is that the only channel I’m seeing get updated is alarm_burglar.
When I remove the magnet to put the Reed Switch into open I get:
2018-01-20 10:16:37.547 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DYNAMIC_VALUES)
2018-01-20 10:16:37.550 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class BASIC
2018-01-20 10:16:37.552 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Received Basic Request
2018-01-20 10:16:37.555 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Basic Set sent to the controller will be processed as Basic Report
2018-01-20 10:16:37.557 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Basic report, value = 0xFF
2018-01-20 10:16:37.562 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-20 10:16:37.564 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2018-01-20 10:16:37.567 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Message has Ack Pending: Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=23, callback=159, payload=17 02 30 02
2018-01-20 10:16:37.616 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DYNAMIC_VALUES)
2018-01-20 10:16:37.617 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class BASIC
2018-01-20 10:16:37.619 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Received Basic Request
2018-01-20 10:16:37.620 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Basic Set sent to the controller will be processed as Basic Report
2018-01-20 10:16:37.621 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Basic report, value = 0xFF
2018-01-20 10:16:37.623 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2018-01-20 10:16:37.624 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-20 10:16:37.625 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2018-01-20 10:16:37.627 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Message has Ack Pending: Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=23, callback=159, payload=17 02 30 02
2018-01-20 10:16:37.912 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DYNAMIC_VALUES)
2018-01-20 10:16:37.916 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class BASIC
2018-01-20 10:16:37.920 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Received Basic Request
2018-01-20 10:16:37.923 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Basic Set sent to the controller will be processed as Basic Report
2018-01-20 10:16:37.927 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Basic report, value = 0xFF
2018-01-20 10:16:37.934 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-20 10:16:37.937 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2018-01-20 10:16:37.941 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Message has Ack Pending: Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=23, callback=159, payload=17 02 30 02
2018-01-20 10:16:38.041 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DYNAMIC_VALUES)
2018-01-20 10:16:38.045 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class ALARM
2018-01-20 10:16:38.048 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Received ALARM command V2
2018-01-20 10:16:38.051 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Process NOTIFICATION_REPORT V2
2018-01-20 10:16:38.053 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: NOTIFICATION report - 7 = 255, event=2, status=255
2018-01-20 10:16:38.056 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Alarm Type = BURGLAR (7)
2018-01-20 10:16:38.061 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-01-20 10:16:38.063 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2018-01-20 10:16:38.076 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Updating channel state zwave:device:cab10335:node23:alarm_burglar to ON [OnOffType]
2018-01-20 10:16:38.081 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Message has Ack Pending: Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=23, callback=159, payload=17 02 30 02
I see that there is a BASIC command coming in with a value of 0xFF. Shouldn’t that be what updates the channel for the sensor_door to open?
I also see an ALARM command coming in immediately after with the Alarm Type BURGLAR and a NOTIFICATION report - 7 = 255, event=2, status=255 which is what I assume made the alarm_burglar update to ON.
I don’t see anything in the logs for the node while the Reed Switch remains open.
When I return the magnet to close the reed switch I get:
2018-01-20 10:42:59.025 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DYNAMIC_VALUES)
2018-01-20 10:42:59.028 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class BASIC
2018-01-20 10:42:59.030 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Received Basic Request
2018-01-20 10:42:59.031 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Basic Set sent to the controller will be processed as Basic Report
2018-01-20 10:42:59.032 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Basic report, value = 0x00
2018-01-20 10:42:59.035 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-20 10:42:59.036 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 0
2018-01-20 10:42:59.088 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DYNAMIC_VALUES)
2018-01-20 10:42:59.090 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class ALARM
2018-01-20 10:42:59.091 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Received ALARM command V2
2018-01-20 10:42:59.092 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Process NOTIFICATION_REPORT V2
2018-01-20 10:42:59.093 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: NOTIFICATION report - 7 = 0, event=2, status=255
2018-01-20 10:42:59.095 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Alarm Type = BURGLAR (7)
2018-01-20 10:42:59.097 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-01-20 10:42:59.098 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2018-01-20 10:42:59.103 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Updating channel state zwave:device:cab10335:node23:alarm_burglar to ON [OnOffType]
I see that there is a BASIC command coming in with a value of 0x00. Shouldn’t that be what updates the channel for the sensor_door to closed?
I also see an ALARM command coming in immediately after with the Alarm Type BURGLAR and a NOTIFICATION report - 7 = 0, event=2, status=255 which is what I assume made the alarm_burglar update but why is it still to ON? The difference I see is that the report is “255” for open and “0” for closed.
When I remove the back cover I get:
2018-01-20 10:12:59.115 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DYNAMIC_VALUES)
2018-01-20 10:12:59.117 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class ALARM
2018-01-20 10:12:59.119 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Received ALARM command V2
2018-01-20 10:12:59.120 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Process NOTIFICATION_REPORT V2
2018-01-20 10:12:59.122 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: NOTIFICATION report - 7 = 255, event=3, status=255
2018-01-20 10:12:59.124 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Alarm Type = BURGLAR (7)
2018-01-20 10:12:59.128 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-01-20 10:12:59.129 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2018-01-20 10:12:59.135 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Updating channel state zwave:device:cab10335:node23:alarm_burglar to ON [OnOffType]
The same alarm_burglar is triggered to on. The difference I noticed in this command over the reed switch command is the NOTIFICATION report - 7 = 255, event=3, status=255. It is a event 3 instead of the 2 for the reed switch. This matches with what @HomeAutomation included earlier
The same commands repeat in the logs every 20-seconds while the back cover is off.
When I return the cover I get:
2018-01-20 10:15:32.035 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 23: Is awake with 3 messages in the wake-up queue.
2018-01-20 10:15:32.040 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 23: Wakeup during initialisation.
2018-01-20 10:15:32.042 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 23: Node advancer - DYNAMIC_VALUES: queue length(3), free to send(false)
2018-01-20 10:15:32.045 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 23: Node advancer - queued packet. Queue length is 3
2018-01-20 10:15:32.050 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveWakeUpEvent
2018-01-20 10:15:32.052 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 23: Sending REQUEST Message = 01 0B 00 13 17 04 71 04 00 06 25 9E 3C
2018-01-20 10:15:32.078 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:cab10335:node23' has been updated.
2018-01-20 10:15:32.084 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 23: Sent Data successfully placed on stack.
2018-01-20 10:15:32.281 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 23: SendData Request. CallBack ID = 158, Status = Transmission complete and ACK received(0)
2018-01-20 10:15:32.285 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Get, dest=23, callback=158, payload=17 04 71 04 00 06
2018-01-20 10:15:37.055 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 23: Timeout while sending message. Requeueing - 1 attempts left!
2018-01-20 10:15:37.060 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 23: Is sleeping
2018-01-20 10:15:37.062 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 23: Message already on the wake-up queue. Removing original.
2018-01-20 10:15:37.065 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 23: Putting message SendData in wakeup queue.
2018-01-20 10:15:37.070 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 23: Putting message SendData in wakeup queue.
I didn’t see any channel updates being triggered and I also didn’t see any NOTIFICATION report.
I apologize for such a long response but I am really trying to learn so that I can help troubleshoot these types of issues more quickly and maybe be of help to others in the future.
Thank you,
B34N