Z-Wave DWS01 New Device Setup

TJOGRADY · August 25, 2017, 6:07pm

I am trying to add a new Z-Wave device to Chris’ database.

The device is a simple Door/Window switch from Monoprice Model HKZW-DWS01.

I have the battery level and tamper alarm working, I just have something misconfigured with the binary sensor.

I uploaded the XML created by the system, so there wasn’t any manual setup done.

Can someone take a look and provide any feedback?

Thanks in advance.

When I trigger the switch this is what I am seeing in the log:

2017-08-25 13:02:39.731 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f7dddbf0_serial_ack changed from 209 to 210

2017-08-25 13:02:39.745 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f7dddbf0_serial_sof changed from 476 to 477

Example of the XML uploaded to the database:

<?xml version="1.0" encoding="UTF-8"?>

<thing:thing-descriptions bindingId="zwave"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xmlns:thing="http://eclipse.org/smarthome/schemas/thing-description/v1.0.0"

  xsi:schemaLocation="http://eclipse.org/smarthome/schemas/thing-description/v1.0.0

                      http://eclipse.org/smarthome/schemas/thing-description/v1.0.0">

  <thing-type id="hank_24259_00_000" listed="false">

    <label>24259 MONOPRICE Door and Window Sensor P/N 24259</label>

    <description>MONOPRICE Door and Window Sensor P/N 24259</description>

    <!-- CHANNEL DEFINITIONS -->

    <channels>

      <channel id="sensor_binary" typeId="sensor_binary">

        <label>Binary Sensor</label>

        <properties>

          <property name="binding:*:OnOffType">SENSOR_BINARY</property>

        </properties>

      </channel>

      <channel id="alarm_access" typeId="alarm_access">

        <label>Alarm (access)</label>

        <properties>

          <property name="binding:*:OnOffType">ALARM;type=ACCESS_CONTROL</property>

        </properties>

      </channel>

      <channel id="alarm_burglar" typeId="alarm_burglar">

        <label>Alarm (burglar)</label>

        <properties>

          <property name="binding:*:OnOffType">ALARM;type=BURGLAR</property>

        </properties>

      </channel>

      <channel id="battery-level" typeId="system.battery-level">

        <properties>

          <property name="binding:*:PercentType">BATTERY</property>

        </properties>

      </channel>

    </channels>

    <!-- DEVICE PROPERTY DEFINITIONS -->

    <properties>

      <property name="vendor">Hank</property>

      <property name="modelId">24259</property>

      <property name="manufacturerId">0208</property>

      <property name="manufacturerRef">0201:0008</property>

      <property name="dbReference">663</property>

    </properties>

    <!-- CONFIGURATION DESCRIPTIONS -->

    <config-description>

      <!-- ASSOCIATION DEFINITIONS -->

      <parameter-group name="association">

        <context>link</context>

        <label>Association Groups</label>

      </parameter-group>

      <parameter name="group_1" type="text" groupName="association" multiple="true">

        <label>1: Group 1</label>

        <description><![CDATA[

Association Group 1<br /><h1>Overview</h1> <ul><li> <p>Group 1 reports the status of the Door/Window Sensor, the battery level, and the tamper button status. </p> </li> </ul>

        ]]></description>

        <multipleLimit>5</multipleLimit>

      </parameter>

      <parameter name="group_2" type="text" groupName="association" multiple="true">

        <label>2: Group 2</label>

        <description><![CDATA[

Association Group 2<br /><h1>Overview</h1> <ul><li> <p>Group 2 is assigned to the Door/Window Sensor BASIC SET command. </p> </li> </ul>

        ]]></description>

        <multipleLimit>5</multipleLimit>

      </parameter>

    </config-description>

  </thing-type>

</thing:thing-descriptions>

TJOGRADY · September 7, 2017, 10:55pm

Hello,

I tried a couple different settings in the database and tested them out. Like I had mentioned the Alarm and Battery Level appear to be working. The actual binary switch is still not functioning as expected. Does anyone with more experience have a couple minutes to take a look at the setup?

I can only imagine that this switch will become more popular as Monoprice has been running frequent sales on them.

Thanks in advance for any assistance, it is appreciated.

chris · September 8, 2017, 9:11am

Please get a debug log so we can see what is happening and I’ll take a look.

TJOGRADY · September 8, 2017, 3:56pm

Hi Chris,

Thanks for taking some time to take a look at my device. I turned on debugging and took a snippet from my log when I actuated the switch a couple times. The device in question is on Node23:

2017-09-08 10:50:49.745 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 17 0A 71 05 00 00 00 FF 06 17 00 00 6C 
2017-09-08 10:50:49.747 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 17 0A 71 05 00 00 00 FF 06 17 00 00 6C 
2017-09-08 10:50:49.749 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 17 0A 71 05 00 00 00 FF 06 17 00 00 
2017-09-08 10:50:49.751 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DETAILS)
2017-09-08 10:50:49.753 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class ALARM
2017-09-08 10:50:49.755 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Received ALARM command V5
2017-09-08 10:50:49.756 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Process NOTIFICATION_REPORT V5
2017-09-08 10:50:49.758 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: NOTIFICATION report - 0 = 0, event=23, status=255
2017-09-08 10:50:49.759 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Alarm Type = ACCESS_CONTROL (0)
2017-09-08 10:50:49.761 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2017-09-08 10:50:49.763 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-09-08 10:50:49.764 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2017-09-08 10:50:49.766 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-09-08 10:50:49.768 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 23, type OnOffType
2017-09-08 10:50:49.769 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Updating channel state zwave:device:f7dddbf0:node23:alarm_access to ON [OnOffType]
2017-09-08 10:50:49.775 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-09-08 10:50:49.777 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 255: Transaction not completed: node address inconsistent.  lastSent=255, incoming=255
2017-09-08 10:51:30.012 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 17 0A 71 05 00 00 00 FF 06 16 00 00 6D 
==> /var/log/openhab2/events.log <==
2017-09-08 10:51:30.016 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f7dddbf0_serial_sof changed from 196 to 197
==> /var/log/openhab2/openhab.log <==
2017-09-08 10:51:30.017 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-09-08 10:51:30.022 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 17 0A 71 05 00 00 00 FF 06 16 00 00 6D 
2017-09-08 10:51:30.024 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 17 0A 71 05 00 00 00 FF 06 16 00 00 6D 
2017-09-08 10:51:30.028 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 17 0A 71 05 00 00 00 FF 06 16 00 00 
2017-09-08 10:51:30.032 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DETAILS)
2017-09-08 10:51:30.034 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class ALARM
2017-09-08 10:51:30.036 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Received ALARM command V5
2017-09-08 10:51:30.038 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Process NOTIFICATION_REPORT V5
2017-09-08 10:51:30.040 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: NOTIFICATION report - 0 = 0, event=22, status=255
2017-09-08 10:51:30.041 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Alarm Type = ACCESS_CONTROL (0)
2017-09-08 10:51:30.043 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2017-09-08 10:51:30.045 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-09-08 10:51:30.047 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2017-09-08 10:51:30.051 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-09-08 10:51:30.054 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 22, type OnOffType
2017-09-08 10:51:30.057 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Updating channel state zwave:device:f7dddbf0:node23:alarm_access to ON [OnOffType]
2017-09-08 10:51:30.068 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-09-08 10:51:30.070 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 255: Transaction not completed: node address inconsistent.  lastSent=255, incoming=255
2017-09-08 10:51:30.914 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 17 03 80 03 64 01 
==> /var/log/openhab2/events.log <==
2017-09-08 10:51:30.918 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f7dddbf0_serial_sof changed from 197 to 198
==> /var/log/openhab2/openhab.log <==
2017-09-08 10:51:30.921 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-09-08 10:51:30.925 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 17 03 80 03 64 01 
2017-09-08 10:51:30.928 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 17 03 80 03 64 01 
2017-09-08 10:51:30.932 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 17 03 80 03 64 
2017-09-08 10:51:30.934 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DETAILS)
2017-09-08 10:51:30.937 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class BATTERY
2017-09-08 10:51:30.940 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 23: Received Battery Request
2017-09-08 10:51:30.943 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 23: Battery report value = 100
2017-09-08 10:51:30.946 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2017-09-08 10:51:30.949 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-09-08 10:51:30.952 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = BATTERY, value = 100
2017-09-08 10:51:30.956 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Updating channel state zwave:device:f7dddbf0:node23:battery-level to 100 [DecimalType]
2017-09-08 10:51:30.964 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 255: Transaction not completed: node address inconsistent.  lastSent=255, incoming=255
2017-09-08 10:51:31.512 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 17 0A 71 05 00 00 00 FF 06 17 00 00 6C 
==> /var/log/openhab2/events.log <==
2017-09-08 10:51:31.516 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f7dddbf0_serial_sof changed from 198 to 199
==> /var/log/openhab2/openhab.log <==
2017-09-08 10:51:31.516 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-09-08 10:51:31.518 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 17 0A 71 05 00 00 00 FF 06 17 00 00 6C 
2017-09-08 10:51:31.521 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 17 0A 71 05 00 00 00 FF 06 17 00 00 6C 
2017-09-08 10:51:31.523 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 17 0A 71 05 00 00 00 FF 06 17 00 00 
2017-09-08 10:51:31.525 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Application Command Request (ALIVE:DETAILS)
2017-09-08 10:51:31.527 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class ALARM
2017-09-08 10:51:31.528 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Received ALARM command V5
2017-09-08 10:51:31.530 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Process NOTIFICATION_REPORT V5
2017-09-08 10:51:31.532 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: NOTIFICATION report - 0 = 0, event=23, status=255
2017-09-08 10:51:31.533 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 23: Alarm Type = ACCESS_CONTROL (0)
2017-09-08 10:51:31.535 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2017-09-08 10:51:31.537 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-09-08 10:51:31.539 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2017-09-08 10:51:31.541 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-09-08 10:51:31.543 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 23, type OnOffType
2017-09-08 10:51:31.544 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Updating channel state zwave:device:f7dddbf0:node23:alarm_access to ON [OnOffType]
2017-09-08 10:51:31.552 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-09-08 10:51:31.556 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 255: Transaction not completed: node address inconsistent.  lastSent=255, incoming=255

chris · September 8, 2017, 8:33pm

I’ll look at some changes to the database that will hopefully sort this…

TJOGRADY · September 9, 2017, 12:15am

Thanks Chris, just let me know when the changes are ready to test. I really appreciate you looking into it!

blairmi2 · September 15, 2017, 2:34am

Hi Chris & Tom,

In an attempt to not create a separate post because this is a new item

New user, running openhab2 on an rpi using a Z-stick gen5. I’ve got your 2.2.0 snapshot binding working as well.

Bought the same DWS01 from monoprice and have it added as a thing with channels displayed in paperUI. Nothing I do seems to trigger the sensor and change the state and paperUI says its in “Node initializing: WAIT”.

If you think this is unrelated i’m happy to make a separate thread. Appreciate you taking the time to help.Here’s what I see in the log.

Picture of control on paperUI: https://ibb.co/gCeWik

22:13:21.334 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Polling zwave:device:1c57d534:node6:sensor_binary
22:13:21.335 [DEBUG] [converter.ZWaveBinarySensorConverter] - NODE 6: Generating poll message for SENSOR_BINARY, endpoint 0
22:13:21.336 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 6: Creating new message for application command SENSOR_BINARY_GET
22:13:21.337 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Polling zwave:device:1c57d534:node6:alarm_access
22:13:21.338 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Polling zwave:device:1c57d534:node6:alarm_burglar
22:13:21.339 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Polling zwave:device:1c57d534:node6:battery-level
22:13:21.340 [DEBUG] [rnal.converter.ZWaveBatteryConverter] - NODE 6: Generating poll message for BATTERY endpoint 0
22:13:21.341 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 6: Creating new message for application command BATTERY_GET
22:13:21.342 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 6: Message already on the wake-up queue. Removing original.
22:13:21.343 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 6: Putting message SendData in wakeup queue.
22:13:21.344 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 6: Message already on the wake-up queue. Removing original.
22:13:21.345 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 6: Putting message SendData in wakeup queue.

TJOGRADY · September 15, 2017, 3:12pm

Hi Mike,

Glad to have someone else on board with these switches. I am still working with Chris on getting the initial setup of the device. Hopefully between the two of us we can provide Chris with what he needs to get the setup tweaked and working.

You have the exact same setup with me all the way down to the Z-stick.

For some reason it appears that the database took a step backwards and I no longer see the device being added with the Thing Type Label of ‘24259 MONOPRICE Door and Window Sensor P/N 24259’ that included Chris’ latest changes. The latest database should have the Thing Type Label of ‘DWS01 Door and Window Sensor’ and should allow for the modification of parameters 14 and 15.

I am currently on: openHAB 2.2.0~20170913092906-1 (Build #1037)

openhab> bundle:list | grep ZWave                                       10:11:04
 10 │ Installed │  80 │ 2.1.0.201708182242     │ ZWave Binding
194 │ Active    │  80 │ 2.2.0.201709130643     │ ZWave Binding

chris · September 15, 2017, 7:16pm

What does it get called now then?

I suspect that because the name was changed, there may be some duplication in the binding, but it still should be detected as one device or other, so it would be good to know what it’s called?

TJOGRADY · September 15, 2017, 9:12pm

Hi Chris,

I updated the name when I noticed it wasn’t exclusively a Monoprice device. The good entry is: ‘DWS01 Door and Window Sensor’. I have the devices under both names in my setup because I removed and added a device. The ones with the ‘DWS01 Door and Window Sensor’ name have the parameter you created. Though, I haven’t had much luck getting the on/off binary switch to work.

If the ‘Thing Type Label’ is the PK for the database and we have this device defined multiple times you can remove the ‘24259 MONOPRICE Door and Window Sensor P/N 24259’ entry.

Please let me know if you need anymore information.

Thanks,
Tom

chris · September 15, 2017, 9:13pm

I’ve done a database resync and this should sort out the duplicate after the device was renamed…

TJOGRADY · September 16, 2017, 1:35am

Excellent, thanks again Chris!

blairmi2 · September 17, 2017, 1:38pm

let me know how I can help! Thanks

chris · September 17, 2017, 1:44pm

Is the latest version still not working?

blairmi2 · September 17, 2017, 1:56pm

I stopped/started the service, deleted the thing, rescanned, and readded. I noticed its still detected as “Z-Wave Zone 6: 24259 MONOPRICE Door and Window Sensor P/N 24259”. I also still have the issue where none of the channels seem to work. No change on my end.

chris · September 17, 2017, 1:57pm

What is the thing type it’s discovered as?

chris · September 17, 2017, 1:57pm

Did you uninstall the binding and reinstall it?

blairmi2 · September 17, 2017, 1:58pm

that I didn’t do…my mistake, new user :). Let me do that and give it a shot.

chris · September 17, 2017, 1:58pm

Ok, if it’s not working after that, let me know the thing type so I can double check everything.

blairmi2 · September 17, 2017, 2:06pm

to reinstall i only need to delete all things, then remove the 2.2.0 snapshot binding from the addons folder right? when i copy it back in and readd my controller, i see no change, same results.

screenshots:

I have one sensor but reset it a few times playing around, i believe thats why its showing up 4 times.