mike2545

Resolved — root cause was the IoX node-server database schema, not KiddeSmokeDet. Environment: IoX 6.1.2_7 PG3x 3.4.25 KiddeSmokeDet 0.1.4 Standard/Production The Kidde node server was installed in slot 6. Its IoX node-server database: NSDB_0010_0006.DB was at: PRAGMA user_version=0 while the other current node-server databases were schema version 2. Dynamic JSON profile updates failed in IoX with: SQL Error : Replacing editor in database failed : table Editor has no column named inlineNlstable Comparing the v0 and v2 schemas showed that the slot-6 database was using the older NSDB structure and was missing multiple fields required by the current profile parser, including desc and inlineNls. The slot-6 database contained no profile rows, so with IoX stopped I backed it up and replaced it with an empty schema-v2 NSDB. After restarting IoX and the unmodified KiddeSmokeDet 0.1.4 plugin, the dynamic profile loaded successfully: Dynamic profile updated with 8 Kidde alarm nodedef variants The slot-6 database then populated normally (9 NodeDef, 10 Editor, 100 NodeDefStatus, 9 AcceptsCommand), and the IoX Admin Console now renders the Kidde nodes and labels correctly. So in this case the [NLS-10:...] rendering problem was caused by an obsolete IoX NSDB schema for that node-server slot, rather than by the KiddeSmokeDet profile definition itself. I have retained the original slot-6 database and can provide additional schema/log details if useful.

### Environment - KiddeSmokeDet: 0.1.4 Standard / Production - Branch: RELEASE260428 - PG3x: 3.4.25 - IoX: 6.1.2 - udi_interface: 3.4.7 - Controller: eisy - Detector: Kidde DETECT / EssWFAC - Node address: d1029477 ### Problem The dynamic JSON profile fails to load. The nodes are created and driver updates are successfully reported to PG3/IoX, but the IoX Admin Console cannot render the node definitions properly. The Admin Console shows unresolved NLS labels such as: [NLS-10:ND-setup-NAME] and: [NLS-10:ND-kiddealarm_v6_4-NAME] The node detail panels are otherwise blank. ### Relevant log errors At startup: interface:updateJsonProfile: Sending profile update request to Polyglot. interface:updateJsonProfile: Update profile request failed: No error message provided nodes:_update_dynamic_profile: Dynamic profile update failed RuntimeError: Update profile request failed: Unknown error PG3 also displays: Dynamic profile update failed. Check PG3x/IoX compatibility. Using the PG3 "Load Profile" button, restarting the node server, closing the Admin Console, and reopening a fresh Admin Console does not resolve the issue. ### Node creation / ADDNODEDONE is working The node lifecycle itself appears healthy after a clean reinstall. The controller receives ADDNODEDONE: nodes:handle_addnode_done: ADDNODEDONE received for controller node The detector is then discovered and added as: Adding node Log Cabin(d1029477) PG3 subsequently returns the child node and the plugin logs: nodes:handle_addnode_done: Applying deferred device update after ADDNODEDONE for d1029477 The plugin then successfully reports the detector drivers to PG3/IoX, including battery state, online status, model, life remaining, and last-seen time. So this does not appear to be an ADDNODEDONE or node-address problem. The failure appears limited to the dynamic JSON profile/NLS loading. ### Smoke alarm test Before deleting the trial installation and installing the perpetual license, I performed a real smoke test using canned smoke. At that time the Kidde nodes were rendering normally in the IoX Admin Console. While the physical detector was alarming, the Kidde API returned: "smoke_alarm": true and the node server reported: Kidde dataset refresh complete: devices=1 events=0 alarms=1 The Kidde Monitors controller alarm count changed to 1 in IoX and later returned to 0 when the alarm cleared. The individual Log Cabin node did not show the alarm state during that test because the node server was still logging that updates were being deferred until ADDNODEDONE. The command path did work: issuing Hush from the ISY mobile app successfully sent the Hush command through the node server to the physical detector. After reinstalling KiddeSmokeDet under the perpetual license, the ADDNODEDONE lifecycle now completes correctly and the Log Cabin child node receives its driver updates. However, the dynamic JSON profile now fails to load, leaving unresolved NLS labels and blank node detail panels in the IoX Admin Console. I have not repeated the smoke test since the perpetual reinstall because the current issue is the failed dynamic profile rendering. Please let me know if there is additional debug output I can provide or another profile-loading method you would like me to test.

My eisy is now running: OS 14.4-RELEASE-p6 IoX firmware 6.1.1 IoX UI 6.1.1 After upgrading packages and rebooting successfully, the certificate presented by the local IoX HTTPS endpoint on port 8443 remains: Subject/issuer: O=UD, CN=polisy Valid from May 30, 2024 Expired May 30, 2025 No Subject Alternative Name The certificate was unchanged by the upgrade. I need a Raspberry Pi automation on the local network to call the IoX REST API using HTTPS with certificate verification enabled. I do not want to disable certificate verification. What is the supported procedure for regenerating or renewing this eisy-managed IoX certificate and establishing verified local HTTPS access?

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