Reworked auto-update infrastructure completely #5011

sjsf · 2018-02-01T13:35:55Z

This PR re-works the mechanism to automatically send item state events automatically when a command event was received.

Bindings (i.e. ThingHandlers via the ThingHandlerCallback) can set a AutoUpdatePolicy for any channel:

Policy	Description
VETO	It's not a good idea to send auto-updates, e.g. because the ThingHandler can (and will) do that much better. Makes sense especially for dimmers/rollershutters to have smooth transitions
DEFAULT	The ThingHandler has no specific needs or opinions - the default if no policy is set explicitly
RECOMMEND	It would be a good idea to send auto-updates (e.g. when a device doesn't expose its current state through its API) - unless another channel is linked to the same item which will take over this duty

The behavior of the AutoUpdateManager can be summarized like this:

Case	Description	Event	Prediction
REQUIRED	No channels are linked to the item -> act as a "binding"	✔️	-
RECOMMENDED	Channels are linked but RECOMMENDed to send auto-updates	✔️	-
OPTIMISTIC	At least one operational channel is linked with DEFAULT policy	- *)	`changeStateTo`
DONT	At least one linked channel cast a VETO	-	-
REVERT	All linked channel are not working	-	`keepCurrentState`

Therefore, in comparison to the previous implementation there are two major improvements:

Sending automatic state updates before the binding can report back the real device status always happened based on the optimistic assumption that "everything will be alright". This doesn't hold true though when the framework already knows that this can't work, e.g. when the channel or thing does not exist, the ThingHandler is not there (yet) or the thing is in OFFLINE mode. In such cases there will be no automatic state update sent anymore.
In the OPTIMISTIC case where the framework can assume that the binding eventually will send such a state update itself, by default now there won't be a automatic state update event sent out anymore. Instead, the prediction callback will be informed so that UIs still can react nicely, but the "real" item state is not affected anymore. This has the huge advantage that e.g. persistence services won't get fed anymore with such "false", optimistic state updates but the item state rather represents the "real" values. RECOMMENDED and REQUIRED cases remain the same, events are still sent out as before.

As a rough summary, these are the changes on technical level:

dropped the remainings of the AutoUpdateBindingConfigProvider
dropped the autoupdate "binding" bundle
Introduced the AutoUpdateManager as part of the core framework
Allow bindings to RECOMMEND or VETO the auto-update for specific channels
Created a new hook to allow UIs getting notified about "optimistic" state updates
Do not really send auto-updates anymore unless no channel is linked or a binding RECOMMENDs to do so for a channel (so that auto-updates can't be mixed-up with "real" updates anymore and e.g. won't get persisted anymore)
The previous behavior of always sending item updates can still be configured for backward compatibility - the *) case above

fixes #595
fixes #4356
Signed-off-by: Simon Kaufmann simon.kfm@googlemail.com

openhab-bot · 2018-02-04T19:25:44Z

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

https://community.openhab.org/t/auoupdate-for-item-in-paperui/39602/2

maggu2810

I just had a short look at the moment.

Shouldn't it also possible to set the auto update policy for all channels of a thing (handler) or for the whole binding? At least the handler should be able to set it easily for all channels of its things.

maggu2810 · 2018-02-06T21:33:27Z

...home.core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/AutoUpdatePolicy.java

+public enum AutoUpdatePolicy {
+ /**
+ * No automatic state update should be sent by the framework. The handler will make sure it sends a state update and
+ * it can to it better than just converting the command to a state.


typo: ... can do it ...

maggu2810 · 2018-02-06T21:34:00Z

...home.core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/AutoUpdatePolicy.java

+
+ /**
+ * The binding does not care and the framework may do what it deems to be right. The state update which the
+ * framework will send out normally will correspond the command state anyway. This is the default of no other policy


typo: ... default if no ...

maggu2810 · 2018-02-06T21:39:54Z

....core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/ThingHandlerCallback.java

+ /**
+ * Give advice to the framework whether automatic state updates should be sent for the given channel or not.
+ *
+ * @param channelUID


A description should be added if it is ready for a final review (also if the comment is "the channel UID" only).
Same below and also in other classes...

kaikreuzer

Looks like a pretty nice enhancement of the functionality.

After an initial review, I'd suggest a few changes, though:

As the policy will depend on the channels, this information should imho be added to the channel definition (and the channel types) directly. This way, binding developers can simply add the information in the thing XMLs and do not require any programmatic logic and calls to the callback.
The CommandResultPredictionListener could be removed when introducing a new "StatePrediction" event - the advantage of using events would be that not only sitemap-based UIs would benefit from this feature, but also UIs like the Paper UI or HABPanel.
The auto-updates should be disabled in general for Group items as those will calculate their state based on their members and predictions aren't really possible in that case (or at least would be highly complex).

kaikreuzer

Thanks @SJKA, looks pretty good to me!
I didn't actively test it, but code-wise I think it is an excellent refactoring.

kaikreuzer · 2018-06-29T09:18:09Z

....thing.xml/src/main/java/org/eclipse/smarthome/core/thing/xml/internal/ChannelConverter.java


 return channelXmlResult;
 }

+ private AutoUpdatePolicy readAutoUpdatePlicy(NodeIterator nodeIterator) {


typo: readAutoUpdateP[o]licy

kaikreuzer · 2018-06-29T09:24:24Z

...ng.xml/src/main/java/org/eclipse/smarthome/core/thing/xml/internal/ChannelTypeConverter.java

+ private AutoUpdatePolicy readAutoUpdatePolicy(NodeIterator nodeIterator) {
+ String string = (String) nodeIterator.nextValue("autoUpdatePolicy", false);
+ if (string != null) {
+ return AutoUpdatePolicy.valueOf(string.toUpperCase(Locale.ENGLISH));


Any special reason for the locale parameter here? All defined values are plain ASCII, aren't they?

No. Just (good) habit.

kaikreuzer · 2018-06-29T09:55:27Z

...me.core.thing/src/main/java/org/eclipse/smarthome/core/thing/internal/AutoUpdateManager.java

+ */
+@NonNullByDefault
+@Component(immediate = true, service = {
+ AutoUpdateManager.class }, configurationPid = "org.eclipse.smarthome.autoupdatemanager", configurationPolicy = ConfigurationPolicy.OPTIONAL)


I would suggest to change the pid to org.eclipse.smarthome.autoupdate

kaikreuzer · 2018-06-29T10:53:00Z

...me.core.thing/src/main/java/org/eclipse/smarthome/core/thing/internal/AutoUpdateManager.java

+ Recommendation autoUpdate = shouldAutoUpdate(itemName);
+
+ // consider user-override via item meta-data
+ MetadataKey key = new MetadataKey("autoupdate", itemName);


Would you want to put that string in a constant?

kaikreuzer · 2018-06-29T10:54:50Z

...me.core.thing/src/main/java/org/eclipse/smarthome/core/thing/internal/AutoUpdateManager.java

+ MetadataKey key = new MetadataKey("autoupdate", itemName);
+ Metadata metadata = metadataRegistry.get(key);
+ if (metadata != null && !metadata.getValue().trim().isEmpty()) {
+ boolean override = Boolean.getBoolean(metadata.getValue());


Careful! Boolean.getBoolean expects a system property name as a parameter - I doubt that this is what you want here.

Argh, thanks! Of course...

kaikreuzer · 2018-06-29T11:01:43Z

....sitemap/src/main/java/org/eclipse/smarthome/io/rest/sitemap/SitemapSubscriptionService.java

+ ItemStatePredictedEvent prediction = (ItemStatePredictedEvent) event;
+ Item item = itemUIRegistry.get(prediction.getItemName());
+ if (item instanceof GroupItem) {
+ return;


Could you leave a comment on why we ignore group items here?

kaikreuzer · 2018-06-29T11:02:25Z

...sitemap/src/main/java/org/eclipse/smarthome/io/rest/sitemap/internal/PageChangeListener.java

@@ -44,6 +47,7 @@
 */
 public class PageChangeListener implements StateChangeListener {

+ private final ScheduledExecutorService scheduler = ThreadPoolManager.getScheduledPool("ui");


Might this be a candidate for the new "common" pool?

kaikreuzer · 2018-06-29T11:03:30Z

...sitemap/src/main/java/org/eclipse/smarthome/io/rest/sitemap/internal/PageChangeListener.java

+ public void keepCurrentState(Item item) {
+ scheduler.schedule(() -> {
+ constructAndSendEvents(item, item.getState());
+ }, 200, TimeUnit.MILLISECONDS);


200ms might be a bit tight, usually we go for 300ms for UI related feedback.

kaikreuzer · 2018-06-29T11:05:29Z

docs/documentation/development/bindings/thing-definition.md

+The following policies are supported:
+
+* **veto**: No automatic state update should be sent by the framework. The thing handler will make sure it sends a state update and it can to it better than just converting the command to a state.
+* **default**: The binding does not care and the framework may do what it deems to be right. The state update which the framework will send out normally will correspond the command state anyway. This is the default of no other policy is set explicitly.


typo: [i]f no other

kaikreuzer · 2018-06-29T11:06:03Z

docs/documentation/development/bindings/thing-definition.md

+
+* **veto**: No automatic state update should be sent by the framework. The thing handler will make sure it sends a state update and it can to it better than just converting the command to a state.
+* **default**: The binding does not care and the framework may do what it deems to be right. The state update which the framework will send out normally will correspond the command state anyway. This is the default of no other policy is set explicitly.
+* **recommend**: An automatic state update should be sent by the framework because no updates will be sent by the binding. This usually is the case when devices don't expose their current state to the handler.


better: will be sent -> are sent

kaikreuzer

Thanks for the updates - may I ask you to rebase the branch?

maggu2810 · 2018-08-09T20:20:51Z

@SJKA My comment above has not been answered, yet.

I am currently using a service that implements that interface: https://github.com/maggu2810/shk/blob/master/bundles/shk-addon-autoupdate-configurator/src/main/java/de/maggu2810/shk/addon/autoupdate/configurator/AutoUpdateConfigurator.java

The implementation also implements the AutoUpdateBindingConfigProvider.

The implementation looks like: https://github.com/maggu2810/shk/blob/master/bundles/shk-addon-autoupdate-configurator/src/main/java/de/maggu2810/shk/addon/autoupdate/configurator/impl/AutoUpdateConfiguratorImpl.java

As you removed the AutoUpdateBindingConfigProvider can you give me an example how to easily disable the auto update for specific binding IDs?

sjsf · 2018-08-13T08:59:10Z

@maggu2810 Sorry, I tried addressing your comments by making it a characteristic of the Channel/ChannelType, but clearly forgot to explicitly mention it here.
Therefore you can:

as a binding, indicate the preference via the Channel (or rather the ChannelType, as its "template")
as a user, set the preference on the item's metadata (i.e. autoupdate:<ITEM_NAME>)
and last but not least, if you want to do this programmatically, you could also either set the corresponding metadata in the ManagedMetadataProvider or even have your own MetadataProvider which dynamically provides the corresponding metadata, e.g. for all items linked to a certain binding. In the latter case you'd just need to be sure to not interfere with the user and thereby have another MetadataProvider which provides metadata for the same keys.

Do you think one of these would cover your scenario?

kaikreuzer · 2018-08-14T15:28:03Z

Just fresh from testing with the ESH demo setup:

smarthome send Weather_Temperature 1
Command has been sent successfully.
osgi> 17:25:31.834 INFO  s.event.ItemCommandEvent[:53] - Item 'Weather_Temperature' received command 1
17:25:31.838 DEBUG o.e.s.c.t.i.p.ProfileCallbackImpl[:69] - Delegating command '1 °C' for item 'Weather_Temperature' to handler for channel 'yahooweather:weather:berlin:temperature'
17:25:31.839 DEBUG o.e.s.c.i.c.InvocationHandlerSync[:55] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.eclipse.smarthome.binding.yahooweather.handler.YahooWeatherHandler@1e1cfe47'.
17:25:31.840 DEBUG o.e.s.b.y.h.YahooWeatherHandler[:157] - Command 1 °C is not supported for channel: temperature
17:25:31.843 ERROR o.e.s.c.i.events.EventHandler[:123] - Creation of ESH-Event failed, because one of the registered event factories has thrown an exception: Error getting class for simple name: 'nullType' using package name 'org.eclipse.smarthome.core.library.types.'.
java.lang.IllegalArgumentException: Error getting class for simple name: 'nullType' using package name 'org.eclipse.smarthome.core.library.types.'.
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:183)
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseType(ItemEventFactory.java:158)
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.getState(ItemEventFactory.java:136)
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.createStatePredictedEvent(ItemEventFactory.java:123)
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.createEventByType(ItemEventFactory.java:82)
	at org.eclipse.smarthome.core.events.AbstractEventFactory.createEvent(AbstractEventFactory.java:50)
	at org.eclipse.smarthome.core.internal.events.EventHandler.createESHEvent(EventHandler.java:121)
	at org.eclipse.smarthome.core.internal.events.EventHandler.handleEvent(EventHandler.java:95)
	at org.eclipse.smarthome.core.internal.events.EventHandler.handleEvent(EventHandler.java:72)
	at org.eclipse.smarthome.core.internal.events.ThreadedEventHandler.lambda$0(ThreadedEventHandler.java:67)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: org.eclipse.smarthome.core.library.types.nullType cannot be found by org.eclipse.smarthome.core_0.10.0.qualifier
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:484)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:179)
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseType(ItemEventFactory.java:158)
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.getState(ItemEventFactory.java:136)
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.createStatePredictedEvent(ItemEventFactory.java:123)

sjsf · 2018-08-17T13:54:02Z

Oh well, nasty little conflict-resolution-mistake I did when rebasing.
À propos: I will do another rebase 😩 Hang on...

Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>

… in advent of eclipse-archived/smarthome#5011 Signed-off-by: Kai Kreuzer <kai@openhab.org>

Related to eclipse-archived/smarthome#5011 Signed-off-by: Kai Kreuzer <kai@openhab.org>

kaikreuzer

lgtm. I have rebased the branch in order to resolve the conflicts.

…390) * adapted AutoUpdateDelegate to the new ESH auto update infrastructure Related to eclipse-archived/smarthome#5011 Signed-off-by: Kai Kreuzer <kai@openhab.org>

lolodomo · 2018-09-06T18:20:40Z

Could we have a clear example what has to be changed in the *.items files please ?
I was setting autoupdate="false" on few of my switch items until now.

kaikreuzer · 2018-09-06T18:53:04Z

If you mean autoupdate="false" then simply keep doing the very same - nothing has changed about that. The feature is meant for bindings to be able to influence the behavior on their own.

lolodomo · 2018-09-06T19:21:53Z

Ok, thank you @kaikreuzer for the information.

…penhab#390) * adapted AutoUpdateDelegate to the new ESH auto update infrastructure Related to eclipse-archived/smarthome#5011 Signed-off-by: Kai Kreuzer <kai@openhab.org>

openhab-bot · 2018-09-13T14:38:36Z

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

https://community.openhab.org/t/new-zwave-device-fails-attempts-to-fix-leads-to-all-new-thing-names-breaking-item-links-and-rules/51326/15

… in advent of eclipse-archived/smarthome#5011 (#5652) Signed-off-by: Kai Kreuzer <kai@openhab.org>

openhab-bot · 2018-09-27T07:12:03Z

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

https://community.openhab.org/t/what-is-itemstatepredictedevent/52387/2

lsafelix75 · 2018-09-29T03:00:03Z

Any binding example on how to apply this autoupdate feature? After reading this, i am still not clear what need to be done. Cheers

maggu2810 · 2018-10-01T12:20:21Z

It depends on your use case.
For the bindings I don't want the auto update mechanism I added this

<autoUpdatePolicy>veto</autoUpdatePolicy>

to my channel types in the XML.

lsafelix75 · 2018-10-09T06:39:45Z

It depends on your use case.
For the bindings I don't want the auto update mechanism I added this
<autoUpdatePolicy>veto</autoUpdatePolicy>
to my channel types in the XML.

ok.. thanks.

openhab-bot · 2018-11-12T10:46:15Z

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

https://community.openhab.org/t/light-behaves-weirdly-when-turned-on-via-rule-tradfri-homematic/56120/10

openhab-bot · 2018-12-19T01:45:39Z

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

https://community.openhab.org/t/zwave-binding-updates/51080/290

unparagoned · 2018-12-22T17:38:49Z

It would be great if there was a global setting we could use to set to work the way it did before, or an easy way to make it work like it was before. I use custom items to trigger my rules, but that's not really working well now.

sjsf added Core APIBreaking labels Feb 1, 2018

kaikreuzer mentioned this pull request Feb 5, 2018

LaMetric Time Binding openhab/openhab-addons#2345

Merged

triller-telekom mentioned this pull request Feb 5, 2018

[wink] Wink Binding initial contribution openhab/openhab-addons#2943

Closed

maggu2810 reviewed Feb 6, 2018

View reviewed changes

kaikreuzer mentioned this pull request Feb 8, 2018

compat1.x Update RollershutterItem.java openhab/openhab-core#288

Closed

kaikreuzer suggested changes Feb 20, 2018

View reviewed changes

htreu mentioned this pull request Feb 22, 2018

Extend ChannelType by command options #5131

Merged

kaikreuzer mentioned this pull request Mar 26, 2018

Feature Request: Check result (state UPDATE) of a COMMAND sent to an item #5309

Open

sjsf force-pushed the autoUpdate branch from 0e40f4e to 89d1612 Compare June 22, 2018 15:02

kaikreuzer suggested changes Jun 29, 2018

View reviewed changes

sjsf force-pushed the autoUpdate branch from 89d1612 to fb48421 Compare July 10, 2018 14:02

kaikreuzer approved these changes Aug 8, 2018

View reviewed changes

sjsf force-pushed the autoUpdate branch from 06eaf9b to 46be54e Compare August 13, 2018 09:12

sjsf force-pushed the autoUpdate branch from 4546743 to 670a86c Compare August 17, 2018 13:55

Simon Kaufmann added 8 commits September 3, 2018 15:34

created AutoUpdateManager

8413dd4

Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>

integrate AutoUpdateManager into ThingHandlerCallback

7932fb9

Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>

integrate AutoUpdateManager into CommunicationManager

e650f75

Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>

dropped o.e.sh.core.autoupdate bundle

00884f1

Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>

dropped random autoupdate package imports

a7bb39e

Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>

dropped AutoUpdateGenericBindingConfigProvider

dea5fb9

Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>

adapt sitemap subscribers

ae6e964

Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>

adapted build

3335444

Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>

kaikreuzer added a commit to kaikreuzer/openhab1-addons that referenced this pull request Sep 3, 2018

removed irrelevant implementations of autoUpdate feature as a cleanup…

9888a4a

… in advent of eclipse-archived/smarthome#5011 Signed-off-by: Kai Kreuzer <kai@openhab.org>

kaikreuzer mentioned this pull request Sep 3, 2018

removed irrelevant implementations of autoUpdate feature as a cleanup… openhab/openhab1-addons#5652

Merged

kaikreuzer added a commit to kaikreuzer/openhab-core that referenced this pull request Sep 4, 2018

adapted AutoUpdateDelegate to the new ESH auto update infrastructure

c4883c0

Related to eclipse-archived/smarthome#5011 Signed-off-by: Kai Kreuzer <kai@openhab.org>

kaikreuzer added a commit to kaikreuzer/openhab-core that referenced this pull request Sep 4, 2018

adapted AutoUpdateDelegate to the new ESH auto update infrastructure

db88fb4

Related to eclipse-archived/smarthome#5011 Signed-off-by: Kai Kreuzer <kai@openhab.org>

kaikreuzer added a commit to kaikreuzer/openhab-core that referenced this pull request Sep 4, 2018

adapted AutoUpdateDelegate to the new ESH auto update infrastructure

179fa36

Related to eclipse-archived/smarthome#5011 Signed-off-by: Kai Kreuzer <kai@openhab.org>

kaikreuzer mentioned this pull request Sep 4, 2018

adapted AutoUpdateDelegate to the new ESH auto update infrastructure openhab/openhab-core#390

Merged

kaikreuzer force-pushed the autoUpdate branch from 670a86c to c86d5e3 Compare September 4, 2018 13:43

kaikreuzer approved these changes Sep 4, 2018

View reviewed changes

kaikreuzer merged commit 1aade3a into eclipse-archived:master Sep 5, 2018

kaikreuzer mentioned this pull request Sep 6, 2018

Initial implementation for JsonBindingService as discussed on #4741 #5856

Closed

kaikreuzer mentioned this pull request Sep 10, 2018

sets the backward compatibility option for the item auto updates openhab/openhab-distro#760

Merged

9037568 pushed a commit to openhab/openhab1-addons that referenced this pull request Sep 16, 2018

removed irrelevant implementations of autoUpdate feature as a cleanup…

d3fdf07

… in advent of eclipse-archived/smarthome#5011 (#5652) Signed-off-by: Kai Kreuzer <kai@openhab.org>

kaikreuzer mentioned this pull request Oct 28, 2018

HABmin "loses" item-channel links openhab/org.openhab.ui.habmin#285

Open

htreu added this to the 0.10.0 milestone Oct 30, 2018

kaikreuzer mentioned this pull request Dec 19, 2018

[mqtt] Rollershutter STOP command, outgoing transform, chained incoming transformations #6695

Merged

kaikreuzer mentioned this pull request Aug 4, 2020

autoupdate="false" should be the default for items openhab/openhab-core#1578

Closed

Reworked auto-update infrastructure completely #5011

Reworked auto-update infrastructure completely #5011

Conversation

sjsf commented Feb 1, 2018 • edited by kaikreuzer Loading

openhab-bot commented Feb 4, 2018

maggu2810 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

kaikreuzer left a comment

Choose a reason for hiding this comment

kaikreuzer 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

kaikreuzer left a comment

Choose a reason for hiding this comment

maggu2810 commented Aug 9, 2018

sjsf commented Aug 13, 2018

kaikreuzer commented Aug 14, 2018

sjsf commented Aug 17, 2018

kaikreuzer left a comment

Choose a reason for hiding this comment

lolodomo commented Sep 6, 2018 • edited Loading

kaikreuzer commented Sep 6, 2018

lolodomo commented Sep 6, 2018

openhab-bot commented Sep 13, 2018

openhab-bot commented Sep 27, 2018

lsafelix75 commented Sep 29, 2018

maggu2810 commented Oct 1, 2018

lsafelix75 commented Oct 9, 2018

openhab-bot commented Nov 12, 2018

openhab-bot commented Dec 19, 2018

unparagoned commented Dec 22, 2018

sjsf commented Feb 1, 2018 •

edited by kaikreuzer

Loading

lolodomo commented Sep 6, 2018 •

edited

Loading