Home » Archived » Eclipse SmartHome » MQTT binding for ESH(Creation of a ESH binding similar to the MQTT binding for OH1.)
| MQTT binding for ESH [message #1562087] |
Tue, 13 January 2015 13:43  |
|
Hello,
I would like to get informed of state updates and raised commands over MQTT. Also I would like to be able to send state updates and commands to an item using MQTT. This is already possible using OH1 and the MQTT binding.
Now I would like to switch to ESH and use a similar approach.
I tried to combine the requirements with the bridge, things, channels concept ESH is using.
Could someone have a look at the notes below if the concept is good, bad, broken, ...? Maybe someone with more knowledge of biology could help with more details.
So here my notes:
Bridge - Broker
The broker (a connection should be established to) could be implemented using a __bridge__.
The alias / name of the broker (used for reference) is the name of the bridge on the special configuration.
The parameters that are necessary to define the connection to a broker could be implemented using __parameters (config-description)__
Parameters:
* url
* clientId
* user
* password
* qos
* retain
* async
Thing - Topic
A topic could be implemented using a __thing__.
We will differ between thing and the topic that is used if a message is sent, so let's use a parameter for that.
It should be possible to configure if a topic is used for states or commands (would it be usefull to support 'state and command'?).
We would also introduce some more parameters later if we need them e.g. transformation, regex-filter, ...).
Channel - Direction
For the direction of a message (incoming or outgoing) __channel(s)__ are used.
So we need at least two channels _in_ (marked readOnly) and _out_.
What should be used as an channel category, is there an 'undefined' one?
Messages
A message is formatted as key-value pairs. So we could add more informations in future without breaking compatibility.
First let's use the key "value" only that will contain the command / state value.
Which coding should be used to format the key-value pairs? As long as we are not using a value that includes new lines, we could interpret a line as a key-value pair. The line starts with the key and the key ends with the first '=' character, all remaining characters are interpret as the value of that key.
|
|
|
| Re: MQTT binding for ESH [message #1562109 is a reply to message #1562087] |
Tue, 13 January 2015 13:56  |
|
Not relevant as it seems that one item could use more than one channel.
If an item could not handle more than one channel the concept needs some changes.
- use only one channel, e.g. "message"
- the thing could be configured, if it is for "in", "out" or "in / out"
- the thing could be configured, if it handles "states", "commands", "state and commands"
- the message needs a new key 'type' that codes 'state' or 'command'
[Updated on: Tue, 13 January 2015 14:09] Report message to a moderator |
|
|
| Re: MQTT binding for ESH [message #1564410 is a reply to message #1562109] |
Wed, 14 January 2015 19:40 |
 Marcel Verpaalen
Messages: 59
Registered: September 2014 |
Member |
|
|
Hi
Was doing some very initial developments few weeks back on MQTT binding as that is for me one of the most important, and one that could benefit from the new ESH features.
Share with you my thoughts on the same.
I indeed came to the same analogy as you, the connection to the mqtt broker should be defined as the bridge. each topic should become a thing.
One very important feature with the ESH binding would be the discovery. part of the bridge configuration would be that you could identify the root for discovery. The bridge would subscribe to this root topic/# and would automatically add a thing for each new topic that arrives. Obviously multiple of these discovery entries would be allowed.
For the Things, I was initially thinking to have different things depending on the direction. e.g. incoming, bidirectional, outgoing rather than having it as a configuration option. The only rationale for that thought was that it would be slightly easier to define the channels as readonly vs read-write.
Indeed it should be possible to configure if a topic is used for states or commands.
I also think retain configuration options is for the topic/thing rather than for the bridge/broker.
I would be very hesitant to make the message itself containing any key-value pair. MQTT messages are many times used to be send to multiple subscribers, don't want to make specific messages for the use in ESH. Hence that is better placed in the configuration of a thing
[Updated on: Thu, 15 January 2015 15:40] Report message to a moderator |
|
|
| Re: MQTT binding for ESH [message #1567622 is a reply to message #1564410] |
Fri, 16 January 2015 13:22 |
|
Thank you for your response.
I started with a very initial development the last day, too.
The io.transport.mqtt already handles a lot of logic, nice to use (if you know how to do it).
|
|
| |
| Re: MQTT binding for ESH [message #1696447 is a reply to message #1696367] |
Tue, 26 May 2015 14:13 |
|
First I created a MQTT binding that is using the Things, Channels, ... stuff -- just to play a little bit.
After that I created a simple binding, that is using the EventBus and the ItemRegistry to publish all state updates to a MQTT broker and all received command from the broker to the EventBus.
The exact source code could not be published, because I have done this not for myself...
|
|
|
| Re: MQTT binding for ESH [message #1702831 is a reply to message #1696447] |
Sat, 25 July 2015 13:01 |
Marcus of Wetware Labs
Messages: 7
Registered: July 2015 |
Junior Member |
|
|
Hi all,
I've been playing with MQTT, Openhab et al for a a while and I've tried the OH1 plug-in with OH2 and it seems to work just fine (as long as also the io.transport.mqtt library from OH1 is used). There's a Docker image here https://github.com/WetwareLabs/docker-openhab2 if someone is interested.
I've been thinking about porting the OH1 MQTT add-on to OH2, and I've made some preliminary progress (I guess it's quite similar to what Markus Rathgeb has achieved previously): MqttEventBusBinding functionality to propagate all states and commands from event bus to MQTT and vice versa.
It uses smarthome.io.transport.mqtt plugin as a broker connection, and both plugins are configured in a separate config file. You can check out the source code at Github here: https://github.com/WetwareLabs/openhab2 Don't forget to also copy the config files and change the MQTT server IP address.
It's basically straightforward copy of relevant pieces of the OH1 MQTT plugin, and only few changes were made to the source code to adjust to the new SmartHome event mechanism and namespaces (although a couple of 1.x compatibility layer dependencies are still there).
I was able to successfully turn on/off Philips Hue lights with MQTT messages. First flicking the light with Paper UI sends these MQTT messages:
home/openHAB/out/hue_LCT001_0017881a90f0_1_color/command ON
home/openHAB/state/hue_LCT001_0017881a90f0_1_color/state ON
Then turn it off by sending our own MQTT msg:
home/openHAB/in/hue_LCT001_0017881a90f0_1_color/command OFF
Now, the MqttItemBinding is a different beast.. Is somebody else working with this right now?
I've been trying to figure out how to map the Thing/Item paradigm to MQTT, both concept-wise and code-wise.
There's the bridge approach with topics defined as things (configuration done here manually of course):
Bridge mqtt:bridge:mosquitto [ ipAddress="192.168.1.80" ]
{
Topic MySensor1_temp [ topicId="/home/sensors/mysensor1/temperature" ]
Topic MySensor1_hum [ topicId="/home/sensors/mysensor1/humidity" ]
Topic MyDevice2_switch [ topicId="/home/devices/mydevice2/switch" ]
.
.
}
Number Bathroom_temperature { channel="mqtt:Topic:mosquitto:MySensor1_temp:input" }
Number Bathroom_humidity { channel="mqtt:Topic:mosquitto:MySensor1_hum:input" }
Switch Livingroom_power_switch { channel="mqtt:Topic:mosquitto:MyDevice2_switch:output" }
Topics then have two channels: "input" and "output" to differentiate between states (input) and commands (output).
This approach could work, but it is little bit ugly when we think about the whole Thing/Item paradigm of SmartHome: A MQTT Topic IS NOT a device or a thing, and MQTT is just a low level protocol to send messages. So to mix MQTT like this with Things is conceptually messy. I'm also thinking about auto-discovery of devices with MQTT.
Suppose we have a temperature/humidity sensor type defined like this:
<thing-type id="GeneralAtmosphereSensor">
<label>Temperature and Humidity Sensor</label>
<description>Simple Temperature and Humidity Sensor</description>
<channels>
<channel id="temperature" typeId="temperatureId" />
<channel id="humidity" typeId="humidityId" />
<channel id="batteryLevel" typeId="number" />
</channels>
</thing-type>
<channel-type id="temperatureId" advanced="true">
<item-type>Number</item-type>
<label>Temperature</label>
<category>Temperature</category>
<tags>
<tag>weather</tag>
</tags>
<state pattern="%d °C" readOnly="true">
</state>
</channel-type>
<channel-type id="humidityId" advanced="true">
<item-type>Number</item-type>
<label>Relative humidity</label>
<category>Humidity</category>
<tags>
<tag>weather</tag>
</tags>
<state min="0" max="100" pattern="%d %%" readOnly="true">
</state>
</channel-type>
Then we receive a MQTT message such as :
topicId="/home/sensors/myNewSensor13242/temperature", payLoad="23.5"
How can we map this into a discovery of new devices?
Maybe we could configure the bridge like this:
Bridge mqtt:bridge:mosquitto [ ipAddress="192.168.1.80" ]
{
Topic-AutoDiscovery TemperatureSensor [ topicId="/home/sensors/+/temperature" mapToThingType="GeneralAtmosphereSensor" mapToThingChannel="temperature"]
Topic-AutoDiscovery HumiditySensor [ topicId="/home/sensors/+/humidity" mapToThingType="GeneralAtmosphereSensor" mapToThingChannel="humidity"]
.
.
}
Then the all-matching '+' part in topic (lets call it MQTT device ID) is mapped to Thing-ID, and if Thing does not exist, create a new one with that ID. If it exists, then simply update the specific channel of that Thing with the MQTT payload. But what about the possible name clash between Thing-ID and MQTT Device ID ?
What do you think?
Also, I'm not really that familiar with SmartHome architecture, so is it possible to define abstract Thing types with XML (such as Temperature sensor here) and dynamically create items linked to it without having to code specific plugin to implement that type?
[Updated on: Sat, 25 July 2015 14:19] Report message to a moderator |
|
|
| Re: MQTT binding for ESH [message #1702861 is a reply to message #1702831] |
Sun, 26 July 2015 13:39 |
Marcus of Wetware Labs
Messages: 7
Registered: July 2015 |
Junior Member |
|
|
Hi guys,
I implemented the MQTT bridge and functionality to receiving messages. The code is there on the GitHub page: https://github.com/WetwareLabs/openhab2
First problem in the previous designs is that it doesn't seem possible to map channels as "input" and "output", since each channel is associated to one and only one Item. We can't have for example input channel receiving both Integer and String Items, so I had to design it it little bit differently:
Each topic has a different channel associated to each possible Item type, and received payloads are propagated to every channel that can handle that payload (of course the Topic could be configured to accept only explicitly defined types, but that's not yet implemented.) Input/output is then defined separately in topic configuration (state or command).
For example here's a simple configuration:
Bridge mqtt:bridge:1 [ broker="mosquitto", url="tcp://192.168.1.80:1443"]
{
topic MySensor1_temp [ topicId="/home/sensors/mysensor1/temperature", type="state" ]
topic MySensor1_hum [ topicId="/home/sensors/mysensor1/humidity", type="state" ]
topic MySensor1_status [ topicId="/home/sensors/mysensor1/status", type="state" ]
topic MyDevice2_switch [ topicId="/home/devices/mydevice2/switch", type="command" ]
topic MyDevice3_switch [ topicId="/home/devices/mydevice3/switch", type="command", transform="MAP(de.map)"]
}
Items are then associated to the channel we are interested in:
Number Temperature_FF_Bath "Temperature [%.1f °C]" <temperature> (Temperature, FF_Bath) { channel="mqtt:topic:1:MySensor1_temp:number" }
String Status_FF_Bath "Sensor status [%s]" (FF_Bath) { channel="mqtt:topic:1:MySensor1_status:string" }
If I update the temperature with following message..
topic: /home/sensors/mysensor1/temperature payload: 24
.. then '24' is casted to all possible Types and sent to the channels that can handle that type:
2015-07-26 16:13:04 [DEBUG] [nding.mqtt.handler.MqttHandler:144 ] - MQTT: Received state (topic '/home/sensors/mysensor1/temperature'). Propagating payload '24' as type 'org.eclipse.smarthome.core.library.types.DecimalType' to channel 'number')
2015-07-26 16:13:04 [DEBUG] [nding.mqtt.handler.MqttHandler:144 ] - MQTT: Received state (topic '/home/sensors/mysensor1/temperature'). Propagating payload '24' as type 'org.eclipse.smarthome.core.library.types.StringType' to channel 'string')
2015-07-26 16:13:04 [INFO ] [smarthome.event.ItemStateEvent:43 ] - Temperature_FF_Bath updated to 24
2015-07-26 16:13:04 [DEBUG] [nding.mqtt.handler.MqttHandler:144 ] - MQTT: Received state (topic '/home/sensors/mysensor1/temperature'). Propagating payload '24' as type 'org.eclipse.smarthome.core.library.types.PercentType' to channel 'color')
2015-07-26 16:13:04 [DEBUG] [s.i.t.m.i.MqttBrokerConnection:442 ] - Publishing message 114 to topic 'home/openHAB/state/Temperature_FF_Bath/state'
2015-07-26 16:13:04 [DEBUG] [nding.mqtt.handler.MqttHandler:144 ] - MQTT: Received state (topic '/home/sensors/mysensor1/temperature'). Propagating payload '24' as type 'org.eclipse.smarthome.core.library.types.PercentType' to channel 'rollershutter')
2015-07-26 16:13:04 [DEBUG] [nding.mqtt.handler.MqttHandler:144 ] - MQTT: Received state (topic '/home/sensors/mysensor1/temperature'). Propagating payload '24' as type 'org.eclipse.smarthome.core.library.types.PercentType' to channel 'dimmer')
FIXEDNow, I would have liked better to refer to the broker in the bridge like this:
Bridge mqtt:bridge:mosquitto [ url="tcp://192.168.1.80:1443"]
.. but the third part of BridgeUID cannot be accessed like this
final String broker = this.getThing().getBridgeUID().segments[2]
FIXEDCurrently the dynamic broker configuration is however not working. The io.transport.mqtt service gets it configuration in a separate file (example file is there in the repository), and if the configuration is changed on run-time, service won't yet disconnect the broker and restart connection in case the IP address is changed. On the other hand, if MQTT service is not configured statically (with the conf file), for some reason dynamic configuration won't be propagated to the service (I wonder if I'm using ConfigurationAdmin correctly..)
Anyway, there's lots of stuff to be done (propagate states/commands to MQTT messages, handling exceptions, commenting and general refactoring) but before I move forward, I'd really appreciate some feedback about if this is the right approach and direction.
Thanks!
[Updated on: Mon, 27 July 2015 21:17] Report message to a moderator |
|
|
| Re: MQTT binding for ESH [message #1702865 is a reply to message #1702861] |
Sun, 26 July 2015 17:00 |
Marcus of Wetware Labs
Messages: 7
Registered: July 2015 |
Junior Member |
|
|
Whoops, we do need to enforce direction of MQTT messaging after all.. I noticed this after implementing sending messages and without any checking of direction the messages sent by MQTT service are bounced back immediately from the broker, resulting in a dead lock of the same message going back and forth 
So now the definition looks like this:
Bridge mqtt:bridge:1 [ broker="mosquitto", url="tcp://192.168.1.80:1443"]
{
topic MySensor1_temp [ topicId="/home/sensors/mysensor1/temperature", type="state", direction="in" ]
topic MySensor1_hum [ topicId="/home/sensors/mysensor1/humidity", type="state", direction="in" ]
topic MySensor1_status [ topicId="/home/sensors/mysensor1/status", type="state", direction="in" ]
topic MyDevice2_switch [ topicId="/home/devices/mydevice2/switch", type="command", direction="out" ]
topic MyDevice3_switch [ topicId="/home/devices/mydevice3/switch", type="command", direction="out", transform="MAP(es.map)"]
}
Also the transforming code works now 
BTW. I thought about conserving the old MQTT definition style with something like below:
..
topic MySensor2342 [ def="<[mosquitto:home/rfm_gw/nb/node03/dev48:state:default]"]
topic MySensor123 [ def="<[mosquitto:home/rfm_gw/nb/node02/dev49:state:default]"]
..
.. but I don't like that the broker definition is redundant, so code would have to be modified anyway. Also it's not that easy to read (although it's quite compact).
What do you guys think?
[Updated on: Sun, 26 July 2015 17:09] Report message to a moderator |
|
|
| Re: MQTT binding for ESH [message #1703007 is a reply to message #1702865] |
Mon, 27 July 2015 21:26 |
Marcus of Wetware Labs
Messages: 7
Registered: July 2015 |
Junior Member |
|
|
All righty then,
now the MQTT broker configuration via Bridge works. Also now the bridge-id == broker name, so configuration looks better now:
Bridge mqtt:bridge:mosquitto [ url="tcp://192.168.1.80:1883" ]
{
topic MySensor1_temp [ topicId="/home/sensors/mysensor1/temperature", type="state", direction="in" ]
topic MySensor1_hum [ topicId="/home/sensors/mysensor1/humidity", type="state", direction="in" ]
topic MySensor1_status [ topicId="/home/sensors/mysensor1/status", type="state", direction="in" ]
topic MyDevice2_switch [ topicId="/home/devices/mydevice2/switch", type="command", direction="out" ]
topic MyDevice3_switch [ topicId="/home/devices/mydevice3/switch", type="command", direction="out", transform="MAP(es.map)"]
topic Openhab_temp [ topicId="/home/openhab/example/temperature", type="state", direction="out" ]
}
.
.
Number Example_Temperature_FF_MQTT "Sensor Temperature [%.1f °C]" <temperature> (FF_MQTT) { channel="mqtt:topic:mosquitto:MySensor1_temp:number" }
Number Example_Humidity_FF_MQTT "Sensor Humidity [%.1f %%]" (FF_MQTT) { channel="mqtt:topic:mosquitto:MySensor1_hum:number" }
.
.
However changing the broker URL or client ID on the fly won't work before a patch is applied to io.transport.mqtt (it's there on my Smarthome GitHub repository until it gets (hopefully) merged into the main branch.)
|
|
|
| Re: MQTT binding for ESH [message #1703416 is a reply to message #1703007] |
Fri, 31 July 2015 12:28 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Hi Marcus,
It looks as if you made great progress on this topic!
Let me add some remarks and question I have about the architecture:
- Things: The discussion reminds me about discussions I had about how to model a KNX system, which also has an IP-gateway as an interface and then only exposes functionality, but not dedicated devices. My pov there is that Things are not really needed at all. Same for MQTT: The Broker is the bridge and it can directly offer channels (which can each have a configuration on their own) - there is no need to have Things inbetween. The only benefit of a thing would be that it would be discoverable; but as I understand your reasoning above, it does not really make much sense to treat a newly received MQTT topic as a thing, so there is not really a need for this. What could be done is to automatically add channels to the existing MQTT bridge for new topics, so that one could easily configure and activate them in the UI.
- Direction: I would assume that in general a channel is bi-directional. It could simply have an "in"-parameter and an "out"-parameter, which defines the mapping/handling of the payload; depending on which parameter has an entry, the direction is automatically defined (and in/out is possible at the same time). Possibly the type (state/command) parameter has to be duplicated as well.
The result could look like:
Bridge mqtt:bridge:mosquitto [ url="tcp://192.168.1.80:1883" ] {
Channels:
Number : mySensor1_temp [ topicId="/home/sensors/mysensor1/temperature", in-type="state" ]
Number : mySensor1_hum [ topicId="/home/sensors/mysensor1/humidity", in-type="state" ]
Number : MySensor1_status [ topicId="/home/sensors/mysensor1/status", in-type="state"
Switch : myDevice2_switch [ topicId="/home/devices/mydevice2/switch", out-type="command", in-type="state" ]
Switch : myDevice3_switch [ topicId="/home/devices/mydevice3/switch", out-type="command", out-transform="MAP(es.map)"]
}
Alternatively one could think about treating a topic-prefix to represent a thing like:
Bridge mqtt:bridge:mosquitto [ url="tcp://192.168.1.80:1883" discover="/home/sensors" ] {
Thing Topic mySensor [ topicId="/home/sensors/mysensor1" ] {
Number : temp [ subtopic="temperature", in-type="state" ]
Number : hum [ subtopic="humidity", in-type="state" ]
Number : status [ subtopic="status", in-type="state"
}
Thing Topic myDevice2 [ topicId="/home/sensors/mydevice2" ] {
Switch : switch [ subtopic="switch", out-type="command", in-type="state" ]
}
Thing Topic myDevice3 [ topicId="/home/sensors/mydevice3" ] {
Switch : switch [ subtopic="switch", out-type="command", out-transform="MAP(es.map)"]
}
}
This version does some assumptions on the structure of the topics, which is a drawback. But if these assumptions can be done, it brings discovery of things and a nice structure.
What do you think about this?
Regards,
Kai
|
|
|
| Re: MQTT binding for ESH [message #1703494 is a reply to message #1703416] |
Sat, 01 August 2015 09:29 |
|
A view to the MQTT part:
You should consider to leave the payload as simple as possible. IMHO it should contains the value only.
If you would like to to add the information command / state to the MQTT part, you should add it to the topic.
Or you do not add it to the MQTT part at all and leave it configurable.
MQTT is indented so I subscribe to a topic and I get events (published messages). You should not need to encode the MQTT payload and decide if the message is of your interest.
If you ever would support broker2broker connections it is more (most) common to filter the topics.
I am using the last part of the topic to code command / state (e.g. .../c and .../s).
So, you could kept a configurable topic, type, direction structure or you use the seconds part of Kai's reply - a more generic topic.
.../device1/value1/c
.../device1/value2/s
IMHO you do not need to support the auto-discover. There are to much information that have to be coded in some MQTT topics (e.g. data type etc.).
|
|
|
| Re: MQTT binding for ESH [message #1703496 is a reply to message #1562087] |
Sat, 01 August 2015 10:41 |
Marcus of Wetware Labs
Messages: 7
Registered: July 2015 |
Junior Member |
|
|
Hi Kai and thanks for the comments!
I'm surprised that there can be individual channels in bridge without Things linked to them. This gives some food for the thought. How one could then refer to those thingless channels in Item decleration? And is there possibility to subscribe to auto-detect new channels on the Bridge?
The problem with MQTT is that its format is so simple (but huge benefit for small sensors, no doubt) which causes that interpretation leaves so much ambiguity. Hence it's hard to design a system with nice auto-detection without having to make assumptions about the topic format, direction and data type (String, Number..) OR without having to explicitly state them in the configuration, which again makes auto-configuration less relevant (but useful though in case you have lots of identical sensors).
I guess we should approach this with few well defined use cases and see which design can satisfy them:
1. Manual configuration with configuration files
User configures Bridges, Things, Channels (or whatever the design implements) by editing configuration files, and explicitly sets topics, directions and data types. In this case we don't have to worry about auto-detection, and basically every approach suggested here by us will work. So this use case doesn't restrict our design.
2. New (3rd party) plugin
A new higher-level plugin is developed to make use of Things and Channels. It shouldn't have to understand MQTT, and can use Things/Channels offered by other plugins as well. I guess it would be interested in only certain types of channels (i.e. hard-coded) and can make use of any suitable auto-detection mechanism available in SmartHome framework. For me it's little bit unclear how these plugins would be implemented and what would be their exact use cases, but it's worthwhile to mention this use case here anyway for future discussion.
3. Auto-detection with device templates
When a new topic is discovered, it is mapped to a new Thing with the help of a device template. Templates properties can be explicitly set at the topic configuration, or a reference is made to external XML that provides these properties.
Problem is that it's not possible to differentiate between device classes at run-time unless they are in different MQTT topic branch. So auto-detection from topics such as:
/home/sensors/myTempsensor/status ONLINE
/home/sensors/myTempsensor/temperature 20
/home/sensors/myMotionDetector/status ONLINE
/home/sensors/tempsensors/myTempsensor/status ONLINE
/home/sensors/tempsensors/myTempsensor/temperature 20
/home/sensors/motiondetectors/myMotionDetector/status ONLINE
So configuration would look something like
Bridge mqtt:bridge:mosquitto [ url="tcp://192.168.1.80:1883" discover="/home/sensors" ] {
Topic-Autodetect mySensorMapper [ topicId="/home/sensors/simpleTemperatureSensors/+/" ] {
Number : temp [ subtopic="temperature", in-type="state" ]
Number : hum [ subtopic="humidity", in-type="state" ]
String : status [ subtopic="status", in-type="state" ]
}
Topic-Autodetect mySensorMapper2 [ topicId="/home/sensors/moreComplexSensors/+/" deviceConfiguration="mySensor.xml" ]
Topic-Autodetect myDeviceMapper2 [ topicId="/home/switches/simpleSwitches/+/" ] {
Switch : switch [ subtopic="switch", out-type="command", in-type="state" ]
}
Topic Topic-Autodetect myDeviceMapper3 [ topicId="/home/switches/spanishSwitches/+/" ] {
Switch : switch [ subtopic="switch", out-type="command", out-transform="MAP(es.map)"]
}
}
Here the mySensor.xml would contain channel description as well as more detailed labels that look nice in UI. I guess in this case it's okay to to implement this Topic-Autodetect as a Thing, since it is actually a service, which has it's own configuration.
So, when MQTT message is received:
/home/sensors/simpleTemperatureSensors/sensor1/temperature 20
There's a name collision possibility with this ID naming scheme, so maybe to mashup the ID such as "mqtt:bridge:mosquitto:mySensorMapper_sensor1" or set a explicit prefix there at the Topic-Autodetect decleration. I'm I correct in saying that 5th part of the ID is reserved for channel name?
4. Manual configuration of the devices with Paper UI using the afore-mentioned templates?
|
|
|
| Re: MQTT binding for ESH [message #1703527 is a reply to message #1703494] |
Sun, 02 August 2015 14:49 |
Marcus of Wetware Labs
Messages: 7
Registered: July 2015 |
Junior Member |
|
|
Hi Markus and thanks for your comments! I missed your reply yesterday while replying to Kai, but here are my comments:
Quote:
A view to the MQTT part:
You should consider to leave the payload as simple as possible. IMHO it should contains the value only.
If you would like to to add the information command / state to the MQTT part, you should add it to the topic.
Or you do not add it to the MQTT part at all and leave it configurable.
MQTT is indented so I subscribe to a topic and I get events (published messages). You should not need to encode the MQTT payload and decide if the message is of your interest.
If you ever would support broker2broker connections it is more (most) common to filter the topics.
Yes, I agree. Encoding the payload was never part of the design, but it was something that was something mentioned in earlier messages. In the current implementation when no data type is declared per topic basis, an effort is done to convert the payload to all possible data types and publish it in all possible channels (each datatype is mapped to a related channel, for example "12" to channels :string, :number etc..). But I think this will be changed when datatype is declared from now on. Also depending on which design we end up, a topic is mapped to either a channel or a thing.
Quote:
I am using the last part of the topic to code command / state (e.g. .../c and .../s).
So, you could kept a configurable topic, type, direction structure or you use the seconds part of Kai's reply - a more generic topic.
.../device1/value1/c
.../device1/value2/s
This would work if the topic generation is under our own control. However if we want to receive states or commands from applications that won't code this state/command into a topic (as in your example), then receiving states/commands would not work and so this approach would not be advisable for more general design.
Quote:
IMHO you do not need to support the auto-discover. There are to much information that have to be coded in some MQTT topics (e.g. data type etc.).
I agree that auto-discovery is not something that we absolutely need, but IMHO it would be quite nice feature for 2 use cases:
- User has multiple sensors of the same type, that each publish their states according to certain MQTT format. Instead of having to configure each sensor separately, user creates a device template that defines topics, channels, data-types etc. Also adding new sensors in the future would be snappy, without user having to sniff MQTT traffic.
- In future there might be commercial products that announce themselves and publish data via MQTT in a predefined format (such as /home/{manufacturer}/{product}/{serialnumber}/status). In this case Openhab (or other system using Smarthome) could come with device templates preinstalled, so auto-discovery would be a real zero-configuration thing!
So even if auto-discovery won't be implemented now, IMHO it would be quite important to make design decisions now that would make it possible to create auto-discovery in the future.
|
|
|
| Re: MQTT binding for ESH [message #1704119 is a reply to message #1703527] |
Fri, 07 August 2015 12:21 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Quote:How one could then refer to those thingless channels in Item decleration?
A Bridge is also a Thing, just with the special feature that it can also provide access to other Things. So you can treat it like a Thing, i.e. link items to it.
Quote:And is there possibility to subscribe to auto-detect new channels on the Bridge?
Yes, this was my idea with the "discover" parameter on the bridge. We could provide knowledge about the topic structure at a given MQTT broker through the configuration to the Bridge. When being instantiated, the Bridge can then register a DiscoveryService and put Things that match the topic structure in the Inbox.
This way, discovery can be achieved if the user can provide some infos about the topic structure. If he cannot, he can't use discovery, but he can define the channels manually in a very fine-grained way.
Quote: Topic-Autodetect mySensorMapper2 [ topicId="/home/sensors/moreComplexSensors/+/" deviceConfiguration="mySensor.xml" ]
I don't quite understand what you are trying here. Is this supposed to be a Channel or a Thing on this Bridge? When textually defining the Things, "Topic-Autodetect" does not make much sense - that's why I called the ThingType simply "Topic" in my example. Having String configuration parameters, which implicitly expect a file name (where and how to locate this?) is imho also a bad idea.
|
|
|
| Re: MQTT binding for ESH [message #1704186 is a reply to message #1704119] |
Sat, 08 August 2015 10:33 |
Marcus of Wetware Labs
Messages: 7
Registered: July 2015 |
Junior Member |
|
|
Thanks for your input!
Kai Kreuzer wrote on Fri, 07 August 2015 12:21Quote:How one could then refer to those thingless channels in Item decleration?
A Bridge is also a Thing, just with the special feature that it can also provide access to other Things. So you can treat it like a Thing, i.e. link items to it.
Quote:And is there possibility to subscribe to auto-detect new channels on the Bridge?
Yes, this was my idea with the "discover" parameter on the bridge. We could provide knowledge about the topic structure at a given MQTT broker through the configuration to the Bridge. When being instantiated, the Bridge can then register a DiscoveryService and put Things that match the topic structure in the Inbox.
This way, discovery can be achieved if the user can provide some infos about the topic structure. If he cannot, he can't use discovery, but he can define the channels manually in a very fine-grained way.
Quote: Topic-Autodetect mySensorMapper2 [ topicId="/home/sensors/moreComplexSensors/+/" deviceConfiguration="mySensor.xml" ]
I don't quite understand what you are trying here. Is this supposed to be a Channel or a Thing on this Bridge? When textually defining the Things, "Topic-Autodetect" does not make much sense - that's why I called the ThingType simply "Topic" in my example. Having String configuration parameters, which implicitly expect a file name (where and how to locate this?) is imho also a bad idea.
Ok, now I see where our misunderstanding comes from I had trouble first understanding your example but I think I got it now. You are trying to describe (in your example) a single discovery MQTT topic "path" per bridge, whereas I was trying to include several of them into one bridge (hence Topic-Autodetect). And if I understand correctly, the Things in your example are still user-configured topics, not autodetected? (I mean, they seem to have a fixed topic in the description) But if that is the case, where and how is the channel configuration (input/output, Item type) done then with autodetected topics/devices?
My idea was to have Things as logical representation of devices, each of them having [1-N] topics. Each topic is then mapped to a channel in that Thing. Each bridge is able to auto-detect multiple different device types and this is where the Topic-Autodetect comes into picture. It is a kind of template, representing a single type of device with its own MQTT topics and channels configuration. From framework viewpoint, it is a Thing.
But I agree, calling it Topic-Autodetect was little bit confusing so lets call it DeviceTemplate instead.
If we first have an existing auto-detecting bridge with two templates:
Bridge mqtt:bridge:mosquitto [ url="tcp://192.168.1.80:1883" ] {
DeviceTemplate mySensorTemplate [ discover="/home/sensors/temperatureSensors/+/" ] {
Number : temp [ subtopic="temperature", in-type="state" ]
Number : hum [ subtopic="humidity", in-type="state" ]
String : status [ subtopic="status", in-type="state" ]
}
DeviceTemplate mySwitchTemplate [ discover="/home/switches/+/" ] {
String : status [ subtopic="status", in-type="state" ]
Switch : switch [ subtopic="switch", out-type="command", in-type="state" ]
}
}
Then we receive following messages:
/home/sensors/temperatureSensors/sensor1/status ONLINE
/home/sensors/temperatureSensors/sensor1/temperature 22
/home/sensors/temperatureSensors/sensor2/status ONLINE
/home/switches/switch1/status ONLINE
/home/switches/switch2/status ONLINE
Then those new Devices would be added to the bridge as new Things (and use DiscoveryService as you would suggest). Note that below I'm not talking about the configuration file anymore but I'm describing the Things, Channels and their values as they would be constructed dynamically on runtime:
Bridge mqtt:bridge:mosquitto [ url="tcp://192.168.1.80:1883" ] {
Device sensor1 [ topicId="/home/sensors/temperatureSensors/sensor1/" ] {
Number : temp [ subtopic="temperature", in-type="state", value="22" ]
Number : hum [ subtopic="humidity", in-type="state", value="undefined" ]
String : status [ subtopic="status", in-type="state", value="ONLINE" ]
}
Device sensor2 [ topicId="/home/sensors/temperatureSensors/sensor2/" ] {
Number : temp [ subtopic="temperature", in-type="state", value="undefined" ]
Number : hum [ subtopic="humidity", in-type="state", value="undefined" ]
String : status [ subtopic="status", in-type="state", value="ONLINE" ]
}
Device switch1 [ topicId="/home/switches/switch1/" ] {
String : status [ subtopic="status", in-type="state", value="ONLINE" ]
Switch : switch [ subtopic="switch", out-type="command", in-type="state" ]
}
Device switch2 [ topicId="/home/switches/switch2/" ] {
String : status [ subtopic="status", in-type="state", value="ONLINE" ]
Switch : switch [ subtopic="switch", out-type="command", in-type="state" ]
}
DeviceTemplate mySensorTemplate [ discover="/home/sensors/temperatureSensors/+/" ] {
Number : temp [ subtopic="temperature", in-type="state" ]
Number : hum [ subtopic="humidity", in-type="state" ]
String : status [ subtopic="status", in-type="state" ]
}
DeviceTemplate mySwitchTemplate [ discover="/home/switches/+/" ] {
String : status [ subtopic="status", in-type="state" ]
Switch : switch [ subtopic="switch", out-type="command", in-type="state" ]
}
}
The reference to a XML file (in my previous posts) that could also be used to describe a DeviceTemplate was just suggestion. I don't necessarily mean it has to be XML, but templates could be referenced in other ways too. My point is that templates should be able to be declared not only via the configuration file but also with a reference to external template. I mean, if in the future services and devices publish status updates in MQTT with predefined topics (such as /{manufacturer}/{product}/{serialnumber}/status), then home automation hubs (like OpenHAB) could came with pre-installed templates, which could help detecting automagically these new devices and expose their functionality. (i.e, no need to write a new plugin for the new Smart TV, just using MQTT would be enough). But I agree this is very advanced topic, and the scenario above not very likely to happen in near future. But one can wish
[Updated on: Sat, 08 August 2015 18:32] Report message to a moderator |
|
| | |
| Re: MQTT binding for ESH [message #1729009 is a reply to message #1719270] |
Sat, 09 April 2016 10:40 |
Ben Suffolk
Messages: 2
Registered: April 2016 |
Junior Member |
|
|
Good morning,
I know I'm coming to this party a bit late
I am currently developing some hardware for a project, but I want to make it as generic as possible so that it can be used for other projects / users outside of the current one.
It seems sensible for me to go down the MQTT route, and I plan to use ECH / OH2 as the user interface for this as there is no point in rolling your own when such a great project / resource is being developed.
Ultimately there will be a number of different hardware modules, each with a number of different capabilities. For instance the first unit will combine a number of power output switches, a number of switched inputs, and possibly some other sensor inputs like the current power consumption of the attached devices.
I would really like to make use of the auto discovery as discussed in this thread to make it easy for the end users, and it looks like both Marcus and Marcel have contributed some code to make this happen, which is great. Really the point of this post is to find out what the current status is of these bindings and to make sure I define the correct device tree for my hardware whilst I have a good opportunity to do so.
I was thinking of something along the lines of this (for say a device with 1 switched outputs, and 1 switched inputs, and 1 current sensor) :
All entires to be under the root of <Some Root>/<Serial Number>, then having something like this :
/status = [ONLINE|OFFLINE]
/1/type/switch = [SWITCH]
/1/status = [ON|OFF]
/2/type/relay = [RELAY]
/2/set = [ON|OFF]
/2/status = [ON|OFF]
/3/type/current_sensor = [CURRENT SENSOR]
/3/status = [1.23]
The idea being that you can have any number of inputs or outputs, all with standard commands (/set to update an output, and /status to read a value) and the (/type) to find out what sort of device it is. I was then thinking that using a number of templates as described above the discover could look for <Some Root>/+/+/type/switch and <Some Root>/+/+/type/relay etc. However that relies on 2 sets of the numbers to make up the effective device id (e.g. <Serial Number>/<Element> so I wonder if I would be better actually combining the Serial Number and Element into a single ID so it looks like a number of different devices, e.g. <Some Root>/<Serial Number>:1/type/switch and <Some Root>/<Serial Number>:2/type/relay
What are your thoughts?
Regards
Ben
|
|
| | |
Goto Forum:
Current Time: Sat Nov 09 03:30:11 GMT 2024
Powered by FUDForum. Page generated in 0.05585 seconds |
] 
Search
Help
Register
Login
Home
