my Polisy keeps rebooting, about once a week or two

[someguy]

I figured it was the power supply going bad, so I bought a new one and it still reboots about once week or two.  any suggestions?  should I open a ticket?  or do you think an error log could help me (us) figure out why it is rebooting?

[DennisC]

1 hour ago, someguy said:

I figured it was the power supply going bad, so I bought a new one and it still reboots about once week or two.  any suggestions?  should I open a ticket?  or do you think an error log could help me (us) figure out why it is rebooting?

What version firmware and UI are you on? This was an issue that was corrected in the current v5.5.9.

[someguy]

@DennisC:  THANK YOU!!!

 

I'm on 5.5.6

how do I upgrade?  I don't see anything that looks familiar to upgrade my firmware.  

[DennisC]

5 minutes ago, someguy said:

@DennisC:  THANK YOU!!!

 

I'm on 5.5.6

how do I upgrade?  I don't see anything that looks familiar to upgrade my firmware.  

If you are on Polisy, in the admin console go to Configuration and click on Upgrade Packages button. The admin console should close. Wait 15 - 30 minutes and log in to admin console again. 

Go back to Configuration and select reboot.

Before opening admin console, you will need to clear your Java cache and download a new start.jnlp. Click on start.jnlp and it will download a new Launcher to your desktop.

 

[photogeek54]

Mine rebooted this morning too. I'm on 5.5.9

[MrBill]

12 minutes ago, photogeek54 said:

Mine rebooted this morning too. I'm on 5.5.9

is it an eisy? if so, is it connected to portal?   If so, the cause of the reboot this morning is known and unrelated to this thread.

[johnnyt]

Rebooting due to a portal outage!? That would be a bit harsh. Please say it ain't so. I'm working hard to avoid cloud dependent stuff. I'm okay to use it for value added stuff but not if it prevents me from doing core stuff without it, or causes my system to reboot. It's one of the reasons I've been sticking with ISY despite the problems since zwave addition that are hopefully going away soon so we can get back to the near flawless beta releases of... is it 5 years ago now?

 

Edited March 24, 2023 by johnnyt

[MrBill]

16 hours ago, johnnyt said:

Rebooting due to a portal outage!? That would be a bit harsh. Please say it ain't so. I'm working hard to avoid cloud dependent stuff. I'm okay to use it for value added stuff but not if it prevents me from doing core stuff without it, or causes my system to reboot. It's one of the reasons I've been sticking with ISY despite the problems since zwave addition that are hopefully going away soon so we can get back to the near flawless beta releases of... is it 5 years ago now?

 

My understanding is that the portal had to be modified to make way for portal access for PG3.

The problem however is that an unexpected reboot was forced on all PG3X (limited to eisy at this point).    The circumstances were unusual, and I'm not certain how the issue could have been mitigated, but an unexpected reboot when the customer may not be available to fix any issues that come up is not excusable.   I've generally worked out all the issues that I once had on reboot, but I'd still be uneasy about an unattended reboot.

[mwester]

17 hours ago, johnnyt said:

Rebooting due to a portal outage!? That would be a bit harsh. Please say it ain't so. I'm working hard to avoid cloud dependent stuff...

It's worse than cloud-dependent.  Being cloud-dependent just means that *my* device is unable to use or access services over the internet for some period of time, but it continues to function for other services.

So we've just learned that UDI has the ability -- and will exercise that ability without notice! -- to cause the ESIY to cease providing *any* services (however briefly it may have been this time).  This crosses the line from being dependent upon cloud services to being a service in and of itself.

So think of the EISY as being a chunk of hardware that *enables* you to use UDI's services.  This isn't a surprise; the OS vendors have moved to this "OS-as-a-service" model years ago.  But to be honest, this is the very last thing I expected from UDI; it's the very antithesis of what the ISY was.

Ah well, progress for all the young'uns...  I'll stick with my ISY.  Have a great day folks, got to get the horses hitched up to the wagon, need to get to town for some shopping.  You crazy kids with your new-fangled inventions...

[bpwwer]

It's a fine line.  So many folks want everything to just work and happen automagiclly but we can only do that if we have control and use "cloud" based systems to make it happen.

It is still a goal to have things work even if access to the Internet is removed, but more and more, the enabling of features requires Internet access.

We're slowly trying to integrate the various components, but that also means that they are becoming a lot more interdependent.  PG3x depends on IoX to function properly both PG3x and IoX depend on UDX to function. There are OS services that all three depend on.  So now when we try to update one component, it can impact all and the safest, more reliable way to ensure they are all working together is to reboot the eisy.

Back when it was just the ISY, it was just one component, but that was still rebooted when the firmware was updated. The main difference was that user's had to initiate the update, it was never pushed.   Maybe that's what should have happened here too, instead of trying the push the update, it should have been user initiated.  I don't know. 

 

[Techman]

Almost every time I update packages on the EISY I'm then unable to access PGx. The only way I've found to resolve this is to remove power from the EISY.

[bpwwer]

4 minutes ago, Techman said:

Almost every time I update packages on the EISY I'm then unable to access PGx. The only way I've found to resolve this is to remove power from the EISY.

If it's reproducible, it would be good to submit a support ticket and let support take a look at your system to try and understand why that is happening.

There should be no difference between rebooting and power cycling the eisy.  However, I've experienced cases where reboot from the AC simply doesn't work.  I.E. it doesn't actually cause the system to reboot.

[Techman]

Here's the error message I get when I try to access PGx prior to removing power. An EISY reboot doesn't resolve the error.

Any suggestions?

[bpwwer]

PG3x uses the UDX component to authenticate.  A 401 means that UDX specifically returned that error to PG3x to indicate that the username/password is not correct.

I don't really know how UDX does that check, it may actually use IoX since it is supposed to be the same username/password used to log into IoX via the admin console.  So one possibility is that IoX isn't running or is in a state where it doesn't respond properly.   Can you use the admin console to log into IoX at this point?

[DennisC]

I've also seen this error several times. When it happened, I had no problem logging into admin console and rebooting eisy.

This would not solve the issue. The only thing that worked for me was to shutdown and remove power. Once eisy restarted after removing power, I would have no problem logging into PG3x.

[Techman]

@bpwwer

@DennisC

In addition to the 401 error I was getting, lately every time I accessed the EISY in the AC I would get a popup that there were updates available and to press update packages, which I did, but the message would keep reappearing each time I opened the AC.

I finally got both problems resolved by pressing the button on the front of the EISY once.

 

[DennisC]

28 minutes ago, Techman said:

@bpwwer

@DennisC

In addition to the 401 error I was getting, lately every time I accessed the EISY in the AC I would get a popup that there were updates available and to press update packages, which I did, but the message would keep reappearing each time I opened the AC.

I finally got both problems resolved by pressing the button on the front of the EISY once.

 

@Techman

This is a known issue and should be corrected in the next release.

[johnnyt]

23 hours ago, bpwwer said:

It is still a goal to have things work even if access to the Internet is removed, but more and more, the enabling of features requires Internet access.

Exactly where can I get a list of the features that would stop working if UDI decided to stop providing the supporting cloud service, or, gulp, decides to get out of the home automation market?

I'm assuming/guessing the following needs a funded cloud service: remote access, the node server store, webhooks, and tie ins to Alexa/Google. While I would certainly miss the NS store for updates and new possibilities, I hope I'm not dependent on it to keep what I have running. The other stuff I listed I either don't use or can get by without.

I think this needs to be clear so folks know what they're buying into / sticking with when they use features dependent on a cloud service.

 

Edited March 26, 2023 by johnnyt

[Geddy]

@johnnyt perhaps that's best addressed by contacting UDI directly rather than random forum post.

https://www.universal-devices.com/contact-us/

sales@universal-devices.com

 

I think this topic has wondered fairly far off topic. OP hasn't returned since Thursday to update status. @someguy your method for updating can be found in this post: 

 

If you still have issues after updating to 5.5.9 please submit a support ticket for review and assistance. Many bugs have been fixed in recent updates and it's easier to support on current versions.