[SOLVED] Monoprice Door Window Sensor Shows up as Unknown Device

Hardware Home Automation
1

I have the Monoprice Door Window Sensor p/n: 24259, but it’s showing up in OpenHAB as an “Unknown Device.” I am currently using the OpenHAB 2.4.0 Snapshot (running in Synology). I have the Aeotec Z-stick Gen 5.

I see the sensor listed in Chris’s site as DSW001. The sensor has “HKZW-DWS01” on the sensor itself. In this thread, a user with the same sensor from Monoprice and using the same Z-stick was having problems detecting the device and getting the sensor it to work. At the end of the thread, the sensor is working after Chris made some changes, and the user updated their Z-Wave Binding. I’m using version 2.4 binding so it should have all changes that made it work. I did notice that the device summary on Chris’s site has the sensor named “DWS01”. How do I know what name the sensor I have is using?

I see the following in the openhab.log file:

2019-01-26 13:54:04.026 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 30: Device discovery could not resolve to a thingType! Manufacturer data not known.

Here’s the section of the events.log file pertaining to this sensor:

2019-01-26 13:53:05.105 [home.event.InboxAddedEvent] - Discovery Result with UID 'zwave:device:zw001:node30' has been added.
2019-01-26 13:53:46.746 [hingStatusInfoChangedEvent] - 'zwave:device:zw001:node30' changed from UNINITIALIZED to INITIALIZING
2019-01-26 13:53:46.752 [hingStatusInfoChangedEvent] - 'zwave:device:zw001:node30' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2019-01-26 13:53:46.754 [hingStatusInfoChangedEvent] - 'zwave:device:zw001:node30' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2019-01-26 13:53:46.792 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:zw001:node30' has been updated.
2019-01-26 13:53:46.810 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:zw001:node30' has been updated.
2019-01-26 13:53:46.834 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:zw001:node30' has been updated.

Why isn’t this sensor working for me? How can I get it working?

2

It may be worth try to removing the device and adding it again, it may not have been fully initialized on the zwave stick before you added it. If the device has a way to wake up the device, opening the case tends to be common way to do that, and leaving it open for few minutes, so the zwave stick can talk to the device and get the configs. Battery operated devices sleep most of the time, so this can take a while sometimes days for it to do it to wake on its own and communicate with zwave controller.

To find out more information about your device you will want to increase the logging for ZWave to debug see https://www.iwasdot.com/setting-openhab2-zwave-to-show-debug-logs/

There is also a helpful tool on https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer for parsing the logs

3

When you say removing the device, do you mean removing it from the z-stick? I’ve done that plenty of times. This sensor was originally node 23 on my z-wave network and now it’s node 30 from doing this so much. I’ve had this sensor sitting for a few weeks, but it still shows up as an “Unknown Device.” If I use the Aeon Labs IMA tool, I do see the node as a “Sensor Notification” for the type. When I trigger the sensor by separating the two pieces, I see following:

Node 30 says commmandclass 113, command 5 (singlecast)

I also see commmandclass 128 and occasionally I see:

Node 30 says METER REPORT (singlecast)

Using Zensys Tool, I see the following when I trigger the sensor:

06:59:12.383: Received: COMMAND_CLASS_ALARM.ALARM_REPORT, hex data: 71 05 00 00 00 FF 06 17 00 00 
06:59:13.182: Received: COMMAND_CLASS_ALARM.ALARM_REPORT, hex data: 71 05 00 00 00 FF 06 16 00 00 
06:59:13.982: Received: COMMAND_CLASS_ALARM.ALARM_REPORT, hex data: 71 05 00 00 00 FF 06 17 00 00 
06:59:14.682: Received: COMMAND_CLASS_ALARM.ALARM_REPORT, hex data: 71 05 00 00 00 FF 06 16 00 00 
06:59:15.150: Received: COMMAND_CLASS_METER.METER_REPORT, hex data: 32 02 21 74 00 00 8F CB 00 00 
06:59:15.383: Received: COMMAND_CLASS_ALARM.ALARM_REPORT, hex data: 71 05 00 00 00 FF 06 17 00 00 
06:59:16.782: Received: COMMAND_CLASS_ALARM.ALARM_REPORT, hex data: 71 05 00 00 00 FF 06 16 00 00 
06:59:17.482: Received: COMMAND_CLASS_ALARM.ALARM_REPORT, hex data: 71 05 00 00 00 FF 06 17 00 00 
06:59:29.074: Received: COMMAND_CLASS_ALARM.ALARM_REPORT, hex data: 71 05 00 00 00 FF 06 16 00 00 
06:59:29.095: Received: COMMAND_CLASS_ALARM.ALARM_REPORT, hex data: 71 05 00 00 00 FF 06 17 00 00 
06:59:29.801: Received: COMMAND_CLASS_BATTERY.BATTERY_REPORT, hex data: 80 03 64 
06:59:45.154: Received: COMMAND_CLASS_METER.METER_REPORT, hex data: 32 02 21 64 00 06 16 4C 01 2C 00 06 16 4A

Hex 0x71 = 113 and 0x80 = 128.

I turned on debug logging in OpenHAB, but there’s too much in the log. Here’s a section for “NODE 30”:

	Line 8720: 2019-01-26 19:27:27.939 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 30: Device discovery completed
	Line 8721: 2019-01-26 19:27:27.945 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 30: Device discovery could not resolve to a thingType! Manufacturer data not known.
	Line 9246: 2019-01-26 19:27:32.297 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: MANUFACTURER not set
	Line 9247: 2019-01-26 19:27:32.298 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Controller status changed to ONLINE.
	Line 9249: 2019-01-26 19:27:32.299 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Controller is ONLINE. Starting device initialisation.
	Line 9261: 2019-01-26 19:27:32.310 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Updating node properties.
	Line 9270: 2019-01-26 19:27:32.318 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Updating node properties. MAN=2147483647
	Line 9272: 2019-01-26 19:27:32.319 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Properties synchronised
	Line 9281: 2019-01-26 19:27:32.329 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Initialising Thing Node...
	Line 9283: 2019-01-26 19:27:32.330 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Polling intialised at 1800 seconds - start in 766800 milliseconds.
	Line 9285: 2019-01-26 19:27:32.331 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 30: Device initialisation complete.
4

What tool can I use to see what manufacturer id and reference type id is being reported by my device? I did not see anything in the Zensys Tool (even when looking at other working devices).

5

Take your favourite text editor and have a look at the corresponding xml file in your /userdata/zwave folder.
Or look at the attributes tab in HABmin or PaperUI:

grafik
grafik759×318 13.4 KB

6

I’ve checked that directory, but don’t see an XML file for the device/node I am having problems with. I see the XML files for all the other devices, but not this one. I assumed this is because the device is still seen as “Unknown Device.”

7

Battery operated? Wake it up manually (you need to push a button in a certain sequence, see the manual please)

8

Yes, battery operated. the manual only says this regarding waking up the device:

The sensor is normally asleep and only “wakes up” when the magnet is separated from the sensor body. However, it can be set to periodically “wake up” to communicate with any assigned devices, update parameters, update the firmware, or detect battery level. use the WAKE UP command class to set the auto wake up internal. The interval can be set to any value between 2678400 seconds, with 0 being the default. When set to 0, the sensor will only wake up when the magnet is separated from the body.

I’ve done that, but I’m still not having any luck with this sensor.

9

I have these sensors for nearly all my windows running on a RP3 and the Aeotec Z-stick.

On the first release of Snapshot 2.4.0 I had issues because the device ‘category’ was not set. This caused my sensors to show up as an “Unknown Device” after working for nearly a year.

The issue appeared to be a property ‘category’ that was added with the latest update that was not defaulted and needed to be set. Once the database was updated my devices were back on line and worked flawlessly.

The one thing to try, if you are sure you are running the latest and greatest OpenHAB version, is to pull the cover back and press the little button near the tamper switch until the little blue LED illuminates. This seemed to work better for me then trying to wake the switch up by opening and closing the window/door it was attached to.

Good luck!

1 Like
10

Well I’ll be damned! I pressed the button and held it for a few seconds until it blinked. As soon as I did that, the sensors (I actually have two I couldn’t get working) were detected by OpenHAB. Thanks, @TJOGRADY!!!

11

Thx, I’ve added this to the database.

12

Glad to hear it worked!

13

I had problems with these devices as well. I’m using the Z-stick s2. I updated the .xml configuration file and they seem to work(appeared as if the wrong configuration file was being used.) Paperui has the option to enable external sensor. I thought if I enabled external sensor it might make a new “thing” but it didn’t. Is the external sensor tied to the magnetic reed sensor? Anybody using the external sensor?