Zwave binding, Color and 5-channels RGBCW - Aeotec Leds Strip ZW121

Add-ons Bindings
1

Hello,

I’m using Openhab and the zwave binding 2.4.0 stable.

I’ve got a Aeotec ZW121 Leds Strip, which is supported by this configuration file in the zwave bindings database.

I’m getting in trouble because I cannot choose the color of the leds (brightness and warm / cold white settings are OK).

The Leds Strips expects a all-in-one 5-channels RGBWC with W and C set to 0 to setup the RGB color, according to its engineering specifications (5.8 chapter) :

Switch Color Set Command Class

White color LED and RGB LED will not light up at the same time, so the software makes the following processing. When you want to activate the current RGB color, the color value of higher priority should be set to 0.
For example: The Warm/ Cold white is the highest priority, when it is configured to 0, the RGB color configuration values can be activated. Otherwise, the LED Strip is always be activated by Warm/Cold white.

I tried to directly write an hexadecimal string in an item linked to the color_color channel, but it does not work :

TerraceLeds_Color.sendCommand(String.format(“%02x%02x%02x%02x%02x”, r, g, b, ww, cw))

10:52:40.041 [INFO ] [smarthome.event.ItemStateChangedEvent] - TerraceLeds_Color changed from NULL to ff00000000
10:52:50.004 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘TerraceLeds_Color’ received command ff00000000

(I also tried the FF value at the other positions, but it does not work either).

Can the Color class in openhab support this “RGBWC” format ? Can the zwave binding support it too ?

The support website of aeotec shows a specific development done by their team for SmartThings hub, where the set color command is :

def rgb = huesatToRGB(hue, saturation)
result << zwave.switchColorV3.switchColorSet(red: rgb[0], green: rgb[1], blue: rgb[2], warmWhite:0, coldWhite:0)

The openhab zwave binding configuration file shows :

<channel id=“color_color” typeId=“color_color”> <label>Color Control</label> <properties> <property name=“binding:*:HSBType”>COMMAND_CLASS_SWITCH_COLOR;colorMode=RGB</property>

Is there a way to switch to an hypothetical “colorMode=RGBWC” ?

You got it : i’m lost :blush:

Thanks for your attention and for this wonderful software :slight_smile:

Regards,

Romain

2

This is what the binding will send if the device supports these channels and the colorMode is RGB.

Please can you describe your actual problem - forgetting what you think might be happening in the ZWave protocol - what is actually the problem you are seeing.

Next will be to provide a logfile so we can see what is happening in the ZWave stack.

3

OK Chris,

Thank you for your interest.

My actuel problem is : after having included the device and linked the color_color channel to a Color Item, I try to use the colorpicker displayed in the sitemap, and nothing happens on the led strips.

For instance, trying to turn the color to blue :

14:57:25.550 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘TerraceLeds_Color’ received command 245,3,100
14:57:25.554 [INFO ] [arthome.event.ItemStatePredictedEvent] - TerraceLeds_Color predicted to become 245,3,100
14:57:25.557 [INFO ] [smarthome.event.ItemStateChangedEvent] - TerraceLeds_Color changed from 245,89,0 to 245,3,100

and a second after that, this new log :

14:57:27.206 [INFO ] [smarthome.event.ItemStateChangedEvent] - TerraceLeds_Color changed from 245,3,100 to 245,3,0

(whatever color i choose, a first A,B,C value set, and a second after, the C value reverts to 0 with A and B remaining as-is).

Regards,

Romain

4

Please can you provide a debug log showing what is happening and I’ll try and take a look.

5

Can this help ? openhab.log (319.4 KB)

6

Thanks. Can you also provide the XML for the device please (in the userdata/zwave folder).

The binding should send the two white channels if they are supported, but they aren’t being sent. This makes me think that the binding thinks they are not supported - presumably because the device has not reported them? The XML might confirm this, or a log from the device initialisation might be needed.

7

Here is the XML for the device : network_ee4f0f5f__node_11.xml (10.6 KB)

8

I would suggest to reinitialise the device - there looks to be a lot of data missing in this file, and the list of supported colors is empty which is the root of the problem.

If that doesn’t fix it, then get a log of the reinitialisation and I’ll take a look to see what is going wrong.

9

Thank you Chris,

When you say reinitialization, do you mean deleting the thing ? or excluding and including again the device from the z-wave network ?

10

No - just select the reinitialise node option from the menu in HABmin (or PaperUI)

11

Just a little update during the reinitialization process : it seems to loop on the following message, increasing the “Try” count every two minutes :

20:31:18.887 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 11: No data from device, but it was ACK’d. Possibly not supported? (Try 8)

the state reported in Habmin is “STATIC VALUES” and I also notice from time to time this message :

18:32:22.495 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 11: Application Command Request (ALIVE:STATIC_VALUES)
18:32:22.496 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 11: Decapsulating COMMAND_CLASS_SECURITY
18:32:22.496 [ERROR] [ommandclass.ZWaveSecurityCommandClass] - NODE 11: Error decapsulating security message
java.security.InvalidKeyException: No installed provider supports this key: (null)

I’ll do a complete report when nothing happen any more.

12

Hi @chris

Nothing more after the initialization completed (it took nearly two hours from 18:20 to 20:09).

Here are the logs starting from the reinitialisation, and here is the network_ee4f0f5f__node_11.xml (9.8 KB)

I’ve also noticed that the binding entered an unstable state after reinitialisation, because even the brightness and cold/warm commands did not work. Restarting the zwave binding provided fonctional brightness and cold/warm commands, but no color.

:neutral_face:

13

There is an error in your log relating to security -:

2019-01-21 18:20:26.942 [ERROR] [mmandclass.ZWaveSecurityCommandClass] - NODE 11: Error encapsulating security message
java.security.InvalidKeyException: No installed provider supports this key: (null)
	at javax.crypto.Cipher.chooseProvider(Cipher.java:892) ~[?:?]
	at javax.crypto.Cipher.init(Cipher.java:1395) ~[?:?]
	at javax.crypto.Cipher.init(Cipher.java:1326) ~[?:?]
	at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.getSecurityMessageEncapsulation(ZWaveSecurityCommandClass.java:361) [221:org.openhab.binding.zwave:2.4.0]
	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.sendNextMessage(ZWaveTransactionManager.java:857) [221:org.openhab.binding.zwave:2.4.0]
	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.access$2(ZWaveTransactionManager.java:799) [221:org.openhab.binding.zwave:2.4.0]
	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:422) [221:org.openhab.binding.zwave:2.4.0]

This is probably why it is not working since all security encapsulation is failing. I think I’ve seen this before but I’m not sure what is causing it. It looks like earlier in the log encap is working ok, although actually maybe only using key0. In this case, it might be caused by not having a security key set in your configuration (??), although I do see it being set for this node (but I don’t log what the key actually is, so I’m not sure exactly what is happening).

Either way, this is the cause of the issue so if you can resolve this, it should work (I hope).

14

Hi @chris,

Thank you for the analysis and the time you give to me.

I agree that if we fix the problem of encap, it will probably fix my color issue.

The question I have now is : how can I fix the encap issue ?

  • I have setup a long time ago a network key in the controller thing, and all my other devices work well in secure mode;

  • I’ve tried to reinitialize the device several times, and I’ve got the same security issue popping-up in the middle of the discovery (at static values and after from memory)

-whatever key it uses (mine or the key0), it is curious : why does it changes brutally at the middle of the reinitialization ?

What can I try first, what makes the most sense ? Send you more detailled logs of reinitialization in order to track a bug in the binding ? Exclude, reset and include again the device ? Try the nightly version of the binding ?

Regards,

Romain

Le mar. 22 janv. 2019 à 09:54, Chris Jackson bot@community.openhab.org a écrit :

15

I also sometimes see this encap/decap error message on other nodes :

23:43:18.001 [ERROR] [ommandclass.ZWaveSecurityCommandClass] - NODE 8: Error decapsulating security message
java.security.InvalidKeyException: No installed provider supports this key: (null)

but never regularly (restarting the bundle can make the message vanish, restarting it again can make it reappear).

16

Hi @chris

I finally managed to solve my problem.

The core problem is that in some parts of the zwave binding code, there are ZWaveSecurityCommandClass that can be registered without adding the network key to it. After the command class has been registered without it, the networkKey attriibute which is null is passed to the encap/decap backend, which throws the exception “no provider supports this key : null”.

I added three modifications to the binding I use at home :

In the ZWaveSecurityCommandClass constructor, I initialize its network key with the controller one

public ZWaveSecurityCommandClass(ZWaveNode node, ZWaveController controller, ZWaveEndpoint endpoint) {
super(node, controller, endpoint);
// MODIFICATION
if (controller != null) {
setNetworkKey(controller.getSecurityKey());
}
// END MODIFICATION
}

but perhaps it would be better to use directly the controller one instead of copying it in a private attribute ?

I also added in the ZWaveNode::getOrAddCommandClass() function :

// If this is the security command class, set the key
if (zwaveCommandClass instanceof ZWaveSecurityCommandClass)
((ZWaveSecurityCommandClass) zwaveCommandClass).setNetworkKey(controller.getSecurityKey());

just before registering it (endpoint.addCommandClass(zwaveCommandClass):wink:

And finally, in the ZWaveNodeInitStageAdvancer::doSecureStages, I notice that many returns can happen before getting to this part :

// If we have lost the XML, and have previously securely included, then this will allow the device to be used
logger.debug(“NODE {}: SECURITY_INC State=GET_SECURE_SUPPORTED”, node.getNodeId());
processTransaction(securityCommandClass.getSecurityCommandsSupportedMessage());

so I added it at the beginning, just after

securityCommandClass.setNetworkKey(controller.getSecurityKey());

Not sure all of these modifications are compliant with the whole stuff, but it clearly improves the discovery process for me.

Regards,

Romain

17

Hi, no feedbacks about my modifications suggestions ?

Romain

18

@chris, Do you have anything further on this? I am getting a similar issue with an Aeotec water sensor.

19

@chris do you have any suggestions?

20

This is a very old issue, on a device that is not the one you have a problem with that was solved. I’m not really sure what your issue is so it might be best to describe what’s up, and provide logs if needed?