You could even try issuing a ‘dynamics’ command immediately before the ‘color-temperature’ command; that way, the lamp would come on immediately with whatever c-t it had previously had, and then gently fade to the new preset c-t value; which would probably be less jarring to people in the room.
1 Like
That’s a very good idea 
I think I’m gonna implement that!
Wouldn’t it be possible to ‘memorize’ changes done in off state in the binding and send them whenever an ‘on’ command is sent (or alternatively, and probably preferably, when an off → on state transition is detected)?
I actually had the same thought today. 
I wanted to test the behavior with API v1 to compare results, but didn’t get to that yet.
See also this comments that are somewhat related:
Your proposal is precisely what I have suggested the OP to do via a dummy item and a rule. This is a hack to try to resolve a particular user’s needs. It carries obvious disadvantages – namely that OH will post-hoc overwrite any commands sent via the Hue system from switches, dimmers, and the app. For that reason such a hack should definitely not be hardwired into the binding code.
API v1 has similar behavior. Color temperature changes while bulb is without power won’t have effect when it comes online again - it resets to previous value.
However, if the bulb is with power and only “soft” turned off, it’s possible to change the color temperature while bulb is “off”, and it will turn on with the set color temperature. This does not work the same way with Hue API v2. Here the color temperature is reset/lost when setting the brightness >0 again.
EDIT: I verified only through the binding with API v1 and API v2 things. not directly through the API. So I cannot yet rule out that the two implementations have impact on this behavior.
Lamps have a minimum dimming level. e.g. 2% So I presume you mean by “soft off” a dimming level > 0 and < minimum dimming level? Currently the binding constrains brightness commands to >= minimum dimming level and <= 100% …
Yeah, I was switching between ~50% and 0% brightness for the tests.
Considering only the “soft off” scenario, will it actually? Any external state changes should fail as well, the same way we do. And if they would succeed, I guess we would receive those state changes as well. So we should be fully synchronized until the moment when we would flush our queued color temperature update. I’m not saying there are no traps still, just playing with the idea.
Disclaimer: The following is only brainstorming… so please bear with me. 
The best moment to “queue” such changes would probably be upon a failed command, e.g.:
Command '0' for thing 'hue:device:xxx', channel 'hue:device:xxx:color-temperature' succeeded with errors: device (light) is "soft off", command (.color_temperature.mirek) may not have effect
First problem: How to detect that? I don’t know. I wouldn’t like to search in the text, but I don’t think there’s an error code available. Maybe we can fully analyze the logic and assess when this error will occur - for example when sending color-temperature while dimming level is below minimum. But this could change in future firmware upgrades (hopefully, actually). So maybe a flag could be set when attempting this command we expect to fail - and the presence of any errors after the call would then confirm and queue. We could remember the current color temperature also for verification.
Next, when should we “retry” the change? There are at least two different scenarios that might occur: The device is turned on again by some external event. Or we send a command ourselves to turn it on again. To be decided if both scenarios should result in the queued update, but probably they should, because otherwise you can’t adjust color temperatures throughout the day and let them become effective when a button would turn the bulb on. So at this point we’ll send our command, but only if the remembered current color temperature is still the same as when we queued the command, as otherwise we would overwrite external changes of color temperature in the meantime. And of course only if the desired color temperature is different from the current color temperature.
For the last sentence (“only if”) I may have just discovered a bug:
- Set color temperature to 100%
- Set brightness to 0%.
- Set color temperature to 0%
- Command failed, but state of the
color-temperaturechannel is still 0%. - Pause the Thing.
- Resume the Thing.
- The
color-temperaturechannel is now updated to 100% (because of initial state).
If we receive push messages with new state after successful commands, we might consider a veto policy here:
@laursen I feel seriously uncomfortable with your line of reasoning here. It is trying to devise a hack to “out fox” the native functionality of the Hue system. This is dangerous and can have unexpected bad consequences. IMHO such a hack could be done on a particular user’s system by means of a dummy item and a rule. But it must not be done opaquely hardwired in the binding code.
See this…
I agree with you. 
I slept on it, and it’s a bad idea for the simple reason that you can"t apply the color temperature until after switching on, thus flickering will happen - as it was pointed out for the rule. It just took me longer to get to that conclusion. The only path forward is requesting Signify to reintroduce this feature.
1 Like
Hi there,
I am currently on the way of setting up my many Hue devices in OpenHABian / OH 4.0.3.
In my Hue Bridge (the physical device in this case), I have extensively used the All4Hue app to create tailored automations and triggers.
A cool and easy interface of these automations to the outside world are virtual number sensors and virtual truth sensors. You can basically do whole mode-switches, takeovers of dimmer by OH, blink triggers and many more cool things with them.
Although using the way more modern API v2 for more or less all actions, I found this kind of virtual sensors are only supported by the Hue API v1 binding (they are shown under “ignored” by default). This is how I use them at the moment…in parallel to the API v2, and as I read and write them a lot, I need them fast, so the default 2Hz / 500ms update rate is just sufficient.
Nevertheless, although it’s far from overloading the bridge itself, it causes a quite sensible lag in the v2 API (a dimmer switch may take 1s more with the API v1 enabled in parallel).
Having the virtual sensors in the API v2 would elegantly solve all these troubles. But… I tried a lot of copying UIDs, resources, numbers and many more. I spent hours of searching. Either I’m blind, unlucky, or it really isn’t possible with the API v2. I would be very grateful for any help!
Indeed.
Could we get a channel added to the bridge to clear the command queue or a switch item to not wait for responses on either the global bridge or individual things / channels?
Im using openhab to randomise lights on a short timer but depending on system load / network conditions etc it backs up sometimes.
Result is, even if the timer has been cancelled and lighting restored to pre-randomisation scenes there’s can be a huge queue where it waits for responses.
No biggy if not, I’ll fork the binding just for this use case, but feel this could be a very useful addition (there’s tons of posts for this use case and even music sync which would then also be possible)
As far as the binding us concerned, neither is there a command queue to clear, nor is it waiting for responses. So short answer: no 
How do the apps that do music sync handle the huge change in states? Is there anything in the api to disable sending state updates?
I’ve monitored in logs and it’s around 4-5 seconds to get an update on state after it’s pushed, what’s the main over head?
No.
You need to be more precise here. What are you logging? If the bridge is taking that long to send a state update, then there is something wrong in the bridge (perhaps overloaded) that OH cannot do anything about. If OH is taking that long to process the update then there is something wrong in your OH PC (perhaps overloaded).
Yeah sorry, a little bit vague and off the cusp…
It’s probably more a limitation to the amount of data being sent over zigbee and how fast the bridge can process it.
Not dived deep enough but changing 20 lights at once obvs bogs it down:
- server load is minimal
- the state changes get processed by the system nigh on instantly
- callback/received state back from the bridge (the RGB is always a little different to that sent) takes a few seconds to return (traced this with some logging)
And as tested, if I’m sending 20 light updates every second or two, when I eventually cancel and null the timer, there is still a queue of updates somewhere that continue to get processed (hence I believed there may be some form of queue within the binding)
What id really love to know… will the entertainment side of things be added? As in this:
Having a quick skim it can do 20 commands each message over UDP at approx 4 messages per second. It processes other commands in the background for when the streaming is disabled