Mqtt 2.5

Hey all,

I have prepared some additional features for OH 2.5 snapshot users. Probably not in before Christmas, but soon after.

The readme got extended with some rules to realize what the MQTT eventbus binding did in 1.x and migration hints for mqtt1 --> mqtt2.

And also:

  • Allow outgoing transformations.
  • Allow chained incoming transformations.



Is the outgoing transform a stop gap solution until such time that a more generic way can be implemented in the core infrastructure? Or is a more generic solution so far off as to just be a wish?

Don’t get me wrong, I’m thrilled to see the capability come back. I’m just curious.

Exactly. The transformation service is cached to at least avoid the service lookup on every publish.
I still not recommend a heavy javascript transformation, but some people might just need a MAP one.


Hi David, et al,

Thanks for the great work on the MQTT binding.
I upgraded (without reading the release notes, auch) and found the new binding to require me te rewrite my .items and .things files. But glad I spend the time. Works great.

How would I use / test the 2.5 binding ?
(I’m using an apt based install).


Kind regards,


For the moment there is no other way than to use the snapshot version of openHAB (or to build from source of course).

Sorry, if I’m asking, but I’m still a bit confused :wink:
Presently I use the MQTT-Eventbus for integrating three OH2-instances, works flawlessly.

If I understand correctly, MQTT2.4+ doesn’t offer eventbus-functionality (as of yet). Are there any plans to implement something like eventbus in 2.5+?
So I presently should stay with MQTT1 and migrate later?

Eventbus access is not allowed for oh2 bindings. If you want it like it is with mqtt1, you unfortunately need to stick to v1. In oh2 you use rules/scripts instead to get a similar behaviour.

What I can imagine to be possible is a real add-on dedicated to connect multiple oh instances. Might use mqtt internally via the new mqtt support.

1 Like

thanks. now I understand!

PS: Rules and scripts Sound a bit odd to have a simple eventbus-sync. So my opinion is, a “eventbus add-on” would be a real need - I can imagine, I’m not the only one having multiple OH2-instances… :wink:

@David_Graeff I just updated to SNAPSHOT-2.5.0~S1498 to be able to use the min/max scaler on dimmer channels, but its not scaling the output only the input. From what I can tell it shouldn’t be doing that.
Do I need to manually updating the binding to the copy on github for that?

The documentation says “outputs a value between 0 and 100”. As long as that is in the “latest”-section of the documentation, the corresponding change that I made recently is not yet available for openHAB.

In the future the output will be scaled as well, true.

Hi David, is there any news with regards of mqtt 2.5 outgoing transformation? I’ve moved to 2.5 snapshot, but I couldn’t found any info about it.
Thanks in advance!

This is the pull request. And as you can see, I did not have time to continue to work on that :confused:

Cheers, David

I updated to OpenHAB 2.5.0-snapshot to fix some annoying bugs but I still noticed a big one in the MQTT binding or maybe in OpenHAB itself?
My mqtt payload is {"battery":100,"voltage":3032,"linkquality":60,"click":"single"} and I’m using the transformationPattern to get the click value.

Type string : click "Click"                    [ stateTopic="zigbee2mqtt/<DEVICE_ID>", transformationPattern="JSONPATH:$.click" ]

When I press the button twice, the first time it will set the value to single but the second time it will not change the item again because the value stays the same. I’m listening on item changes with node red. Right now it’s not possible to turn a device on and off with a single click.

A stateful channel will only pass a value to an item if the value actually changed, that is correct.
You want the “trigger” channel of the mqtt broker thing instead. If fires every time when a value is received.

The issue is, that you cannot apply a transformation before the condition (fixed string) is evaluated. You probably need a rule in this case.

Cheers, David


any update on when the MQTT outgoing transformations will be implemented? I still have both the old MQTT and the new MQTT binding “working” side by side, but yesterday, for the second time, somehow the old binding stopped working. I’m not sure what I did last time to get it working again, but it would be great if we were able to migrate everything to the new binding.

Thanks for a heads.

It is implemented since two months or so :slight_smile: Just remember that openHAB has no “stable” / “unstable” branches that gets any backports of later changes (we just call it “stable”). You must be on openHAB snapshots to get those changes.

The timing is just really bad at the moment, because openHAB is in the process of changing the build system. The snapshots sporadically do not work since that process started end of January and is finished by maybe end of the month.

Cheers, David

Ok. I thought there was something still missing in the binding (either incoming or outgoing transformations (I need both).

What would be your advice? Wait till that build system change process is over?

Hi, i updated to Snapshot version but i couldnt find description of how to use outgoing transformations for mqtt, do you have a readme or link to examples? Thank you!

Look at the examples for incoming transformations, outgoing are working the same. It’s self explanatory in Paper UI so I don’t really get your question.

Outgoing transformations are available in OH 2.5 Milestone 1 which was released prior to the changes David described.