wrj0

Thanks @kclenden. Ticket opened to report this possible IoX bug.

So, IoX may be determining 01Jan as day 0. Easy enough to do a simple modification to correct in a program: $iISY.DayOfYear = [Current Day of Year] $iISY.DayOfYear += 1

Yep, clock is set to 24-hour format, and is correct. Good thought, though.

In both my Polisy and eisy, I noticed today that $iISY.DayOfYear = [Current Day of Year] sets that variable to 48. But, today is day 49 for 2023 per epochconverter.com. Both devices correctly show today's date is Sat 02/18/2023. IoX v5.5.6 on both devices. What am I missing?

Yep, same thing with my tstat. Heat/Cool State status on UD Mobile immediately goes from Idle to Heating, but after completion of a heat cycle, it does take a few minutes before showing Idle. But Fan Mode status goes back to Auto immediately. Curious. @hchain Apologies for the delayed response; just saw your message above.

I picked up one of the TZ45R tstats off eBay for $30, and installed it yesterday. Enrolled easily into eisy, and so far basic functions seem to be working fine. UD Mobile controls the basic HVAC functions. Current temperature, Heat/Cool state, Fan Mode, Fan State, and Heat/Cool temperature set points all update immediately in UD Mobile. Initial IoX programs to detect and report temperature settings are working properly. Hard to beat this deal for a low-cost, simple Zwave thermostat.

Thanks for the suggestion. I may eventually go with something like the Kasa smart plug, but was hoping to use an existing eisy feature or service like WOL, if supported by the eisy.

Arbil's answer above offers a good reason.

After issuing a remote "shutdown -p now" and turning off the eisy, can it be restarted, perhaps via a Wake-On-Lan magic packet? If so, how does one enable WOL on the eisy?

Same here. Updated packages in eisy AC, went from 5.5.2 to 5.5.3. Cleared Java cache, pulled new start.jnlp. Can access AC only by selecting LAN in Launcher; Cloud selection doesn't seem to do anything. But, unlike mbking's experience, this is the first time I've noticed this issue.

Another recommendation for the Occupancy Node Server. Had it working well on ISY994 and Polisy for a long time, and very recently got it working on eisy.

@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.