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

AndreasBrett · December 13, 2018, 12:54am

I really can’t tell as I haven’t had the time to check the specs for MQTT about allowed payload formats. I can work around those 2 issues like you mentioned and I see your concerns but then again: it’s always sad to lose functionality with an update.

rlkoshak · December 13, 2018, 3:03am

My only complaint with this attitude is that many or most of us do not have the ability or the control necessary to forever the end device to change. I’ve seen you respond severally times with "tell Shelly/Tasmota/ESP Easy to use Homie. That’s all well and good if they do that but in the mean time is as oh users are screwed and if they never adopt homie we are permanently screwed.

This is a similar situation. If we can’t change the end device we are screwed. There is no help from oh. Conform to OH items or remain incompatible. Why support transforms at all? Just change the end device, right?

I seriously doubt it is more efficient to call a transform from a rule and it is a significantly more amount of work for the end OH user. This really feels like letting the beauty of the coffee take precedence over the users.

Over all it really comes across as antithetical to what OH stands for. We are an adapter that lets different technologies interoperate. We are not a system that imposes requirements on third parties before we deign to work with them.

Personally, if it were up to me I’d pull transformations out of the bindings entirely and implement a service that lets us use transformations with ANY binding.

So the stance for the MQTT binding is force the end device to conform to OH and if you can’t do that go pound sand. Not very user friendly.

David_Graeff · December 13, 2018, 6:28am

It is really just the js transformation that concerns me, which is relatively new. The framework and they way how to resolve a transformation within bindings does not feel prepared for this. If I would at least be allowed to cache the transformation as a binding developer.

And no this is not against users this is to prevent heavy abuse because there are more and more OutOfMemoryExceptions happening.

I think with the formatter for outgoing messages you can already do a lot. The only thing not possible is split a complex type into its components and convert a state to something completely different.

Personals I think this can only be solved efficiency within the core. As you suggested. Generic bindings like mqtt,http,coap should not offer transformation options at all, but the framework should bring support for it.

Cheers, David

vzorglub · December 13, 2018, 7:15am

How heavy? This for the user to decide.
A warning in the docs should inform the user.

The new binding should strive to have ALL the functionality and flexibility of the old one.

David_Graeff · December 13, 2018, 7:59am

I agree. In the mid-run a solution in the ESH core can be found, I’m sure. Just before the release of 2.4 the binding and core cannot be changed that fundamental anymore though.

vzorglub · December 14, 2018, 10:13am

User case for outbound transformations.
I really think this important despite your reservations about performance issues.

See:

Where the user is using a MAP transform outbound

I have my own case where, when I started in HA, I mage my own arduino device to control 433MHz devices.
I made some design “errors”. The value for of is 0 and for ON is 9
The reason for this was htat I could have settings it between.
I still have two of these legacy devices, they are hard to access AND I have lost the original code.
I don’t want to write that code again. I don’t want to spend hours accessing those devices. They are very reliable.
What I want is being able to send 0 for OFF and 9 for ON. To do that I currently use the MAP transform.

Switch	LivingRoom_WallLights         "Wall Lights"                  (LivingRoom, MaghribLights, SunsetLights)            [ "Lighting" ] { mqtt=">[mybroker:ESP8266/LivingRoom/WallLights:command:*:MAP(off0on9.map)]" }

How can I achieve that with the NEW binding?

David_Graeff · December 14, 2018, 2:03pm

You can’t. Use mqttv1.

Cheers, David

vzorglub · December 14, 2018, 7:14pm

That is very helpful. Thanks for listening to users needs. You did for the mqtt action. Why not this?

David_Graeff · December 14, 2018, 7:43pm

I have responded already. Just two post above.

thaasoph · December 16, 2018, 4:56pm

I have tried to use one of my contact sensors over the new MQTT binding but for some reason I can’t get it to work at all.

My mosquitto is working fine and the state changes get published properly on the configured topic but for some reason I cannot get any state change of my Items whatsoever.

I have boiled down my configuration as much as possible in order to eliminate possible causes of errors.

mqtt.things:

Bridge mqtt:broker:mosquitto "local mosquitto" [ host="localhost", secure="OFF" ]{
    Thing mqtt:topic:xcontact {
    Channels:
        Type contact : contact "Xiaomi Contact" [mqttstate="deconz/contact/16"]
    }

    Thing mqtt:topic:xcontactString {
    Channels:
        Type string : contactString "Xiaomi Contact String" [mqttstate="deconz/contact/16"]
    }
}

It doesn’t seem to make a difference whether I use this notation or “Thing topic xcontact”.

mqtt.items:

String ContactString "[%s]" { channel="mqtt:topic:xcontactString:contactString" }
Contact XContact "Contact"  { channel="mqtt:topic:xcontact:contact" }

sitemap:

Text item=ContactString label="Buttonevent [%s]"
Default item=XContact label="Contact"  icon="door"

Is there anything I can do to debug this issue further? According to the log the binding does connect to the broker but after that I cannot achieve any state change.

jongj · December 16, 2018, 5:23pm

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.

David_Graeff · December 16, 2018, 5:30pm

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.

jongj · December 16, 2018, 5:38pm

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

Dome · December 16, 2018, 6:53pm

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

vzorglub · December 16, 2018, 7:05pm

That’s what I did yesterday. Thanks

meingraham · December 16, 2018, 7:43pm

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?

David_Graeff · December 16, 2018, 7:59pm

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

thaasoph · December 16, 2018, 9:32pm

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?

David_Graeff · December 16, 2018, 10:13pm

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

antares2001 · December 16, 2018, 10:37pm

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