I have been struggling for 2 days after upgrading from OpenHAB 2.1 to 2.4, but gave up the migration towards the new MQTT binding. I also use JSON transformations, so I will stick with the old mqtt 1.3 binding until there’s a more stable version (and hoping for better documentation on the JSON specifics)
The mqtt2 binding is actually way more stable than mqtt1. Automatic test suits, newer paho library, asynchronous receiving and sending. But it is fully building on OH 2 concepts. And if you have avoided to learn the new concepts so far (probably because you have migrated from OH 1), it will be difficult to understand why the new binding does things more “complicated”.
The same problem here. At the moment it isn’t as flexible as the good old one in my eyes. For my dimmer it is neccesary to transform a value form 0-100 to 0-255 before publishing (subscribing the other direction). With the old one I can use a scale for it
That’s not true. I got it working. Can’t show my config because I’m restructuring every MQTT-Things right now to thing-file-based config. Basically I followed these instructions:
I entered the Javascript transformation as a single line into PaperUI. It worked.
As soon as have my file based config running. I’ll let you know…
I also tried it and had some problems - I found out that the “outgoing transformations” feature is coming in version 2.5 which will definitely help in make this work again.
For On/Off and Color Temperature I got it working using the formatBeforePublish feature:
formatBeforePublish="{\"color_temp\":%s}"
The problem with Brightness and Color Temperature is the value range (0-255 and 133-526) that can’t be send by using a slider or dimmer. With the old binding I used a JS transformation.
There is a discussion at the Zigbee2MQTT Github (" Option for non-JSON output #493") to get a feature that one can have the JSON path changed to MQTT channels but it seems to me that the intersection of openHAB and Zigbee2MQTT users is not that big.
Fortunately I got all my Xiaomi devices running with the new MQTT binding and Zigbee2MQTT. Transforming incoming JSON messages using transformationPattern is working very good so far.
Thx, this helped alot. Finally i can control my lampy lamp with paper ui.
...
Channels:
Type switch : state "lamp" [ stateTopic="zigbee2mqtt/lamp", transformationPattern="JSONPATH:$.state", commandTopic="zigbee2mqtt/lamp/set", on="ON", off="OFF", formatBeforePublish="{\"state\":\"%s\"}" ]
Now it really publishes
{“state”:“OFF”}
to the topic. But holy, thats complicated.
Do you have already found a workaround for the rgb problem?
but it seems to me that the intersection of openHAB and Zigbee2MQTT users is not that big.
Think so too. Thats why i am running homeassistant and openhab parallel to compare and to find the best solution for me… the inbuilt discovery from hass is much better than ohab though.
We have that too but using a different MQTT convention (“Homie”). HA developers were really active in the meantime to push their MQTT HA components discovery into many open source projects and we have to catch up to promote our convention. Battle of the giants, I guess.
Yea i know, that’s no offense. I know ur putting much work into the addons. But do you maybe know if there is an alternative way to use zigbee2mqtt (or a similar tool) with e.g. homie convention, to get my zigbee gadgets connected without using a manufactorer’s (zigbee)gateway?
I’m using the deconz software on the same raspberry pi then openHAB and a 30€ raspbee Zigbee dongle.
The deconz software is emulating a hue bridge but with realtime support and we have a binding for that since OH 2.4.
At some point someone should add Homie to zigbee2mqtt. I’m just a bit busy with the new Paper UI design study at the moment.