In the 1.x version of the hue binding we were able to set the state polling with
hue:refresh=10000
However I don’t see it documented in 2.x binding, nor can I find the source code for the 2.1.0 hue binding in the openhab2-addons git repo to look it up.
Did somebody figure this out? I need faster updates than the default (10 seconds?).
For anybody finding this topic later and is using text files, you can probably (I didn’t test it yet) modify the polling interval by adding pollingInterval="5" to the bridge thing definition, i.e.:
Also while I asked this, I realized that there’s a better way to solve this than to hammer the bridge with generic queries.
Whenever I request a state change I can quickly query again the state of the light and if it doesn’t match, resend it. It seems that my commands don’t reach some far away bulbs all the time, despite the bridge replying with “success” to them.
Hi, can you please show me the commands you used in order to achieve that?
In fact I have an idead to do it with a sleep timer but then it means that the whole function is blocked and I want to make sure that if it cannot reach the Hue bulb, that the rest of the functions will continue working.
I did not solve it yet, just got the idea for it. I can share it when it’s working. For now I can sketch it up. I use an extra switch for controlling the light from within openHAB and don’t really care for the real items state, because of the slow updates from the bridge.
rule "Room Light Control"
when
Item room_light_command received command
then
if (receivedCommand == ON) {
sendHttpPutRequest('http://x.x.x.x/api/xxxx/lights/7/state', 'application/json',
'{"on": true, "transitiontime": 4}')
// here do a "Thread::sleep(500)" -- or a bit more than 500 ms, have to figure it out,
// to allow the hue bridge to update the state of the light
// do a "sendHttpGetRequest", and parse the json to check if the "on" is true
// resend the Put request if necessary, maybe do a loop around here
}
else {
// same for OFF
}
end
… or just blast out the “on” request a couple of times to increase the odds it arrives, in case the bridge fakes the status to on until some polling happens internally too. I didn’t test it yet.
Instead of the sleep, we can actually use createTimer, but I think it’s fine to lock the thread a bit as it’s only doing this one thing.
I’m having a separate watchdog for light that remain off/on after a command, but that’s too slow, as I’m running it only every 15 seconds and I don’t want to stand in a dark room for up to 15 seconds after the motion sensor activates.
The problem with your rule is that you’re using the same item for setting and checking the value, that’s why
you’re checking if all of them are nonzero, it’s true on the first run
you overwrite all the values with zero, even if they didn’t get received by your bulbs, there’s no time for openHAB to query the new values from the hue bridge, it only happens once every 10 seconds.
your while loop exists because everything is zero, even though it can be nonzero when a bulb didn’t receive the command and gets finally polled by openHAB
I would recommend creating a separate item for setting the values and one for checking (for each bulb).
Part of the reason I’m using direct sendHttpPutRequest is to be able to more accurately use the possibilities of the hue bridge. If you want to control multiple lights for example, it’s useful to create “groups” of them, see here. And then you can send the same changes to all three bulbs with one command. But that is not the issue with your rule though.
If you would send the command directly to the bridge, you could query & send the values from the openHAB items until they match though.
I tried this but it doesn’t do anything:
rule "Bureau rue lumiere froide"
when
Item e2_chambre_rue_boutton_virtuel_lumiere_froide received command
then
sendHttpPutRequest(‘http://192.168.0.111/api/ZzSuumxSfih6j7-mzAAxcX5xO1BsFiA4dvyp8LTY/groups/4’, ‘application/json’,
’{“action”: {“bri”: 10,“ct”:10}}’)
end