Would you be able to add this and re-release the binding? I can re-test then.
Qubino ZMNHDD:
Parameter No. 250 – Unsecure / Secure Inclusion
Available configuration parameter (data type is 1 Byte Dec):
default Value 0
0 – Unsecure Inclusion
1 – Secure Inclusion
A Flush dimmer supports both, the secure and unsecure
inclusion. Even if the controller does not support security
command classes, a dimmer could be included as
unsecure and keep all the functionality
Does seem a bit of a long way round - thankfully I have just 1 of these
do I understand it correctly that zwave_secure mode means, that the traffic is AES 128bit encrypted? My thought was that zwave is always AES encrypted but currently I’m not sure in that and as more as I read, I get more unsure
also I’m reading things like that zwave plus support a more secure (secure2 or sth like that) technology to which denies prevents man in the middle attacks while inclusion etc.
Yes - this is not implemented in many devices yet, and is not implemented in OH. In reality, the chance of intercept is extremely small with the existing encryption scheme so I think there’s very little risk with S0.
@chris, I still see a temperature scale in the channel configuration of my WAPIRZ-1, so I’m guessing UoM hasn’t been implemented in the dev binding. Since the scale currently defaults to Celsius, UoM will be very helpful for those who use Fahrenheit. Is this something you plan to add?
Or is it already in there but the scale setting needs to be removed from the channel?
@chris thx for your answer.
your device database on cd-jackson are they up2date? because I bought the devolo mt2653 keyfob which I got sucessfully included as secured, and the neo coolcam sos keyfob I didnt. but on both keyfobs in your database there stands, that they dont support secure mode.
I can not be 100% sure - there are around 840 devices, and I simply cannot check everything. If you spot an error, then please feel free o correct it.
This will not matter - the binding does not use this information and it’s only in the database for completeness. Of course, it should be correct in the database, so please feel free to update any errors.
While it’s true that the network traffic will increase by 2 to 3 times, I’m not sure it’s necessarily a bad idea. I’d say security is always good, but it’s a personal choice if you think someone is likely to hack your temperature sensors or even lights, and you need to balance this against the impact on your network…
Personally, I only secure locks for this reason, but the choice is yours .
I’ve just updated the binding to include the UoM conversions for temperature sensors and thermostat readings/setpoints. @5iver has kindly tested that the conversions work for temperature sensors in degF, but if anyone can confirm that thermostat setpoints are also working, it would be useful.
Currently, the setpoint scale setting is still available in the setpoint channel, but it should be overridden by unit setting in the QuantityType command - if this all works, I’ll remove the setpoint setting in the channel.
Hi Chris, i’m new here and i hope you understand my englisch
I have a problem with the secure inclusion mode. My z-wave-binding 2.3.0 snapshot is from 3.5.2018.
My devices are two thermostat eurotronics spirit and one fibaro door sensor 2.
I have no Problems with the z-wave-binding 2.3.0 snapshot from the beginning of march.
What are the different by the secure inclusion Mode between this snapshots?
Are you sure you are running the right version? I don’t think there was a version from 3 May - looking at the history, there was one on the 30th April, then I updated it yesterday.
The logs are not from the right version of the binding.
There are a lot of differences. I think before looking too much further I think you should double check the version as I’m pretty sure that you are not running the version that supports security. Please read the first few posts in this thread.
Ok perfect, i have found the correct version on the top.
After the installation of the new version from 7. May , i have a new Problem:
2018-05-08 20:46:57.952 [ERROR] [org.openhab.binding.zwave] - FrameworkEvent ERROR - org.openhab.binding.zwave
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [245]
Unresolved requirement: Import-Package: javax.measure.quantity
at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1599) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
Is the Development Binding compatible with Openhab 2.2.0.1?