I’m a tester at Sensative AB for our line of Strips, Z-wave devices. Strips is a battery operated device with three different variants: Strips Guard (door/window sensor), Strips Comfort (lux & temperature sensor), Strips Drips (leakage sensor).
For some time now, we’ve had some customers report issues including our devices in openhab. When testing, i was unable to reproduce the issue myself. That is until recently when i was doing some compatibility testing with the latest milestone build, 2.5.0.M5 (windows version), were i think i might have come across the same issues that our user’s have faced, although i’m not sure exactly what triggers it.
I started out with a hard reset on my z-stick to clear it of all previous z-wave devices. I thereafter continued by adding a Strips Guard to the system and got it working ok immediately. I excluded the device and included again, still fine.
On the third attempt though, the interview was cut short by the controller sending WUNMI (Wake Up No More Information) before the Association Set command was sent to Strips, i could see this in the z-wave sniffer logs that i had running at the time. Without the Association Set command, Strips is left without a lifeline and thus doesn’t know who to send open/close commands to. This results in Strips blinking five times for open events (our standard failure LED indication). If i in the Papper UI, under Strips’ settings, assign the lifeline association towards the controller and wake it up 3 times (not sure why it takes so many NIF - Node Information Frame - events for controller to send…) it gets the association ID and is able to send open/close.
In my fourth inclusion attempt i again did not get Association Set. This time i decided to test repeatedly waking up Strips (sending NIF) to see how long it would take to complete the interview. It took a staggering 15 manual wake up commands before association was sent normally. The reason so many wake ups were required is because the controller keeps sending WUNMI after only one or two reports instead of sending all the reports at once.
I also had the debug logs running in openhab while testing. I’m not too familiar with the system myself so i can’t really tell why the system sends WUNMI so early. Perhaps someone else here is able to understand why? Link to z-wave sniffer and debug logs:
The .zlf files can be opened with the SiLabs zniffer tool if you have it.
I’m currently testing with a milestone build so i imagine there may be some bugs and room for refinement, but i am also quite sure that similar inclusion issues exists in the current stable build 2.4.0. I’ve personally seen association issues in that firmware although wasn’t able to reproduce after accidentally reseting the controller.
Has anyone else had issues with lifeline association not being set during inclusion?
Some other posts i found that seemed to show similar issues: