forum

In order to verify why I was having trouble to include some door/window sensors (binary sensors), I started an investigation into Z-Way's z-wave inclusion compliance. Since I also develop my own end devices based on ZGM130S and ZGM230S hardware, using Silicon Labs' SS5 software, I was able to investigate at a fairly low level.

The main issue I found is the inclusion of "APPLICATION_NODEINFO_NOT_LISTENING" devices using UNSECURE mode.

Once the unsecured command class list (cmdClassListNonSecureNotIncluded[]) contains the command classes COMMAND_CLASS_SECURITY and/or COMMAND_CLASS_SECURITY_2, the Z-Way inclusion process will hang and the interview following the formal inclusion process will not take place. As a result, Z-Way displays the included end device, but without any functionality.

I have used multiple SDKs (SDK v3.2.3 / Z-Wave 7.16.3.0 and SDK v4.1.0 / Z-Wave 7.18.0.0) as well as different Z-Way versions (Raspberry Pi version 3.2.3 and 4.0.0-102-g45c41aa6). In contrast, both, secure S0 and S2 inclusions are properly completed.

Take a long story short… in case you find that your battery powered sensor is not included correctly by Z-Way in unsecure mode, simply use a secure S0 or S2 mode which may or may not be better anyway.


Just one other remark… Booting a Raspberry Pi using Z-Way version 34.0.0-102-g45c41aa6 unfortunately creates the PI warning:
dtwarn: overlay ‘pi3-miniuart-bt’ has been renamed ‘minimart-bt'
This warning is not displayed when using Z-Way version 3.2.3.

Hello!

When Z-Way includes a device non-securely, it waits 20 seconds to let secure timers in the device to time out. After 20 seconds the interview will resume. You will have to wake up your device. This is not an issue, but a feature.

Hello & thank you for your reply.

I think you are suggesting a process that might be too difficult for non-experienced users. I'm sure you know that many companies develop their devices based on Silicon Labs example projects, who end their learning mode by:

//Make sure that the application stays awake for 10 s after learn mode finished
//to wait for more messages from the controller
CC_WakeUp_stayAwake10s ();

/* Also tell application to automatically extend the stay awake period by 10
* seconds on message activities - even though we did not get here by a proper
* wakeup from Deep Sleep
*/
CC_WakeUp_AutoStayAwakeAfterInclusion ();

Instead of waiting 20s and then letting a device coast in deep sleep mode, I suggest sending a dummy command 3x every 5s to keep the end device awake. After 20 seconds, the controller could continue with its interview process.

Thanks.

This is a good idea! We will think about doing it in Z-Way.