TSinclair Posted March 24, 2023 Posted March 24, 2023 (edited) Please educate me. One of the reasons I have been loyal to ISY (and now eisy) all these years has been to maintain local control. To me this means that everything within the walls of my home works, even if the internet is down. I was very surprised to get that angry call from the wife this morning that "I can't turn on the damn lights". What this translates to is lights using motion or contact sensors through the DSC Node Server, and Hue lights using Network Resourses did not function during the outage this morning. I don't understand how that can be. I apparently mistakenly assumed the portal maintenance this morning would only impact UD Mobile, and Alexa routines. Please educate me on the dependencies on the portal. Edited March 24, 2023 by TSinclair correct typo 1
bmercier Posted March 24, 2023 Posted March 24, 2023 I'm not sure how your issue could be linked to the maintenance. Also I'm not sure how the DSC nodeserver works, if it relies on cloud resources. The answer may lie in the nodeserver log. Benoit
Goose66 Posted March 24, 2023 Posted March 24, 2023 The DSC Node Server does not use any cloud resources, and does not need the Portal to be active. I don't know about the Hue node server for controlling the lights.
Goose66 Posted March 24, 2023 Posted March 24, 2023 (edited) To answer the "Please Educate Me" question, most node servers do not require the portal or other UDI cloud-based resources to operate - even those that operate through vendors' cloud-based services. However, some node servers utilize oAuth (actually, a specific oAuth method) for authorization to the vendors' cloud-based services, and these node servers may very well require UDI cloud-based resources to complete and maintain this authorization. I will also throw in my personal 2-cents here: the UDI platform is now and has always been a DIY Home Automation platform, and, IMO, it is the responsibility of each individual to educate themselves on the architecture and interface requirements of each automation device they add to their system. That said, it may be helpful for node server developers to specifically point out when their node servers require UDI cloud-based resources for oAuth authentication or other. Edited March 24, 2023 by Goose66 1
bmercier Posted March 24, 2023 Posted March 24, 2023 8 minutes ago, Goose66 said: To answer the "Please Educate Me" question, most node servers do not require the portal or other UDI cloud-based resources to operate - even those that operate through vendors' cloud-based services. However, some node servers utilize oAuth (actually, a specific oAuth method) for authorization to the vendors' cloud-based services, and these node servers may very well require UDI cloud-based resources to complete and maintain this authorization. I would add that the maintenance did not impact the database, the web server or the oAuth servers. The only impact was that the ISY to Portal connectivity was dropped for a few seconds, and the subscriptions as well. Benoit
TSinclair Posted March 24, 2023 Author Posted March 24, 2023 Thanks, this is what I assumed related to the Envisalink/DSC node server. To clarify, the Hue lights are controlled through ISY Network Resources using programs. I never figured there would be a portal dependency, but according the the wife, they did not work from ~7:15am to 7:23 am CDT. I also got a notice from Telegram, through the Notification Node Server, that the service started up at 7:21 CDT. I can't look at Node server logs right now, but it now seems something caused some of them to restart. I am here on this forum to learn, I'm not casting blame, I just want to understand.
Goose66 Posted March 24, 2023 Posted March 24, 2023 4 minutes ago, TSinclair said: I can't look at Node server logs right now, but it now seems something caused some of them to restart. I am here on this forum to learn, I'm not casting blame, I just want to understand. If something in the brief portal maintenance caused node servers to restart, then this would be important learning for all of us!
MrBill Posted March 24, 2023 Posted March 24, 2023 1 hour ago, TSinclair said: (and now eisy) Perhaps your eisy went through a random reboot, someone I was chatting with indicated they had one this morning with eisy... unclear what's causing those. Unfortunately the platform is still going thru some growing pains.
TSinclair Posted March 24, 2023 Author Posted March 24, 2023 I had that thought, but based on timestamps of my state variables, eisy did not reboot. Here is the eisy error log during the window. Anything concerning? It seems strange that some of the timestamps are out of order. Is it possible something caused eisy to go into a busy state?Fri 20230324 060713.txt
MrBill Posted March 24, 2023 Posted March 24, 2023 Fri 2023/03/24 07:21:49 AM 0 -5 Start IoX started at 07:21:49 AM.... sure seems like it rebooted to me...
TSinclair Posted March 24, 2023 Author Posted March 24, 2023 You are correct. I wish I had a dang screen print so ya'll don't think I'm crazy! I was logged into AC from the office for the last ~hour. Just this moment I was disconnected and when I reconnect all the state variables now show the system restarted at 7:21:49am.
TSinclair Posted March 24, 2023 Author Posted March 24, 2023 So chalk this up too random reboot that just happened to coincide with the maintenance window. good grief.
mjrush Posted March 24, 2023 Posted March 24, 2023 (edited) My eisy rebooted this morning with this in the error log file. I don't believe it has done this before. Fri 2023/03/24 07:22:46 AM 0 -170001 {"certificateId":"","certificatePem":"-----BEGIN CERTIFICATE----- Fri 2023/03/24 07:22:55 AM 0 -5 Start 7:22 Arizona time, same as PDT now. Polisy and ISY994 didn't reboot. Polisy has a portal subscription, 994's was transferred to eisy. Both Polisy and esiy are 5.5.9 and are on a UPS. Edited March 24, 2023 by mjrush
bmercier Posted March 24, 2023 Posted March 24, 2023 This update is in preparation of PG3 remote access. One of the thing that it does, is provision access to AWS IoT Core. The reboot is a sign that provisioning went successfully. We are noticing an issue currently, several eisy's keep losing their connection and reconnecting. This is currently under investigation. 1
Geddy Posted March 24, 2023 Posted March 24, 2023 5 minutes ago, bmercier said: The reboot is a sign that provisioning went successfully. Well that explains my reboot about 10:25 eastern today. Thanks.
Goose66 Posted March 24, 2023 Posted March 24, 2023 34 minutes ago, bmercier said: This update is in preparation of PG3 remote access. One of the thing that it does, is provision access to AWS IoT Core. The reboot is a sign that provisioning went successfully. We are noticing an issue currently, several eisy's keep losing their connection and reconnecting. This is currently under investigation. So the maintenance did indeed cause eISYs (and associated PG3/node servers) to reboot?
bmercier Posted March 24, 2023 Posted March 24, 2023 33 minutes ago, Goose66 said: So the maintenance did indeed cause eISYs (and associated PG3/node servers) to reboot? Yes, if at 5.5.9 with a valid license.
Goose66 Posted March 24, 2023 Posted March 24, 2023 (edited) Well, I guess that makes @TSinclair original post deserving of a "Thanks!" Edited March 24, 2023 by Goose66 1
brians Posted March 24, 2023 Posted March 24, 2023 Is this reboot EISY only? I have a Polisy and it did not reboot and everything is working normally. Just wondering since it didn't reboot was the update unsuccessful for me?
Geddy Posted March 24, 2023 Posted March 24, 2023 1 hour ago, brians said: Is this reboot EISY only? I have a Polisy and it did not reboot and everything is working normally. Just wondering since it didn't reboot was the update unsuccessful for me? Not sure, but I think from some comments it was eisy targeted. It could have impacted some Polisy if they have converted to PG3x. I think it was more targeted to PG3x and IoX 5.5.9 based on reading this thread and maintenance thread(s).
bmercier Posted March 25, 2023 Posted March 25, 2023 1 hour ago, Geddy said: Not sure, but I think from some comments it was eisy targeted. It could have impacted some Polisy if they have converted to PG3x. I think it was more targeted to PG3x and IoX 5.5.9 based on reading this thread and maintenance thread(s). Precisely. PG3x and IoX 5.5.9 only.
DennisC Posted March 25, 2023 Posted March 25, 2023 9 hours ago, Geddy said: Well that explains my reboot about 10:25 eastern today. Thanks. Mine was at 8:21 am eastern time. How come yours was so late? 1
bmercier Posted March 25, 2023 Posted March 25, 2023 Just now, DennisC said: Mine was at 8:21 am eastern time. How come yours was so late? Provisioning takes time. eisys were provisioned one after the other, automatically in sequence. 1
Geddy Posted March 25, 2023 Posted March 25, 2023 6 minutes ago, DennisC said: How come yours was so late? Like me, my eisy doesn’t like to jump the gun on updates! That or it slept in on a Friday. Thanks for the explanation @bmercier! 1
photogeek54 Posted March 25, 2023 Posted March 25, 2023 PLEASE give us notice before causing an Eisy to reboot! A reboot is not temporary for me, all my programs cease to run following a reboot until I set a state variable. This was done as a safety measure to insure a way to access Iox in the event of an infinite loop. 2
Recommended Posts