v0.50.3 was in beta for quite a while. It has a lot of backend changes so I wanted to give the community a chance to check it out. Its been two months and there are not any comments, so here we go.

v0.50.4 is just a docs change. Added to the README the formats which are expected by the plugin by device. Its a question which comes up every so often, not needed for regular config, just if you are going deeper. There is a link in the configuration to it.

v0.50.5/6 are install minor fixes

Let me know if you have any unintended consequences.

## 0.50.5/6 install.sh minor changes

## 0.50.4

- Add MQTT payload format examples to README for all sensor types

- Link POLYGLOT_CONFIG sensor section to README payload reference

## 0.50.3

- Restructure POLYGLOT_CONFIG for devfile-first setup with upload and SSH paths

- Add starter data/mqtt-devices.yaml template

- Trim README to capability and installation overview only

## 0.50.2

- Extract device discovery and topic registration into discovery module

- Unwrap Tasmota StatusSNS payloads once in Controller before routing to nodes

- Skip duplicate status topic registration on re-discovery

- Remove dead pass stubs from node modules

- Fix disconnect handler exception path

## 0.50.1

- Fix startup handler gate when CUSTOMPARAMS arrives last

- Fix poll heartbeat guard to respect controller ready state

- Accept documented devlist JSON arrays alongside legacy dict upserts

- Merge devfile and devlist configuration as documented

- Resubscribe MQTT topics after DISCOVER when already connected

- Add MQTT connect timeout instead of infinite wait

- Fix sensor message routing to use two-argument updateInfo

- Refactor config loading, device registry, and MQTT bridge modules

- Add MQTasmotaSensor base class for shared Tasmota sensor behavior

- Unsubscribe MQTT topics when nodes are removed

- Add legacy config regression test suite

Edited August 18Aug 18 by sjenkins
split beta

I found an MQTT reconnection issue in v0.50.6.

Environment:

- eisy / FreeBSD 14.3

- PG3x 3.4.11

- IoX 6.0.4

- MQTT plugin 0.50.6, slot 10

- External Mosquitto 2.0.21 broker

If the external broker is unavailable when the plugin starts, MqttBridge.start() times out, stops the Paho network loop, and returns false. PG3x continues showing the plugin process as Connected, but the external MQTT connection never recovers. Restoring the broker hours later did not help; manually restarting the plugin immediately restored operation.

I also found that the disconnect callback only attempted one synchronous reconnect(). If that attempt failed, no further attempts were made.

We locally tested a fix using:

- connect_async()

- loop_start()

- reconnect_delay_set(min_delay=2, max_delay=30)

- Paho’s continuing automatic reconnect instead of calling reconnect() once inside ondisconnect

- Resubscription only from onconnect

- Rejecting and logging publishes while disconnected

Both controlled tests passed:

1. Existing broker connection lost: the plugin remained running and reconnected/resubscribed automatically after the broker returned.

2. Plugin started while the broker was offline: the plugin remained running in a retrying state and connected/resubscribed automatically after the broker returned.

Relevant recovery log:

MQTT network loop started; automatic reconnect enabled

Started MQTT NodeServer v{'version': '0.50.6'}

Poly MQTT connected/reconnected

Established-connection test:

Poly MQTT disconnected (rc 7); Paho will retry automatically

Poly MQTT connected/reconnected

I have a reversible two-file patch for nodes/mqtt_bridge.py and nodes/Controller.py and can provide it for review.

@mike2545 ,

good find, this looks like its not new to this version but has been around a bit. I have not been testing with an external mqtt server but likely should add this to my tests. I would normally say to just write a pull request but today the repo is on the move (should not effect downloads or updates) and may move twice before the day is up. Can you attach your patch files in a response & I will incorporate them into the solution, likely with a test or two to lock it in. Again, thanks so much for the thoughtful bug report!

Thank you. I have attached the patch generated against the installed v0.50.6 files.

It modifies:

- nodes/mqtt_bridge.py

- nodes/Controller.py

The patch enables Paho’s continuing reconnect loop with bounded backoff, removes the one-shot reconnect call from the disconnect callback, subscribes once from the successful connection callback, and rejects/logs publishes while the external broker is disconnected.

We tested both cases:

1. An established external MQTT connection was interrupted and later restored.

2. The plugin was started while the external broker was unavailable.

In both cases the plugin remained running, connected automatically when the broker became available, resubscribed, and resumed normal operation without a PG3x restart.

Please feel free to adjust the implementation or notices to match your preferred design. Thanks for incorporating the fix.

mqtt-0.50.6-auto-reconnect.patch

@mike2545

just pushed a beta v0.50.8 to the non-production store, give it a try

thanks again

Tested MQTT beta v0.50.8 successfully.

The following scenarios passed:

1. Normal connection and garage-door operation.

2. Complete external MQTT/GaragePi reboot while the plugin remained running.

3. Automatic reconnection and resubscription after the broker returned.

4. Plugin restart while the external broker was already offline.

5. The waiting/retrying notice appeared during the outage and cleared automatically after reconnection.

6. Door status and commands resumed normally through UD Mobile without another plugin restart.

The beta fixes both the established-connection-loss case and the original broker-unavailable-at-startup case for me.

Thank you for turning this around so quickly.

Thanks for pointing out the opportunity!