mike2545

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.

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

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.

Quick update: today the Camect nodes are triggering IoX programs again. Nothing was changed on the system since yesterday (still PG3x 3.4.13), so it may have been related to the node server reinstall or IoX needing time to rebuild program event subscriptions. I'll keep monitoring it, but for now everything appears to be working normally again. Thanks for taking a look.

System: - Work system: eisy / IoX 6.0.4 / PG3x 3.4.13 - Home system: PG3x 3.4.11 works correctly - Camect plugin version: 3.1.0 - Status in PG3x: Connected Problem: Camect alerts are visible in the Camect UI and the PG3x log shows successful updates to IoX, but ISY/IoX programs are not triggering on the work system. What I already tested: - Removed and reinstalled the Camect plugin - Confirmed alerts appear in Camect - Confirmed PG3x shows node updates such as GPV and ST changing - PG3x log shows “Successfully set ...” for Camect nodes - This same setup works at home on PG3x 3.4.11 Why I suspect PG3x: The main difference I can see is PG3x version: - Home: 3.4.11 works - Work: 3.4.13 does not trigger programs Question: Has anything changed in PG3x 3.4.13 that could affect Camect node event/status handling in IoX programs after reinstall? Also, should Camect programs be triggered using STATUS, CONTROL, GPV, or another driver on current versions? Examples from log: - Host:update_status: cams=True report=True - Successfully set 01_004 :: GPV to 1 - Successfully set 01_004 :: GPV to 0 - Successfully set 01_003 :: GPV to 1 - Successfully set 01_003 :: GPV to 0 Thanks.

Ok now I have the developer interface with polyglot on eisy. Maybe you can answer this question: In Polyglot v3 Developer Mode, where should server.json go so OAuth config and node metadata are properly picked up? I’m building a NodeServer manually, and although everything works in google_calendar_ns, PG3 isn’t seeing the server.json, so the “Authenticate” button fails and client_id is undefined. Do I need to manually copy server.json into /var/polyglot/pg3/ns/<slot>? Or is there a better dev workflow to make sure it gets registered? Kind regards, Mike2545

Jim, thanks for the screenshot, it's my understanding that one needs to be part of the developers to get that button. Hope my application for membership gets approved. Kind Regards Mike2545 Edit, I have the button, it just doesn't do anything.

Where exactly?

I am using Eisy, polyglot PG3x, where is the Upload Node Server Profile button to test out a new node server i am working on? Kind Regards, Mike2545

Jim, I know you have been busy, but is there an estimate on when you would be able to work on this?

Jim, thank you for taking the time to investigate this issue. I can't speak for all Camect users, but for me just an alert on USPS, it really does not matter if it's a car or truck, etc... Kind regards, Mike2545

JImbo, I am running iox v5.9.1 Can confirm status changes in iox for person, car, truck etc... but not USPS

Paul, yes I can log into Camect and click on alerts, filter by mail truck and see that it recognizes the mail truck with its software. Run then on the program sends me a text message, so that is configured correctly. In iox clicking on USPS in Camect triggers the program. I can change the program to trigger with person, truck, car. USPS is not triggering in iox.

Paul, thank you for the reply. I have watched the mail truck pass the camera and it does not trigger USPS. I have attached an image of the program that should work if the trigger is passed to the eisy.

Hello, I am trying to get an alert when the USPS truck arrives but the Camect plugin wont trigger. Any help would be greatly appreciated. Kind Regards, Mike2545