[CLOSED] MQTT binding version 2.4 (Pre-release !)

David_Graeff · October 17, 2018, 7:06pm

I seriously don’t know about any plans for the long run. But at the moment there is no developer interface to create new actions like the mqtt1 action. You always need to depend on OH1 legacy bundles.

But I guess there will always be a component for dynamicly interacting with the outside world (for instance generating a mail with generated receptioners), may it be actions or the new rule (automation) system.

But at the same time in my opinion the mantra should be: what can be statically defined, should be statically defined. And you are creating the 10 things or channels only once.

Mqtt has no other benefit over the telegram protocol than that it is an open standard, I guess.

If time permits I will look into the automation framework and integrate mqtt into it.
Cheers, David

christoph_wempe · October 17, 2018, 7:27pm

I 100% agree with @rlkoshak.
Even though I cannot name a specific use case, either.

May this is something to discuss at the up comming SmartHomeDay in Stuttgart.
(But I will not be there)

kevin · October 18, 2018, 9:06am

I use MQTT action to send a constructed string to a set of SOnOff Tasmota devices. My use constructs a String consisting of “cmnd/“ plus a “device name”.toString generates from group membership plus “/AP1” to reset its default access point to the closest one. I also use something that is basically the same with “/reboot” on the end to reboot them every 28 days based on the reported uptime.
It would be very useful if the new binding could allow this as I have a lot of SOnOff’s to manage

vzorglub · October 18, 2018, 9:11am

@kevin,

That’s interesting
Could you write up a thread with these rules and setup, please?

kevin · October 18, 2018, 9:18am

I can but it’ll take 24 hours as I’m away from my PC, and it’ll need simplifying as it’s part of a very complicated rule
Will see what I can do over the weekend

vzorglub · October 18, 2018, 11:00am

There a case for using the MQTT action to avoid a binding loop

David_Graeff · October 18, 2018, 11:16am

In the mean time I figured that the two new bindings “MQTT Broker configuration” and “MQTT Things” are actually not responsible for what you guys asking for. A new binding, a spiritual successor of the MQTT actions binding, is required that builds up on the new automation engine.

David_Graeff · October 18, 2018, 11:18am

Actually, nowadays you would solve this with a Profile that keeps two items in sync, I guess. But never mind there are many ways to Rome and many solutions to a problem.

Cheers, David

David_Graeff · October 18, 2018, 11:43am

I have added the missing piece ^^. Follow:

vzorglub · October 18, 2018, 11:56am

Can you explain that, please?

vzorglub · October 19, 2018, 8:39pm

@David_Graeff
David,
I have looked for the documentation for the new binding but I could not find it.
I really would like to familiarize myself with this as I am one one the most active MQTT helpers here.
Do you have a link I could follow, please?

David_Graeff · October 19, 2018, 9:21pm

This is how the not yet included integration of MQTT in the new Rule engine looks like:

There is no documentation for this yet.

Documentation for the MQTT Broker configuration binding is here:

github.com

eclipse/smarthome/blob/master/extensions/binding/org.eclipse.smarthome.binding.mqtt/README.md

# MQTT Binding

> MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol.
> It was designed as an extremely lightweight publish/subscribe messaging transport.

MQTT is a server/client architecture.
A server, also called broker is not provided within this binding,
but it allows to detect running brokers and to manage connections.
The hereby configured broker connections make it possible to link MQTT topics to Things and Channels.

It has the following extensions:

<!--list-subs-->

## Supported Bridges

* Broker: This bridge represents an MQTT Broker connection, configured and managed by this binding.
* SystemBroker: A system configured broker cannot be changed by this binding and will be listed as read-only system-broker.

## Bridge Configuration

This file has been truncated. show original

Documentation for the MQTT Things binding is here:

github.com

eclipse/smarthome/blob/master/extensions/binding/org.eclipse.smarthome.binding.mqtt.generic/README.md

# MQTT Generic Thing Binding

> MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport.

This binding allows to link MQTT topics to Things.

## Supported Things

There a few Things dedicated to MQTT conventions available and a Generic MQTT Thing.
The last one is comparable to what was found in the mqtt 1.x binding. 

### Homie Thing

Devices that follow the [Homie convention](https://homieiot.github.io/) 3.x and better
are auto-discovered and represented by this Homie Thing.

Find the next table to understand the topology mapping from Homie to the Framework: 

| Homie    | Framework     | Example MQTT topic                 |
|----------|---------------|------------------------------------|

This file has been truncated. show original

vzorglub · October 19, 2018, 10:13pm

Shouldn’t the example item:

demo.items:

Switch Kitchen_Light "Kitchen Light" {mqtt="<[...], >[...]" }

Be like this instead:

Switch Kitchen_Light "Kitchen Light" { channel="mqtt:mybroker:topic:mything:text" }

David_Graeff · October 19, 2018, 10:57pm

This and other issues in the readme are fixed in a not yet included pull request.

kevin · October 20, 2018, 2:15am

The rule to reset the Tasmota ESP devices to the correct access point using MQTT Action is below - each device that runs on the lower access point is a member of the group “LowerAP”

rule "Reset AP" when Item ResetWiFi received command then
LowerAP.members.forEach[ WiFiItem |
publish("ESP", "cmnd/" + WiFiItem.name.toString + "/AP", "1")
]
end

reinhold · October 20, 2018, 10:02am

@David_Graeff First, thank you very much for taking on the much-requested OpenHab 2.x MQTT binding! That was really somthing that was missing terribly from OpenHab so far. I have to admit, I did not test the binding so far, because it seems it is not yet included in milestone builds… So everything I say here is deduced only from the documentation and this thread. Please correct me if I misunderstand anything.

Now, in my use cases (RFLink-to-mqtt bridge, zigbee2mqtt bridge, ESPEasy sensors & actuators) I have two issues:

Several nodes do not send individual topics for its sensor value, but send one JSON-encoded array containing all information. E.g. topic /RFLink/sensors/Alecto V1/00bc

    {"Family":"Alecto V1","ID":"00bc","TEMP":17.1,"HUM":67,"BAT":"OK"}

Currently, I’m using a OpenHab item like:

    mqtt="<[mqtt:/RFLink/sensors/Alecto V1/00bc:state:JS(MQTT_BatteryState.js)]"
    mqtt="<[mqtt:/RFLink/sensors/Alecto V1/00bc:state:JSONPATH($.TEMP)]"

If I understand the documentation correctly, this is not possible with your new mqtt binding?

Some of the devices connected via MQTT provide commands that allow switching devices on/off. There is typically a dedicated mqtt topic for each device whereyou can send your commands to. E.g. my ESPEasy-based humidifier:

Switch Venta_Power "Venta LW45 Ein/Aus" <power> (power) { mqtt="<[mqtt:/Venta/Venta/cmd:command:ON:ventapower 1], >[mqtt:/Venta/Venta/cmd:command:OFF:ventapower 0], <[mqtt:/Venta/Venta/Power:state:MAP(OnOffBinary.map)]" }
Number Venta_Level "Venta LW45 Level" <power> (power) { mqtt=">[mqtt:/Venta/Venta/cmd:command:*:ventalevel ${command}], <[mqtt:/Venta/Venta/Level:state:default]" }

Of my Sonoff S20 plug (running tasmota):

Switch Power_SonoffS20 				"Strom Sonoff S20"	<poweroutlet>	(power)
    { mqtt=">[mqtt:/sensors/sonoff/s20/cmnd/POWER:command:*:default],
            <[mqtt:/sensors/sonoff/s20/stat/POWER:state:default]" }

It would be great if the mqtt binding could also support those actions of the old mqtt binding.

David_Graeff · October 20, 2018, 1:39pm

I think that 1) is already possible with the transformation that you can apply for received values.

you need the mqtt automation module to send arbitraty values to arbitrary topics. Or alternatively would it be helpful if commands could have a transformation applied as well?

Cheers David

vzorglub · October 20, 2018, 2:02pm

Yes please
And could ALL transformations be possible as well, please for the inbound messages. REGEX is particularly useful

reinhold · October 20, 2018, 2:31pm

About 1) (the node sends all its sensor values in one combined JSON):
Once the binding is available for testing, I’ll try it out. From the documentation I thought that the thing’s variables/channels would be auto-detected from the homie topics. Probably I simply misunderstood the docs…
In my case, the topic name does not follow the homie specification, but all variables (temp, humidity, battery, etc.) have the exact same topic. So I probably just misunderstood the auto-detection of the channels. If each entry of a json-encoded value can automatically create a separate channel, then all is fine.

For example, my outside thermometer sends all data combined as one JSON object to one mqtt topic (/RFLink/sensors/Alecto V1/00bc):

    {"Family":"Alecto V1","ID":"00bc","TEMP":17.1,"HUM":67,"BAT":"OK"}

From this, I would expect one thing with 5 channels to be auto-created:

Family
ID
Temperature
Humidity
Battery (with a transformation from “OK” to ON)

Similarly, the Tasmota firmware of my Sonoff devices sends all “telemetry” data as JSON to /sensors/sonoff/s20/tele/STATE, while the MQTT thing should create one channel for each entry of the JSON.

About 2) (setting an item value needs to send to a different mqtt topic than reading the value):

I’m not using commands explicitly, but simply set the OpenHab item’s value to e.g. ON or the level. So far, the mqtt item’s definition itself handled sending the appropriate mqtt value to the correct topic. In my example for the Venta_Level, I simply set the item Venta_Level to 3 and the current mqtt binding will use the item definition to send the command “ventalevel 3” to /Venta/Venta/cmd.

Where would I define the commands’ transformations in the PaperUI for the channel/item link?

reinhold · October 20, 2018, 6:52pm

Okay, I finally figured out how to try out the new mqtt binding with OpenHabian: You need to manually DOWNGRADE from the M4 milestone build to the daily snapshot! Apparently the debian versioning system regards M4 as a higher version number than 20181018…

Anyway, I now have a test installation up and running and I must say, I’m impressed. And I take back most of the things I said in the previous post.
As you have to manually create the channels for each variable manually (with a different command topic where applicable), you really have all the flexibility that one needs. For my example of the RFLink thermometer, one can easily set up three channels with the same topic and use different transformations (you need to press “Show More” to show the input field for the transformation, but then you even get the nice hint how to use it).

So, the only thing that is left is the transformation for the command. To turn the Venta humidifier on, I need to send “ventapower 1” to the command topic rather than only the item value 1. Similarly, to switch to a given level, I need to send “ventalevel [level]”. Having a command transformation would be very helpful.
In the old mqtt binding, the transformation for the level was simply ‘ventalevel {command}’, while for the on/off command I had to condition on the current status and send the opposite status, i.e.

mqtt=">[mqtt:/Venta/Venta/cmd:command:ON:ventapower 1], 
>[mqtt:/Venta/Venta/cmd:command:OFF:ventapower 0]"

Another issue I encountered was that the temperature was defined as a decimal, but at least the display in PaperUI showed it as integer. So even though the thermometer resported a temperature of 15,6C, the PaperUI showed 16C.