MQTT Client already connected closing old connection problem

[homeautomaton]

I have a strange problem. Installed the same OS and same version of rtl_433 on a Pi Zero W, right beside a Pi (original version), and on the Zero, MQTT always fails with repeated messages like this:

[MQTT] MQTT Connection failed...
MQTT: MQTT Connection failed...
[MQTT] MQTT Connection failed...
MQTT: MQTT Connection failed...

Looking at the code, this appears to be a closed connection, with no specific error code to report. The very same configuration works just fine on the wired connection of the original Pi.

[zuckschwerdt]

Wrong port number? Wrong IP address? Does mosquitto_sub work with the same parameters?

[homeautomaton]

The port number and IP address are in the configuration file, copied, bit-for-bit from the original pi where it works. When I attempt to switch to the pi zero, I get the failures shown above.

If I intentionally try a wrong port or address, the error changes:

[MQTT] MQTT connect error: Connection refused
MQTT: MQTT connect error: Connection refused

Intentionally using the wrong username gives me this:

[MQTT] MQTT Connection error: 5
MQTT: MQTT Connection error: 5

Moreover, tcpdump shows there are packets exchanged with the mqtt server. The payload of the login packet looks identical. I don't have mosquitto_pub on either pi (yet), but tcpdump and the other clues above confirm that IP, address, username and password are correct. They would (and do) produce the other errors if incorrect.

[zuckschwerdt]

Ok, if packets are exchanged and it works somewhere else then this could be about ACL permissions (are you allowing only specific IPs?) or the "client id". Try using a different -d, e.g. if you don't use that option now then use -d 0. If that works you have multiple machines connected that have the same hostname. Perhaps change that then.

[homeautomaton]

Here's info from the Mosquitto log on the broker:

2023-04-11 06:25:21: New connection from 172.30.32.2:34786 on port 1883.
2023-04-11 06:25:21: Client <unknown> closed its connection.
2023-04-11 06:25:26: New connection from 192.168.1.93:48318 on port 1883.
2023-04-11 06:25:27: Client rtl_433-5758d7a3 already connected, closing old connection.
2023-04-11 06:25:27: New client connected from 192.168.1.93:48318 as rtl_433-5758d7a3 (p2, c0, k60, u'rtl_315').
2023-04-11 06:25:27: New connection from 192.168.1.173:55752 on port 1883.
2023-04-11 06:25:27: Client rtl_433-5758d7a3 already connected, closing old connection.
2023-04-11 06:25:27: New client connected from 192.168.1.173:55752 as rtl_433-5758d7a3 (p2, c0, k60, u'rtl_433').
2023-04-11 06:25:27: New connection from 192.168.1.93:48332 on port 1883.

Interesting I always see the 172.30.32.2 address first, somehow due to starting rtl_433 on the Zero, at 192.168.1.93. I bet this is something to do with bridging for docker, where the broker runs.

[homeautomaton]

Oh. This is interesting. It's only failing when another rtl_433 is still running, on the other Pi. There are two .conf files, one for 433MHz and one for 315Mhz. I was working to migrate the 315 to the Zero, and kept the 433 running on the original Pi. (I want to have the flexibility to put receivers in different parts of the house.) If I stop the 433 instance (which uses a different mqtt username), the 315Mhz running on the Pi Zero can now connect.

[zuckschwerdt]

Yes, the client ID is a hash of the hostname and the device selection (-d). Those must be distinct between all machines. Are perhaps both Pi's named "raspberrypi"?

[homeautomaton]

They both show up in the mosquitto logs as rtl_433-5758d7a3, if using -d 0 (which is already in the .conf files).

[homeautomaton]

Yes. Using "00" for one, and "0" for the other works. I'll look at changing the hostnames, to be more thorough.

Thanks once again for your help. If I'd looked at the broker's logs sooner, I might've clued in on the hash thing!

[homeautomaton]

Changed host names to rpi_01 and rpi_02, and put the device IDs back to "0", and all is well now.

[kceventus]

Would it make sense to incorporate the MQTT login/username as part of the hash? Or look at the network interface and use IP or MAC address?

[zuckschwerdt]

Hostname and SDR device are the proper unique identifiers. If you have a collision there then you already have other problems (e.g. MDNS).

[kceventus]

ok