MQTT Broker will not connect

  • Platform information:
    • Hardware: Pi 4 / 8 GB
    • OS: buster w/openhabian install on top. uname -a
    • Linux pi-home 5.10.92-v7l+ #1514 SMP Mon Jan 17 17:38:03 GMT 2022 armv7l GNU/Linux
    • Java Runtime Environment: java --version
      • openjdk 11.0.14 2022-01-18
      • OpenJDK Runtime Environment (build 11.0.14+9-post-Raspbian-1deb11u1)
      • OpenJDK Server VM (build 11.0.14+9-post-Raspbian-1deb11u1, mixed mode)
    • openHAB version: 3.2.0 (openhab-cli info)
    • Mosquitto version (from error message on --version):
      • mosquitto version 2.0.11
      • mosquitto is an MQTT v5.0/v3.1.1/v3.1 broker.

I am getting the following in the fronttail:
/var/log/openhab/openhab.log

2022-02-18 22:06:17.382 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to '10.247.251.1'. Next attempt in 60000ms
2022-02-18 22:06:17.388 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.247.251.1' with clientid dbdd0c9e-6d46-4a62-8a6e-b70866a3e0b6

and
/var/log/openhab/events.log

2022-02-18 22:06:17.388 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:systemBroker:pi-home' changed from OFFLINE (COMMUNICATION_ERROR): java.io.IOException: Connection reset by peer to OFFLINE
2022-02-18 22:06:17.440 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:systemBroker:pi-home' changed from OFFLINE to OFFLINE (COMMUNICATION_ERROR): java.io.IOException: Connection reset by peer

I installed Mosquitto from the openhab configuration tool. It doesn’t seem very configurable (I tried adding a file with various log_type values in /etc/mosquitto/conf.d, but they had no effect).

I configured the binding in the UI. The setup:
Name: pi-home
Broker Host: 10.247.251.1
Secure Connection: Off
Hostname Validated: Off
Broker Username: {empty}
Broker Paswword: {empty}

I tested Mosquitto via the command line:
Putty1:
pi@pi-home:~ $ mosquitto_sub -A 10.247.251.1 -t Test
Putty2:
pi@pi-home:~ $ mosquitto_pub -A 10.247.251.1 -t Test -m “Hello Mosquitto!”
Putty1:
Hello Mosquitto!

I believe that the “restore” logs are coming from the binding and the Java exceptions from the broker Thing, which was auto-discovered. (Tip for network developers: Log the IPs - which connection reset?)

247.251.251.1 is wlan0 (static). 10.247.246.250 is eth0 (static). Both generate the same errors.

hostapd and isc-dhcp-server are running on wlan0 with all the WiFi devices (some Kasa/TP-Link lightbulbs and the Roomba, so far). Routing is disabled, so nothing can get from wlan0 to eth0 (to the Internet).

Anyone have any idea what might be wrong?

1 Like

sudo systemctl stop mosquitto.service
sudo nano /etc/mosquitto/mosquitto.conf

Add:

Listener 1883 0.0.0.0

allow_anonymous true

sudo systemctl start mosquitto.service

Check its running.

systemctl status mosquitto.service
sudo netstat -tlnp | grep mosq

And get response:
tcp 0 0 127.0.0.1:1883 0.0.0.0:* LISTEN 4712/mosquitto
tcp6 0 0 ::1:1883 :::* LISTEN 4712/mosquito

Change your bridge type from systembroker to broker

M4rk, 0.0.0.0 seems to be the default:

pi@pi-home:~ $ cat /etc/mosquitto/mosquitto.conf
    ...
    listener 1883
    allow_anonymous true

pi@pi-home:~ $  ps -e | grep mosq
    1264 ?        00:01:19 mosquitto
pi@pi-home:~ $ sudo netstat -tlnp | grep mosq
    tcp        0      0 0.0.0.0:1883            0.0.0.0:*               LISTEN      1264/mosquitto
    tcp6       0      0 :::1883                 :::*                    LISTEN      1264/mosquitto

But, I made it explicit. Interestingly, the IPv6 listener is gone. Since I’m using IPv4, I don’t care.

This didn’t seem to make a difference.

Jim T, that is not an editable property. I:

  • Removed the Thing
  • Added a new Thing
  • Selected the MQTT binding
  • Under Add Manually,
  • Got both MQTT Broker and MQTT System Broker options
  • Chose the non-System one
  • Entered the IP
  • Left Secure Connection turned off
  • It showed up Online

This removed the Thing Java exceptions. The “restore” logs are still there. I’m a Windows guy:

sudo shutdown -r now

Still getting the “restore” INFO logs:

2022-02-20 11:25:52.237 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to '10.247.251.1'. Next attempt in 60000ms
2022-02-20 11:25:52.241 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.247.251.1' with clientid 08117541-5024-40bb-9e8b-cd7d278d44a9

The Thing exceptions are definitely gone. Thanks!

Yes you needed to delete the bridge and recreate it using the other type. System Broker is a remnant of an old system inherited from openhab 1 or 2, I don’t remember. It is actually no longer used, and will be removed in openhab 3.3 to avoid confusion.

The reconnection message is curious. I don’t get it on my system, but I’ll investigate further as to how it appeared. Does it appear on a freshly booted rpi?

Rebooting makes no difference. It’s still going strong - every minute for days now.

I briefly had my Roomba connected. Somehow, it wandered back to the other WiFi network and I cannot get it back on the automation network. That’s also retrying (every second) forever, but at least I understand what’s going on (although it’s also reporting “online” so who knows what’s going on, for sure).

I was setting up MQTT to start the Tuya adventure, but it’s a bit intimidating and I haven’t started, yet. I’ll try deleting the Roomba and the Bridge, rebooting, then re-adding the Bridge.

Something is starting a connection:

2022-02-25 22:19:02.955 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.247.251.1' with clientid 7013ea02-0c89-4d7b-8266-f3c2703a1b49

There is no Thing that should be. This is going to be TMI, but I’ll trim the logs down as much as possible. The startup sequence in openhab.log

2022-02-25 22:18:58.773 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel

The first Thing in event.log

2022-02-25 22:19:00.269 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:0100:ecb5fa1de3aa:2' changed from INITIALIZING to ONLINE

Then a not-Thing back in openhab.log. I have no idea where this coming from. I haven’t tried to use Influx, yet, so I have no idea what might be wrong with its configuration.

2022-02-25 22:19:00.840 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'QueryablePersistenceService.query()' on 'org.openhab.persistence.influxdb.InfluxDBPersistenceService@51ac99': error parsing query: found .623, expected ; at line 1, char 47

Then the iRobot binding dumps tons of debug logs (from when I was trying to connect the Robot; I haven’t changed the binding back to info level). The end of it, still in openhab.log:

2022-02-25 22:19:01.410 [DEBUG] [nal.discovery.IRobotDiscoveryService] - bundle org.openhab.binding.irobot:3.2.0 (264)[org.openhab.binding.irobot.internal.discovery.IRobotDiscoveryService(309)] : Changed state from satisfied to active
2022-02-25 22:19:02.408 [DEBUG] [nal.discovery.IRobotDiscoveryService] - Starting broadcast for /10.247.246.255
2022-02-25 22:19:02.955 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.247.251.1' with clientid 7013ea02-0c89-4d7b-8266-f3c2703a1b49

It could be the iRobot binding, but there a whole 500msec between those; lots could have happened. The binding has no configuration, that I can see. The description does say this " The binding interfaces to the robot directly without any need for a dedicated MQTT server." The word “dedicated” is a poor choice. Does that mean that there is one built into the binding and I don’t need an “external” MQTT server? Does that mean that I can share a non-dedicated external MQTT server with other things?

In events.log, the tplink binding comes up. In openhab.log the zwave controller starts (also in debug level) initializing, then in events.log it starts coming up. Then in openhab.log the MQTT issue starts:

2022-02-25 22:19:13.824 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to '10.247.251.1'. Next attempt in 60000ms
2022-02-25 22:19:13.927 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.247.251.1' with clientid 7013ea02-0c89-4d7b-8266-f3c2703a1b49

The obvious thing to do is Remove the iRobot binding and reboot again. No joy.

2022-02-25 22:40:36.782 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.247.251.1' with clientid 6e514f56-bd36-4ab3-8b6e-47f2d2e0b16a
...
2022-02-25 22:40:47.538 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to '10.247.251.1'. Next attempt in 60000ms
2022-02-25 22:40:47.599 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.247.251.1' with clientid 6e514f56-bd36-4ab3-8b6e-47f2d2e0b16a

As long as I’m pulling this apart, I might as well yank the MQTT Binding out, too. The mosquitto process is still running. Rebooting… And the error is gone. On the bright side, mosquitto is back up.

Adding the binding back… Hmm… The Setting page has “System MQTT Broker” at the bottom, under “Other Services”; this is not a Thing. I didn’t notice if that was there before I restored the binding. Whacking it again. It’s gone and so is the System MQTT Broker. At the risk of destablization, I’m not rebooting, just adding it back. The “System MQTT Broker” is back. As are the errors:

2022-02-25 22:53:52.934 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.247.251.1' with clientid 6fc79bde-3772-4c1a-bdbe-8483471b03a7
2022-02-25 22:54:03.330 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to '10.247.251.1'. Next attempt in 60000ms
2022-02-25 22:54:03.377 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.247.251.1' with clientid 6fc79bde-3772-4c1a-bdbe-8483471b03a7

This is definitely the MQTT binding. I don’t see anything on that System Broker page that looks wrong (it’s the same as documented, above). I suspect that Removing the binding did not erase the configuration, wherever that might be stored, because the Broker Port is set and I set it. It was blank the first time I looked at this page - long before I made this post.

Hope that helps.

What’s wrong is that do you do not want this at all in OH3 - there are several posts about removing, if I remember right some folk could not remove depending on prior history, but could effectively disable with some setting or other.

The system broker bridge is removed in 3.3

Searching on this site is hopeless.

@rossko57, you are correct. I stumbled across the answer in this comment on a totally unrelated issue from openHAB 1.5. Summary: Just remove the broker host - ignoring the red warning text - and it stops trying.

@jimtng, thanks. I suppose there is no harm in upgrading since I have very little that could be broken.

Meanwhile, I’ve just been ignoring the error and now logging is broken. NOT a problem for this thread. I’ll post a new one. It seems like a legitimate defect.

Update:

pi@pi-home:~ $ sudo apt-get update
...
Fetched 60.0 kB in 2s (26.2 kB/s)
Reading package lists... Done
pi@pi-home:~ $ sudo apt-get install openhab
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
openhab is already the newest version (3.2.0-1).
0 upgraded, 0 newly installed, 0 to remove and 31 not upgraded.

I have the same issue. I ran OH3 (frequently upgraded) on my Raspberry Pi 4 for a year, and then the Pi’s storage (SSD) suddenly dead. I replace the SSD with a new HDD, reinstall OH3 and copy all textual files .things, .items, .rules… back into openHAB.

The strange is, my Mosquitto broker bridge declared in the textual file (that used to work before) could not connect. It’s always Channel output shutdown or Connection reset by peer, but the MQTT broker that creates in the OH3 UI can work as normal.

This is code of the textual broker bridge that couldn’t connect:

UID: mqtt:broker:MosquittoMQTTBroker
label: Mosquitto MQTT Broker
thingTypeUID: mqtt:broker
configuration:
  lwtQos: 0
  publickeypin: true
  keepAlive: 60
  clientid: 8d47c548-3098-40e0-a2eb-19c58d0ca9b3
  secure: false
  birthRetain: true
  shutdownRetain: false
  certificatepin: true
  qos: 0
  reconnectTime: 60000
  host: localhost
  lwtRetain: true
  enableDiscovery: true

and this is code of the broker bridge that created in OH3 UI:

UID: mqtt:broker:98e901e9bf
label: MQTT Broker
thingTypeUID: mqtt:broker
configuration:
  lwtQos: 0
  publickeypin: true
  keepAlive: 60
  clientid: dae893a5-3665-4a2a-be74-2ebce62cb8c5
  secure: false
  birthRetain: true
  shutdownRetain: false
  certificatepin: true
  qos: 0
  reconnectTime: 60000
  host: localhost
  lwtRetain: true
  enableDiscovery: true

Sorry, after digging deeper I realized that the faulty comes from a Tuya MQTT item that was misconfigured. MQTT Broker is doing good job :stuck_out_tongue: