The MQTT support uses the eclipse paho library as a base. Recently that was updated to the newest version for extended features.
It could be, that mqttv1 now eats up threads over time, because the disconnect API behaves slightly different now. If I find time, I’ll have a look at the that old code.
My first attempt is not successful. I was able to get the mqtt2 binding working correctly and I can control the switch via this binding now. But after the 4 channels were created I got 4 switches in PaperUI Control as well, which do not change, if I’m switching the on the device itself. I’ve made something wrong…
Paper UI will show you 4 switches that is correct. Paper UI is a maintenance solution and not perfect in regard to visually displaying controls.
But if you operate one switch all others should be in sync. AutoUpdate behaviour might need to be set to follow if you have manually set it to veto.
All switches have their correct state topic set? Have you tried to turn on the “is command” configuration option? I’m not sure if that is required in this configuration.
just in sense of transparency: I’m using OH 2.3 with MQTT 1.12 binding and no issues at all. BUT I’ve scheduled a restart of OH service each night 3am in order to avoid issue e.g. when I unplug and reconnect my logitech harmony devices. That means, MQTT binding will never run more than 24hours. Within these 24hours everything works like a charm.
That’s ok for me. Just wanted to make sure, that I’m using the correct channel type. Later on I’m using HABPanel for controlling everything.
OK. I’ve found the issue. The state topic was wrong. Now it works correctly! Many thanks!!
Is it possible to configure the whole thing with a configuration file? Currently I’m using 7 Sonoff switches and configure all of them via PaperUI is annoying. Based on the example for configuring things in configuration files I cannot figure out how to configure it, because the mqtt2 binding does still not have a valid documentation, that I’m aware of.
Thanks for the idea, but I’m not really thrilled by the idea of using scheduled restarts to workaround such issues, if there are other ways to achieve a reliable solution.
I’m currently in the process of migrating FHEM to openHAB. openHAB has a much cleaner configuration logic implemented than FHEM. I wasn’t able to configure advanced things in FHEM on my own after 2 years, without the use of community hints. The configuration in openHAB is much more straight-forward. However, for now FHEM was more reliable and less fragile when it comes to things like caching. But to be honest, I’ve never used MQTT with FHEM. That was the point where I’ve decided to give openHAB a try.
got it, but please keep in mind that the shared information about the scheduled restart (of the service! not the whole machine) actually wasn’t a suggestion 
I just wanted to share that within 24hours everything is fine with the MQTT service 1.12. and I didn’t implement the restart because of MQTT, but because of my logitech binding as soon as I noticed that a physical power outage of my logitech harmony hub generated problems in openhab. maybe that’s not the case anymore with the latest version. anyway, as it doesn’t harm I let it restart every night.
In an earlier response you said that we would ongoingly be able to run both the v1 and v2.4 MQTT bindings concurrently. That still OK ?
I ask because there seem to be several features in the v1 binding that are awkward or even not going to be possible in v2.4. Yes, indeed they might not have been elegant or correct but they worked. Backwards compatibility is important. There also seems to a rather antagonistic approach to solving these issues and a very dismissive view of some implementations that should be encouraged to change if they want to work with OH.
V1 works for me … my whole system revolves around MQTT and I was initially excited by v2.4 but now I’m apprehensive and indeed it’s tainted my OH comfortability a little. OH is not my only or even main controller but I sense discordances.
I believe that this is still valid (David will re-confirm for sure)
MQTTv1 will continue to use the “old” ConfigAdmin PID: org.openhab.mqtt and it’s own bundle names (org.openhab.binding.mqtt & org.openhab.io.transport.mqtt)
For MQTTv2 binding: PID: org.eclipse.mqtt and the bundles are: org.eclipse.smarthome.binding.mqtt & org.eclipse.smarthome.io.transport.mqtt & org.eclipse.paho.client.mqttv3)
You can test this theory in a demo system by installing both addons and putting some basic configs.
I used M8 and they work fine in parallel.
Because oh 1.x and 2.x architectures are so drastically different, backwards compatibility is simply not possible. See the exec 1.x and 2.x bindings and how fundamentally different they both work. This will be a similar case.
I can confirm that you can run MQTT 1.x and 2x at the same time. And so far the only thing that I’m aware of that isn’t going to be supported is translations on outgoing publishes, which you can implement in a Rule. And even this will come back eventually
But if you are expecting to be able to just copy your existing mqtt configs and go you will be disappointed. 1.x and 2.x bindings are fundamentally different.
You are late to the game to tell your requirements, at least for oh 2.4. What are you still missing from the binding?
With mqtt v1 not supported I do not mean that it will not run. But as usual in software development the underlying libraries will be updated over time and if mqtt1 at some point in the future behaves strange or limited, there will be no one that maintains the old implementation.
I would like to ask this question again, because I’m afraid this might get lost, but is essentially for me (currently I’m waiting for a response on this, before configuring everything through PaperUI). Just a hint would be great. Noone needs to create the whole configuration for me, based on my previously postest mqtt1 configuration.
Thanks in advance.
there are few users of MQTTv2 who have posted their MQTT.things configs. Check:
There were also a few more configs but I can’t find the posts atm.
I will also go for full text based configs when I decide to move away from MQTTv1 
Maybe start a new thread with your examples to avoid going offtopic in this thread
@Dim Thank you very much! When I got this running, I will share my examples, as adivsed, in a new thread.
OK. Just a short status update on the thing configuration. I got that working and I will post my solution later in a new topic. However, (@David_Graeff) for now it seems that the MQTT client behaves odd sometimes. Most of the times I saved the configuration file, the bridge or thing was in state offline or showed the state online, but in the mosquitto.log I could see that the client has disconnected after the connection was made. As a result controling my devices was not possible. After some more changes to the configuration file, everything was working properly again, but the issue occured again after additional changes. For now it seems, that after a warm restart of the openhab2 service does fix that problem.
Tomorrow I will try to dig deeper into this. If this issue only occurs after changing the configuration file but the service is working stable, that wouldn’t be something a big problem. If the client is unreliable as well, I will need to think about a workaround, as mentioned earlier by @StefanH.
I’ve created a new example topic of my currently running configuration: Using Sonoff Power Switches with Tasmota firmware and openHAB2 MQTT2 binding
@David_Graeff it seems, that my things stop working with the message “No MQTT client”, if the linked item is changed or if the channel is changed, when there is already a linked item. I fetched the following logs, after changed my mqtt.things file:
2018-12-16 12:14:11.446 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'mqtt.things'
==> mosquitto/mosquitto.log <==
1544958851: Client paho439851773078352 disconnected.
==> openhab2/openhab.log <==
2018-12-16 12:14:11.529 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'x.x.x.x' with clientid paho481440911850144 and file store '/var/lib/openhab2/mqtt/x.x.x.x'
==> openhab2/events.log <==
2018-12-16 12:14:11.541 [hingStatusInfoChangedEvent] - 'mqtt:broker:MosquittoMqttBroker' changed from ONLINE to OFFLINE
2018-12-16 12:14:11.542 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs01' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2018-12-16 12:14:11.542 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs03' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2018-12-16 12:14:11.543 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs04' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2018-12-16 12:14:11.543 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs06' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2018-12-16 12:14:11.544 [hingStatusInfoChangedEvent] - 'mqtt:broker:MosquittoMqttBroker' changed from ONLINE to OFFLINE
2018-12-16 12:14:11.544 [me.event.ThingUpdatedEvent] - Thing 'mqtt:broker:MosquittoMqttBroker' has been updated.
2018-12-16 12:14:11.556 [hingStatusInfoChangedEvent] - 'mqtt:broker:MosquittoMqttBroker' changed from OFFLINE to ONLINE
2018-12-16 12:14:11.558 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs04' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2018-12-16 12:14:11.559 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs01' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2018-12-16 12:14:11.562 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs06' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2018-12-16 12:14:11.562 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs03' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2018-12-16 12:14:11.564 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs02' changed from UNINITIALIZED to INITIALIZING
2018-12-16 12:14:11.566 [me.event.ThingUpdatedEvent] - Thing 'mqtt:broker:MosquittoMqttBroker' has been updated.
2018-12-16 12:14:11.568 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs02' changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): java.lang.Exception: No MQTT client
2018-12-16 12:14:11.575 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs05' changed from UNINITIALIZED to INITIALIZING
2018-12-16 12:14:11.578 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs05' changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): java.lang.Exception: No MQTT client
2018-12-16 12:14:11.583 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs07' changed from UNINITIALIZED to INITIALIZING
2018-12-16 12:14:11.585 [hingStatusInfoChangedEvent] - 'mqtt:topic:SonoffPs07' changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): java.lang.Exception: No MQTT client
Hope that helps to figure out the issue.
Everytime you change the Things file, the old Thing will be removed (the MqttBrokerConnection disconnects from Mosquitto) and a new Thing is created. The Thing has the same ID as before, and the correctly connects (ONLINE).
What apparently does not work reliable is the “Topic” Thing. This is also recreated on every file change. It does pick up the broker Thing. But it does not pick up the connection within the broker Thing, because that is not yet existing in exactly that millisecond. I will have a look into this.
Could you please create a bug report on Github as well? Title would be along the lines of “MQTT: Textual configuration results in flaky connection status” or so. And also refer to this post.
There is not much I can do before the OH 2.4 release I guess.
As long as this is working stable, I can handle those issues, because for now they only occur when changing the configuration.
I will create an issue on Github as requested. Thanks for your help!
Just a short feedback: For now the MQTTv2 binding seems to work stable for me. At the time of writing it’s running for more than 24 hours without any change top openHAB2 (no configuration changes related to MQTT, no server reboots, no service restarts). For now it seems to work reliable and stable. 
I will monitor this for a couple of days and mark the topic as solved, if there is no change in behavior.
@David_Graeff Thanks again for your help and work on this binding!! 