[hue] Support to activate scenes

[leluna]

I think the ability to activate scenes is really essential for hues. Although I've seen some tutorials on how to do this, none of them seem really none-trivial to me. I know that you can create the scenes as rules, but the scenes creator in the hue app is very convenient in my opinion.

[cweitkamp]

FTR: #6044

[regnets]

I just wanted to create an issue regarding this topic. Great to see that someone is already working on scene support. However, I noticed that the PR request isn't there any more (got a 404 on clicking on that link).

So what's the status on this?

Anyway i will add a small bounty for your work leluna.

[regnets]

Bounty added:
https://www.bountysource.com/issues/80067079-hue-support-to-activate-scenes

@leluna: I also created another feature request regarding support for groups/rooms, maybe you are interested in working on this.

[lolodomo]

@leluna : there is a problem to access your PR. But I see in your Git repository that you still have a branch for this PR: https://github.com/leluna/openhab2-addons/tree/huescene
Your change is relatively basic and could be reviewed probably relatively quickly. Could you create a new PR ?

[cweitkamp]

@leluna @lolodomo code-wise PR #6044 is reviewed and fine. We are missing a piece of documentation (see #6044 (review)). If you cannot access it here is my last comment:

Would you be so kind and add some information to the README.md? I am not really sure which commands I have to send to the new channel. Do you think it is possible to add dynamic state options for it? I will test the new feature in the next couple of days.

[lolodomo]

@cweitkamp : any idea why I can't access this PR ? It shows me the Ooops page.

[cweitkamp]

No, sry. It happens in my phone too.

[DerOetzi]

I can't open the PR as well -> Ooops Page

[lolodomo]

I am waiting first the merge of my PR #7539 and then I will submit an alternative PR to @leluna PR including an update of the documentation. In addition to the channel, we could consider a thing action too.

[leluna]

Strangely, even I myself cannot open the pull request :D I added a little documentation as well as example item/sitemap config, saw your message too late. Did not add the activation of a scene for a specific group though. Thanks for the support for groups btw!

[lolodomo]

Cool, you are still there.
When I use the hue app, it looks like a scene is attached to a group/room. So it would make sense to move your new channel from the bridge thing to the group think type ?
How the user can identify the scene id ? Is it the scene name we see/set in the hue app ?

[leluna]

Practically, you MUST select a group to create a scene, so it actually doesn't matter which group it applies to upon activation, as the scene is uniquely identified by the ID. If you then activate the scene for the wrong group, nothing happens, so it's essentially the same as activating it with group 0. It is only useful for subgroups / overlapping groups, e.g. in a house with multiple floors? Moving the channel to groups better fits the hue app design though, gonna do that I guess :)

The scene ID is a internal technical ID assigned by the hue bridge (I added that in the readme), sadly not the scene name... I use the REST API to directly query the scenes (also in the readme).
I use the scene channel as a switch in the sitemap, with only few common scenes I use, so it doesn't really matter to me. However, dynamic state options would probably be really nice if someone use many scenes, or in the paper UI. I don't quite understand the machanism yet... Also, it's maybe better to do that as a separate feature?

[lolodomo]

Practically, you MUST select a group to create a scene, so it actually doesn't matter which group it applies to upon activation, as the scene is uniquely identified by the ID. If you then activate the scene for the wrong group, nothing happens, so it's essentially the same as activating it with group 0.

Ok, but do you have a request to get the available scenes for a particular room ? If we have, we should add a scene channel to a group thing type.

The scene ID is a internal technical ID assigned by the hue bridge (I added that in the readme), sadly not the scene name... I use the REST API to directly query the scenes (also in the readme).

If it exists a REST API to get the scenes, we should use it to build a dynamic option provider for the "scene" channel at the bridge level and if possible at the group level.

However, dynamic state options would probably be really nice if someone use many scenes, or in the paper UI. I don't quite understand the machanism yet... Also, it's maybe better to do that as a separate feature?

No because it is very easy to add. Just provide the hue API and I will help you.

Regarding your PR, I would suggest that your create a new PR based on the last code merged.

[leluna]

Ok, but do you have a request to get the available scenes for a particular room ? If we have, we should add a scene channel to a group thing type.

I linked the REST API in the readme as I don't want to duplicate the Hue documentation. The REST path is simply /api/username/scenes. There is no reqeust to get the scenes for a particular room, you can only request all scenes.

Theoretically, there are also LightScenes instead of GroupScenes. If you want to activate a LightScenes for all lights belonging to the scene, you have to use the group 0. Do you think we should leave the bridge channel in for that purpose? Or remove the brdige channel and add to readme that the group 0 should be used for that? All scenes created in the hue app are group scenes as far as I understood correctly.

Regarding your PR, I would suggest that your create a new PR based on the last code merged.
It is based on the latest 2.5.x branch. I looked at your new change quickly and saw that I accidentally did it too :D So it should be quite easy to rebase once your change is merged.

[lolodomo]

Let me test the get scenes API to look at the result.

Theoretically, there are also LightScenes instead of GroupScenes. If you want to activate a LightScenes for all lights belonging to the scene, you have to use the group 0. Do you think we should leave the bridge channel in for that purpose? Or remove the brdige channel and add to readme that the group 0 should be used for that?

I am not sure yet.

[lolodomo]

Ok, I run the REST request through the binding.

Can you please add in HueBridge a method getScenes() returning a list of class Scene. Filter only the scenes with recycle=false.
In Scene class, declare at least fields id, name and lights.

[lolodomo]

The bridge is keeping a lot of scenes with recycle=true, some scenes which are no more available. I don't know if there is a way to trash them ?

You are right, a scene is linked to a set of lights (not to a group).
For the channel "scene" on the group thing type, we should filer scenes having all lights in this group/room.
We keep the channel "scene" on the bridge thing with no filter on lights, so all scenes will be available (except the ones which are removed). The option label should then be as clear as possible, in particular to distinguish scenes with same name available in different rooms, like "Lumineux" for example.
The option label should contain at least the scene id and the scene name. This will allow a final user to get the id he can then use in a rule for example. For example ""Test (id uzRsDHJwsB3Wo5j)"

[lolodomo]

And the options on channels will be updated by the light polling job.

[leluna]

In Scene class, declare at least fields id, name and lights.
For the channel "scene" on the group thing type, we should filer scenes having all lights in this group/room.

There are LightScenes and GroupScenes. The default scenes as well as the custom defines scenes are all GroupScenes in my case. GroupScene is a new API sinsce 1.28, so older scenes are probably are LightScenes. "Group" seems to be the new dominant concept to me. If you activate a LightScene with a group, it activates all lights in the scenes that are also contained in the group. So I think we should store "group" instead of "lights" and assume "group 0" for all LightScenes.

This impairs the filtering function for LightScenes but I think it behaves more consistently with the hue API?

[lolodomo]

Thinking about it, I thing a clean implementation would be to create a new scene thing type. Auto discovery will be iomplemented to propose each scene in the openHAB inbox. The user will not have to care about the scene id in this case. The scene thing type will have a switch channel to run the scene.

[leluna]

The option label should then be as clear as possible, in particular to distinguish scenes with same name available in different rooms, like "Lumineux" for example.
The option label should contain at least the scene id and the scene name. This will allow a final user to get the id he can then use in a rule for example. For example ""Test (id uzRsDHJwsB3Wo5j)"

Maybe we can even make it formattable? I know from other bindings where you can use placeholders in the sitemap?

[lolodomo]

Maybe we can even make it formattable? I know from other bindings where you can use placeholders in the sitemap?

I was talking about the option label.
But read my last message, I think the proper implementation is rather a new scene thing type.

[lolodomo]

There are LightScenes and GroupScenes. The default scenes as well as the custom defines scenes are all GroupScenes in my case. GroupScene is a new API sinsce 1.28, so older scenes are probably are LightScenes. "Group" seems to be the new dominant concept to me. If you activate a LightScene with a group, it activates all lights in the scenes that are also contained in the group. So I think we should store "group" instead of "lights" and assume "group 0" for all LightScenes.

I just tested the API you provided to me. If there other APIs, I let you check what API has to be used and if you can add a group id in the Scene object.
But I would really like to define new thing objects for scenes rather than having to find a scene id and use it as command in a channel. Let openHAB doing this job.
WDYT ?

[leluna]

Thinking about it, I thing a clean implementation would be to create a new scene thing type. Auto discovery will be iomplemented to propose each scene in the openHAB inbox. The user will not have to care about the scene id in this case. The scene thing type will have a switch channel to run the scene.

That would be quite a huge amount of things.... By default, hue creates the standard scenes (about 6?) for each group upon creation. If you have 3 groups, you would have 24 things already, I don't think that it improves the usability.

[lolodomo]

They will appear in the inbox but the user has then the choice to create or not a thing type.

[lolodomo]

But yes you're right, if the user plans to use most of the scenes in openHAB, this could make too many things to create.

[lolodomo]

So let's continue with the channel and the scene id as command.

[leluna]

Maybe we can even make it formattable? I know from other bindings where you can use placeholders in the sitemap?

I was talking about the option label.
But read my last message, I think the proper implementation is rather a new scene thing type.

Yeah I was also thinking about option label. That could still be done by using dynamic state options / ConfigOptionProvider? The ConfigOptionProvider has a method to retrieve options. Either this method triggers a polling of all scenes from the bridge, or we poll the scenes with the lights and provide it to the method. What I don't quite get is the osgi part of this mechanism... Do we have to expose the BridgeHandler as a @Component and use @Reference in the ConfigOptionProvider??

[lolodomo]

Yeah I was also thinking about option label. That could still be done by using dynamic state options / ConfigOptionProvider? The ConfigOptionProvider has a method to retrieve options. Either this method triggers a polling of all scenes from the bridge, or we poll the scenes with the lights and provide it to the method. What I don't quite get is the osgi part of this mechanism... Do we have to expose the BridgeHandler as a @component and use @reference in the ConfigOptionProvider??

You just have to create a HueStateDescriptionOptionProvider by extending the BaseDynamicStateDescriptionProvider. This will be a component started automatically. Then in your thing handler factory, you reference this HueStateDescriptionOptionProvider component and you pass it as argument to the hue bridge handler. Finally you just have to call stateDescriptionProvider.setStateOptions for your channel with a list of options you will build from your list of scenes.
Look at the Sonos binding as example: class SonosStateDescriptionOptionProvider.
The option label is defined by the binding code exactly as you want but can not be updated by the user.

[lolodomo]

I would suggest a new poll job for the scenes with a lower refresh frequency than for lights, maybe run every 10 or 15 minutes by default. This job will call getScenes, build the list of options and call stateDescriptionProvider.setStateOptions with it. That's all for the scene channel on the bridge thing.

[leluna]

@lolodomo I added the channel to the group thing. However, I cannot test it as the groups are not discovered. If I define them manually, they remain offline. Using a fresh 2.5 SNAPSHOT docker image. Any idea what the reason could be?

[lolodomo]

Enable TRACE logs and you should see what are the groups returned by getGroups() at every poll.
If you have no groups returned by the API, please investiguate what could be wrong in the code.

Edit: still working well for me with a version just compiled from the branch 2.5.x.

[leluna]

Seems like I had duplicate hue binding jars in place as I only changed the file ending of one.... dumb rookie mistake hide face sorry for the confusion!