Expose GPIO modules (Raspberry Pi, Beaglebone, PCF8754, PiFace2 etc.) and digital sensors (LM75 etc.) to an MQTT server for remote control and monitoring.
MIT License
460
stars
157
forks
source link
MQTT does not reconnect on authentication failure #363
[x] I have read the README.md file and visited the Documentation to see if the information there helps.
Describe the bug
If the MQTT Broker cannot authenticate the client, there is no retry on the client to reconnect/reauthenticate.
In my case, my MQTT Broker (EMQX) has a MongoDB for the user authentication. In case the connection from the MQTT Broker to the MongoDB does down for any reason, the MQTT Broker cannot authenticate the client. The client will print out the error below. If the MongoDB is up again, the authentication is working again, but I have to restart the client process, because there will be no automatic reconnecting attemps.
Expected behavior
If the MQTT Broker cannot authenticate the client, the client has a retry to connect to the Broker. (Like if the MQTT broker is offline and there is a timeout - maybe this could be handled identical.)
Error messages and traceback
(CRITICAL): Not authorised to connect to MQTT broker.
Config
mqtt:
host: emqx.local
port: 1883
user: "raspberry"
password: "securePassword"
topic_prefix: smarthome/raspberry
discovery: true
discovery_name: Raspberry
gpio_modules:
- name: raspberrypi
module: raspberrypi
digital_outputs:
- name: someName
module: raspberrypi
pin: 26 # This is specified as the GPIO.BCM standard, not GPIO.BOARD
on_payload: "on"
off_payload: "off"
initial: high # This optional value controls the initial state of the pin before receipt of any messages from MQTT. Valid options are 'low' and 'high'.
retain: yes # This option value controls if the message is retained. Default is no.
publish_initial: yes # Publish the initial value of the output on startup. Default is no.
inverted: yes
Hardware
Platform: Raspberry Pi
Connected hardware: Simple Relais
System:
OS: Raspbian 11
Python version: 3.9.2
User you're running as: pi (via systemd service)
Using a virtualenv?: no
Additional context
It may be some edge case, but in favor of security, I would like to have some fix that this doesn't occur anymore, as it's a bit annoying to restart the client if something wasn't available for 30 seconds. This may be moved into an feature request, but for me it's a more of a bug. This error is here also for a longer time now, so it's nothing with the latest releases I think
I'm running it as a systemd service with the following config places at /etc/systemd/system/mqtt_gpio.service) for having a proper autostart on the raspberry pi:
Describe the bug If the MQTT Broker cannot authenticate the client, there is no retry on the client to reconnect/reauthenticate. In my case, my MQTT Broker (EMQX) has a MongoDB for the user authentication. In case the connection from the MQTT Broker to the MongoDB does down for any reason, the MQTT Broker cannot authenticate the client. The client will print out the error below. If the MongoDB is up again, the authentication is working again, but I have to restart the client process, because there will be no automatic reconnecting attemps.
Expected behavior If the MQTT Broker cannot authenticate the client, the client has a retry to connect to the Broker. (Like if the MQTT broker is offline and there is a timeout - maybe this could be handled identical.)
Error messages and traceback
Config
Hardware
System:
Additional context It may be some edge case, but in favor of security, I would like to have some fix that this doesn't occur anymore, as it's a bit annoying to restart the client if something wasn't available for 30 seconds. This may be moved into an feature request, but for me it's a more of a bug. This error is here also for a longer time now, so it's nothing with the latest releases I think
I'm running it as a systemd service with the following config places at
/etc/systemd/system/mqtt_gpio.service) for having a proper autostart on the raspberry pi: