[SOLVED] Vision Door/Windows sensor zd2102 open/close and tamper are not triggered to different events

I think the documentation is wrong. Nothing different in the log if I open door/window magnet or open binary switch. Looks like a error in documenation. Tamper switch acts different

tamper:

2017-05-30 20:32:05.365 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 6: Application Command Request (ALIVE:DETAILS)
2017-05-30 20:32:05.365 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 6: Incoming command class ALARM
2017-05-30 20:32:05.366 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 6: Received ALARM command V4
2017-05-30 20:32:05.366 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 6: Process NOTIFICATION_REPORT V4
2017-05-30 20:32:05.367 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 6: NOTIFICATION report - 7 = 255, event=3, status=255
2017-05-30 20:32:05.367 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 6: Alarm Type = BURGLAR (7)

external switch:

2017-05-30 20:29:16.175 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 6: Application Command Request (ALIVE:DETAILS)
2017-05-30 20:29:16.176 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 6: Incoming command class BASIC
2017-05-30 20:29:16.177 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 6: Received Basic Request
2017-05-30 20:29:16.178 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 6: Basic Set sent to the controller will be processed as Basic Report
2017-05-30 20:29:16.179 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 6: Basic report, value = 0xFF
2017-05-30 20:29:16.180 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2017-05-30 20:29:16.181 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-05-30 20:29:16.182 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2017-05-30 20:29:16.184 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=6, callback=25, payload=06 01 00
2017-05-30 20:29:16.186 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 06 03 20 01 FF
2017-05-30 20:29:16.187 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=25, expected=SendData, cancelled=false      MISMATCH

door/window magnet:

2017-05-30 20:27:46.061 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 6: Application Command Request (ALIVE:DETAILS)
2017-05-30 20:27:46.061 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 6: Incoming command class BASIC
2017-05-30 20:27:46.062 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 6: Received Basic Request
2017-05-30 20:27:46.062 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 6: Basic Set sent to the controller will be processed as Basic Report
2017-05-30 20:27:46.063 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 6: Basic report, value = 0xFF
2017-05-30 20:27:46.063 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2017-05-30 20:27:46.064 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-05-30 20:27:46.064 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255

I think we can close here. Thanks for the new binding. Now it works well.

External sensor is useless but this is by design :wink:

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!).