Zooz ZSE29 v2 include trouble

1

I’ve been fighting with this sensor for more hours than I’m comfortable admitting.

More than a year ago I purchased one of these sensors before it was supported by Openhab (I was running 2.4). I included it in my network and it was an unrecognized device. I realized that I needed to update OH to get the new ZWave database so I waited until my next regular update several months later and after that it worked fine (updated to 2.5.0).

Skip ahead to today, and I recently ordered another one of these sensors from Amazon and have been trying to get it included. I am able to include the new node just fine, but it always shows up as an “Unknown Device.” I tried lots of manual 3x tamper switch presses and battery removal/re-insertions with no luck, so I figured it just needed time, so I left it over night, hoping it would work, it didn’t. I then began to wonder, did the update of OH trigger something to detect the device corretly? I performed an update, knowing at least one update was available and I’m now up to 2.5.2. After the update, one of the things from a failed include of this sensor had gone from “Unknown Device” to “ZSE29 Outdoor Motion Sensor v2”. However, the most recent include didn’t seem to have my device using the node ID assigned to this recognized device so I decided to try an exclude and re-include. It did appear that the exclude worked, and it was a different “Unknown Device” node ID that was excluded. I attempted to include again and again it created another new node ID thing, but it came in as “Unknown Device”. Nothing I can do seems to get this device recognized. The manual says that battery removal and insertion is the only way to wake the device, but doing so has not resulted in OH picking up the correct device info. This is what I see in the OH log file:

2020-03-14 14:08:17.593 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 134: Device discovery could not resolve to a thingType! Manufacturer data not known.

And after an OH restart I see this:

2020-03-14 14:30:13.003 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 134: Restore from config: Error. Data invalid, ignoring config.

Does the “Data invalid, ignoring config” message mean that it’s never going to discover this device correctly?

In the event log from the last time I attempted to include the sensor I see this:

2020-03-14 13:18:03.626 [home.event.InboxAddedEvent] - Discovery Result with UID 'zwave:device:162d1544ad3:node134'     has been added.
2020-03-14 13:18:24.976 [me.event.InboxRemovedEvent] - Discovery Result with UID 'zwave:device:162d1544ad3:node134'     has been removed.
2020-03-14 13:18:24.981 [hingStatusInfoChangedEvent] - 'zwave:device:162d1544ad3:node134' changed from UNINITIALIZED     to INITIALIZING
2020-03-14 13:18:24.988 [hingStatusInfoChangedEvent] - 'zwave:device:162d1544ad3:node134' changed from INITIALIZING     to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2020-03-14 13:18:24.989 [hingStatusInfoChangedEvent] - 'zwave:device:162d1544ad3:node134' changed from OFFLINE (BRID    GE_OFFLINE): Controller is offline to OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller
2020-03-14 13:18:24.989 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:162d1544ad3:node134' has been updated.

It’s frustrating that my original “v1” sensor is working fine, but the visually identical “v2” sensor is giving me trouble with discovery. Can anyone suggest a way to troubleshoot this or get the sensor to cooperate?

Thanks!

2

I have one of these and it works OK. I also setup the device in the db. Have you tried including it while it is powered by AC?

Also, I believe you can update your v1 to a v2 with a firmware update.

3

I have tried powering with USB and don’t see any difference in behavior.

Just now I enabled DEBUG logs in the zwave binding and attempted an include of the device again. I uploaded the log into the log viewer and while I know nothing about the expected content of these logs, it looks to me like the device responded to the controller with enough information for the log parser to identify it as the correct device, but the thing in my OH installation just shows “Unknown Device” (node 139).

zwave_include.log (374.4 KB)

4

If you try USB the device must be powered by USB when including it into the network.Otherwise it still behaves as a battery operated device.

5

I think that’s true of other battery/USB powered devices but maybe not this one? It includes in the box a battery replacement device that fills the battery bay with a USB cord hanging off of it, effectively allowing replacement of the batteries with a USB cable. I suppose the device could know the difference if it detected this based on voltage (4.5 vs 5), but I haven’t seen any indication of that in the manual and I can’t get it to work so I can’t say if it impacts overall device functionality.

6

I know my Zooz sensor acts that way according to the helpful Zooz support I have a different model though.

7

FYI, looks like you can’t update a v1 sensor to v2, according to the Zooz support page:

This version cannot be updated to VER. 2.0 with an OTA firmware update because some of the upgrades required changes in the hardware and software beyond the Z-Wave chip.

8

Sorry for that. I was not aware that v2 included a hardware update too.

Exclude the device, plug in the USB adapter, and then include it again. It will communicate and perform much better as a mains powered device.

2020-03-14 16:26:13.203 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 139: Device discovery resolved to thingType zwave:zooz_zse29v2_02_000

Yes, the device looks like it has been identified, but it does not complete initialization and the end of the log shows a lot of errors. Your log also shows 14 devices that could not be resolved to a thingType! My guess is that these are ghost nodes from a device being hard reset and then reincluded. Do you have a bunch of devices that show up in your Inbox after a restart or zwave discovery? These ghost nodes can cause issues within your network and it is best to remove them.

1 Like
9

I’ve tried several times including the device on USB power with no change in the result. It still ends up an unknown device. Do you think the ghost nodes are related to the problem? I’ve had trouble getting rid of them. I tried some tools to remove them from the ZStick with no success.

10

What version of openHAB are you running? That database entry was updated fairly recently.

11

I updated yesterday from 2.5.0 to 2.5.2.

12

@5iver last updated that 13 days ago. Was that after 2.5.2? We would know best.

EDIT: I think it was updated after 2.5.2. you can use the install script to install a Snapshot version of the binding,
Zigbee and Z-Wave manual install script - Tutorials & Examples - openHAB Community

13

Interesting. Like I said earlier, I did see a thing created with ZSE29 “v2” in the name, so it seems like the binding knows about v2, but maybe there’s an even newer FW update for this sensor that requires a change to the device in the binding? I may try updating to a snapshot version of the binding and see if that fixes it, but depends on my free time in the coming days. I may also just wait until the next update (assuming 2.5.3 is coming in a few weeks?).

Regarding the ghost nodes, I’ve read various posts with suggestions for dealing with this. A while back it was the Zensys windows tool that was supposed to delete it directly from your ZStick, but I had limited success with that. I have several “ONLINE” nodes that I believe are ghost nodes, it’s my understanding that only failed nodes can be removed from the controller, is that correct? I know habmin supports deleting these nodes, but I’ve not had success, and it looks like others haven’t either:

https://community.openhab.org/t/solved-how-to-delete-a-dead-node-from-a-zwave-stick/28024/14

14

Curious. Zensys Tools always worked fir me with a different stick.
If you think you may have a hardware problem Zooz support is very good.

15

You say it does not complete initialization, is this because of the “NO ACK after 8336 ms”? Do you think the log indicates a problem with the device, or a problem with OH? In my mind it seems like OH recognized the device and the thing that is created isn’t update correctly, but if you say initialization didn’t finish, then that would explain why the thing is an “Unknown Device”. Is there any reason to think an update to the binding will help this situation? Did the device identify itself in a way that indicates OH 2.5.2 didn’t recognize it? Just trying to determine next steps to getting this working.

One problem I had just before I collected this log was an old Ecolink PIR sensor I have been using for a year or two seems to have gotten stuck in include mode. Whenever I did an include/exclude, it would remove and then add itself. I assume the device failed, so I’ve excluded it and removed the battery and don’t see it giving me trouble any more. That brings me back to the ghost devices, maybe I need to try and get them cleaned up too? Could that be contributing to the problem?

16

Have you included the device using mains power yet?

17

I tried it twice this evening with USB power. Once it included as an Unknown Device. I excluded it and then factory reset the sensor, then tried again. This time rather than setting the sensor down during the include I kept motion active in front of it (I wouldn’t expect this to impact the process, but I’m grasping at straws) and this time it included as a new thing with the correct device type “ZSE29 Outdoor Motion Sensor V2”. Yay! Or maybe…

While the sensor seems to be included correctly, I don’t see any zwave messages received by the controller when I move in front of it (motion trigger). I do however see messages for the device in the OH log when I trigger it by pressing the tamper switch 3 times. Doing this several times has resulted in updating luminance, but so far that’s the only sensor that has reported anything. I’ll keep trying and see if I can get it to cooperate.

zooz_include141_zwave_logs.log (478.5 KB)

18

I’ve attempted modifying configuration parameters, and most of them seem to stick with an important exception. I can’t seem to get Association Group changes configured (I assume this is why I’m not getting motion notifications). At present the Lifeline is blank and Group 2 is blank. Nothing I set sticks. For other settings I configure them in habmin and then wake up the sensor, but not the Association Group parameters. This is what I see with zwave binding DEBUG enabled and I try to modify association group parameters:

2020-03-15 21:13:04.942 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 141: Went to sleep COMPLETE
2020-03-15 21:13:04.942 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2020-03-15 21:13:15.642 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 141: Configuration update received
2020-03-15 21:13:15.644 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 141: Configuration update set group_1 to controller (String)
2020-03-15 21:13:15.645 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 141: Association 1 consolidated to [controller]
2020-03-15 21:13:15.646 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 141: Unknown association group 1

Any suggestions?

19

I can’t seem to configure the Association Group via Habin, PaperUI, or REST. In all cases it seems to reject the value for those fields (group_1, group_2). Can anyone comment on whether this is a known issue (I’m on 2.5.2)? I saw a post back in 2.5.0 development where this was a problem, but I got the impression that this shouldn’t be an issue any more.

20

The controller may be confused due to the ghost nodes. Try removing them and see if that helps. Habmin can do this, but you can also use a third-party tool from Silicon Labs, which is an upgrade to the Zensys Tools app that you might see referenced in the forum.