I implemented the Door Lock class and both lock state and control are working correctly.
Posts made by Rob
-
RE: Schlage Lock BE469 Z-Wave Connect Touchscreen Deadbolt
-
RE: Schlage Lock BE469 Z-Wave Connect Touchscreen Deadbolt
My BE469 is now connected. It's mapped to an OpenSensor type and the alarm class values aren't implemented correctly, so there's work to do now.
Note:
The OpenZWave options.xml shows an example NetworkKey as:
<!-- If you are using any Security Devices, you MUST set a network Key --> <!-- <Option name="NetworkKey" value="0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10" /> -->
Add the
NetworkKey
property and string value to the ZWave config options object without any spaces. -
Schlage Lock BE469 Z-Wave Connect Touchscreen Deadbolt
I just installed this Z-Wave deadbolt yesterday. Theatersoft will need some additional command classes support: Door Lock V1, etc. Also TBD - the secure controller requirement...
-
Using multiple Z-Wave controllers at the same time
Pictured are a Aeotec ZW090 Z-Stick Gen5 US and a Sigma Designs UZB Z-Wave USB Adapter. Both work equally well with the Theatersoft ZWave service and the underlying stack consisting of the
libopenzwave
library andopenzwave-shared
Node addon.You might not need another controller until your Z-Wave network reaches the 232 devices per controller limit, but it's useful to have a second controller connected to the same machine to use for debugging and testing purposes. It can be time consuming to need to wait for initialization of a large Z-Wave network if you need to restart frequently for whatever reason. With a second controller you avoid downtime or destabilization on the primary network.
Theatersoft allows any number of device services, including multiple instances of the ZWave service, so using multiple controllers is not a problem.
Here's how - add a new service in
config.json
:{ "module": "@theatersoft/zwave", "export": "ZWave", "name": "ZWave", "config": { "port": "/dev/zwave", "options": { "Logging": true, "ConsoleOutput": true, "SaveLogLevel": 5 } }, { "module": "@theatersoft/zwave", "export": "ZWave", "name": "ZWave2", "config": { "port": "/dev/zwave2", "options": { "Logging": true, "ConsoleOutput": true, "SaveLogLevel": 7 } }
Bus services names must be unique, so I've just named the second service
ZWave2
and also changed the port to/dev/zwave2
. Why use custom symlinks like/dev/zwave
to the controller devices instead of/dev/ttyACM0
? The symlinks are associated with a particular controller, while the tty device names can change depending on enumeration order. I'll show how to create the symlinks in a followup post.Services config files (e.g. OpenZWave zwcfg_0x<home_id>.xml) are stored separately in corresponding service directories, e.g.:
/opt/Theatersoft/.config/theatersoft/ZWave2
I also find it useful to increase the OpenZWave log level, using the
options
property shown above.