When trying to include the ZWave device Aeotec Nanomode quad remote (ZWA003), the controller could add it and it showed up in the things with the correct device name.
However, I could not get it to send scenes or battery info to openhab.
Then I found out that openhab had not created an xml file.
The device can be put into awake mode, which I did hoping to complete the device initialization, but to no effect.
Using long wakeup or quick wakeup on the device multiple times had no result.
I then moved the ZWave stick to my PC and started Silabâs âZWave PC Controller 5â. It showed that the device was included by the stick, however when I requested a NIF the SW responded with:
âWakeup period not specifiedâ
I then excluded the device from the stick and re-included it. I now had the option to enable S0 and S2 (both enabled by default).
However, when I then returned the stick to my RPi (where I deleted the device first), it could add the remote but with the message:
âDevice discovery could not resolve to a thingType! Manufacturer data not known.â
âError decapsulating security messageâ
âjava.security.InvalidKeyException: No installed provider supports this key: (null)â
at javax.crypto.Cipher.chooseProvider(Cipher.java:930) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1286) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1223) ~[?:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.generateMAC(ZWaveSecurityCommandClass.java:528) ~[bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.getSecurityMessageDecapsulation(ZWaveSecurityCommandClass.java:319) [bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveNode.processCommand(ZWaveNode.java:1238) [bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:532) [bundleFile:?]
I tried this with both S0 and S2 enabled and with only S0 enabled - with the same result.
I excluded the remote from the stick again and started from fresh with my test RPi and a fully reset ZWave stick.
I attached the resulting logs with ZWave logging enabled.
These are the actions that I did:
10:26: added the ZWave stick to RPi
10:33: added the ZWA003 remote to openhab
10:37: I changed the configuration: (device is in awake mode)
association group 1: controller
wakeup interval: 1800
11:09: I changed the configuration: (device is in awake mode)
association group 1: controller
wakeup interval: 300
wakeup node: 1
11:21: log shows: polling node 2 â Polling deferred until initialization complete (while device is in awake mode)
11:24: I set ZWave controller default wakeup to 60
11:25: controller requests NIF â no response (while device is still in awake mode)
11:28: moved stick to PC Controller again
â again cannot request NIF : Wakeup interval for current node not assigned (while device is in awake mode)
â excluded device from USB stick
â again included device to USB stick, now with both S0 and S2 disabled
â the wakup interval is assigned when using PC Controller, a NIF is returned when I put the device in awake mode
(the PC controller log is attached as jpeg)
11:38: returned the controller to RPi, device is in awake mode
11:40: Device initialisation complete
â xml is now created at 11:39
Finally working, my rule receives a scene number when pushing a button.
11:51: removed the device from the stick (using âexclude devicesâ) â this worked OK
To me it is not clear why openhab fails the initialization. Could be the fact that the device is a ZWave+ thing and that it can support encryption?
Or that in the first initialization stages the wakeup period isnât communicated? Silabâs SW failed to get a NIF in this case as well.
It wasnât my intention to include it with encryption (I left the default security setting to âentry control devicesâ, which it isnât). Only when I included on the stick with Silabâs SW I noticed the device supports S0 and S2. I then just tried to see if openhab could continue its initializations, but that probably didnât work because of the default setting and the key of course.
The main problem is that when I try to include it without security (openhabâs default), it seems to already go wrong in the inclusion stage: this is why after the inclusion on the Zwave stick with openhab, and then moving the stick to the PC, Silabâs SW complains and even doesnât try to get the NIF. And when executing the inclusion (without S0 and S2) with Silabâs SW and moving the stick over to openhab, openhab can continue inserting it into its own database (and creating the xml file) without problems.
So I suppose the problem is in the initial inclusion that prohibits getting the NIF (both with openhab and Silabâs SW).
If it is useful, I can try to include it into openhab with its security setting changed to âall devicesâ, but openhab should be able to include it without security - Silabâs SW can do itâŠ
You will notice on the list of devices sleeping nodes do not have a check mark like listening devices. Check the little box by the device to say it is listening and it will. It is just how the app works. It was a demonstrator not a fully fledged app. The error message is also normal and does not indicate an issue.
Problems with Zwave battery devices initialization are well known. I have a PR to address a few of them "One and DONE, but AFAIK, like yourself, everyone ultimately gets the device included (in hours or days), so the PR is an enhancement, not a bug fix. I can see from using the viewer, one of the issues. The last âadd Node Stopâ takes up 4 seconds of the first initialization, so there is only 1 second left before the node goes to sleep.
Also as you discovered you canât set certain parameters until the initialization has reached that stage or that if you include with security you need to include with OH/Zwave binding as the key is on the controller UI page (advanced tab).
What I find interesting in the context of the work I did is that adding the Node with the PC controller and then transferring the stick to OH/Zwave, you avoided the second Semi-stuck condition. Note that the manufacturing specific GET is the same as above and is the real start of initialization
Iâm going to have to test that when I get a chance as an alternative idea. I have the PR changes in a custom binding, so do not have the issue anymore.
Another battery device I have has a button combination to force it to send a NIF, and that speeds up the inclusion process a lot. This device comes with a rechargeable battery so they donât have to be too careful with power and they implemented a mode in which the device can be awake for minutes. Indeed, once I got the initial inclusion working with the PC SW, placing the device in this mode made the rest of the inclusion in openhab finish very fast.
But I am afraid that since the inclusion got stuck quite early in the process that I would never be able to include it in openhab without using the PC SW. I woke up the device many times when trying to include it using openhab only but never got any further in the initialization (and I can only put the device in awake mode after it has been included).
Thanks for investigating this problem and hopefully we will see your improvements in a next OH release.
I donât know how to keep sleeping devices awake. How is that done? Is there a battery life concern?
edit: I also read in the Silabs spec that battery devices will go to sleep on their own after 10 seconds of inactivity. How does this fit into what you are doing?
To answer your question, somewhat indirectly, mains powered device do not have the issue because they wait out the 4 second delay and resume configuring. Since there is no sleep timer activated for that type of device, there is no âgo to sleepâ message that cuts the configuration short. So it is only for battery devices that are flagged in the binding as zwave_listening = false
All the ones I have will wake if the inclusion button is pressed or a menu item is selected. Most of my sensors are Fibaro.
The older Fibaro models it is a single press of the B button and the device sends a NIF report which works well with openHAB.
Newer like the Walli controller need to enter menu which is not so easy
7.5: Waking up
When on battery power, the device needs to be woken up to receive
information about the new configuration from the Z-Wave controller,
like parameters and associations. By default the device is woken up
automatically every 6 hours.
You can wake up the device manually using first menu position
(white).
All the aeotec I have hold the action button for 2 seconds. I think some if you hold for 5s they will stay awake for 5 mins. I think the mote does this if you hold any button for 2 or 5s.
I only ever do it when including and always set wakeup to max for the device and polling to 10 days to maximise battery life. I disable any reports I do not need and set every other report to the max interval or increment that is regular enough for my purposes and get a couple of years on a battery.
Only when adding so little impact and yes they should be designed to go to sleep if the controller fails to send no more commands and I think most are.
So the answer is probably a timing thing. If the device is allowed to sleep and is not made to wake it can all get stuck. The fact I have never seen it happen must be my good luck.
I misunderstood this to mean you modified the device so the binding viewed the device as âlisteningâ and therefore not involve the Wakeup Timer Task routine in the binding. I now understand that you use the wake routine again (within 5 seconds) before the binding sends the âgo to sleepâ message. Interesting !
