ZWave inclusion fails for Aeotec SWA003

[Peacock (Marc)]

System:
RPi4B - openHABian 1.7.2 - openhab 3.2.0 release - openjdk 11.0.14

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.

events.log (7.5 KB)
openhab.log (799.4 KB)

[robmac (R Macdonald)]

@Peacock

I now had the option to enable S0 and S2

If you included with encryption. The binding only supports S0 and the key will be different so it will not work unless you bring the key across.

I will test adding a sleeping device and see if there are any issues.

[Peacock (Marc)]

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…

[robmac (R Macdonald)]

@Peacock

then moving the stick to the PC, Silab’s SW complains and even doesn’t try to get the NIF

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.

[apella12 (Bob Eckhoff)]

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.

Only about 11 commands get processed before 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

After 34 messages and 3 seconds is DONE.

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.

Hope this helps you understand what was going on.

Bob

[robmac (R Macdonald)]

I am so used to keeping sleeping devices awake and monitoring with zniffer that I have never noticed the issue.

I assume that you can only reproduce the issue if you let the device sleep?

[Peacock (Marc)]

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.

[apella12 (Bob Eckhoff)]

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

Bob

[robmac (R Macdonald)]

@apella12

I don’t know how to keep sleeping devices awake. How is that done? Is there a battery life concern?

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.

@apella12

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?

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.

@apella12

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

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.

[apella12 (Bob Eckhoff)]

@robmac

I am so used to keeping sleeping devices awake

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 !

Bob

[robmac (R Macdonald)]

I have no patience to wait