Zwave2mqtt: [question] GE14294 Dimmer

Created on 11 Mar 2020  路  15Comments  路  Source: OpenZWave/Zwave2Mqtt

I have added a GE 14294 dimmer to zwave2mqtt, and it looks like it was added fine except that it says it is not secure even though I selected secure when I added it.

My major issue with it is that the state is nowhere near in sync with the actual light itself. I try to set the state in the zwave2mqtt control panel, and I've tried it directly in HA, but they are all so out of whack it's not even usable. It says it's off when it's on, says it's at 1% brightness when it's at 100%, etc. I originally went in and tried it with retain on, that didn't work, so I turned retain off, restarted HA and zwave2mqtt, cleared all the retain flags with mqtt explorer and it's still just as terrible.

If I change the dimmer on the wall, that always gets reflected right away correctly in HA, but controlling it from HA and having the light actually respond just flat out doesn't work.

I've run debugs and it looks like the messages are coming through correctly to set the brightness and whatnot but it just doesn't match what the actual light is doing.

I have been using HA for a while, and am coming from using SmartThings as my zwave/zigbee hub and trying to migrate to this to get rid of the cloud dependency. Please help!

question

All 15 comments

@broyuken If you added it securely don't trust that flag, secure command class is not supported from all devices and there is no way right now to know if it is secured or not. There is an open feature request on openzwave about this.

If using with hass please be sure that your gatewat payload type setting is set to JSON time-value or zwave object (not Just value)

Than what version of z2m and OZW are you using?

I have it set to ValueID Topics and Time-Value. I'm running OZW 1.6.974 and z2m 2.2.0.

Could you check slack channel? There is an open conversation about this

Yep, that's me :)

@broyuken If you added it securely don't trust that flag, secure command class is not supported from all devices and there is no way right now to know if it is secured or not. There is an open feature request on openzwave about this.

I don't know why your confused here:
1) All ZWave Plus Devices mandate Security Support. (S0). This is just about any device manufactured in the last 5 years or so
2) The Presence of the Security CC indicates that the device is able to be included Securely
3) The Security CC exposes a ValueID with Index 1 (Label "Secured") that indicates if the endpoint on the device is encrypted. That is the flag you should look for.

The feature request will be to address S2 when we support it (as its will be more than just "encrypted" or not with S2 - There will potentially be 4 levels of encryption).

I don't know why your confused here

I'm not confused @Fishwaldo . Actually on the code I make this check:

https://github.com/OpenZWave/Zwave2Mqtt/blob/ccd8650471a3fd68595702d7f3e0b65c44072602/lib/ZwaveClient.js#L399-L401

As you can see I check both the index and the command class, if so I set the secure to true. But seems not all devices support that command class?

I got the index from here:
https://github.com/OpenZWave/open-zwave/blob/master/config/Localization.xml#L843-L848

But you say this:

there is no way right now to know if it is secured or not.

With your code- then you have everything you need.

@Fishwaldo with that I mean "there is no way that works with 100% of devices",, I can tell that that method almost doesn't work as many users are still asking me why they see all nodes set as not secure even if them are secured.

Anyway you told me to check index 1 but localization tells to check index 0. Am I wrong??

But seems not all devices support that command class?

As mentioned, pre-zwave+ devices do not support it. So the absence of the CC indicates the device can not do Secure Inclusion. All ZWave+ devices have to support the Security CC (otherwise they can not get certified) hence, that CC would be present, and the index value tells you if we successfully negotiated the encryption when adding the device.

I can tell that that method almost doesn't work as many users are still asking me why they see all nodes set as not secure even if them are secured.

If the Node is pre-zwave, security is not supported. If the Node is ZWave+ then Security is supported and if the value is false, then its a "user error" of sorts.

Anyway you told me to check index 1 but localization tells to check index 0. Am I wrong??

Sorry, your correct. Index 0. A comprehensive list is actually in here (as some values might not always get translated) - ValueIDIndexDefines.def

So a combination of presence of the CC and the Index 0 flag gives you:
1) No Security CC - Not Supported
2) Security CC present, index 0 = false - Supported but not enabled
3) Security CC Present, index 0 = true - Supported and enabled.

So a combination of presence of the CC and the Index 0 flag gives you:

Yes so it is what I'm actally doing right now :) I make set the node as not secure at start and than once that value is added I check if its value is true or false. My question is, should I ask for refresh that value or the value I get in valueAdded event is correct?

I've just seen you test it during valueAdded. This is probably your issue. You should do the test in ValueChanged as well (if your not already). (eg, when a node is added to OZW, the initial communications are clear text, its only half way through the interview process that security keys are negotiated - Hence when index 0 is "added" to the list of ValueID's, its possible security hasn't been negiated and hence why you don't get accurate results.

Then it should be working. For those reporting its "not true" then id be reviewing to ensure they added secure, or consult log files of OZW why it isn't working.

Was this page helpful?
0 / 5 - 0 ratings