Recently some of my Hue bulbs seem to have changed their behaviour. I have a bunch of lights that are controlled by rules based on time of day, ambient light level, motion etc. Some of the bulbs are the white ambience type and some are full colour.
A few days ago the colour ones just stopped working, while the white ones continued to function perfectly. The logs indicated that commands were being sent as normal, so I tried a bunch of things such as updating OH to the latest stable version with all packages updated, restarted the Hue Bridge, and removed the Bulb Things and re added them. Nothing worked.
To eliminate the complexities of the rules I set up a test switch on site map and wrote a simple rule that just turned on one of the lamps when the switch changed to on. It didn’t work. The command that I’ve been using successfully to turn on the lamps is"
After much playing around I discovered the only way I can turn on the bulb is to use:
HueBedroomReadingLamp_Color.sendCommand(ON)
The white ambience bulbs will still turn on quite happily by sending them a brightness value that is greater than 0.
Can anyone please explain why this behaviour has changed as I’m concerned that if I don’t fully understand what’s happening that my current workaround may also fail at some point.
The problem is, that the bulb is not enabled anymore. If the light is already on, all cooler command will work and the color is changed. But if the light is off, a „x,x,x“ color command will not enable the light anymore.
In the German thread, also a downgrade was checked. And also older releases have the same problem. So I think it is a problem of the laste Hue-Bridge-Software releases.
I’ve been away for the weekend, but will try your suggestion tonight - thanks very much for responding. It’s odd that what was working fine has suddenly stopped, but perhaps Tim’s suspicion that the Hue Bridge software has changed is correct.
Cheers,
Pete.
I am on vacation right now, so I cannot check. But I have two hypotheses…
OH core rules processor no longer can parse a comma delimited triplet string (like “10,20,30”) automatically as an HsbType command, or…
As you suggest, that something changed in the July Hue firmware update.
Apropos 2. above: the Hue bridge itself processes colorXY, brightness, and on/off states as three different orthogonal state vectors (i.e. it can change a color (say) independent of changing the on/off or brightness states), whereas the OH system requires the three state vectors to be non orthogonally coupled (i.e. you can send an on/off or dimming command to the color channel, etc.). And this means that the OH binding has some “logic” to “re-orthogonalize” the three state vectors. I was never comfortable with that messy requirement, so we also implemented the advanced “on/off only” and “dimming only” chanels, that allow you to send send orthogonal commands directly, and bypass the the “re-orthogonalization” of OH.
Do you mean the v1 bridge hardware? Which only supports API v1. Or the v2 bridge hardware? Which supports both API v1 and v2.
If it is really the v1 bridge hardware, then neither the firmware nor the binding have changed, so if you nevertheless notice a change in behaviour then the only thing that would have changed is the OH core itself.
sorry for the missing information. The hardware is the v2 bridge and I use the openHAB v1 API binding. I think it is not part of the core… the guy in the german openHab forum try a downgrade and it is still the same issue. Furthermore I think the lights works a few days with my current openHAB version
The workaround from @lolu word als in my Blocky case. I send a “ON” in front of the HSB value.
Hi Andrew,
I tried adding the line you suggested but I think there’s some kind of syntax error that I’m not spotting. My rule looks like this:
rule "Test_Rule_On"
when
Item Rule_Trigger changed to ON
then
AmazonEchoStudio_Speak.sendCommand('Routine triggered')
HueBedroomReadingLamp_Color.sendCommand(new HSBType("250,200,85"))
end
But in the Problems section of the editor I get this:
Ambiguous feature call.
The extension methods
sendCommand(Item, Number) in BusEvent and
sendCommand(Item, Command) in BusEvent
both match.
I’m probably making a noobie mistake somewhere, but I’m not sure what.
I am glad you found a solution. It looks like the Hue bridge behaviour did indeed change (at least for users still using API v1). It is not that anything was “broken” in the OH binding by that change; but rather that the behaviour is now simply different than it was before. Therefore I am not planning to make any specific “fix” in the binding (for API v1), and will simply guide other users to use the same workaround as you did here.
Apropos users on API v2, I think that whatever change that Philips / Signify made in v1 will not have been replicated in v2. (Since v2 was always doing it the same way as v1 now does). And therefore I am also not planning to make any changes in the OH binding v2 functionality.
