Done 
Here it is.
Thanks for your support again!
Today I had a deeper look at the Java code, and I also tested it on my own system. It seems that my advice to delete and recreate the thing was wrong (or actually overkill).
The scenes list will be automatically refreshed on any of the following events: a) dis-/re- enable the thing, or b) dis-/re- enable the bridge, or c) stop/re-start OH, or d) delete/re-create the thing (overkill).
@Hundertvolt1 can you kindly confirm that the above is indeed true for your case? (In which case we can probably close the Issue on GitHub).
Hi, I just checked the different methods.
The result was somewhat unexpected…
- First test: Add a scene to a room, disable-enable the Thing for the room. Success! The new scene appeared / was commandable.
- Second test: Add another scene, disable-enable the (virtual) Hue Bridge Thing, both v1 and v2. This did not work.
Super strange: disable-enable the room Thing, which worked just before, did not work either, even minutes after the bridges were up again. - From there on, I did not manage to add the new scene, and even deleting the first added scene was no longer possible (deleted in the physical bridge, and still there in the Thing…)
- Also, a stop-start of the openhab service did not update it. A second stop-start now lead to all scene suggestions in the GUI rules to disappear. For all things, not just the one room…
So the functionality seems somewhat there but quite brittle. Let me know if I can do some more tests!
By the way, I used Chrome and re-loaded the page regularly, so it should not be a caching issue…
UPDATE: Some 5 minutes later after the service restart, scenes are back and in sync again!
Is there something like a rate limit how often to query the scenes in place? I did the tests quite quickly, the first try worked, and then the second time it worked was some 10 minutes later - all in between failed, even the known-working ones.
A rate limit would explain this very well…
Hi @AndrewFG and Maintainers 
I am wondering and just curious if the Binding supports the “Hue Play HDMI Sync Box” as well?
I was searching for it in the things inbox - but it’s not there 
Can the sync-box be controlled as well?
Best, Kai
I did not write any code for such devices, so the short answer is “no”.
The longer answer is that, the Hue API v2 does have some ‘entertainment’ API endpoints, as you can see from the link below. BUT from looking at those APIs, it is actually very hard to imagine a use case where OH would interact with them.
I don’t own such a box, so a) I may be the wrong person to imagine potential use cases, and b) unable to test any resulting code. So perhaps @April_Wexler you can have a look at the APIs and let me know what kind of use cases you imagine to have based on them?
Thanks for your fast answer, Andrew.
The use cases are quite simple, e.g.:
- switch on (other lights), if Hue Sync Box was switched off
- reduce brightness of synced lamps after dawn (increase brightness if bright light outside)
- enable Alexa/Siri support via OH: start syncbox, start sync, stop sync etc.
I found in another thread a solution to add the HUE sync box:
https://community.openhab.org/t/philips-hdmi-sync-api/111679/9
After installing and enabling that jar the sync box appeared in OH.
Of course it would be nicer to have all in one binding 
Some API infos are already in the code, but it seems to be APIv1:
https://github.com/Homey-GER/openhab-addons
In fact there is a totally different API for that device.
Hello @AndrewFG,
I have run into some problems I was hoping I could get some help on, please.
I use OpenHAB 4.0.4 with the Hue binding version shipped with OH 4.0.4 and Hue API v2. All configuration is done textually. I previously used API v1 and just switched over. Here is an excerpt of my config files:
.things file
Bridge hue:bridge-api2:dg [ipAddress="...", applicationKey="..."] {
Thing room DG_NZ_Room "DG Nordzimmer" [resourceId="0eae1497-868a-4e00-8793-2defc2a547d2"]
Thing device DG_NZ_Light_Desk [resourceId="ac66600f-7e85-4e27-9c31-e7345e880dd9"]
}
.items file
String DG_NZ_Lights_Scene "Lichtkonzept [%s]" <gluehbirne> (S_DG_Nordzimmer, F_Innenlichter) {channel="hue:room:dg:DG_NZ_Room:scene"}
String DG_NZ_Lights_LightBulb_Desk_Alert "Schreibtisch Alarm" <gluehbirne> (S_DG_Nordzimmer, F_Innenlichter) {channel="hue:device:dg:DG_NZ_Light_Desk:alert"}
.sitemapfile
Selection item=DG_NZ_Lights_Scene mappings=["DG NZ Off"="Aus", "DG NZ Nightlight"="Nachtlicht", "DG NZ White Max"="Weiss", "DG NZ Gaming White"="Gaming Weiss", "DG NZ Gaming Red"="Gaming Rot"]
The problems I ran into are:
- When I toggle through scenes using a Philips Hue Dimmer Switch, Items like DG_NZ_Lights_Scene always have the value UNDEF.
- When I send commands to a scene-channel, like so DG_NZ_Lights_Scene.sendCommand(“DG NZ Off”), it doesn’t do anything.
- When I send commands to the alert-channel of a device, like so DG_NZ_Lights_LightBulb_Desk_Alert.sendCommand(“LSELECT”), it doesn’t do anything.
Could you please help me by telling me what I am missing / doing wrong in these cases?
Thank you very much for your time and effort!
Best regards,
Gregory
Sorry but I don’t understand what you are trying to do here. Can you please explain more?
Is “DG NZ Off” the actual name of a scene? Open the scene channel in Main UI and click on the current scene (it may say UNDEF); it will show you the list of available scene names.
Ditto open the alert channel in Main UI and click on the current alert; it will show you the list of available alerts (probably “BREATHE”)
Hi @AndrewFG,
thanks for the quick reply.
I did use openhab:hue <bridgeUID> scenes and openhab:hue <bridgeUID> things to dump all scenes and things on my two Philips Hue bridges to files and then entered them correctly into my OpenHAB configuration files when I setup API v2. Using BasicUI to for example switch to the scene “DG NZ Off” works like a charm, as I have a scene with that name on the Hue bridge. So the scenes and things are all valid in my configs.
Regarding 1.: I use both OpenHAB to control my lights as well as regular physical Hue Dimmer Switches from Philips in different rooms. Pressing the ON button on the physical device toggles between Scenes, which have all been setup beforehand in the Hue App. Whenever I use the physical device to toggle scenes, I would expect the scene-channel for that room to return the friendly name of the scene I switched to. Instead it always returns UNDEF. This seems like an error to me. I have a workaround in place to detect the correct scene by different means and use postUpdate to set the Item in OpenHAB, but it would be way easier if the scene-channel of the room would return the correct friendly name of the scene I switched to using the physical Hue Dimmer Switch for that room.
Regarding 2.: DG NZ Off is a valid scene’s friendly name, setup by me using the Hue App and returned to me by openhab:hue <bridgeUID> scenes. Switching to it through BasicUI works, but not using sendCommand in rules.
Regarding 3.: same here, the device has an alert channel. But using the sendCommand("LSelect") et al. commands in rules does not do anything.
Thanks for your help. It’s greatly appreciated.
P.S.: for anybody that is curious, DG NZ Off is a scene that turns all lights off (and similarly named scenes for other rooms). To do that, I created a scene in the Hue App and then used WinHue on my PC to edit the scene and disable all lights in the scene as the Hue App does not support that (it wants at least one light to be turned on). This way I can use one Selection item in my sitemap to list all scenes for a room, including Off and don’t have to use a Switch as well as the Selection.
P.P.S: and if anybody wonders. I prefer writing my config in code instead of by the UI. I started that way before the UI was available as a viable alternative and I have all my configs in a Git repository, so that I can go back if need be, use branches when I work on adding new stuff etc.
A few things…
- there is a bug in the OH binding resp. the Hue bridge, when a scene is changed it first sends a message saying the new scene was enabled (which sets the scene name in UI) but it then sends a message saying the old scene was disabled (which sets the scene name in UI to UNDEF). I dont know why they send the disable message after the enable message (it used to be the other way round). But I am working on a fix to reverse the message order so the UI will display the right value.
- in light of the above, is your DG NZ Off really not working? Or just not updating the display?
- as you say DG NZ Off is quite funky can you please post some OH trace logs to show the network activity when you activate this scene?
- maybe also try the scene name in all lowercase and/or uppercase…
PS as I said already LSelect is not an alert name in API v2 … try BREATHE instead.
Is there any update on how to stop BREATHE action beside setting dimming to 0? Is this a limitation of the new Hue API in general or something that just not yet implemented, as the API is new and on the most likely long todo list?
My use case is, that a light is already on, I want to send BREATHE, stop it and the light should continue to stay ON (as it was on before).
Thanks already for your work
It stops automatically after 15 seconds. And returns to its prior state.
Yes, your right, but that was not what I wanted to ask.
Sorry if the post before was unclear.
I wanted to ask if it’s possible to stop it prior to the automatic stop (like it was possible with the leffect from v1 API, where you could send NO_EFFECT if I remember correctly)
The two currently supported alerts are BREATHE and NO_ACTION. I did not try it, but possibly sending the latter to the channel may pre-emptively stop the former. Please let me know.
I have send the NO_ACTION command a few seconds after the BREATHE, but the lightbulb continues with the BREATHE action.
I have tested this with hue bridge software v1.61.1961076030 and a hue color lamp LCA006 with software 1.104.2
Hi Matthias,
same here. I used LSelect with API1.
With API2 I am unable to stop the Alarm Blinking (BREATHE) earlier.
In the meantime I accepted for myself that it is blinking for 15 seconds
If you find a solution how to stop BREATHE earlier, please let us know.
Ok. Thanks for the feedback. I think this is just the way it is; and it is not something that the OH binding could change.
1 Like