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

Add-ons Bindings
21

So you are saying that OH 2 is moving away from supporting Action bindings at all? By this logic either OH 2 shouldn’t support Actions at all or I don’t see why MQTT is any different from Telegram or email or Prowl.

Why not?

If retaining the ability we currently have to generate both the topic and the payload for messages in Rules saving the effort in creating dozens of special purpose Things/Channels isn’t enough justification in and of itself, then so be it. I think it is pretty hostile to the old timers who currently depend on this capability though.

Since we are talking about topics that OH publishes to, these are topics that I don’t think we can rely on them being automatically discoverable since they may not exist until OH publishes to them. So we are looking at manually creating Things.

So we are going from something like:

    publish("actuator/"+triggeringItem.name+"/cmd", "ON")

To creating N things with 6+ clicks and two fields manually typed out per Thing plus 2+ more clicks to create the Items.

As I said before, CAN we do this by manually defining Topics and Channels? Probably yes. But it feels like a step backwards, not a step forward.

But I don’t personally really have any strong issue either way. I don’t use the MQTT Action personally so it isn’t going to impact me personally. But I can foresee a number of users being a little upset about this reduction in capability.

1 Like
22

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

23

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)

24

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

25

@kevin,

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

2 Likes
26

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 :slight_smile:
Will see what I can do over the weekend

27

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

28

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.

29

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

30

I have added the missing piece ^^. Follow:

1 Like
31

Can you explain that, please?

32

@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?

33

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

Screenshot%20from%202018-10-19%2023-17-12
Screenshot from 2018-10-19 23-17-12.png1367×721 39.9 KB

There is no documentation for this yet.

Documentation for the MQTT Broker configuration binding is here:

Documentation for the MQTT Things binding is here:

34

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" }
35

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

36

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
1 Like
37

@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:

  1. 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?

  1. 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.

38

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

  1. 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

39

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

40

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?

1 Like