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

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

bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/connection/Clip2Bridge.java

d0b918e44


      
          /**
           * @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

bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/Clip2ThingHandler.java

d0b918e44


      
          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