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

remisharrock · January 18, 2025, 10:47am

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 ?

AndrewFG · January 18, 2025, 5:40pm

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.

AndrewFG · January 18, 2025, 6:11pm

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.

remisharrock · January 19, 2025, 11:24pm

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).

AndrewFG · January 19, 2025, 11:36pm

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.

remisharrock · January 19, 2025, 11:45pm

"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 ?

AndrewFG · January 20, 2025, 8:48am

No.

remisharrock · January 20, 2025, 12:05pm

I see you are the author of the Clip2Bridge class.

What I saw is (for api V2):

First a Throttler here

github.com

openhab/openhab-addons/blob/d0b918e448186a46228332131be75162b4b30d4d/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/connection/Clip2Bridge.java#L489


      
          /**
           * @param permitCount indicates how many stream permits to be acquired.
           * @throws InterruptedException
           */
          Throttler(int permitCount) throws InterruptedException {
              this.permitCount = permitCount;
              streamMutex.acquire(permitCount);
              long delay;
              synchronized (Clip2Bridge.this) {
                  Instant now = Instant.now();
                  delay = Objects.requireNonNull(lastRequestTime
                          .map(t -> Math.max(0, Duration.between(now, t).toMillis() + REQUEST_INTERVAL_MILLISECS))
                          .orElse(0L));
                  lastRequestTime = Optional.of(now.plusMillis(delay));
              }
              Thread.sleep(delay);
          }
          
          @Override
          public void close() {
              streamMutex.release(permitCount);

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

github.com

openhab/openhab-addons/blob/d0b918e448186a46228332131be75162b4b30d4d/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/Clip2ThingHandler.java#L132


      
          private static final int FLAG_CHANNELS_UPDATE = 8;
          private static final int FLAG_SCENE_ADD = 16;
          private static final int FLAG_SCENE_DELETE = 32;
          
          /**
           * A map of service Resources whose state contributes to the overall state of this thing. It is a map between the
           * resource ID (string) and a Resource object containing the last known state. e.g. a DEVICE thing may support a
           * LIGHT service whose Resource contributes to its overall state, or a ROOM or ZONE thing may support a
           * GROUPED_LIGHT service whose Resource contributes to the its overall state.
           */
          private final Map<String, Resource> serviceContributorsCache = new ConcurrentHashMap<>();
          
          /**
           * A map of Resource IDs which are targets for commands to be sent. It is a map between the type of command
           * (ResourcesType) and the resource ID to which the command shall be sent. e.g. a LIGHT 'on' command shall be sent
           * to the respective LIGHT resource ID.
           */
          private final Map<ResourceType, String> commandResourceIds = new ConcurrentHashMap<>();
          
          /**
           * Button devices contain one or more physical buttons, each of which is represented by a BUTTON Resource with its

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