Hue room : brightness is erratic vs dimming-only is kind of ok (fewer issues) when increasing decreasing the value (video attached)

Add-ons Bindings
1

Openhab 4.3.2
I have a hue room with 4 lamps (3 play bars and a color bulb).
When I control the room with the brightness channel, the changing is sometimes totally erratic and slow
When I control the room with the dimming-only channel, it is way better, but still could be improved.
Here is a video to show the behavior :

any idea ?

2

You need to remember that the Hue bridge is not a super computer. It is rate limited in terms of both the number of commands it can receive from OH per second, and in the number of state change events it can send to OH per second. So when you ask it to do both at the same time it is doubly rate limited. So basically your test is simply pushing the limits of the poor thing.

Yup.

As mentioned previously elsewhere, the OH architecture defines that the On/Off state, Brightness state, and Color state are non orthogonally combined into a single HSBType state variable. So when you fiddle rapidly with a Dimmer Item connected to the Color channel, then OH is sending a JSON command containing THREE values (OnOff, Dimming, ColorXY) to the bridge. And (therefore) the bridge is responding with THREE state change event values.

By contrast the OnOff Only, Dimming Only, and Color XY Only channels ARE orthogonal. This means that if you fiddle rapidly with such a channel it will send just ONE state command, and receive just ONE state change event value.

For the benefit of those who doubted the need for the xyz Only channels (you know who you are) this is yet another proof that I was right when I insisted that these latter channels must be included.

3

And by the way when you fiddle with a Dimmer item that is connected to such a room/zone then OH sends a pair of Dimming and OnOff state values to the bridge, (which the bridge expands into three pairs of Dimming and OnOff state commands internally to each of the lamps, and it waits internally to receive three pairs of state updates from the lamps), and when that is done the bridge finally sends FOUR pairs of state events to OH … one for each lamp plus one for the whole room/zone.

4

That’s exactly what I was thinking. I had the same problem when using the SLZB-06M (connected via network) instead of the Hue Bridge (I commented the issue here on zigbee2mqtt Lots of 'BUSY' reports · Issue #24249 · Koenkk/zigbee2mqtt · GitHub )
So I was thinking about implementing a kind of QoS, I know MQTT has 3 QoS levels see there : mqtt - npm - I know Hue is about Zigbee not MQTT, but that’s for an example.
Or another idea would be to have an option for “rate limiting” of commands sent by the hue binding to avoid flooding the poor little hue bridge. This “rate limiting” could simply ignore commands (and send a log notification of ignored messages), this option could be “max number of commands per second” , what do you think ?
That would totally solve the problem I encounter in the video (waiting many seconds after the last interaction on the GUI to actually have the real modification of the lamps states).

5

The Hue binding has rate limiting for commands sent to the bridge. And the bridge has rate limiting on state updates sent to OH. The command rate limiter has a queue so that no commands will be lost. And the event rate limiter combines events so that possibly intermediate values may be lost, but the final value always gets through.

6

"has a queue so that no commands will be lost"

I see and I understand now, I would prefer to have the choice of “QoS”, basically the same as choosing between TCP and UDP if I may take this analogy :

  • TCP-like behavior would be: no commands are lost (but one command in the queue might be executed in a very long future, and if the rate of commands is continue and too “high” some command may even never arrive, or the queue would explode - out of memory)
  • UDP-like behavior would be: I don’t care if commands are lost, but I don’t want a command sent 20 seconds earlier to be executed…

Another idea would be to be able to configure the size of the queue and to ignore commands that could not fit in the queue, that would be approximately the same as UDP-like, and would solve the problem also.

Would that be possible ?

7

No.

8

I see you are the author of the Clip2Bridge class.

What I saw is (for api V2):

First a Throttler here

If I understand correctly, you throttle the requests to a maximum of one per REQUEST_INTERVAL_MILLISECS (you fixed that to 50 ms)

also you have a maximum of 3 concurrent sessions in case of PUT ( putResource uses MAX_CONCURRENT_STREAMS = 3 ) and 1 in case of GET ( getResourcesImpl uses the value 1 directly )

What I also saw is that you have a cache mechanism with serviceContributorsCache and sceneContributorsCache

Is the cache mechanism the equivalent of the queue for api V1 ?

Indeed, you were mentionning that

The command rate limiter has a queue

but I can find a queue only for API V1 and not V2 ?

In that case, to implement my idea, do I have to have a limit of a maximum number of elements in those caches ?

It’s just to know where I can start implementing that idea of ignoring commands when there are too many commands arriving at the same time.

Thanks for the help

9

Sorry I dont really understand what you are trying to do? Can you please explain?

10

I want to avoid a situation where a command sent 10 seconds ago is executed, so I’m trying to find a solution to implement that.
Either by ignoring some commands in the queue, another way would be to have a timespamp and timeout for commands. In both cases, the user should have the option to choose between

  • be sure to execute all commands even if they take 20 seconds to be executed
  • do not execute commands if they are executed too late
11

Your hypothetical situation will never happen. The bridge can process about 20 commands per second.

Do you have an actual problem? If so please give exact details and we can discuss.

12

Sure, I have 2 real problems:

  • I have enocean switches (rocker switches) that control all my lights in my house. With the raw_rocker_to_dimmer profile, when I long press the switch there is an INCREASE or DECREASE command every 200ms . I did not understand why after 2 seconds of pressing the brightness control was overshooting, that is, when I released the switch it would continue increasing/decreasing the brightness , sometimes for a few seconds! So it became IMPOSSIBLE to control the brightness correctly : i wanted the brightness exactly when I released the switch. For now I had to deactivate this and only control the ON OFF with the switch because of that. And I control the brightness with my hue app.
  • that’s where I started investigating and I saw that when I use the official Hue App or the Hue essential app, I could change the brighness in a very fluid manner using the sliders. I did the same with openhab and it had the same behavior as described in my video: it’s impossible to control the brightness if you slide it more than 2/3 seconds because the commands are completely out of sync with the interaction with the slider. As you can see in my video, it sometimes takes a few seconds to stabilize the brightness - up to 10 seconds even MORE - this is an UNACCEPTABLE interaction . It does work correctly with the hue official app so I want to implement the same behavior and I want to understand how it works and help fixing that.

is it more clear ?

13

Apropos the sliders: instead of sliding why not try tapping? It generates one command instead of 20…

14

sliders is for sliding. if sliding more than 2 seconds overshoots, then the sliding interaction is broken. This interaction is not broken in the hue official app. Of course I use tapping to bypass this broken interaction, but tapping a slider is not the same as sliding a slider.

Regarding my switches and the INCREASE DECREASE commands every 200ms , I could also imagine a convoluted solution where I inhibit those commands using rules but I would rather fix the problem differently and directly in the hue binding if possible. Anyway, in that case it could be a rule that do not send more than 1 INCREASE DECREASE command every second… imagine how I could do that within a rule ?

15

I understand your issue. But neither the problem nor the fix is in the Hue binding. The issue is that OH sends the commands too fast for the bridge to handle. Any other binding would also have the same problem if you send commands too fast for its API to handle. The solution is probably somewhere in OH core. Maybe the StateFilter profile. Let me think about it.

1 Like
16

To be more specific: what you need is a command rate limit filter. I am hoping there is already such a thing in OH core. And if it is not, and we eventually need to start writing new code, then we should not write code specifically for just one binding, but rather write code that could be applied as a filter on any binding. I am pinging @laursen and @Lolodomo since I think you guys may have some thoughts on this??

17

I did not read the full discussion.
In Basic UI, there is a slider mode where command changes are sent only every 300 ms while sliding. It is appropriate to devices not responding ultra fast.
Maybe it is a mode missing in Main UI ?

18

Interesting. @remisharrock could you please test that?

However I understand that would only be a partial fix. The other part being the issue with up/down buttons sending commands too fast. Or??

19

@remisharrock I don’t recall exactly but I think there is a configuration setting on Items which affects how they follow user inputs. Something like update policy? Can you please experiment with that?

See the Item autoupdate and/or expire parameter settings.

EDIT maybe the following PRs apply?

20

sure I soon as I find some time I will and I will report here , thank you so much !