Mqtt things #3876

davidgraeff · 2017-07-24T05:10:22Z

Implementation of the second idea mentioned in #3812.

This has a strong dependency on #4146 and a soft dependency on #4142 for graphical configuration.

Abstract

At this very moment there exist no means to actually connect mqtt topics to ESH things. There are a lot of commercial and non-commercial (Owntracks, EasyESP, Homie) Mqtt products out there who deserve their own binding.

But for a start I propose a simple generic Mqtt binding where you can bind topics to things (very much like the Openhab 1.x Mqtt binding, but modern) with the following features:

List all configured brokers of the io.transport.mqtt.MqttService and let the user add them as bridges.
Manually add a thing (Text, Number, OnOff-thing) and bind it to a Mqtt state and/or command topic.
Allow to use a transformation pattern to extract a state from a formatted response like JSON. An example would be the pattern JSONPATH:$.device.status.temperature for an incoming message of {device: {status: { temperature: 23.2 }}}.
The number thing can have a configured min, max and step so that its channel is suitable for Dimmer/Rollershutter item types.
The onoff thing allows to configure what should be interpreted as the states and send for the states "ON" and "OFF".

Discussion

I have added four things with one channel each (the value channel). The following item types can be used with the channel:

TextThing: String
NumberThing: Number
PercentThing: Rollershutter, Dimmer
OnOffThing: Contact, Switch

I'm not sure if we need more things to cover the basic needs, but I might have overlooked use cases.

Cheers,
David

davidgraeff · 2017-07-30T07:31:22Z

@htreu Can you have a look at this PR? It is a simpler and smaller PR than the Mqtt Broker configuration PR and there are less subjects that need to be discussed architecture-wise.

ThomDietrich · 2017-07-30T09:02:49Z

@davidgraeff
your arguments against a auto-discovery make perfect sense. Do you think a manual discovery process in which topics of all retained messages and of new messages as they come in would help users to add things and items? Yes I'm talking about a # subscription 😄 Sounds like an easy task and a huge time safer...

Also: Don't you think the binding should support the other noteworthy MQTT message features retained flag and qos? Who knows what the user might need them for...

davidgraeff · 2017-07-30T09:05:07Z

I want to keep this PR simple for the start. Additional features can be added later. But it is more likely to get this merged faster if the PR is smaller.

@ThomDietrich : Can you elaborate on QoS and retained messages? As far as I know, those are client connection and last-will options and not per-topic options. You can choose those for the mqtt client connection already right now.

ThomDietrich · 2017-07-30T22:42:56Z

Reasonable and I'd also root for a faster merge.

QoS and Retained are both properties on per message basis actually, even though they are often identical amongst all messages per topic. Even though they might not be important in the beginning they are one of a few basic properties. I wonder if the initial version of the binding should support them to facilitate further ambitions.

As you see fit! Thanks for working on this crucial feature.

kaikreuzer · 2017-08-28T08:48:34Z

As mentioned in #3812 (comment), there is no direct dependency on Paper UI work for merging this PR.

The implementation is done, but changes are requested, see #3812 (comment).

This is the outstanding part that should be addressed before the PR can be reviewed & merged.

davidgraeff · 2017-08-28T20:32:50Z

Adapted to dynamic channels. Is the current implementation how it should look like? (Especially the ThingHandler?)

Bind Mqtt topics to things. Broker connections are listed as brigdes. A generic thing can be added. The thing can host one or multiple channels, each linked to a mqtt state / command topic and an own optional transformation. A channel is one of the following types: * TextChannel * NumberChannel * PercentageChannel * OnOffChannel A channel can be configured with a transformation pattern for an incoming message from a Mqtt state topic. This allows to extract a value from JSON/XML/etc, as it seems to get popular on some Mqtt topics to encode multiple values into json. The handlers and all value classes are backed by tests. Signed-off-by: David Gräff <david.graeff@web.de>

weswitt · 2017-11-15T21:55:25Z

Is this PR going to be accepted? Would like to use this.

htreu · 2018-01-18T11:23:57Z

Hi @davidgraeff, this one also seems to be nearly finished. Here Paper UI support is also ready for extending Channels on Things. Would be nice to see your engagement again :-)

sjsf

I didn't do an in-depth review yet, as there are still some major inconsistencies to solve. Nevertheless, I left a few comments on stuff that caught my eyes while browsing through the productive (in the sense of non-test) code.

sjsf · 2018-01-23T14:59:16Z

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

@@ -0,0 +1,202 @@
+<?xml version="1.0" encoding="UTF-8"?>


The current state of this file doesn't correlate with the code (topic-ThingType, different names for config parameters, different ChannelTypeUIDs, configuration on channels instead of things, extensible-attribute,...). Could it be that you forgot to commit the updated version?

sjsf · 2018-01-23T15:05:11Z

...eneric/src/main/java/org/eclipse/smarthome/binding/mqttgeneric/handler/MqttThingHandler.java

+                config.transformationPattern = config.transformationPattern.substring(index + 1);
+                config.transformationService = getTransformationService(type);
+                if (config.transformationService == null) {
+                    throw new IllegalArgumentException("The transformation type is unknown: " + type);


This is not so much of a good idea...

Don't keep references on OSGi services (which is essentially what you are doing here, although TransformationHelper unfortunately hides this fact pretty well)

The transformation service implementation which is configured for this channel might not/currently be available but will be later on. If you let initialization fail because of this, the handler won't get a chance to recover from this.

Therefore, please only remember the transformation name and rather grab a fresh reference every time.

sjsf · 2018-01-23T15:06:01Z

...qttgeneric/src/main/java/org/eclipse/smarthome/binding/mqttgeneric/internal/NumberValue.java

+
+    @Override
+    public State update(String updatedValue) throws IllegalArgumentException {
+        numberValue = PercentType.valueOf(updatedValue);


Should be DecimalType here I assume?

sjsf · 2018-01-23T15:06:49Z

...qttgeneric/src/main/java/org/eclipse/smarthome/binding/mqttgeneric/internal/NumberValue.java

+                v = numberValue.doubleValue() + step;
+            }
+            numberValue = new PercentType(new BigDecimal(v));
+        } else {


DecimalType is missing here

sjsf · 2018-01-23T15:06:58Z

...qttgeneric/src/main/java/org/eclipse/smarthome/binding/mqttgeneric/internal/NumberValue.java

+    @Override
+    public String update(Command command) throws IllegalArgumentException {
+        if (command instanceof StringType) {
+            numberValue = PercentType.valueOf(((StringType) command).toString());


DecimalType

openhab-bot · 2018-01-25T12:44:02Z

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

https://community.openhab.org/t/light-color-rgb-rgbw-rgbcw-to-and-from-hsb-dimmer-conversion/39132/3

sjsf · 2018-02-16T13:27:04Z

I took the freedom to rebase this PR and add some commits on-top, filed as #5101. This is not meant to be a hostile take-over, just meant as an offer to push this binding forward. You are more than welcome to continue on this PR here and either implement the review feedback and other amendments yourself or take them from #5101. In the meantime I'm going to close this PR in order to prevent confusion.

davidgraeff · 2018-02-16T19:43:47Z

Haha all good, no offense taken. Good to see progress :)

davidgraeff force-pushed the mqtt_things branch from de2bda3 to 0ebca59 Compare July 24, 2017 05:21

ThomDietrich mentioned this pull request Jul 24, 2017

Openhab2 binding - Anyone already working on one? homieiot/convention#10

Closed

davidgraeff force-pushed the mqtt_things branch 4 times, most recently from d66a980 to 14bfc4d Compare July 29, 2017 08:22

davidgraeff changed the title ~~[WIP] Mqtt things~~ Mqtt things Jul 29, 2017

davidgraeff force-pushed the mqtt_things branch 3 times, most recently from ba1ecc9 to dbf3eff Compare July 30, 2017 07:28

davidgraeff changed the title ~~Mqtt things~~ [Waiting for PaperUI feature] Mqtt things Aug 16, 2017

htreu mentioned this pull request Aug 28, 2017

PaperUI: add new channels to things #4142

Closed

kaikreuzer changed the title ~~[Waiting for PaperUI feature] Mqtt things~~ [WIP] Mqtt things Aug 28, 2017

davidgraeff changed the title ~~[WIP] Mqtt things~~ [Depends on #4146] Mqtt things Aug 28, 2017

davidgraeff force-pushed the mqtt_things branch 2 times, most recently from 9f5ce95 to 23a2d77 Compare August 28, 2017 20:31

davidgraeff force-pushed the mqtt_things branch from 23a2d77 to 1b40122 Compare August 29, 2017 03:33

davidgraeff changed the title ~~[Depends on #4146] Mqtt things~~ Mqtt things Sep 7, 2017

ThomDietrich mentioned this pull request Nov 21, 2017

DS18x20 only some out of all sensors published arendst/Tasmota#1215

Closed

sjsf suggested changes Jan 23, 2018

View reviewed changes

sjsf mentioned this pull request Feb 16, 2018

MQTT Generic Binding #5101

Closed

sjsf closed this Feb 16, 2018

davidgraeff mentioned this pull request Mar 15, 2018

Mqtt Broker configuration binding #3839

Merged

davidgraeff mentioned this pull request Apr 23, 2018

Mqtt generic things and Homie 3.x things #5450

Closed

davidgraeff mentioned this pull request Jul 9, 2018

[MQTT Generic Things] with Homie 3.x and HomeAssistant thing discovery #5880

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mqtt things #3876

Mqtt things #3876

davidgraeff commented Jul 24, 2017 •

edited

Loading

davidgraeff commented Jul 30, 2017 •

edited

Loading

ThomDietrich commented Jul 30, 2017

davidgraeff commented Jul 30, 2017 •

edited

Loading

ThomDietrich commented Jul 30, 2017 •

edited

Loading

kaikreuzer commented Aug 28, 2017

davidgraeff commented Aug 28, 2017 •

edited

Loading

weswitt commented Nov 15, 2017

htreu commented Jan 18, 2018

sjsf left a comment

sjsf Jan 23, 2018

sjsf Jan 23, 2018

sjsf Jan 23, 2018

sjsf Jan 23, 2018

sjsf Jan 23, 2018

openhab-bot commented Jan 25, 2018

sjsf commented Feb 16, 2018

davidgraeff commented Feb 16, 2018

Mqtt things #3876

Mqtt things #3876

Conversation

davidgraeff commented Jul 24, 2017 • edited Loading

Abstract

Discussion

davidgraeff commented Jul 30, 2017 • edited Loading

ThomDietrich commented Jul 30, 2017

davidgraeff commented Jul 30, 2017 • edited Loading

ThomDietrich commented Jul 30, 2017 • edited Loading

kaikreuzer commented Aug 28, 2017

davidgraeff commented Aug 28, 2017 • edited Loading

weswitt commented Nov 15, 2017

htreu commented Jan 18, 2018

sjsf left a comment

Choose a reason for hiding this comment

sjsf Jan 23, 2018

Choose a reason for hiding this comment

sjsf Jan 23, 2018

Choose a reason for hiding this comment

sjsf Jan 23, 2018

Choose a reason for hiding this comment

sjsf Jan 23, 2018

Choose a reason for hiding this comment

sjsf Jan 23, 2018

Choose a reason for hiding this comment

openhab-bot commented Jan 25, 2018

sjsf commented Feb 16, 2018

davidgraeff commented Feb 16, 2018

davidgraeff commented Jul 24, 2017 •

edited

Loading

davidgraeff commented Jul 30, 2017 •

edited

Loading

davidgraeff commented Jul 30, 2017 •

edited

Loading

ThomDietrich commented Jul 30, 2017 •

edited

Loading

davidgraeff commented Aug 28, 2017 •

edited

Loading