Each of those channels goes from 0 to 0xFF, like your typical RGB hex format. Generally you set either red, green and blue, or just warmWhite and/or coldWhite. Brightness is still controlled by the SwitchMultilevel or Basic command class.
Unfortunately querying the current color is a pain; you have to get each component individually:
Yes, the first device type above works decently with the Fibaro, though the color temperature slider doesn’t work and it doesn’t do the “max white” trick that Todd Wackford’s handler did.
Interesting, the device type provided for the Aeon Bulb is not working for me. Changing color and brightness do not do anything. I can’t even turn the bulb on and off with the device type. Changing back to the Dimmer Switch device type allows for the bulb to be dimmed on and off . . .
It sounds like your bulb may have failed secure inclusion. Did you join the device after you installed the device type? You could also try the other handler I posted.
I have a hue bulb that alerts me when someone comes to my front door or opens my mailbox. wanted to do the same thing downstairs with aeon labs bulb. made this new device type and added to my hue smart app and it does not work.
In live logging I see it gets the change color command, but it doesnt get the turn on command.
Has anyone been able to notify with aeon labs bulb? @duncan
I had to exclude the bulb from the zwave network, remove it from smart things list, and then re-add it with the new device type installed in order for me to control it with the new device type. At first i simply tried changing the type from the web based IDE, but that broke it. Once I removed it and started over, it works well now. Only thing I notice is the color on the wheel doesnt correlate well to the color the bulb shows. For example, I switch it to orange on the wheel, the light actually turns green. I am sure they are still working with this, so for now its ok. Just glad to be able to set the color at all.
@AdamMullins Yeah that would be a bug, thanks for letting me know. I’m guessing this is broken because it’s setting the color by hue+saturation instead of RGB like the mobile app does. I’ll look into it.
Is the warmWhite and coldWhite a hex value as well? I see the red, green, blue values as 0xFF, but the warmWhite, coldWhite as just 0 in the example above.
I’m hoping to tie one of these lights in with my doorbell so that the lights will flash like a strobe light in some other color than white(most likely blue or red) when the doorbell is rung. This looks like it gives me some hope of doing that.
Any chance this is working with any apps that use HUE Bulbs yet? I see the commands in the IDE, but changes in the bulb. The bulb works if manually adjusted.
Really great effort on this. I had the Aeon LED bulb, a dimmer, and was about to start down the Fibaro HC2 route.
I discovered the new hub a few days ago, got my delivery yesterday and started looking at possibilities. At first I was a bit disappointed that I couldn’t find any native RGBW support, but this works just fine.
Bottom slider is white only I think, top is colour brightness.
not working on the new aeon zwave switch v6… should control the night light color…
I tried this directly but not changing the color… any ideas, aeon says I need to be using the color class. see below
To change the color of the night light, your controller will need to support the color CC, if it does not then it is not possible until your controller supports the command class in Z-Wave.
Any chance the great minds in this thread could look at the Homeseer HSM200 LED device to determine how easy it might be to integrate functionality? @DrZWave has a device type for this device, but maybe this newer command class would work better and allow me to pull the device into a Smart Lighting app?
I’ve been considering purchasing several of these to put throughout the house. I found a user manual for it, but is there any engineering or developer documentation out there?
Reading through the device type code, it looks like some type of work-around was needed bc back in April, ST didn’t have good support (maybe that has changed, which is why I think the info posted in this thread is vital in the right hands with the right knowledge)
Edit: among other helpful data in the manual…
Here is the wording in the code of the device type for the HSM200 (aka EZMultiPli…same device, different name): // cmds << zwave.colorControlV1.stateSet(stateDataLength: 3, VariantGroup1: [0x02, myred], VariantGroup2:[ 0x03, mygreen], VariantGroup3:[0x04,myblue]).format() // ST support for this command as of 2015/02/23 does not support the color IDs so this command cannot be used.
// So instead we’ll use these commands to hack around the lack of support of the above command
cmds << zwave.basicV1.basicSet(value: 0x00).format() // As of 2015/02/23 ST is not supporting stateSet properly but found this hack that works.
if (myred!=0) {
cmds << zwave.colorControlV1.startCapabilityLevelChange(capabilityId: 0x02, startState: myred, ignoreStartState: True, updown: True).format()
cmds << zwave.colorControlV1.stopStateChange(capabilityId: 0x02).format()
}
…and it goes on but this is a good representation
Looks promising. Are you sure the Homeseer and the EZMultiPli are the same? They look slightly different, but maybe one is just re-branded. These things are expensive, but I might pick one up to play around with.
Yes, they are, internally at least. I own the Homeseer HSM200 and it responds to the color switch command class as described in the manual (capability ID and all).
If you want to try to get things working with me as a tester, I’m happy to try different things out. (I know it’s easier to test when you own the device though)
So I just tried writing a DTH that uses exactly this command and I get the following error: groovy.lang.MissingPropertyException: No such property: componentName for class: physicalgraph.zwave.commands.switchcolorv3.SwitchColorGet
Interestingly, the error refers to componentName whereas the command uses colorComponent, which is weird. I’m not sure what’s going on, any ideas? Has something changed?
[Update]
It does seem possible to make a request using the colorComponentId property instead. E.g.: zwave.switchColorV3.switchColorGet(colorComponentId: 2) which returns SwitchColorReport(colorComponent: red, colorComponentId: 2, value: 95)
So, I’m guessing there’s a bug in physicalgraph.zwave.commands.switchcolorv3.SwitchColorGet class which incorrectly processes the colorComponent property and incorrectly throws the error above. Over to you @duncan.
