wrj0

@JCase I had the same problem trying to add an old ApplianceLinc to eisy that was working fine on my Polisy. The eisy is at our second home and is being setup from scratch. Even with the ApplianceLinc on the same power strip as the PLM, side by side, the new add Insteon device command status would get to 7% and then error out with: The following devices could not be added: 1B.7D.83 Cannot determine Insteon Engine I did have a small UPS on site in the same room as the PLM. Putting the UPS on a FilterLinc allowed the ApplianceLinc to be immediately added and controlled without any problem.

Thank you, Bob. Another one of your outstanding explanations.

Is there a description of the information provided in the various PG3 Log Levels? And when they might be used in troubleshooting? Log levels: Critical, Error, Warning, Info, Debug, DB Operations. I've searched in the forum and wiki, but seem to have missed finding the descriptions. Thanks.

Many thanks, Bob. Problem solved. I found a browser opened to the PG3 page on a PC that I occasionally use to remote in to my network via VPN. That page had indeed been open for well over a week. Closing it has stopped the reported errors. Funny how something so simple has caused me so much troubleshooting grief over the past few days. Thanks for a nice Christmas present!

During the holidays, I sucessfully migrated from ISY994 to IoP, installed the new Matter board, and migrated to Matter. And now have IoP programs running properly, and have begun to have z-wave support (with some device response issues as reported by others). node servers running on PG3 are reporting data to the IoP (Climacell, Weatherbit, Elk, Notifications and ST-Inventory all seem to be running fine, and are properly updating IoP data. And, the Occupancy NS is properly detecting and reporting geofences to IoP. However, I see lots of frequent errors in the PG3 log. For example: 12/25/2022, 13:17:36 [pg3] error: MQTTS: clientError: pg3frontend_W6ySn not authorized 12/25/2022, 13:17:42 [pg3] error: MQTTS: clientError: pg3frontend_W6ySn not authorized 12/25/2022, 13:17:48 [pg3] error: MQTTS: clientError: pg3frontend_W6ySn not authorized 12/25/2022, 13:17:54 [pg3] error: MQTTS: clientError: pg3frontend_W6ySn not authorized 12/25/2022, 13:18:00 [pg3] error: MQTTS: clientError: pg3frontend_W6ySn not authorized 12/25/2022, 13:18:06 [pg3] error: MQTTS: clientError: pg3frontend_W6ySn not authorized 12/25/2022, 13:18:13 [pg3] error: MQTTS: clientError: pg3frontend_W6ySn not authorized These errors repeatedly show in the log every few seconds. I've run Upgrade Packages in IoP, have restarted PG3, and have power-cycled Polisy, but these errors continue. While I don't see errors in the individual Node Server logs, I did Stop each of my node servers one at a time to see if that helped with the PG3 log errors - it did not. A screenshot of my PG3 dashboard is provided below - running PG3 3.1.16 and IoP 5.5.0. I'm at a loss to understand the reported MQTTS errors. And given the efforts that UDI is currently undergoing, really don't want to bug them at this time. Wonder if someone here could offer some suggestions on what I may do to resolve these errors. Thanks in advance!

Just read this notice at tomorrow.io: Does this mean the Climacell Node Server can provide the daily et0 sum? Rather than our needing to calculate the sum throughout the day?

It's great to see the status information presented by the ST-Inventory Node Server. I have a question about the status report of the Node Server. http://<my-isy994-ip>/rest/nodes/n004_controller returns (among other things): <property id="ST" value="1" formatted="True" uom="2"/> and ${sys.node.n004_controller.name}: ${sys.node.n004_controller.ST} always returns: "ST-Inventory: True" even if the ST-Inventory Node Server is stopped. Should the "ST" property id return False when the Node Server is stopped or off line?

@gviliunas I had a similar problem with another NS, getting the same error message when trying to do a Re-install. My solution: Please see this post.

Tried installing Climacell from the Node Server Store, rather than re-installing it from the Purchases tab; it gave me an Install option, and allowed Climacell to be installed again at the same slot it was in before. Seems to be working fine now. Not sure why the Re-Install from the PG3 Purchases tab didn't work, but glad to have this Node Server back in operation.

@Michel Kohanim I've bugged you enough lately. 😄

While trouble shooting a backup problem with my ISY994, I deleted my node servers and after resolving the backup issue (with wizard-like assistance from Michel and Chris) have now begun re-installing them. Climacell fails to re-install with the error: "Can't find purchase option for license record." PG3 Node server Store shows the Climacell NS purchase date, Order ID, and that the NS is active, but I can't get it to re-install. Other node servers are re-installing fine. Suggestions, please.

Today, I re-ran AC, Config>Update packages. A few minutes later, PG3 showed: And after doing a PG3 System>Restart Polyglot 3, both Version and Front End Version now show 3.1.8. Thanks for the quick fix in 3.1.8.

Thanks for the suggestion @MrBill, but no joy. Tried it in three different browsers.

Can't seem to upgrade my Polisy from v3.0.63 to v3.1.6 Here's what I have done: In Polisy PG3 AC, Config>Update packages. Polisy beeped 5 times. Waited 5+ minutes, then in PG3 selected System>Restart Polyglot 3. After Polisy came back up, PG3 stills showed 3.0.63. Later, pressed Polisy front button once, beeped 5 times, after 20 minutes, PG3 still is on 3.0.63. Later via SSH to Polisy: sudo shutdown -p now Waited 10 minutes, then power cycled polisy. Beeped a few times (didn't count) Polisy still shows 3.0.63 Will appreciate any suggestions on what am I doing wrong. Thanks.

That was it! Restarting the ISY fixed the variable substitution; today, both report "Wednesday". Apologies for bugging you on this one, but many thanks for both your support and for your work on the node servers.

@bpwwerI'm running both WeatherBit and ClimaCell node servers in PG3 and notice a difference in the way they report the GV19 node (day of week forecast is for) in email variable substitutions. WeatherBit NS ${sys.node.n001_forecast_0.GV19} returns "Tuesday" ClimaCell NS ${sys.node.n006_forecast_0.GV19} returns "1" Yet, both Node Servers show 'Tuesday" in the Admin Console Day field on their respective Forecast 0 screen. Am I missing something in how to properly use GV19 in the ClimaCell NS? Thanks.

Is there a way to search for something in the list of Configuration>Emails/Notifications>Customizations? For example, can I search for a specific substitution variable in the list of Customizations without having to open and manually read each of the entries in the list? It seems there should be a way to export the list into an XML or TXT file for search purposes.

Once the storms passed, I spent a couple of hours looking at the configs of ISY, Polisy, and PG3, and restarting them a few times, trying to get my first Notification NS to show up in PG3. Finally realized that after purchasing the NS (trial version), I still had to go to back to the store and select Install. After doing that the NS showed up fine in PG3 Dashboard and populates properly in my ISY994. Got too lost in the configuration details to see what was likely clearly obvious to others. To borrow an expression from another knucklehead: Doh!

@apostolakisl Thanks. My first NS install on PG3 as well. I’ll try deleting/re-installing the ISY from PG3 as you suggested, once the local thunderstorms have subsided.

@apostolakisl I have a similar problem with installation of a NS on PG3, that I can't get to show up on my ISY (PG2 node servers are running fine). May I ask what you deleted and reinstalled? (the node server, the ISY entry on PG3?, something else?)

Successfully upgraded from 5.4.0 to 5.4.1 using Polisy front panel push button. AC and PG2 appear to be functioning without any issues. Log shows bios ver: 1.1.3, after successful installation of UEFI.

Geofence was sporadic for me in iOS 15.2 but has been functioning consistently in iOS 15.3.

After updating to iOS 15.3, Locative detected boundary crossings (both in and out) for the single test I made. Pushover received the boundary crossing info from Locative and properly reported to my iPhone 13. Hopefully, it will continue to function properly.

For the past two days Locative has properly reported entering and exiting my current location's geofence. Seems to have started working again after upgrading from iOS 15.1 to 15.1.1. Fingers crossed it will continue to work.

After the reinstall, it turns out Locative only worked the first time exiting one of my geofences and the first time entering another geofence at a distant location. Subsequent crossing either boundary no longer triggers Locative. It seems an update to iOS 15.1 is indeed needed to correct this problem.