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.
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.
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.
What version of openHAB are you running? That database entry was updated fairly recently.
I updated yesterday from 2.5.0 to 2.5.2.
@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
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
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.
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?
Have you included the device using mains power yet?
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)
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?
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.
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.
Thanks, I’ll give it a try. Yesterday I did attempt to remove the ghost nodes through Habmin (set them to failed, then remove from controller), but when I delete the thing then search, they all show up in the Inbox again. I also tried the Zensys Tool in the past and it refused to delete these nodes as well. I haven’t tried the Silicon Labs tool though, so I’ll give it a shot and report back.
The SiLabs tool worked! Finally a way to delete these ghost nodes, thanks for the pointer!
However, now that I’ve removed the ghost nodes, I still am unable to configure the Association Groups for this Zooz sensor. OH just refuses to set anything in the “group_1” or “group_2” fields. It’s not even that it gets to the device since it’s asleep most of the time. The device config the fields in OH stay blank after modifying, there’s no pending change like for other fields. Is there something else I can try?
I decided to try one more exclude and include now that the ghost nodes are cleaned up. Everything worked correctly this time and I was also able to configure the lifeline Association Group. Now the sensor works like it should!
Thanks everyone for your help and ideas! In the end I think the problem was a confluence of separate issues that made this more trouble than it should have been. However, I learned some things along the way and can better troubleshoot this kind of thing in the future. I really appreciate all the work that goes into developing and supporting OH.
That is the type of solution we strive to provide here. Too many people want to be spoon-fed a complete solution to copy. Thee then have no idea how to troubleshoot or modify the configuration.
This message indicates that there was something wrong with the initialisation since hte association group is unknown. You would need to reinitialise the device to recover this - there is an option to do this in the thing configuration.
Thanks Chris, that’s a good tip.