Changes to the Tradfri Binding to discover and use Groups #3799

S0urceror · 2017-07-04T20:14:45Z

I have updated the Tradfri Gateway binding so that it also correctly identifies groups (IPSO: 15004) of lamps bound to a remote. With the update I made they appear in the OpenHab Inbox as new Things. You can bind these to a Switch item.

Now it is easy to switch all lamps within a group on or off. Also it is possible to make a rule that executes when you select On/Off in the remote. Enabling to use the Ikea remotes for other purposes in OpenHAB as well.

…onal Remotes added to empty ones)

sjsf

Thanks a lot for your first contribution! Pretty cool to have native group support.

I left a few comments inside the code - mainly thoughts on whether it is possible to reduce some code duplications.

May I also ask you to sign a contributor license agreement at the Eclipse Foundation and include a "Signed-Off" line in your commit message(s)? (See also our Conventions for Pull Requests).

Unfortunately this is necessary once in order to meet the intellectual property requirements. Rest assured, the next PR is gonna be much easier once this is in place.

sjsf · 2017-07-05T14:18:27Z

extensions/binding/org.eclipse.smarthome.binding.tradfri/ESH-INF/thing/thing-types.xml

+        <description>A group of Tradfri lamps</description>
+
+        <channels>
+            <channel id="group_state" typeId="group_state"/>


do groups really only have an on/off feature, or could we rather reuse the existing brightness channel here? I noticed the return value also includes the "5851" (aka DIMMER) field.

I'll test this.

It's write-only. Don't know if we should include the brightness channel if it behaves like this.

sjsf · 2017-07-05T14:20:35Z

...adfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGatewayHandler.java

            updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.CONFIGURATION_ERROR, e.getMessage());
            return;
        }
+        devices.client.setEndpoint(endPoint);
+
+        // setup GROUPS scanner


As this more or less duplicates the code from above, could you please factor out the common parts into a separate method?

sjsf · 2017-07-05T14:23:19Z

...adfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGatewayHandler.java

-    public void startScan() {
-        if (endPoint != null) {
-            deviceClient.get(new TradfriCoapHandler(this));
+    public class MyCoapCallback implements CoapCallback {


How about naming it TradfriCoapCallback?

sjsf · 2017-07-05T14:24:01Z

...adfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGatewayHandler.java

+        private TradfriCoapClient client;
+        private String gatewayURI;
+
+        MyCoapCallback() {


As this is empty, there is no need to implement it.

sjsf · 2017-07-05T14:28:16Z

...tradfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGroupHandler.java

+ * @author Kai Kreuzer - Initial contribution
+ * @author Mario Smit - Group Handler added
+ */
+public class TradfriGroupHandler extends BaseThingHandler implements CoapCallback {


As there is quite a lot of common code in TradfriLightHandler and TradfriGroupHandler, wouldn`t it make sense to inherit from each other or introduce a common abstract base class which both inherit from? I'm a bit concerned that all this copied code will be hard to be maintained consistently.

sjsf · 2017-07-05T14:35:19Z

extensions/binding/org.eclipse.smarthome.binding.tradfri/ESH-INF/thing/thing-types.xml

@@ -109,5 +129,11 @@
        <description>Allows to control the color temperature of light.</description>
        <category>ColorLight</category>
    </channel-type>
-
+
+    <channel-type id="group_state">


If there are constellations which don't expose a dimmer (5851) but only an ON/OFF (5850) so that this is really needed, I would suggest keeping it group-agnostic, i.e. name it switch and remove all the references to groups from label & description, so that it can be used also directly in case they ever decide to offer a non-dimmable lamp.

I would advocate against this.

Currently Groups are a collection of lamps, a remote and/or a IR switch. And currently not all info of the group is exposed thought the gateway.

We don't know what devices Ikea will launch in the future but I heard rumours about mains-switches and colour bulbs. And hopefully they will also correct the problem of directly listening to the remote device instead of checking the group status.

I am sure this will change the behaviour of Groups extending their current switch behaviour. Remotes will become Switches and Dimmers exposed through the GW.

sjsf · 2017-07-05T14:37:59Z

extensions/binding/org.eclipse.smarthome.binding.tradfri/ESH-INF/thing/thing-types.xml

@@ -69,6 +69,26 @@
            </parameter>
        </config-description>
    </thing-type>
+    <thing-type id="group">


Do groups really differ significantly from lamps (apart from their URL & ID, of course)? Or could they rather be considered as a single lamp? What I want to say with it: Do we really need a dedicated thing-type for them? (And this really is meant to be an open question)

Hi sjka,

I noticed different behaviours (which I will retest) from groups vs lights. In a group with 1 light the remote switches on the group and light within (which changes the brightness). If the brightness of the light is changed I don't see the group brightness changing. Maybe group brightness is only a write only variable. I will check and come back to this.

Confirmed. Group brightness is a write-only variable. Setting it causes all lights to update it's brightness. After this it stays at this value even though we set all lights at another brightness value.

Don't know if we should include it if it has such strange behaviour. What do you think?

sjsf · 2017-07-05T14:40:14Z

...tradfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGroupHandler.java

+    /**
+     * This class is a Java wrapper for the raw JSON data about the group state.
+     */
+    private static class GroupData {


Here again, my feeling from just looking at the code is that TradfriLightHandler.LightData could be reused or at least should be made reusable.

sjsf · 2017-07-05T14:41:07Z

...dfri/src/main/java/org/eclipse/smarthome/binding/tradfri/internal/TradfriHandlerFactory.java

@@ -56,6 +58,9 @@ protected ThingHandler createHandler(Thing thing) {
            return handler;
        } else if (SUPPORTED_LIGHT_TYPES_UIDS.contains(thingTypeUID)) {
            return new TradfriLightHandler(thing);
+        } else if (thingTypeUID.equals(THING_TYPE_GROUP)) {
+            // TODO: Construct Group Handler


left-over //TODO

S0urceror · 2017-07-05T16:42:23Z

Good points. Looks like I have work to do ;-). I'll follow up on you as soon as I complete it.

…

On 5 July 2017 at 16:49:27, Simon Kaufmann ***@***.***) wrote: ***@***.**** requested changes on this pull request. Thanks a lot for your first contribution! Pretty cool to have native group support. I left a few comments inside the code - mainly thoughts on whether it is possible to reduce some code duplications. May I also ask you to sign a contributor license agreement at the Eclipse Foundation and include a "Signed-Off" line in your commit message(s)? (See also our Conventions for Pull Requests <https://www.eclipse.org/smarthome/documentation/community/contributing.html#conventions-for-pull-requests> ). Unfortunately this is necessary once in order to meet the intellectual property requirements. Rest assured, the next PR is gonna be much easier once this is in place. ------------------------------ In extensions/binding/org.eclipse.smarthome.binding.tradfri/ESH-INF/thing/thing-types.xml <#3799 (comment)>: > @@ -69,6 +69,26 @@ </parameter> </config-description> </thing-type> + <thing-type id="group"> + <supported-bridge-type-refs> + <bridge-type-ref id="gateway"/> + </supported-bridge-type-refs> + + <label>Tradfri Group</label> + <description>A group of Tradfri lamps</description> + + <channels> + <channel id="group_state" typeId="group_state"/> do groups really only have an on/off feature, or could we rather reuse the existing brightness channel here? I noticed the return value also includes the "5851" (aka DIMMER) field. ------------------------------ In extensions/binding/org.eclipse.smarthome.binding.tradfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGatewayHandler.java <#3799 (comment)>: > updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.CONFIGURATION_ERROR, e.getMessage()); return; } + devices.client.setEndpoint(endPoint); + + // setup GROUPS scanner As this more or less duplicates the code from above, could you please factor out the common parts into a separate method? ------------------------------ In extensions/binding/org.eclipse.smarthome.binding.tradfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGatewayHandler.java <#3799 (comment)>: > @@ -125,74 +146,83 @@ public void dispose() { super.dispose(); } - /** - * Does a request to the gateway to list all available devices/services. - * The response is received and processed by the method ***@***.*** onUpdate(JsonElement data)}. - */ - public void startScan() { - if (endPoint != null) { - deviceClient.get(new TradfriCoapHandler(this)); + public class MyCoapCallback implements CoapCallback { How about naming it TradfriCoapCallback? ------------------------------ In extensions/binding/org.eclipse.smarthome.binding.tradfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGatewayHandler.java <#3799 (comment)>: > @@ -125,74 +146,83 @@ public void dispose() { super.dispose(); } - /** - * Does a request to the gateway to list all available devices/services. - * The response is received and processed by the method ***@***.*** onUpdate(JsonElement data)}. - */ - public void startScan() { - if (endPoint != null) { - deviceClient.get(new TradfriCoapHandler(this)); + public class MyCoapCallback implements CoapCallback { + private TradfriCoapClient client; + private String gatewayURI; + + MyCoapCallback() { As this is empty, there is no need to implement it. ------------------------------ In extensions/binding/org.eclipse.smarthome.binding.tradfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGroupHandler.java <#3799 (comment)>: > +import org.eclipse.smarthome.core.types.RefreshType; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import com.google.gson.JsonElement; +import com.google.gson.JsonObject; +import com.google.gson.JsonSyntaxException; + +/** + * The ***@***.*** TradfriGroupHandler} is responsible for handling commands for + * individual lights. + * + * @author Kai Kreuzer - Initial contribution + * @author Mario Smit - Group Handler added + */ +public class TradfriGroupHandler extends BaseThingHandler implements CoapCallback { As there is quite a lot of common code in TradfriLightHandler and TradfriGroupHandler, wouldn`t it make sense to inherit from each other or introduce a common abstract base class which both inherit from? I'm a bit concerned that all this copied code will be hard to be maintained consistently. ------------------------------ In extensions/binding/org.eclipse.smarthome.binding.tradfri/ESH-INF/thing/thing-types.xml <#3799 (comment)>: > @@ -109,5 +129,11 @@ <description>Allows to control the color temperature of light.</description> <category>ColorLight</category> </channel-type> - + + <channel-type id="group_state"> If there are constellations which don't expose a dimmer (5851) but only an ON/OFF (5850) so that this is really needed, I would suggest keeping it group-agnostic, i.e. name it switch and remove all the references to groups from label & description, so that it can be used also directly in case they ever decide to offer a non-dimmable lamp. ------------------------------ In extensions/binding/org.eclipse.smarthome.binding.tradfri/ESH-INF/thing/thing-types.xml <#3799 (comment)>: > @@ -69,6 +69,26 @@ </parameter> </config-description> </thing-type> + <thing-type id="group"> Do groups really differ significantly from lamps (apart from their URL & ID, of course)? Or could they rather be considered as a single lamp? What I want to say with it: Do we really need a dedicated thing-type for them? (And this really is meant to be an open question) ------------------------------ In extensions/binding/org.eclipse.smarthome.binding.tradfri/src/main/java/org/eclipse/smarthome/binding/tradfri/handler/TradfriGroupHandler.java <#3799 (comment)>: > + logger.error("Unknown channel UID {}", channelUID); + } + } + + private void handleGroupStateCommand(Command command) { + if (command instanceof OnOffType) { + setState(((OnOffType) command)); + } else { + logger.debug("Cannot handle command {} for channel {}", command, CHANNEL_GROUP_STATE); + } + } + + /** + * This class is a Java wrapper for the raw JSON data about the group state. + */ + private static class GroupData { Here again, my feeling from just looking at the code is that TradfriLightHandler.LightData could be reused or at least should be made reusable. ------------------------------ In extensions/binding/org.eclipse.smarthome.binding.tradfri/src/main/java/org/eclipse/smarthome/binding/tradfri/internal/TradfriHandlerFactory.java <#3799 (comment)>: > @@ -56,6 +58,9 @@ protected ThingHandler createHandler(Thing thing) { return handler; } else if (SUPPORTED_LIGHT_TYPES_UIDS.contains(thingTypeUID)) { return new TradfriLightHandler(thing); + } else if (thingTypeUID.equals(THING_TYPE_GROUP)) { + // TODO: Construct Group Handler left-over //TODO — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3799 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwvKLTk05-YCswJO4magmUyEfy_gZH2ks5sK6J3gaJpZM4ONqS4> .

Signed-off-by: mario.smit.nl@gmail.com

Removing my veto so others can take over reviewing.

sjsf · 2017-07-30T17:57:32Z

Would you mind rebasing your branch please? With the latest merge, this PR became unreadable because it does not only show your changes, but ~14k lines of others.

S0urceror · 2017-07-30T19:07:25Z

I am currently enjoying my holidays. Please bear with me for another 1,5 weeks. I will take care of this asap. On 30 July 2017 at 19:57:34, Simon Kaufmann (notifications@github.com) wrote: Would you mind rebasing your branch please? With the latest merge, this PR became unreadable because it does not only show your changes, but ~14k lines of others. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3799 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwvKKTi2vrMOWbDyJwgPREst25n7qrjks5sTMQOgaJpZM4ONqS4> .

triller-telekom · 2017-08-09T13:38:49Z

While you are changing your commit history anyway, could you please also add a proper "Signed-of-by" statement to them? For this you also need to sign the Eclipse contribution agreement.

Signed-off-by: Mario Smit <mario.smit.nl@gmail.com>

S0urceror · 2017-08-16T12:59:55Z

Have merged with the latest changes of 'master'. I have signed the Eclipse contribution agreement and added the signed-of-by statement. Please check if all is well and pull in the change please.

thelaoshi · 2017-08-17T20:32:35Z

Just tried your build and switching groups on/off works very well. Is it possible to detect motion sensors in this way though? Tried it with one but seems that it doesnt change the group state :-(

S0urceror · 2017-08-18T09:00:28Z

Hi Mike, I don’t have a motion sensor myself but I suspect that the Ikea gateway is not emitting messages from this device (just like the remote) other then the battery status. What I did is with the Tradfri App on my phone is create a Group of lights (which may be empty) and bind the remote to this. From that moment onward you can listen to the (empty) group status updates with my updated binding and know what state the remote is in. Maybe you can do the same with your motion sensor. Bind it to an (empty) group with the App and then listen to the Group events with my updated binding. This way you always know the status of your motion sensor which is where you’re after. Right? Let me know if it works. If not I need to buy a motion sensor myself to see what the GW is emitting and update the binding to listen to those. Best, Mario On 17 August 2017 at 22:32:41, Mike (notifications@github.com) wrote: Just tried your build and switching groups on/off works very well. Is it possible to detect motion sensors in this way though? Tried it with one but seems that it doesnt change the group state :-( — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#3799 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwvKEGgwnU1WUd6Mw4ZxTkV6eClO4vYks5sZKNogaJpZM4ONqS4> .

thelaoshi · 2017-08-18T10:56:34Z

Hey Mario,
that is exactly what I tried, but I get no group status update this way. Tried a group with a sensor and lamps, only with sensor etc.
I have no remote though and cannot test if its working with it. But I can turn off/on the bulbs that are are in a group with the group switch. So basically it should work.
Maybe its just like the dimmer option on the remote.

S0urceror · 2017-08-21T09:05:39Z

Yes I think you’re right. I can research this further if I get a motion sensor myself. With the binding in debug mode I can then better check the log and step through the code to see if we can somehow add the motion sensor to the binding. I’ll update you if I find something out. On 18 August 2017 at 12:56:39, Mike (notifications@github.com) wrote: Hey Mario, that is exactly what I tried, but I get no group status update this way. Tried a group with a sensor and lamps, only with sensor etc. I have no remote though and cannot test if its working with it. But I can turn off/on the bulbs that are are in a group with the group switch. So basically it should work. Maybe its just like the dimmer option on the remote. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#3799 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwvKG4-x5ftG3A13b7xeIatDURkHxN5ks5sZW3mgaJpZM4ONqS4> .

S0urceror · 2017-08-22T07:20:12Z

People looking to try my changes, pending PR, can find them here: https://github.com/S0urceror/tradfri-jars

Place the files in the addons folder. Groups (and lights) should automatically appear in the Inbox of Paper UI

thelaoshi · 2017-08-29T07:00:13Z

Any news here ?

S0urceror · 2017-08-29T11:43:52Z

Hi Mike, I am still waiting for someone to pick up my PR. A couple of weeks ago I performed all the requested things like merging it with the latest head, etc. But nothing happened. What’s the best way to approach this? Should I close this PR and open a new one? Best, Mario On 29 August 2017 at 09:00:19, Mike (notifications@github.com) wrote: Any news here ? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#3799 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwvKIMU_FbA1H6Ds6lr_FZIolnKee3Bks5sc7cBgaJpZM4ONqS4> .

thelaoshi · 2017-08-29T12:00:10Z

good question :-) I'm new to this, too

What i noticed, when I last build the binding is, that the test failed, because of some kind of wrong number of types or sth lilke that. Maybe thats a problem (Mostly i disable the tests) ?

Ah, and is it possible to use newer californium versions etc ? Wonder if they maybe make less problems with the connection to the gateway

sjsf · 2017-08-29T12:06:20Z

Apologies for the delay!

Should I close this PR and open a new one?

No, please don't! That's just add to the chaos we are fighting here...

The Travis PR build detected a test failure:

correctSupportedTypes(org.eclipse.smarthome.binding.tradfri.discovery.TradfriDiscoveryServiceTest)  Time elapsed: 0.025 sec  <<< FAILURE!
java.lang.AssertionError: 
Expected: is <2>
     but: was <3>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:865)
	at org.junit.Assert.assertThat(Assert.java:832)
	at org.eclipse.smarthome.binding.tradfri.discovery.TradfriDiscoveryServiceTest.correctSupportedTypes(TradfriDiscoveryServiceTest.java:84)

I'd suggest that you fix that one first. In addition, as you can see in the failed "IP validation", there are some commits not properly signed-off or having a wrong committer entry. Please fix those - I'd suggest by properly rebasing your branch instead of merging the master into it.

We will have a look as quickly as possible.

openhab-bot · 2017-10-01T17:57:28Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/tradfri-remote-support/34695/3

hreichert · 2017-10-02T11:38:03Z

Hey @S0urceror
do you work on this any further?

S0urceror · 2017-10-06T19:14:18Z

In summer I made it ready to be integrated but somehow it was not picked up by the maintainers. Now it is again behind the current development tree. I’ll try with a new PR soon after I merge it with the current tree. From: Holger Reichert <notifications@github.com> Reply-To: eclipse/smarthome <reply@reply.github.com> Date: Monday, October 2, 2017 at 1:38 PM To: eclipse/smarthome <smarthome@noreply.github.com> Cc: S0urceror <mario.smit.nl@gmail.com>, Mention <mention@noreply.github.com> Subject: Re: [eclipse/smarthome] Changes to the Tradfri Binding to discover and use Groups (#3799) Hey @S0urceror do you work on this any further? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

hreichert · 2017-10-06T19:24:59Z

Your PR was not in a mergable state, see comment #3799 (comment)

cweitkamp · 2017-10-06T19:34:17Z

@S0urceror isn't it possibly to rebase your work to the current master?

Your work is great as well and I can't wait to get it merged into the master branch.

hreichert · 2017-10-06T20:02:02Z

I'm eagerly awaiting the native group support, too!
But my fear is the following:
@S0urceror puts further effort into rebasing/merging, meanwhile #4373 gets merged (with big refactorings?); and then there are new, maybe even bigger, conflicts; and @S0urceror is getting (even more?) frustrated.
Also I think that the implementation of native group support is getting easier, after #4373 is in. So maybe it's better to wait for this PR.

Just my 2 cents, what do you guys think?

And @S0urceror If you need help with something, you can always drop me a mail.

S0urceror · 2017-10-06T20:03:03Z

Yes that’s what I will do soon and raise a new PR to get it included. Groeten, Mario

…

On 6 October 2017 at 21:34:22, Christoph Weitkamp ***@***.***) wrote: @S0urceror <https://github.com/s0urceror> isn't it possibly to rebase your work to the current master? Your work is great as well and I can't wait to get it merged into the master branch. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3799 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwvKGusyhtWQ8ajjGyrBUAvsEWRZtMqks5spoC-gaJpZM4ONqS4> .

openhab-bot · 2017-10-10T11:33:44Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/ikea-tradfri-gateway/26135/135

cweitkamp · 2017-11-12T10:35:16Z

@S0urceror may I come back to you and ask if you like to contribute your implementation for group support based on the refactored code again?

S0urceror · 2017-11-13T17:04:06Z

Hi @cweitkamp,

Of course I can do that. Do you consider the current release stable to reinclude?

cweitkamp · 2017-11-13T18:07:28Z

Yes, I do. Let me know if you need any help.

openhab-bot · 2018-10-07T18:40:26Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/ikea-tradfri-gateway/26135/181

Changes to the Tradfri Binding to discover and use Groups (and additi…

594aea4

…onal Remotes added to empty ones)

sjsf previously requested changes Jul 5, 2017

View reviewed changes

Couple of changes requested by sjka under id: eclipse-archived#3799

de202b4

Signed-off-by: mario.smit.nl@gmail.com

sjsf added the Binding-Trådfri label Jul 11, 2017

Merge https://github.com/S0urceror/smarthome

a0688bc

Merge branch 'master' of https://github.com/eclipse/smarthome

0b6b329

Signed-off-by: Mario Smit <mario.smit.nl@gmail.com>

S0urceror closed this Aug 16, 2017

S0urceror reopened this Aug 16, 2017

S0urceror force-pushed the master branch from 10d2d8e to 0b6b329 Compare August 16, 2017 13:04

sjsf added the feedback label Sep 8, 2017

cweitkamp mentioned this pull request Sep 21, 2017

Initial contribution of Trådfri binding #3653

Merged

cweitkamp mentioned this pull request Oct 4, 2017

[Tradfri] Added support for remote controller and motion sensor devices #4373

Merged

7 tasks

S0urceror closed this Oct 6, 2017

sjsf mentioned this pull request Nov 6, 2017

[Tradfri] Binding doens´t provide group events after Tradfri App/Gateway Update #4488

Closed

Changes to the Tradfri Binding to discover and use Groups #3799

Changes to the Tradfri Binding to discover and use Groups #3799

Conversation

S0urceror commented Jul 4, 2017

sjsf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

S0urceror commented Jul 5, 2017 via email

sjsf commented Jul 30, 2017

S0urceror commented Jul 30, 2017 via email

triller-telekom commented Aug 9, 2017

S0urceror commented Aug 16, 2017

thelaoshi commented Aug 17, 2017

S0urceror commented Aug 18, 2017 via email

thelaoshi commented Aug 18, 2017

S0urceror commented Aug 21, 2017 via email

S0urceror commented Aug 22, 2017

thelaoshi commented Aug 29, 2017

S0urceror commented Aug 29, 2017 via email

thelaoshi commented Aug 29, 2017

sjsf commented Aug 29, 2017

openhab-bot commented Oct 1, 2017

hreichert commented Oct 2, 2017

S0urceror commented Oct 6, 2017 via email

hreichert commented Oct 6, 2017

cweitkamp commented Oct 6, 2017

hreichert commented Oct 6, 2017

S0urceror commented Oct 6, 2017 via email

openhab-bot commented Oct 10, 2017

cweitkamp commented Nov 12, 2017

S0urceror commented Nov 13, 2017 • edited

cweitkamp commented Nov 13, 2017

openhab-bot commented Oct 7, 2018

S0urceror commented Nov 13, 2017 •

edited