Philips Hue CLIP 2 API v2 Discussion Thread

Add-ons Bindings
484

Hi @AndrewFG :
I finally get some time to migrate the remaining to API v2. What’s left are all Hue Lab effects (colorloop and sunset). I plan to use “PRISM” for colorloop and write a small script to do sunset (should be simple as I have one for sunrise :slight_smile: )
I also need to bind some actions to the dimmer switch, with Hue Lab it’s possible to configure long press, I guess now I have to implement as a rule in OH. I checked the document and find the following button event: DOUBLE_SHORT_RELEASE=4. I assumed it was for double click however I can’t seem to get it work, do you know if it’s because Dimmer Switch doesn’t support it?

485

I think the easiest way for you would be to look in the OH events log, which should show all the events that are triggered when any particular button is pressed or released in any particular manner.

1 Like
486

Hi thanks for your reply! I have a rule that listens to all triggering events and print them in log, and I can confirm double click for dimmer switch is indeed not supported.
Anyways good news to report, I managed to migrate to V2 API, and so far very happy with the result. The only minor thing I’m missing in Hue Lab is the possibility of grouping lights for a particular effect. For example with Hue Lab I can group all my spot lights to run colorloop effect, with the PRISM I can only send it to individual light. I have a switch that controls play/stop prism effect on a group of spot lights, with rules:

  1. When switch is on/off I start/stop the effect on all lights
  2. When a particular spot has effect on/off I sync the state to the switch

Clearly for (2) there is a problem in case the spots are out of sync (some have effect on and some have off).

487

Please check if such function is possible in the Hue App – excluding Hue labs; if it would be possible in the normal App and not yet possible in OH then, if you can describe how you achieved it, it would probably be possible to do the same in OH.

1 Like
488

Hi @AndrewFG : sorry I was too quick. I must admit that I don’t play with Hue App enough. Anyways I learned the trick to create a Scene in a room for the lights to have the same effect. So I guess I just need to figure out how to use the binding to send Scene to the room :slight_smile:

Edit: I can even add the scene to Apple Homekit so no need to implement rules in OpenHAB

489

… or you can use a rule in OH as in this post…

490

Ok, I’d like to withdraw what I wrote about exporting Hue scene to HomeKit, it’s simply not working for effects. As soon as I turn on lamp for other purpose, I can no longer start playing effect from HomeKit, the scene just turn on the light and stays the same colour.

491

Hi @AndrewFG : sorry to bother you with another question related to the auto-discovery of the binding. I have ignored all rooms/groups in inbox, however looks like every time when OH restarts, the binding re-adds them to the inbox:

2024-08-13 11:08:18.809 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:room:xxxxxxxxxxxxxxx:xxxxxx-616c-4296-9489-xxxxxxxxxxxx' to inbox.

Is there anyway to disable detecting Things which are already ignored?

492

I believe it is normal to continue to detect things (even if they have been ignored). The act of ignoring a thing means that it will only be displayed in the inbox if the “show ignored things” checkbox is checked.

493

Thanks for your reply!
The strange thing is, those things were already ignored, but after restart they are re-added to the inbox and appear not ignored (and they’re gone from the ignored list).
So looks to me that they’re first removed (so ignored state was not preserved) then re-added.

494

I am not able to replicate this behaviour. Can you please provide more details about the thing definitions as well as logs etc.?

495

I cannot find anything special in the log file except for the following:

2024-08-17 13:18:47.692 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:zone:xxxxx:xxxxx-xxxxx-xxx-xxxxx-xxxxx' to inbox.

I have seen something similar from other binding, so I assume it’s not the root cause.
I have a Hue.things configuration file generated from the binding which only contains lights (no room or zone). Could that cause the detection thinking those rooms/zones are new ?

496

You will always see that message in the log. Notwithstanding the message, it does not really mean that the thing has been added to the inbox :frowning: – rather it means that the thing was discovered again … and …

  • if it is already in the inbox: it will not be added again
  • if it is already in the inbox plus marked as ignored: it will not be added again
497

Thanks for your reply!
How can I check why it decides to add them to the inbox again? (should I turn on debug?)
Does the Hue.things configuration file (without those items) could affect the decision?

1 Like
498

You could try that.

499

Ok, I couldn’t find any trace in the log so I give up. It just keep adding rooms to inbox despite the rooms are already ignored. I guess a solution could be add all rooms to Things. Anyways it’s not a big deal.

I’d like to report another issue though, not sure if something related to the binding or my rules. I have created a switch to enable PRISM effect in HomeKit, below are the rules:

rule "Send colorloop effect to Hue"
  when 
    Item Mias_room_colourloop_switch changed
  then
    if(Mias_room_colourloop_switch.state == ON) {
      logInfo("TESTING", "Send PRISM to HUE")
      Mia_room_wall_lamp_effect.sendCommand("PRISM")
    }
    else {
      logInfo("TESTING", "Send NO_EFFECT to HUE")
      Mia_room_wall_lamp_effect.sendCommand("NO_EFFECT")
    }   
end

rule "Receive colorloop effect from Hue"
  when 
    Item Mia_room_wall_lamp_effect changed 
  then
    if(Mia_room_wall_lamp_effect.state == "PRISM") {
     logInfo("TESTING", "Send ON to colorloop")
      Mias_room_colourloop_switch.sendCommand(ON)
    }
    else {
      logInfo("TESTING", "Send OFF to colorloop")
      Mias_room_colourloop_switch.sendCommand(OFF)
    }
end

Here is the problem, when I turn off the effect, it sends NO_EFFECT to hue, but immediately after I received PRISM effect from the channel, which cause to turn on the switch, this caused the effect cannot be turned off (and same when I turn on). From the event log:

2024-09-10 09:38:40.995 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Mia_room_wall_lamp_effect' received command NO_EFFECT
2024-09-10 09:38:40.998 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Mia_room_wall_lamp_effect' predicted to become NO_EFFECT
2024-09-10 09:38:40.999 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Mia_room_wall_lamp_effect' changed from PRISM to NO_EFFECT
2024-09-10 09:38:41.144 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Mia_room_wall_lamp_effect' changed from NO_EFFECT to PRISM
2024-09-10 09:38:41.147 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Mia_room_wall_lamp_effect' received command PRISM
2024-09-10 09:38:41.151 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Mia_room_wall_lamp_effect' predicted to become PRISM
2024-09-10 09:38:42.153 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Mia_room_wall_lamp_effect' changed from PRISM to NO_EFFECT
2024-09-10 09:38:42.153 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Mia_room_wall_lamp_effect' changed from NO_EFFECT to PRISM

From the openhab.log:

2024-09-10 09:38:40.994 [INFO ] [rg.openhab.core.model.script.TESTING] - Send NO_EFFECT to HUE
2024-09-10 09:38:41.000 [INFO ] [rg.openhab.core.model.script.TESTING] - Send OFF to colorloop
2024-09-10 09:38:41.145 [INFO ] [rg.openhab.core.model.script.TESTING] - Send ON to colorloop
2024-09-10 09:38:41.147 [INFO ] [rg.openhab.core.model.script.TESTING] - Send PRISM to HUE
2024-09-10 09:38:42.153 [INFO ] [rg.openhab.core.model.script.TESTING] - Send ON to colorloop

I also noticed that the binding triggers the execution of rule multiple times despite that the effect stays the same. Does the binding poll the effects periodically? Or does Hue report the current effect before making the change?
Appreciate your input on this!

500

Hmm. Your code is pretty obviously an infinite loop between the two rules (independent of the Hue binding).

Indeed you seem to be lucky that there is something in OH which (by chance) is preventing that infinite regression.

I suggest to introduce a global state variable outside your two rules to eliminate the regression. e.g. ‘if wasPrismAlreadySet then return’

501

Hi @AndrewFG : thank you for your reply! I don’t think my rule introduce any loop unless I have a wrong understanding of how “Item xxxx changed” trigger works.
I’m syncing state of a switch to the effect, when switch in turned on (from off), it sets PRISM effect, which should trigger the other rule as the value changed from “NO_EFFECT” to PRISM, which then sets the switch to on. Note that here first rule will never be executed again as there is no change to the switch state.

What I have observed is that when changing between effects, the item quickly flip between old and new value. For example when I change from NO_EFFECT to PRISM, what I can see in the log:

  1. It predict to be PRISM and change to PRISM
  2. After 200ms the effect item changed back to NO_EFFECT (I have disabled the 2nd rule so no command/update being sent by the rules engine)
  3. Then it quickly flip back to PRISM

This might just be the way how Hue works, the simple solution I find is to set autoupdate=“false”.

502

Maybe this is similar to this:

which only fixed the issue I had with light channels.

503

Yes that would work. Or any other method to debounce state changes from OH…