I have three identical Hue ceiling lights in this room. They are connected via the Hue Bridge. I have been using CocoHue, but yesterday also installed the inbuilt Hue integration app for comparison.
One of these ceiling lights has been behaving oddly for a few days, but I can't think of any updates I ran around that time (It may have coincided but I didn't note the change at the time). I would have suspected the bulb itself of beginning to fail, but it behaves perfectly when controlled directly from Hue, or even via Hubitat when accessing it via Hue scenes rather than directly addressing the bulb as a device.
With CocoHue, when turning off from any colour or white, it turns blue just before finally going out, and therefore it turns on blue. With the inbuilt integration it turns on many seconds after clicking On from the device page, and takes even longer to turn off (and also turns blue just before going out). All the other bulbs are fine.
I have tried changing the positions of the Hue Bridge and the HE hub, just in case signals were interfering with each other in the direction of that bulb. Oh, and I also turned off power to the bulbs for a few minutes and rebooted the hub.
This is a mystery, can anyone shed any light? (pardon the pun)
I'm not sure what would be going on here, but I doubt it's related to Hubitat's or the CoCoHue integration. I can't speak for theirs, but mine basically sends this with an off() command:
{"on": false, "transitiontime": 40}
...though the transitiontime may vary depending on your preferences (actually not sure if I've released that version yet, but coming soon if not ). It's possible removing the "transitiontime" thing may help at least third-party bulbs or non-Hue-Bridge devices like deCONZ or diyHue work better if that confuses them, but it seems unlikely to be a problem either way.
My guess is the bulb itself, but I know that's hard to troubleshoot. "Rebooting" the bulb (turning off the switch for a few seconds) and Hue Bridge might not be a bad start if you haven't tried that already.
The only thing I had not tried is rebooting the Hue bridge which I have just done. Now the light is still passing through blue on its way off, but succeeds in reaching white as it turns on. However an even more bizarre anomaly has now raised its head. Turning off that one light from the device page now also turns off another at the same time.
I have a feeling this is such a one-off that no one is going to be able to explain it (and yes could be caused by the bulbs themselves going rogue or getting old I guess) so I'll focus instead on workarounds. But if anyone else has experienced similar weirdness do please comment, if only to let me know I'm not alone lol!
Out of interest, when CocoHue sends the command to the Hue system, are you addressing the bulb directly, or sending a request to Hue to control it in a particular way? And is that different to what happens when you request a scene that is set up on Hue?
Update: I realised I'd been seeing a tradesperson visiting next door and some light drilling. Then I noticed a new nearby wifi network on my phone's list, and it happened to be sitting on channel 6. So I changed Hue's zigbee channel to 25 and it seems a little better so far... The problem bulb is the one nearest the wall I share with the neighbor.
That's quite interesting, I am literally in the process of writing, well trying, to write a linux CRON job to look at the channel's used by my own wifi networks, want to have some read out of them available on a dashboard for convenience, given I have 3 zigbee networks and two wifi networks of my own. I would like to expand it to look at other wifi networks as well to keep an eye on any potential clashes.
Well if you're not actually adjoining your neighbor's home then you probably don't need to worry about cross-home interference, but we're literally only the other side of a brick wall no thicker than the ones we have between our own rooms, which are passing the signal through easily.
There is no way to turn a bulb off other than addressing it specifically (by Hue light ID), unless you're dealing with a group (and then it's the group by group ID). I don't know how the Hue app works; third parties must use the Hue API, but because Philips wrote both their mobile app and the system it controls, my guess is that they use a proprietary communication method between the two (looks like the app gets instant updates from the bulbs, for example). However, I imagine that by the time the Bridge sends commands to the bulbs or groups that it's pretty much the same.
I was wondering if when I send a request via the Hue app, or a Hue button or automation, the Bridge actually checks the bulb after the command has been sent to see if the end result is as it should be, whereas if it's simply passing on a message coming from Hubitat, it just passes it on and lets the bulb do what it feels like with it.
Most Hue button devices don't use the Bridge at all; they broadcast group commands to the network, then bulbs respond if they're part of that group. (That being said, they've been requiring the Bridge for more and more lately and appear to have even rebranded it a "hub," so this might not be as true as it used to be.) I'm not sure what the app does but can't imagine it would be that different from anything else, though all I can do there is guess.
Well scene and group data must be stored on the Bridge otherwise Hubitat wouldn't be able to access it, (I assume it's not querying the app on my phone) so I'd have guessed when using those "devices" Hubitat must be addressing the bulbs via some translation on the Hue Bridge? The hubitat's not reading in the scene settings and storing them and then asking the bulbs to go that colour? Or is it?
Correct, the Bridge also stores groups and scenes (and light) data. My point was just that lots of Hue accessories do group messaging directly to the devices (also including the Bridge, which is just another device in the network--it's not like Zigbee Home Automation we're used to on Hubitat, where the hub is in fact a hub and handles communication between devices--but the Bridge isn't technically needed for most actions a remote/button device will perform on Hue).
Hubitat, of course, must go through the Hue Bridge--that's the "bridge" part, between your LAN and the Hue Zigbee network. But no, CoCoHue doesn't store the scene settings; it gets the scene ID from Hue when the device is added, then tells the Hue Bridge to activate that scene ID. The Hue Bridge then, presumably, sends a a group broadcast to activate that scene. Scene data is stored on bulbs, or at least can (should?) be, so this should again just be a single communication from the Bridge to the network and not the Bridge sending a bunch of commands to each bulb to get them in the right state (though that is pretty much how native Hubitat scenes work ).
Storing scene data on the bulbs seems somehow unintuitive. How much nvram does a Hue bulb have? I've not heard a limit to how many scenes a bulb can be part of. I had been under the impression a bulb only knew its last colour setting before it was switched off (soft or hard switch), and its default behaviour upon power on.
I don't know how much storage is available on the bulbs, and I think the Bridge might be be able to store more scenes than a bulb can, but I might be confusing that with some Bridge limit and then maybe the rest are just in-app until they're used again ... but I can't imagine it taking up that much space on the bulb, basically a scene ID, likely also for just a specific group ID (though the v1 app I think only did your entire network), and whatever settings (level, color [in hs, ct, or xy], or just the fact that it's off). In any case, those are implementation details I don't know specifically but also don't think I've ever seen as a problem for anyone.
Storing scene data on the bulbs is, IMHO, actually a good idea: one group broadcast to get all bulbs into the desired state immediately seems a lot better than flooding your network with a bunch of messages to each bulb to get each one into the right state--less time, limited to no "popcorn," and high reliability. I think that's part of the reason Hubitat's Scenes app doesn't always work well for a lot of people without workarounds like spacing out commands or "double activation."
). It's possible removing the "transitiontime" thing may help at least third-party bulbs or non-Hue-Bridge devices like deCONZ or diyHue work better if that confuses them, but it seems unlikely to be a problem either way.
