[hue] Add channel to the hue bridge to activate predefined 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.

As an intermediate solutation, this does not retrieve the list of available scenes, so the user have to provide the scene IDs in e.g. a switch control. (Also haven't written any intergration test yet, as I am quite unfamiliar with the setup.)

The concept is to add the hue as a separate gateway thing to control functionatlities that goes beyond that of a bridge. This approach is taken from the Mi Home addon.

[J-N-K]

Why can't this functionality be added to the bridge thing?

[kaikreuzer]

I fully agree with @J-N-K that this would be the right way to add this functionality.

[leluna]

I first tried to add it to the existing bridge thing and simply could not get it to work. Do you know any add-ons where the bridge also has an additional functionality that I can refer to?

[cweitkamp]

The avmfritz binding implements a bridge fritzbox which has a channel apply_template. But in general it should be nearly the same like adding a channel to a thing.

[J-N-K]

onewire has extensible channels on the bridge.

[andrewfg]

Just so you know, the Hue binding (v2.5 snapshot) causes repeated log messages as shown below. Since the message comes from PersistentInbox, my suspicion as that the problem is inside that Class. But perhaps the problem is in the Hue binding after all ??

2019-09-16 16:27:41.879 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:29:38.061 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:33:43.886 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:35:42.078 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:37:40.293 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:39:30.844 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:42:30.238 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:46:01.237 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:48:33.150 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:50:23.411 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2019-09-16 16:53:49.298 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.

[cweitkamp]

@andrewfg I provided a fix for it (see #6094).

[philippwaller]

As an intermediate solutation, this does not retrieve the list of available scenes, so the user have to provide the scene IDs in e.g. a switch control.

Some while ago I developed a Hue REST-Client in Groovy for my JSR233 use cases. I integrated a simple caching layer to resolve the scene names. You can find the code here. When the setSceneByName method is executed, the client determines the scene ID through the cache entries. If the cache lookup does not produce a result, the cache will be updated and the search restarted.

I think it would be great to handle a Hue group as a Thing. Scenes could then be controlled via a channel of a group Thing. The available channel options/scenes should be explorable via the REST API. In addition, a group thing might have a switch, dimmer and color channel.

Attached is the mentioned Groovy code. Nothing fancy but it does what it's supposed to do in my smart home automation.
https://gist.github.com/philippwaller/c2e1f5558c22e4be8e80b3767dce7467

[martinvw]

@leluna what is the status of this pull request, are you still planning on finalizing it? Are you blocked in any way?

[cweitkamp]

Sry for getting back to you that late.

Do not care about the itest failures. Just ignore them if it is building fine locally. We are aware of that but do not have a solution for it yet.

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.

[TravisBuddy]

Travis tests have failed

Hey @leluna,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.

[TravisBuddy]

Travis tests have failed

Hey @leluna,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.

[TravisBuddy]

Travis tests have failed

Hey @leluna,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.