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
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:
[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.
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!
Not sure how this can be achieved…
this is the addons.cfg
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).
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.
My guess on your mqtt action usage is
Have no Tasmota devices… all Arduinos with wired Ethernet via MQTT… spread more over the property than on the ‘living spaces’… doing pumps, tanks, valves, irrigation, gates, etc. various hubs (or rather concentration points) connected with fibre (to protect from lightning).
The house is still being build
My current approach is to not touch this config/setup until I find time to migrate to OHv3 (mid next year).
I went through backups to check the file date of addons.cfg… it wasn’t changed in the last 1.5 years, since then I had 3 updates in 2.5. Go figure.
[edit_1] … just found this snippet " Dec 16, 2018 — # MQTT Actions. There is an openHAB 1.x addon, called “MQTT Action”. It allows to send arbitrary payloads to arbitrary topics from rule and script…" I am using the publish() command in rules.