[Solved] Upgrade from 2.5.10 to 2.5.11 resulted in missing MQTTv1 processing

  • Platform information:
    • Hardware: Raspberry Pi 3 Model B Rev 1.2_
    • System: Host: rpi3ohv2 Kernel: 5.4.51-v7+ armv7l bits: 32 Console: tty 2
    • Distro: Raspbian GNU/Linux 10 (buster)
    • OpenJDK Runtime Environment (Zulu 8.31.1.122-linux_aarch32hf) (build 1.8.0_181-b122)
  • Version: 2.5.10 (Build) (apt-get), text-based config
    • binding = astro, exec, logreader, network, ntp, systeminfo, fritzboxtr0641, expire1, mqtt1, weather1
    • ui = paper, basic, classic, restdocs
    • persistence = rrd4j, mapdb
    • action = mail, mqtt
    • transformation = map, javascript, xslt, scale, jsonpath

I upgraded from 2.5.10 to 2.5.11 simply to be on the latest version of 2.5.
After the upgrade MQTT messages were no longer processed.
No changes were made to the config.

Since all controllers in my place run on MQTT, pretty much every thing is non-functional.

After unsuccessful attempts to troubleshoot the problem… I reverted back to 2.5.10… only to discover the problem persists.

I am at a loss on how to fix this.

The openhab.log does not give my any clues about mosquitto being loaded/started, but says Stopping broker connection 'mymosquitto' when stopping OH.

I really need some help. Thanks.

Steps undertaken so far:

  1. initial upgrade to 2.5.11
  2. restart; lots of errors
  3. stop OH
  4. clear cache
  5. start OH; seemingly normal start
  6. stop OH
  7. start OH; seemingly normal start
    –> still no MQTT processing
  8. sudo apt install openhab2=2.5.10-1
  9. clear cache
  10. start OH
    –> still no MQTT processing
  11. stop and start OH; seemingly normal start
    –> still no MQTT processing

Non-MQTT stuff is working.

However the mosquitto broker is installed and running and works for other things:

sudo service mosquitto status
â—Ź mosquitto.service - Mosquitto MQTT v3.1/v3.1.1 Broker
   Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-10-26 14:04:07 AEST; 1 hour ago
     Docs: man:mosquitto.conf(5)
           man:mosquitto(8)
 Main PID: 10530 (mosquitto)
    Tasks: 1 (limit: 2184)
   CGroup: /system.slice/mosquitto.service
           └─10530 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf

If a couple of reboots won’t fix it then you can try clearing cache which will force everything to rebuild.

Thanks… I will add what I have done in the original post.

Mosquitto is a separate software, so the openHAB logs won’t show whether this is loaded or not. In a Linux command terminal (or over SSH), what does

sudo systemctl status mosquitto

show?

added to initial post:

sudo service mosquitto status
â—Ź mosquitto.service - Mosquitto MQTT v3.1/v3.1.1 Broker
   Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-10-26 14:04:07 AEST; 1 hour ago
     Docs: man:mosquitto.conf(5)
           man:mosquitto(8)
 Main PID: 10530 (mosquitto)
    Tasks: 1 (limit: 2184)
   CGroup: /system.slice/mosquitto.service
           └─10530 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf

OK, that looks good!

Next, we should check the Broker Thing within openHAB, and whether it’s successfully connected.

Can you confirm that your Broker Thing is successfully connected when you look in PaperUI?

What is your Broker Thing configuration?

There is none. It is a text-based config.

That’s not true: PaperUI will still show your Broker Thing, and whether it is connected (“ONLINE”) - you just can’t edit it. Should be somewhere like Configuration -> Things

Please also show your configuration of your Broker Thing.

Well… it is a few minutes away, as the machine is booting and takes some 9 minutes.

… I was using the rPi to build a new 2.5 system, but on a different drive… the system upgrade just finished; hence, the swap of drives and rebooting the system.


I have to say that this GUI config business is doing my head in. I tried to config the MQTTv2 version, but it is so much work given that all my controllers talk MQTT.


OK, back in business…
… and yes, there is no MQTT broker in the PaperUI
There is a services/mqtt.cfg:

mymosquitto.url=tcp://localhost:1883
mymosquitto.clientId=openhab
mymosquitto.retain=true

I have got the bindings:
image
image

[edit_1] for completeness: I had deleted the following file and it got recreated the same way (identical):

cat /var/lib/openhab2/config/org/openhab/mqtt.config
:org.apache.felix.configadmin.revision:=L"1"
mymosquitto.clientId="openhab"
mymosquitto.retain="true"
mymosquitto.url="tcp://localhost:1883"
service.pid="org.openhab.mqtt"

So you are using the version 1 MQTT binding, in this case nothing usefull will be shown on PaperUI and you don’t need to have or better won’t have any MQTT Thing.
If the broker is running as before and your items are created by the same file I’d would check with MQTTfx (or a similar program) whether mqtt messages are processed at all.

And for the sake of all the users trying to help, in the present situation ( MQTT version 2 being out 2 years AND OH3 ( to one with no version1 support) went public a week ago ) it would be a good idea to highlight the use of an deprecated binding.

Yes, as stated in the O.P. :slight_smile:
Agree with what you’re saying.
However, the work involved to change will be significant.
… and I hope you’re not blaming me for having upgraded a minor and official release which broke the system.

mosquitto is up and running fine.
I can run commands, which are accepted by the controllers, but not processed by OH.

This is what puzzles the heck out of me. OH seems to connect, if I can assume that from the fact it states in the log that it it disconnecting from the mymosquitto broker.

I guess now you have a decision to make. Keep bashing away until you get the old one working or upgrading to mqtt2 on oh3 or goto OH3.

GO with OH3

All I tried to say was the use of MQTT1 should have been highlighted.

If OH is disconnecting it is DISconnected! The reason for disconnecting is the culprit!
Most times in such cases a non-unique clientID was the reason.

2020-12-26 16:22:51.941 [INFO ] [penhab.io.transport.mqtt.MqttService] - Stopping broker connection 'mymosquitto'

… is what I get in openhab.log when shutting OH down.

When I try to change the clientId in mqtt.cfg, this is recorded in the openhab.log:

2020-12-26 19:37:40.458 [ERROR] [org.apache.felix.configadmin        ] - Cannot use configuration org.openhab.mqtt for [org.openhab.io.transport.mqtt.MqttService, org.osgi.service.cm.ManagedService, id=381, bundle=237/mvn:org.openhab.io/org.openhab.io.transport.mqtt/1.14.0]: No visibility to configuration bound to mvn:org.openhab.action/org.openhab.action.mqtt/1.14.0

OK, you do use the binding and the action. I faintly remmber a problem with them, if I remember correctly the action needed to be loaded after the binding to solve the problem (will have to digg into old posts to verify).
and thanks for changing the title! :+1:

Not sure how this can be achieved…

this is the addons.cfg

grep "^[^#;]" /etc/openhab2/services/addons.cfg 
remote = true
legacy = true
binding = astro,exec,logreader,network,ntp,systeminfo,fritzboxtr0641,expire1,mqtt1,weather1
ui = paper,basic,classic,restdocs,habpanel
persistence = rrd4j,mapdb
action = mail,mqtt
transformation = map,javascript,xslt,scale,jsonpath

There is no option to determine load order…

[all I did was upgrade 2.5.10 to 2.5.11, stop, start and it should have been fine; no config changes of any sort were made; and the timestamps of the config files are all before the upgrade]

Such problem could be resolved by loading the mqtt action manually after the mqtt binding was installed. I think unloading the action (which is set in the addons.cfg) won’t work for you, so try to remove it from the addons.cfg, restart and load the mqtt action afterwards manually (if you still need it).

:slight_smile: I proactively moved the mqtt1 entry to the front (as you suggested earlier), and restarted, and…

… mqtt is working again.

Phew… the “Haussegen hing schief” given the 'most-of-the-day" outage.

I am not sure, whether the action is required (was always there from years ago).
… but considering I hadn’t made the change you then suggested to remove the mqtt action and reboot… I think we have a fix.

Thank you so much for hanging in there! Much appreciated.

1 Like

Your welcome :christmas_tree:

My guess on your mqtt action usage is Tasmota Admin.