It seems that the Fibaro FGS-213 is not in the database for the OpenHAB 1 Z-Wave binding. When I configure it I get:
[ERROR] [.z.i.config.ZWaveConfiguration] - NODE 8: Error in doSet - no database found
and it is not possible to configure it via Habmin, either, where it shows as a grey dot. Am I doing something wrong?
Having contacted @chris I have been informed that this device is listed in the z-wave database. I still do not understand why it is generating those errors. Any suggestions would be most welcome. I am using OpenHAB 1.8.3.
Thank you.
See my last comment on GH - it’s in the OH2 database (which is where the issue was raised), but it’s not in the OH1 database. It just needs to be exported from the database and added to a pull request in GH.
If you’re happy to do a PR, that would be great, but if you’re unsure how to do this I’ll do it - just let me know.
Hi Chris, I am somewhat versed in GH and doing/reviewing/approving PRs, but I am not knowledgeable about the way OH and your database have been developed. In my daily job I code in R, Python and some LISP, never Java. 
I can give it a go, though, if I figure out the artefacts that need to be touched. Happy to try, thank you for the pointer.
Ah - good man 
You can export the OH1 file from my website
This will provide two lists - one is the actual file - it goes into the /database/fibaro folder in the zwave binding. The other part at the top needs to go into the products.xml file which is in the /database folder.
Just yell if you have any questions.
Thanks.
I have ported the OH2 entry to OH1, see PR https://github.com/openhab/openhab1-addons/pull/5148. Unsure if it was supposed to go into the master branch or not.
I am happy to report that the device is now being recognised, having updated the binding to the latest build 1.10.0.201703240211, from https://openhab.ci.cloudbees.com/job/openHAB1-Addons/.
I get an error, however. Any idea what is causing it?
2017-03-24 09:23:10.451 [ERROR] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 8: Error instantiating command class 0x98
java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.8.0_111]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[na:1.8.0_111]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.8.0_111]
at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_111]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveCommandClass.getInstance(ZWaveCommandClass.java:247) [bundlefile:na]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveCommandClass.getInstance(ZWaveCommandClass.java:210) [bundlefile:na]
at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationUpdateMessageClass.handleRequest(ApplicationUpdateMessageClass.java:96) [bundlefile:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:231) [bundlefile:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:204) [bundlefile:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$6(ZWaveController.java:199) [bundlefile:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1247) [bundlefile:na]
Caused by: java.lang.IllegalStateException: NODE 8: node wants to use security but key is not set
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.<init>(ZWaveSecurityCommandClass.java:342) ~[bundlefile:na]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClassWithInitialization.<init>(ZWaveSecurityCommandClassWithInitialization.java:77) ~[bundlefile:na]
... 11 common frames omitted
Thanks.
The error is that the security key is not set - I guess if you set the security key it will go away 
I see! I suppose this is related to the other issue, that is that I have not found a way to know which devices have been included in the secure mode, and which have not. I wonder if seeing this error is a reliable indicator that a device has been included insecurely.
I think that seeing this error is a reliable way to say that NO devices are securely included. If the key hasn’t been set, and that’s a global setting, then it likely means that no devices can use security.
@chris, this is very helpful and explains why I have never seen any signs of secured inclusion on my network. I also had no idea that the z-wave key had to be set, somehow. I assumed this was an automated function of the z-wave protocol.
Is there a way to use Habmin, or any part of the binding config, to set the key? I use the Aotec Z-Stick Gen5 and I have not seen any options pertaining to the key. I use Habmin (thank you!) to configure every device parameter, but again, I have not seen security key options anywhere.
Many thanks for helping me unravel the z-wave security complexity.
No - as with any secure system - the user should set a key otherwise it’s potentially insecure.
No - it needs to be set in the config file as far as I know.
The key is not related to the stick - it’s a software (ie binding) issue only.
Thank you, Chris. I had a look at the openhab.cfg looking for any signs of z-wave binding security key options but I cannot see any. Could you, please, let me know what settings let’s me provide a key for secure inclusions?
I respectfully disagree on this point. Having security on by default with reasonable auto-generated keys is always better than having no security.
For example, think of https and imagine what would happen if users had to generate their own keys to establish connections—hardly anyone would use it. A key derived from something like /dev/urandom is fine for most uses, and for whom it is not, hardware-based key generators exist. In case someone reading this now thinks “But what about servers? Surely admins set the keys on them?” even that is not the case. Automated KMS (Key Management Service) are normally in charge of that, and for smaller installs there are popular techniques like the LetsEncrypt implementation of the IETF ACME protocol, supported by EFF, precisely to ensure automated key and certificate generation, leading to more, rather than less security.
In summary, I strongly believe that having z-wave default to having secure inclusion would be a good thing for everyone, especially for the future of z-wave reputation, which I am sure will suffer as first attacks become more prevalent. I trust my opinion might help you, as the maintainer of a very prominent z-wave technology, in some of your future decision making.
Thank you, again, for answering my questions.
Sorry - I’m not really sure. As I’ve said elsewhere I’ve never used these options. Do a search for OH1 Schlage on the forum - there’s a long thread about this. As said earlier, I never managed to get this to work well for me so I completely re-implemented security on OH2.
Maybe, but your question was if it was default in the protocol - the protocol (ie the stick) does not handle security - it’s all done in the binding.
Default keys might be ok, but if you autogenerate a key, then you’re pretty much guaranteed to lock yourself out if you don’t know where it’s set! My OH2 implementation does exaclty this and many people lock themselves out when they reset something and the key changes.
Sorry - https security is completely different issue.
Personally, I do not use ZWave security unless you have locks, or other such secure systems, but it’s up to you. It will generate a lot more traffic on the network, and the chance of timeouts etc is significantly increased. The function is provided - it’s up to users to understand its use and configure their system as they like.
On OH2, this is the default - autogenerated key, but only used for security devices.
Thanks. I suppose I need to consider OH2 again. I hope the other bindings I use work better with it now than the last time I checked.