[hue] Add hue gateway as thing to activate predefined scenes #6043 #7540

leluna · 2020-05-03T12:49:14Z

TravisBuddy · 2020-05-03T12:59:20Z

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.

lolodomo · 2020-05-03T14:41:42Z

Please add WIP, we need to add the dynamic option provider for scene ids before this feature is merged.

Note that https://developers.meethue.com/develop/hue-api/ needs a developer account. This is not a solution for a final user. The final user should not have to determine the scene id.

cweitkamp · 2020-05-04T11:43:17Z

Replaces #6044

TravisBuddy · 2020-05-05T14:21:06Z

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.

lolodomo · 2020-05-08T16:17:24Z

Take care, it does not compile because you forgot @author in your 2 new classes and the header on one of the two new classes.
The changes to apply:

$ git diff  src/main/java/org/openhab/binding/hue/internal/Scene.java
diff --git a/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/Scene.java b/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/Scene.java
index 59b262ca14..b1e7e23060 100644
--- a/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/Scene.java
+++ b/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/Scene.java
@@ -24,6 +24,8 @@ import com.google.gson.reflect.TypeToken;

 /**
  * Basic scene information.
+ *
+ * @author toto - Initial contribution
  */
 public class Scene {
     public static final Type GSON_TYPE = new TypeToken<Map<String, Scene>>() {

and

$ git diff   src/main/java/org/openhab/binding/hue/internal/handler/HueStateDescriptionOptionProvider.java
diff --git a/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueStateDescriptionOptionProvider.java b/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueStateDescriptionOptionProvider.java
index bc4fb03367..7448ca7e42 100644
--- a/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueStateDescriptionOptionProvider.java
+++ b/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueStateDescriptionOptionProvider.java
@@ -1,3 +1,15 @@
+/**
+ * Copyright (c) 2010-2020 Contributors to the openHAB project
+ *
+ * See the NOTICE file(s) distributed with this work for additional
+ * information.
+ *
+ * This program and the accompanying materials are made available under the
+ * terms of the Eclipse Public License 2.0 which is available at
+ * http://www.eclipse.org/legal/epl-2.0
+ *
+ * SPDX-License-Identifier: EPL-2.0
+ */
 package org.openhab.binding.hue.internal.handler;

 import org.eclipse.jdt.annotation.NonNullByDefault;
@@ -10,6 +22,8 @@ import org.osgi.service.component.annotations.Reference;
 /**
  * Dynamic provider of state options for {@link HueBridgeHandler} while leaving other state description fields as
  * original.
+ *
+ * @author toto - Initial contribution
  */
 @Component(service = { DynamicStateDescriptionProvider.class, HueStateDescriptionOptionProvider.class })
 @NonNullByDefault

lolodomo · 2020-05-08T16:53:06Z

Quick test after updating few files to build a jar:

The dynamic options are built on the bridge channel.

The problem I see is that I have no group/room indication. So I have several scenes with the same name (Veilleuse for example) and I don't know for which room the scene applies.
I think the group/room should be determined when possible and when it is not returned by the API, and then displayed in the option label.
You should probably sort the scenes too.
Please suppress the space just after the opening parenthesis (or add a space before the closing parenthesis).

I tested one scene from the UI and it worked as expected. Good.

Remains to implement the additional channel on a group thing type.

lolodomo · 2020-05-08T18:07:12Z

Here are the proposed changes to get the room included in the option label:

$ git diff   src/main/java/org/openhab/binding/hue/internal/handler/HueBridgeHandler.java
diff --git a/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueBridgeHandler.java b/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueBridgeHandler.java
index e368e5cedd..e0c2fb8a7d 100644
--- a/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueBridgeHandler.java
+++ b/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueBridgeHandler.java
@@ -16,6 +16,7 @@ import static org.eclipse.smarthome.core.thing.Thing.*;
 import static org.openhab.binding.hue.internal.HueBindingConstants.*;

 import java.io.IOException;
+import java.util.ArrayList;
 import java.util.Collection;
 import java.util.Collections;
 import java.util.HashMap;
@@ -55,6 +56,7 @@ import org.openhab.binding.hue.internal.FullLight;
 import org.openhab.binding.hue.internal.FullSensor;
 import org.openhab.binding.hue.internal.HueBridge;
 import org.openhab.binding.hue.internal.HueConfigStatusMessage;
+import org.openhab.binding.hue.internal.Scene;
 import org.openhab.binding.hue.internal.State;
 import org.openhab.binding.hue.internal.StateUpdate;
 import org.openhab.binding.hue.internal.config.HueBridgeConfig;
@@ -323,9 +325,39 @@ public class HueBridgeHandler extends ConfigStatusBridgeHandler implements HueCl
         protected void doConnectedRun() throws IOException, ApiException {
             Map<String, String> groupNames = lastGroupStates.entrySet().parallelStream()
                     .collect(Collectors.toMap(Map.Entry::getKey, e -> e.getValue().getName()));
-            List<StateOption> stateOptions = hueBridge.getScenes().parallelStream()//
-                    .map(scene -> scene.toStateOption(groupNames))//
-                    .collect(Collectors.toList());
+            List<StateOption> stateOptions = new ArrayList<>();
+            for (Scene scene : hueBridge.getScenes()) {
+                if (scene.getGroupId() == null) {
+                    // Check whether all lights in the scene belongs to the same room
+                    String sceneGroupId = null;
+                    for (String sceneLightId : scene.getLightIds()) {
+                        String groupId = null;
+                        for (Entry<String, FullGroup> groupEntry : lastGroupStates.entrySet()) {
+                            FullGroup group = groupEntry.getValue();
+                            if ("Room".equalsIgnoreCase(group.getType())) {
+                                for (String groupLightId : group.getLights()) {
+                                    if (sceneLightId.equals(groupLightId)) {
+                                        groupId = group.getId();
+                                        break;
+                                    }
+                                }
+                            }
+                        }
+                        if (groupId == null) {
+                            break;
+                        } else if (sceneGroupId == null) {
+                            sceneGroupId = groupId;
+                        } else if (!sceneGroupId.equals(groupId)) {
+                            sceneGroupId = null;
+                            break;
+                        }
+                    }
+                    scene.setGroupId(sceneGroupId);
+                    logger.trace("Computed room for scene {} ({}): {}", scene.getName(), scene.getId(),
+                            scene.getGroupId());
+                }
+                stateOptions.add(scene.toStateOption(groupNames));
+            }
             stateDescriptionOptionProvider.setStateOptions(new ChannelUID(getThing().getUID(), CHANNEL_SCENE),
                     stateOptions);
         }
@@ -537,7 +569,7 @@ public class HueBridgeHandler extends ConfigStatusBridgeHandler implements HueCl

     private void startScenePolling() {
         if (scenePollingJob == null || scenePollingJob.isCancelled()) {
-            scenePollingJob = scheduler.scheduleWithFixedDelay(scenePollingRunnable, 1, scenePollingInterval,
+            scenePollingJob = scheduler.scheduleWithFixedDelay(scenePollingRunnable, 5000, scenePollingInterval,
                     TimeUnit.MILLISECONDS);
         }
     }

Note that we have to delay a little the start of the scene job to give a chance to get the groups loaded first by the light job.

lolodomo

Few changes required.

....openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/HueBindingConstants.java

lolodomo · 2020-05-08T18:17:18Z

bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/HueBridge.java

+     * @param id the scene to be activated
+     * @throws IOException if the bridge cannot be reached
+     */
+    public CompletableFuture<Result> activateScene(String id) {


Suggestion: runScene

How about recallScene? That would be consistent to the hue API

...enhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/HueThingHandlerFactory.java

bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/Scene.java

lolodomo · 2020-05-08T18:38:24Z

...rg.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueClient.java

+     *
+     * @param id the ID of the scene to activate
+     */
+    void activateScene(String id);


Suggestion: runScene

-> recallScene

lolodomo · 2020-05-08T18:40:15Z

...nhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/handler/HueGroupHandler.java

@@ -24,6 +24,7 @@
 import org.eclipse.smarthome.core.library.types.IncreaseDecreaseType;


Please move all the changes on this class in a different PR because they have no link with the current feature added.
If you want to push these changes, I would suggest that you consider the hue light handler too because the code is very similar.
It makes no real sense to make it different in one place only.

The scene channel is added to groups here. When navigting through the class, I think these are quite minor changes that improved the readability of the code greatly for me. Is it of importance that the two classes are kept similar (except for the case that someone want to refactor both class)?

This will not help the maintenance if this is coded differently in the different classes.

...rc/main/java/org/openhab/binding/hue/internal/handler/HueStateDescriptionOptionProvider.java

lolodomo · 2020-05-08T18:42:15Z

bundles/org.openhab.binding.hue/src/main/resources/ESH-INF/thing/channels.xml

+	<channel-type id="scene">
+		<item-type>String</item-type>
+		<label>Scene</label>
+		<description>The scene channel allows activating a scene to all lights that belong to the scene.</description>


Suggestion: running

-> recalling

lolodomo · 2020-05-08T19:05:38Z

And for implementing the new channel on the group thing type, you will need a new interface ScenesStatusListener that will be implemented by the HueGroupHandler and with the method onScenesChanged called by the bridge in the scene polling job. The method could be:
void onScenesChanged(@Nullable HueBridge bridge, List<Scene> scenes);
Of course, the group handler will consider only the scenes for its own group and ignore the others.
Your HueStateDescriptionOptionProvider should also be passed to the constructor of the HueGroupHandler.

I am just asking myself if we should avoid rebuilding the options when there is no change in scenes.

lolodomo · 2020-05-08T22:57:15Z

As I can see in the code, there is still something missing to build the options for the channel on each group thing.

And please consider setting the group id for scenes when it is not returned by the API. My proposal only sets it when all lights are in the same room. Without that included, the scenes are not usable with the bridge v1 because several scenes have the same name.

lolodomo · 2020-05-09T10:09:48Z

@leluna : on the group thing, of course you can define a pattern for the option label without the group name.

lolodomo · 2020-05-09T10:15:53Z

Regarding the scene ids, one alternative could be to not display it in the option label but give a way to the user to retrieve it in another way. It could be done through a console command like for example: smarthome:hue <thingUID> scenes

lolodomo · 2020-05-17T09:56:09Z

@leluna : do you have some time to finish this new feature ?
Do you need help (I can push something to your repo for your review and merge) ?
What about my idea of a console command to list the scenes with their id that would avoid the display of a bid id in UI ?

leluna · 2020-05-17T15:33:58Z

@lolodomo Sorry for the long pause, finding time is more difficult than I thought... Also, sthe group API is more complex than I thought... I will try to finish the group state option as soon as possible.

I would like to avoid computing the group ad hoc. Computing the group ad hoc seems like added complexity for only legacy versions to me. As the backend API is more stable than the frontend app in general, I think we should stick to the API whenever possible for future maintenance.

Concerning the global scene label: I would propose to only display the group name if it is defined for a group. The reason is that the group that it belongs to is not well defined in general. There are three types of group: light group, room and zone. I fail to see why we should display only the room that it belongs to, but not zones and light groups.. A zone be defined by the lights of exactly one room. Also, it is possible to define zones with exactly the same lights.... Sure we could imply that undefined group ID only exists for legacy versions, but that is not true. Anyone or any product that uses the API directly can create scenes using the API without group ID, with LightScene being even the default.
For users of older versions, that would render the global scene channel rather unusable. However, they can use the group scene channels instead.

Concerning the group scene label: I would propose to include a scene if the group includes AT LEAST ALL lights of the scene. If we want to be consistent to the hue API, the scene would be applicable to the group already if the group includes AT LEAST ONE light of the scene. However, that would mean that a room in a zone would also display all scenes of the zone, which is strange to me.. Only including the scene if the lights are an EXACT match to the group seem rather far from the API tho me. Thus, this solution would offer only a subset of the hue API functionalities, but a superset of the current hue app functionalities (I think?!).
The problem: anyone or any product that creates scenes using the API directly would be missing functionalities. For example: Using the API, you can define only ONE scene that contain all lights, than only activates it for certain groups/rooms. (Which seems so much more sensible to me than the hue way to create all default scenes for each room -.-) This configuration would not be usable with the this implementation.... Also, if hue decides to switch to this way in the future, which they easily can, as it does not change the API itself at all (only the app), we would have to change the hue binding although the hue API did not change...

Concerning the console command: I think that would be great! That would make the label a lot shorter. Also, I can only copy paste the ID by using developer tools in the browser right now =.= I think it is much quicker if you implement the console command. The most agile solution would be probably delivering the scene feature without ID (still usable via paper UI), and you add the console command as a new feature? Or should I leave it in the label, and you remove it with the console command feature?

Sorry for the HUGE amount of text... I thought it would be better for all me considerations to be documented somewhere... And thanks for the help again and again!

lolodomo · 2020-05-17T17:29:54Z

Sorry for the long pause, finding time is more difficult than I thought...

Ok, no problem.

I would like to avoid computing the group ad hoc. Computing the group ad hoc seems like added complexity for only legacy versions to me. As the backend API is more stable than the frontend app in general, I think we should stick to the API whenever possible for future maintenance.

Concerning the global scene label: I would propose to only display the group name if it is defined for a group. The reason is that the group that it belongs to is not well defined in general. There are three types of group: light group, room and zone. I fail to see why we should display only the room that it belongs to, but not zones and light groups.. A zone be defined by the lights of exactly one room. Also, it is possible to define zones with exactly the same lights.... Sure we could imply that undefined group ID only exists for legacy versions, but that is not true. Anyone or any product that uses the API directly can create scenes using the API without group ID, with LightScene being even the default.
For users of older versions, that would render the global scene channel rather unusable. However, they can use the group scene channels instead.

Why not considering the API version ? I guess the API version is different for a bridge v1 ? In this case, we compute the group.
Or we can add a configuration setting to enable this computation and it could be disabled by default.

If we have the scenes available on each group thing, the feature would be usable. If not, that full feature is simply useless for owners of the bridge v1 while we could make it usable.

Concerning the group scene label: I would propose to include a scene if the group includes AT LEAST ALL lights of the scene

Make sense to me.
That means a scene with lights of different rooms will be only available on the bridge thing.

Concerning the console command: I think that would be great! That would make the label a lot shorter. Also, I can only copy paste the ID by using developer tools in the browser right now =.= I think it is much quicker if you implement the console command. The most agile solution would be probably delivering the scene feature without ID (still usable via paper UI), and you add the console command as a new feature? Or should I leave it in the label, and you remove it with the console command feature?

Ok, I will provide a separate PR. So please don't put the id in the label but please add a TRACE log somewhere in the code so that the scene ids could be retrieved at least from the logs ... until the console command is added.

lolodomo · 2020-05-17T19:33:27Z

I prepared the addition of the console command for scenes with PR #7664
Once my PR is merged, this would be really easy to add the new command for scenes.

TravisBuddy · 2020-05-18T14:49:23Z

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.

Signed-off-by: leluna <[email protected]>

TravisBuddy · 2020-05-19T20:52:17Z

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.

leluna · 2020-05-19T21:07:04Z

Other problem: The integration test is failing in travis build, and I can't really understand the problem based on the log... Any hint?

lolodomo · 2020-05-24T07:40:15Z

I got a NPE:

09:35:07.850 [WARN ] [hue.internal.handler.HueBridgeHandler] - An unexpected error occurred: null
java.lang.NullPointerException: null
        at java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:469) ~[?:1.8.0_152]
        at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) ~[?:1.8.0_152]
        at java.util.TimSort.sort(TimSort.java:220) ~[?:1.8.0_152]
        at java.util.Arrays.parallelSort(Arrays.java:1113) ~[?:1.8.0_152]
        at java.util.stream.SortedOps$OfRef.opEvaluateParallel(SortedOps.java:158) ~[?:1.8.0_152]
        at java.util.stream.AbstractPipeline.opEvaluateParallelLazy(AbstractPipeline.java:704) ~[?:1.8.0_152]
        at java.util.stream.AbstractPipeline.sourceSpliterator(AbstractPipeline.java:431) ~[?:1.8.0_152]
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) ~[?:1.8.0_152]
        at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) ~[?:1.8.0_152]
        at org.openhab.binding.hue.internal.HueBridge.getScenes(HueBridge.java:886) ~[bundleFile:?]
        at org.openhab.binding.hue.internal.handler.HueBridgeHandler$3.doConnectedRun(HueBridgeHandler.java:326) ~[bundleFile:?]
        at org.openhab.binding.hue.internal.handler.HueBridgeHandler$PollingRunnable.run(HueBridgeHandler.java:127) [bundleFile:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_152]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_152]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_152]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_152]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_152]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_152]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]

It is due to that part .sorted(Comparator.comparing(Scene::getGroupId) in getScenes. It cannot work because I have no group id.

lolodomo · 2020-05-24T07:51:13Z

If I remove this sort, then it looks like the list of scenes is correctly built for each group thing and for the bridge thing.

lolodomo · 2020-05-24T07:56:15Z

On the bridge channel, of course I got only the scene name without any group and so several options with the same label. That is certainly here where my "patch" is required.
But as the channel is usable on each group thing, I can live without the channel on the bridge thing being usable in my case.

lolodomo · 2020-05-28T15:31:30Z

Other problem: The integration test is failing in travis build, and I can't really understand the problem based on the log... Any hint?

Apparently, we don't have to take care about failing travis incremental builds because there is apparently a bug somewhere in the build process when integration tests are present for a binding. What is important here is that the full build of your PR is succeeded.

lolodomo · 2020-05-28T15:35:42Z

Please note that you have to take care that the binding will still be ok if used with the hue emulation binding.

lolodomo · 2020-06-12T06:19:08Z

@leluna : no time to finish?

lolodomo · 2020-06-21T09:11:27Z

I take a look to the hue emulation binding. If I correctly understand, the hue emulation binding is defining a hue scene for each openHAB rule (NGRE ?) having a particular tag...

The recallScene feature from this PR will lead to a failure with the hue emulation binding because it does not yet support "scene" as group state update. That is not really a problem but we just have to check that the returned error will be correctly handled by the hue binding. Then the hue emulation binding could be enhanced to support this new feature.

Ideally, this should be tested by someone using the hue emulation binding but I am confident that this enhancement will not break the use of the binding with the hue emulation binding.

lolodomo · 2020-06-28T07:17:46Z

@leluna : as you are not available, I propose to create my own PR with your code and of course I will credit you. I will rebase the code changes, fixes the NPE and add the missing console command.
And I will be available for reviewers.

leluna · 2020-06-28T16:30:53Z

@leluna : as you are not available, I propose to create my own PR with your code and of course I will credit you. I will rebase the code changes, fixes the NPE and add the missing console command.
And I will be available for reviewers.

Thanks! Really can't find the time to finish it atm. Also, have no clue of the hue simulation binding... The NPE should be fixed already, if I recall correctly. Changed the sort.

Tomibeck · 2020-07-07T14:13:16Z

@lolodomo Hey were you already able to commit or merge something?

lolodomo · 2020-07-07T15:11:17Z

Not yet.
I hoped first the merge of one of my other pending PRs before starting on this.
Unfortunately the review & merge apparently just slow down.

Closes openhab#6043 This is the continuation of the PR openhab#7540 95% of credits go to leluna Signed-off-by: Laurent Garnier <[email protected]> Also-by: leluna <[email protected]>

lolodomo · 2020-07-09T22:22:26Z

@Tomibeck : in case you are interested in this new feature, please move to the new PR, I inserted a jar file for testing.

* [hue] Add support for hue scene activation Closes #6043 This is the continuation of the PR #7540 95% of credits go to leluna Signed-off-by: Laurent Garnier <[email protected]> Also-by: leluna <[email protected]>

lolodomo · 2020-07-13T21:53:51Z

Closed by #8098

* [hue] Add support for hue scene activation Closes openhab#6043 This is the continuation of the PR openhab#7540 95% of credits go to leluna Signed-off-by: Laurent Garnier <[email protected]> Also-by: leluna <[email protected]> Signed-off-by: CSchlipp <[email protected]>

* [hue] Add support for hue scene activation Closes openhab#6043 This is the continuation of the PR openhab#7540 95% of credits go to leluna Signed-off-by: Laurent Garnier <[email protected]> Also-by: leluna <[email protected]> Signed-off-by: MPH80 <[email protected]>

* [hue] Add support for hue scene activation Closes openhab#6043 This is the continuation of the PR openhab#7540 95% of credits go to leluna Signed-off-by: Laurent Garnier <[email protected]> Also-by: leluna <[email protected]>

* [hue] Add support for hue scene activation Closes openhab#6043 This is the continuation of the PR openhab#7540 95% of credits go to leluna Signed-off-by: Laurent Garnier <[email protected]> Also-by: leluna <[email protected]> Signed-off-by: Daan Meijer <[email protected]>

* [hue] Add support for hue scene activation Closes openhab#6043 This is the continuation of the PR openhab#7540 95% of credits go to leluna Signed-off-by: Laurent Garnier <[email protected]> Also-by: leluna <[email protected]>

leluna requested a review from cweitkamp as a code owner May 3, 2020 12:49

leluna force-pushed the hue_scene branch from 733a37c to 2ba1c72 Compare May 3, 2020 12:56

cpmeister added the work in progress A PR that is not yet ready to be merged label May 3, 2020

cpmeister changed the title ~~Add hue gateway as thing to activate predefined scenes #6043~~ [hue] Add hue gateway as thing to activate predefined scenes #6043 May 3, 2020

cpmeister linked an issue May 3, 2020 that may be closed by this pull request

[hue] Support to activate scenes #6043

Closed

cpmeister removed a link to an issue May 3, 2020

[hue] Support to activate scenes #6043

Closed

cweitkamp added the enhancement An enhancement or new feature for an existing add-on label May 4, 2020

leluna marked this pull request as draft May 4, 2020 12:38

leluna force-pushed the hue_scene branch from e73762c to 5a1abf2 Compare May 5, 2020 14:18

lolodomo requested changes May 8, 2020

View reviewed changes

leluna force-pushed the hue_scene branch from 5a1abf2 to 59234ff Compare May 8, 2020 20:56

leluna force-pushed the hue_scene branch 2 times, most recently from c207cda to 62bb6af Compare May 18, 2020 14:45

leluna force-pushed the hue_scene branch from 62bb6af to 35e635a Compare May 19, 2020 06:35

Add dynamic state options to group scene channel

e74bb89

Signed-off-by: leluna <[email protected]>

leluna force-pushed the hue_scene branch from 35e635a to e74bb89 Compare May 19, 2020 20:48

kaikreuzer force-pushed the 2.5.x branch from 536fc42 to 3ab1af1 Compare June 21, 2020 16:12

lolodomo mentioned this pull request Jul 9, 2020

[hue] Add support for hue scene activation #8098

Merged

lolodomo closed this Jul 13, 2020

		@@ -24,6 +24,7 @@
		import org.eclipse.smarthome.core.library.types.IncreaseDecreaseType;

[hue] Add hue gateway as thing to activate predefined scenes #6043 #7540

[hue] Add hue gateway as thing to activate predefined scenes #6043 #7540

Conversation

leluna commented May 3, 2020 • edited by cweitkamp Loading

TravisBuddy commented May 3, 2020

Travis tests have failed

lolodomo commented May 3, 2020

cweitkamp commented May 4, 2020

TravisBuddy commented May 5, 2020

Travis tests have failed

lolodomo commented May 8, 2020

lolodomo commented May 8, 2020

lolodomo commented May 8, 2020 • edited Loading

lolodomo left a comment

Choose a reason for hiding this comment

lolodomo May 8, 2020 • edited Loading

Choose a reason for hiding this comment

leluna May 8, 2020

Choose a reason for hiding this comment

lolodomo May 8, 2020

Choose a reason for hiding this comment

leluna May 8, 2020

Choose a reason for hiding this comment

lolodomo May 8, 2020 • edited Loading

Choose a reason for hiding this comment

leluna May 8, 2020

Choose a reason for hiding this comment

lolodomo May 8, 2020 • edited Loading

Choose a reason for hiding this comment

lolodomo May 8, 2020

Choose a reason for hiding this comment

leluna May 8, 2020

Choose a reason for hiding this comment

lolodomo commented May 8, 2020 • edited Loading

lolodomo commented May 8, 2020

lolodomo commented May 9, 2020

lolodomo commented May 9, 2020

lolodomo commented May 17, 2020

leluna commented May 17, 2020

lolodomo commented May 17, 2020

lolodomo commented May 17, 2020

TravisBuddy commented May 18, 2020

Travis tests have failed

TravisBuddy commented May 19, 2020

Travis tests have failed

leluna commented May 19, 2020

lolodomo commented May 24, 2020

lolodomo commented May 24, 2020

lolodomo commented May 24, 2020 • edited Loading

lolodomo commented May 28, 2020

lolodomo commented May 28, 2020

lolodomo commented Jun 12, 2020

lolodomo commented Jun 21, 2020 • edited Loading

lolodomo commented Jun 28, 2020

leluna commented Jun 28, 2020

Tomibeck commented Jul 7, 2020

lolodomo commented Jul 7, 2020

lolodomo commented Jul 9, 2020

lolodomo commented Jul 13, 2020

leluna commented May 3, 2020 •

edited by cweitkamp

Loading

lolodomo commented May 8, 2020 •

edited

Loading

lolodomo May 8, 2020 •

edited

Loading

lolodomo May 8, 2020 •

edited

Loading

lolodomo May 8, 2020 •

edited

Loading

lolodomo commented May 8, 2020 •

edited

Loading

lolodomo commented May 24, 2020 •

edited

Loading

lolodomo commented Jun 21, 2020 •

edited

Loading