MrBill

A cloud service that barely breaks even at less that ~$1/month to cover the cost of the Amazon Server it runs on. It's a cloud service, they break sometimes.

This was a server side failure, and there are no steps end-users can take to prevent it in the future. It could have been a myriad of things, some of which UD has no control over because the portal is running on AWS, meaning it might be purely an AWS issue.

I just edited refresh your page if you already have it on the screen.

This should do what you want to do.... Schedule tree - [ID 00C8][Parent 00EF] If From 7:00:00 PM to 03:00:00 AM (next day) Then Enable Program Alternate Christmas Tree $s.Christmas = 1 Else Disable Program Alternate Christmas Tree $s.Christmas = -1 Set 'Kasa Controller / Color Christmas tree lights' Off Set 'Kasa Controller / White Christmas tree lights' Off Alternate Christmas Tree - [ID 00C2][Parent 00EF] If $s.Christmas is 1 Then Set 'Kasa Controller / White Christmas tree lights' On Set 'Kasa Controller / Color Christmas tree lights' Off Wait 15 Min $s.Christmas = 0 Else Set 'Kasa Controller / Color Christmas tree lights' On Set 'Kasa Controller / White Christmas tree lights' Off Wait 15 Min $s.Christmas = 1 Disclaimer: I didn't test it, If you have problems I'll set it up here and see where it goes wrong.

You probaly updated the firmware on the TP-Link devices. That makes them incompatible with 3rd party products. Complain to Tp-link.

There is a product named eisy that replaces Polisy, new hardware, same OS and software as Polisy.

I gave you the answer, so did @bpwwer PG2 on Pi is dead. It won’t update. Stop complaining about it. Either make up your mind to 1) stay with the platform and update your hardware. 2) run it just like it is now without updating/upgrading anything or 3) find something else that better meets your needs.

PG2 running on a raspberry pi has been past END of Life for a few years now. More recently PG2 on Polisy has been deprecated because it has a replacement PG3. Polisy is also out of stock and has been since last May. Due to supply chain issues it’s being replaced as eisy… basically similar to Polisy, but different hardware running the same OS and software.

Forgot to mention that you get free product support for life. As @asbril points out just open a ticket. Sure support won’t set up and program your system for you for free, but other than that you get pretty much unlimited support, just open a ticket.

Don’t forget to mention the portal subscription at less than $1/month is the single best home automation value on the entire internet.

Right... they also tweeted it today:

I didn't use it in Win10 either... never even been on that java tab to do anything...

My take is the original components on older PLMs were poor quality and/or not quite the correct spec. PLMs manufactured after about 2016 seem to be better quality from the start, perhaps even newer is even better, but i don't know that. In short my take is that once repaired they may be better going forward and not require additional cyclic maintenance. @Mustang65 can you tell use the date codes on your failed PLMs, and if you remember how old they are/were when they failed... I'm curious about the vintages. Especially how many were after 2016ish. @larryllix did the box maybe get dropped while you were moving?

I use windows 11 and don't (and never have) make use of the "Exception Site List"

This is a reboot: Tue 2022/11/15 04:57:46 PM System -5 Start did you manually do that or did randomly occur? Unfortunately it's not uncommon to see a bunch of nasty errors like UDQ: Queue Full in the minutes after a restart. The rather cryptic but sometimes useful error code listing can be found here. The concerning error that stands off the page to me is: Mon 2022/11/14 03:00:45 AM System -170001 UDQ: Queue(s) Full, message ignored which is not following in the minutes after a restart. that like means that your ISY is too busy doing something it shouldn't be doing. Possibly a run away program. You might find this via the program summary tab, sorting by activity column. We aren't interested in "Idle" Is there anything "running" that's probably not sitting in a "wait"? if so, those would be a good place to start. Do you have any problems with your internet connection? is it stable and "always on' or does it cut out sometimes? In general, that might be too small of a snipet of the Error log to check. You might also send the full error log to Michel support@universal-devices.com for his comments.

Check your ISY error log for clues to what’s happening. Is this a 994 or IoP running on Polisy? Error log is on the tools menu in the admin console. what version is the ISY running? there’s no direct way to schedule a restart for the ISY, but that would be a bandaid rather than the solution to the problem. for whatever it’s worth, I don’t have this problem. I’ve gone 6 months without have to reboot the ISY.

seems to be a Ubiquiti Dream Machine Pro problem then. I didn't think any router would auto-update tho, too easy to break something unattended.

@Pete C Open a ticket. Michel will get you back online faster than alot of back and forth in the forum. support@universal-devices.com

I believe catch up at restart is only referring to the start time of the program. Once the program is running it will run for an hour and finish an hour after it started, not "catch up" the steps by ignoring the 'waits'. So in your example: "Let's say that I have a program that starts at sunrise"-- if it's after sunrise the program will start -- "and this program has several steps after a set number of minutes and ends at sunsrise plus 1 hour." -- the "wait" statements in your program have no way of knowing anything about catching up... they will still wait... the program will still take 1 hour to run.

In my case the bench has many plugs on a strip within arms reach. Like this, but not because mine not plug in and is wiremold branded (a "sample" the factory rep sent me as a christmas present back when I was in the business)

They aren't listed period currently. You'll note this list, contains availability dates for items that we know are coming, and it lists several item as "discontinued", it however doesn't specifically list mini-remotes either with a date of return, or discontinued.

I'm wondering if your SD card failed. and/or you somehow connected with the wrong version of the admin console. Were you working remotely through the portal? Or on the same network as the ISY.

In addition to Factory resetting the ISY you should also factory reset each device. Most devices, Pull out the Air-gap or set button, wait briefly, then press the same all the way in and HOLD it in until the long beep STOPS or ends. Devices that don't have a set button that pulls out, same process basically, hold the set button while the device is powered up and continue holding it in until the long beep stops or ends. This could be done as they are installed, but i tend to wire devices up to a test cord, and plug them in, factory reset them, add them to the ISY, test them, and then install them. (cap the red wire with a wirenut while using the test cord.)

one more thought, you might want to add a nag.... NoExercise.SendMessage - (Enable Run at Startup) If $sExercise.State is 0 Then Wait 170 hours (24*7+2) Repeat every 6 hours Set 'Notification Controller / Service Pushover polyglot' ....... and whatever else to change the message to no exercise in the past 170 hours. Else (none) Now if the 170 hours expires the messages will continue being sent every 6 hours until the generator is exercised.

I'm assuming that excerise state is always 1 or 0, also assuming you want to keep the message that positive message that the exercise started then simply add an ELSE Exercise.SendMessage - [ID 0026][Parent 0025] If $sExercise.State is 1 Then Set 'Notification Controller / Service Pushover polyglot' Send Sys Short With Params To iphone Priority=Normal Format=Monospace Sound=Pushover (default) Retry=30 Expire=60 Else Wait 170 hours (24*7+2) Set 'Notification Controller / Service Pushover polyglot' ....... and whatever else to change the message to no exercise in the past 170 hours. When exercise becomes 1 again the Wait will be interrupted and the notification below will never be sent. Another similar method is a separate program: NoExercise.SendMessage - (Enable Run at Startup) If $sExercise.State is 0 Then Wait 170 hours (24*7+2) Set 'Notification Controller / Service Pushover polyglot' ....... and whatever else to change the message to no exercise in the past 170 hours. Else (none) This program assumes that $sExercise.State will be zero when the ISY starts up, and will immediate start waiting 170 hours. An advantage to this program is that the original program could effectively be disabled, with only No Excercise notifications being sent. Either way should be ok, I would prefer the second if it was mine.