I’m reaching out to developers to try and find someone who can help me to adjust my code to be able to find the current state of the bulb if it is manually turned on with the physical switch.
I’ve combined the code for the RGBW bulbs, and the Tunable bulbs that are on the community page. I’m not a programmer so I’m sure the code could use some cleaning, but it works and I haven’t had any bugs in it so I’m happy… well, except for one bug.
The Zigbee bulb (Ecosmart RGBW) is connected to a light fixture that is controlled with a physical switch. Sometimes it’s nice to be able to turn the light of and on with the physical switch instead of opening the app on my phone. But when I turn on the bulb with the physical switch SmartThings doesn’t know that the bulb is on.
Can someone take a look at my code and let me know how to fix it so that it knows when the bulb is on or off with the physical switch?
First of all, thanks @rpress for getting back to me.
I added the following code, but I don’t see how to ‘click configure in the simulator’. I haven’t really used the simulator much, and for this device it lets you install it, but the simulator seems to be empty.
This code seems to have fixed it so that when the physical switch is turned on SmartThings updates the status to ‘on’. but it doesn’t seem to know when the light is turned off using the physical switch. So it’s half fixed… but not perfect yet.
Any idea what else I need to do to make this work?
I don’t think anyone has implemented detecting if the light is off. This is more complicated, because when the device is off it doesn’t communicate. There could be some kind of heartbeat timer that will detect a missing report. But as far as I know poll() is still broken which precludes something like this.
Did the rest of my code look ok? I’d love to share this with anyone who wants it. I just wanted a zigbee bulb controller that did both colour Temp and RGBW and I couldn’t find one, so that’s why I made this device type.
I’d love to combine the projects, are you interested in using the hue, saturation slides from my code, could I push some of those items (after testing it and making sure I have it working with your code)?
Also, your branch name is a bit funny… RGWB? typically it would be RGBW like is in the device name. I think that’s just a typo.
Good stuff Tyler! Very clean implementation! I’d recommend you incorporate the Color Mode attribute to know whether the bulb is currently lit based on the Hue/Sat or Color Temperature values. It’s attribute ‘0008’ of the Color cluster, otherwise the actual light shade is still unknown.
It doesn’t fit into the current capability taxonomy, but it would be important for any SmartApp trying to get the true state of a RGBW device. Maybe it could be an optional addition to the Color capability.
Kris, I built this device handler for Hue and Lightify RGBW bulbs based on the Improved Zigbee Hue device handler that several people contributed to. I plan to refine it using the new zigbee layer soon:
@Sticks18, I assume this should work fine with any Zigbee RGBW bulb?
I’ve got an Ecosmart RGBW bulb (Home Depot, much cheaper than Hue) and that’s where all of this started.
The colour wheel has buttons for warm, or cool white (When part of the multi-tile), but on the Ecosmart bulb the colour reproduction for the colour temps are horrid when using the colour wheel buttons. The temp slider though works great so I combined the two devices from the community GitHub repo (zigbee-hue-bulb.src and zigbee-white-color-temperature-bulb.src) Then I got carried away and made some hue sliders that change depending on the colour of the bulb etc.
I’m still learning how SmartThings works, so perhaps this doesn’t matter, but it seems like the fingerprint links it to the right device?
The ecosmart bulb has the following under “Raw Data”
Yup, it should work with any zigbee RGBW bulb including the Ecosmart. Give it a shot. The only real difference is the Ecosmart is Home Automation profile, not Zigbee Light Link (The 0104 in your fingerprint vs C05E in mine). Zigbee Light Link added a few new features like Color Loop and Alerts that I was testing in the ‘enhanced_features’ branch of my Github.
You might like the UI, and I added gradual transitions for level and color changes. It will also gradually dim up/down on on/off changes if the bulb supports it.
It can certainly be cleaned up, especially with the new zigbee stuff.
It was horrible on the Hue too. Those buttons try and emulate white color temps via hue/sat values. I added code to the beginning of setColor to watch for those defaults and convert them to 2700K and 3500K directly.
I’ll test out both of your devices and see which one to go with. (As I’m sure they are both better than my hodgepodge of code splicing mess)
@Sticks18, your code seems to be more advanced, just not sure I need most of the features as they look targeted at Hue specific tasks. I love the multitile changing colour, and that the name of the colour is listed on there.
I hate those 1 height sliders though… they look better, but it’s impossible to grab them using an iphone 5s.
The version of code in my master branch doesn’t use any of the Light Link enhancements, so it should work 100%.
In some ways it’s more robust, but it’s mostly just inefficient compared to the newer coding style. The multitile reflecting the bulb color and coordinating color temp vs color were my main additions.
I was trying to conserve space and display more information, otherwise you have to scroll to get to see all the tiles (iPhone 6). I’ve had trouble with sliders lately too, but both 1 and 2 height sliders. After all the work, I rarely touch the sliders anymore because of other automations.
I was using the color mode attribute to print out on the tile whether it was color temp or color. You can see it in the current implementation of OSRAM RGBW Flex lightstrip. I have stayed away from it for now to make sure we have a clean, stable and better implementation. I do plan to work on getting that aspect back. Didn’t think that it would be useful anywhere other than color names, but you guys made the right observation that we could potentially use this in the future for smartapps.
The only change that I have made for now is adding a delay to the commands in between saturation and hue. I kept seeing that the bulb was slow to respond if the delay was only 200ms. (default delay).
RGBW isn’t a typo We plan to have two implementation : RGBW and RGB.