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

I just tried the new MQTT binding (M8) and have some observations.
The textual thing type definitions in the examples seem to be wrong:

    Channels:
    Type switch : lamp "Kitchen Lamp" [ mqttstate="lamp/enabled", mqttcommand="lamp/enabled/set" ]

this should be:

    Channels:
    Type switch : lamp "Kitchen Lamp" [ stateTopic="lamp/enabled", commandTopic="lamp/enabled/set" ]

Also when I try to define a datetime channel like this:

    Channels:
    Type datetime: latestReportTime "Report time" [stateTopic="devices/atag-one", transformationPattern="JSONPATH:$.latestReportTime"]

I get this error message:

2018-12-16 17:47:30.966 [ERROR] [.thing.internal.GenericThingProvider] - Channel type mqtt:datetime could not be resolved.

and the last one, values between 0 and 100 seem to be devided by 100.

2018-12-16 18:12:11.584 [vent.ItemStateChangedEvent] - mqtt_topic_atag_current changed from 0.59000000 to 120
2018-12-16 18:12:38.700 [vent.ItemStateChangedEvent] - mqtt_topic_atag_current changed from 120 to 0.60000000

The incoming mqtt topic values where 59, 120 and 60.

The datetime channel is only available with rc1. The error on the number channel is also resolved with rc1.

Thanks, Iā€™ll fix that quickly.

Edit: Done.

The 2.4 release and website documentation together with the release should contain the correct example.

And what about this one? https://github.com/eclipse/smarthome/blob/master/extensions/binding/org.eclipse.smarthome.binding.mqtt.generic/README.md

edit:
thats covered by this https://github.com/eclipse/smarthome/pull/6687/commits/04d0f55efb4961990890c2715ee0e1f1099d20e0

@vzorglub While this doesnā€™t address the underlying frustration or problem, one possible workaround is to utilize nodeRED to perform the necessary transformations. Cumbersome, I know, but in your case it would only need to be set up for two items and would allow you to completely shed MQTT v1.

You could leave your openHAB items without channel definitions and simply have nodeRED pull in and transform, then output to an MQTT out channel. Or, you could pull the data in with an MQTT in node.

Iā€™m learning node-RED right now, and as they say, when all you have is a hammer, every problem begins to look like a nail! :grinning:

Thatā€™s what I did yesterday. Thanks

1 Like

Is there an alternative to having to use Node Red? Although NR is on my ToDo list, right now itā€™s a nice to have vs. a must haveā€¦ at least in my setup. I have not installed and thus not learned to use NR. Iā€™ve been following this thread, but may have missed alternatives. Would receiving the MQTT payload in OH be done by subscribing one Item to it, trigger a rule to perform the transformation and then publishing via MQTT using the MQTT Action to deliver the intended message to the actual destined Item?

Yup. For now. Iā€™m sure there will be an easier way in OH 2.5.

Is there a known issue when trying to configure a MQTT thing via the .things file?
When I try to configure a MQTT thing and take a look at it in the Paper UI the channels looks like this:

mqtt:topic:mosquitto:xcontactString:contactString

which corresponds to:

mqtt:topic:<broker>:<thingId>:<channelId>

Isnā€™t that wrong? Shouldnā€™t it be:

mqtt:<broker>:topic:<thingId>:<channelId>

Could this be the reason why I cannot get any messages at all to my items?

Bindings do not need to explicitly support textual configuration. If Paper UI works, the textual configuration works as well. The example of the readme file is working, too.

Cheers, David

Hello,

I installed the new binding today, and am running into trouble that my eventbus stuff is not working any more (i.e., multiple OpenHAB instances talking to a main one).

My eventbus was configured like this:

broker=mosquitto
commandPublishTopic=/server/out/${item}/command
stateSubscribeTopic=/client/out/${item}/state

Now thatā€™s not working any more. How do I configure a replacement in the new binding? I donā€™t get it from the UI (or the textual setup).

Or other question - can I go back to version 1 somehow? Itā€™s not listed in bundles in PaperUI and Iā€™m currently stuck in a totally non-working system (with 6 OpenHAB client instances and > 150 devices)ā€¦ not good at all. :frowning: worst is that I installed it by accident, as the latest nightly 2.4 OpenHAB version reported me some issues with mqtt binding so I thought Iā€™d go and reinstall itā€¦ and got stuck.

1 Like

Event bus is not supported in the 2.4 version binding. You can fairly easily recreate that capability though by adding all the items to a Group and using the MQTT Action in a Rule to publish updates and commands and changes to the proper topics.

Because there is now at.x Verizon of the binding the 1.x version is now considered ā€œlegacyā€. By default Paper I will not show legacy bindings. You can change that in configuration system settings. There has an option labeled something like ā€œshow legacy bindingsā€.

Now that the 1.x and 2.x bindings can happily coexist on the same OH.

1 Like

@meingraham @vzorglub
Maybe check out ā€œHABAppā€? MQTT support is only available in the dev branch but Iā€™ll merge it this week.
It would allow you to directly connect to your mqtt instance, trigger on value and then publish it again.
Also you can write rules in plain python which is very nice. :slight_smile:

Hello @rlkoshak

thanks for your reply. Hmmmā€¦ thatā€™s a pity as the eventbus fairly easy enabled me to have such a complex system running without a bigger overhead on configuration, as everybody got notified properly. That puts a bigger hurdle in front of me. Sure I can put all devices into a group but thatā€™s quite some effort (Iā€™m not talking of an installation with 3 devices but perhaps not yet big but quite large installation) and I need to do it on all the instances I have running. And then I still need to figure out a proper rule for that. For somebody on full time work and whoā€™s just become father a bit challenging. :wink:

Especially when considering that everything used to work really well with the 1.x binding and IMHO it would have been nice if features were not stripped out of the system with the new version as this possibility to run multiple instances was one of the main killer-features that let me chose OpenHAB (the nicest thing was that it used to work via VPN even for the home of my parents that I could take care of when they werenā€™t there).

If thereā€™s anywhere a hint of how the rule(s) for this should look like, I would be really gracious to get some help on that.

Also I noticed that the documentation for the v2 binding seems not in place (when I click on the binding name in Paper UI, it gives me a 404 error page).

1 Like

MQTT v1 is still available.

As expected the openHAB 2 version works different, because it takes all the new concepts like Things and Channels and the new automation engine into account.

The sender side is actually not complicated, if Paper UI would support the new automation engine in all detail already, you could even do this graphically. You want a rule that triggers on any item update and push the item id and item value via the (new) MQTT action.

The receiver side is simple as well actually. You configure a trigger channel on your Broker Thing and in a second rule, react on that trigger, extract the item id and state and post it to the eventbus.

There will be a Rule Template, encapsulating those two rules for easier handling soon.

Cheers,
David

2 Likes

I am giving up on this binding!!!
Textual things throw warningsā€¦
And the breaking point is that after a restart ALL items are in UNDEF state and because of the order in which things are done during restart the restoreOnStartUp doesnā€™t work. OH restores and then the binding puts everything on UNDEF.
Unworkableā€¦

Hello @David_Graeff

thanks for your reply. It would really be helpful to have some kind of tutorial explaining how to mimic the old eventbus behavior. I get that it might make from a software engineering perspective make sense to have this overhaul of the binding, but it should be ensured that stuff that used to work still works (or can be achieved without too much of a hassle even on existing installations that have grown ā€“ I think thatā€™s anyhow where MQTT makes sense, as for a one-system / 2 z-wave switches systems you wonā€™t need MQTT).

I switched back to the 1.x binding (by rolling back my OpenHAB installation a version) but I am also aware that at some point in time the 1.x binding is going to be broken if thereā€™s major architectural changes in OpenHAB so I want to switch to the new binding but of course all has to work as before (and not cost me days of reworking the setup).

Thanks again and Iā€™m looking forward to a tutorial or templates for the rules.

1 Like

That looks like a nice addition to have this as a configuration option. You can use MQTT in different ways. If you fully go with retained topics, the binding is expected to put items to UNDEF if the retained topic vanished.

Could actually be made smart instead. If the channel is retained, the items are put to UNDEF, if the channel is not retained, the item state is not touched, or similar.

See https://github.com/openhab/openhab2-addons/issues/4393

I donā€™t use retained topics, I use restoreOnStartup.
So OH restarts, the items get restored from MAPdb, the binding kicks in and put all the items to NULL and then to UNDEF. restoreOnStartup out of the windows. How do I get my values back? WITHOUT using MQTT retain because itā€™s a pain in the neck.

2 Likes

You really donā€™t need to do that. The mqttv1 binding is still available for OH 2.4 and can even coexist with the new binding. You just need to enable the legacy addon repository