Xathros

Hello @bmercier, Not sure is this is a bug or not but in at least the last 2 versions of PG3X, I am unable to get the system log to stay at anything other than the info level. I can change the dropdown to any other log level but if I leave the log page and come back, it's back to info. I'd prefer to have at error or warning for my normal day to day usage. -Xathros

Hello all, Please disregard my post (above) about disabled programs running. After messing with this for a while I finally realized that I had some Alexa routines set up that followed my state variables for the washer and dryer running states. Life was so much simpler when everything was done on the ISY... Now with automations set up in ISY, Alexa, Kasa, Smartthings, HomeKit etc it's getting harder to figure out exactly where the point of failure lies when there's a problem. I should have known it wasn't the ISY/IoX! 🤨 -Xathros

Same here. In fact, I've been struggling to get all 3 of my doors working with the My-Q stuff since one is a commercial opener and some of the My-Q gateway/hub devices don't work with the commercial openers. Finally got it all working and now they block my access with anything other than their crappy app. The only real feature I use in their app is a scheduled close at night if I forgot and left a door open. I can code that on the ISY so no loss there. I'm installing the YoLink stuff and will end up with better functionality on all three doors for less than the price of one My-Q gateway. And no more disco party flashing lights when I close my shop door from the house! -Xathros

Disabled Program still triggering Hello all. After the DST issues yesterday and messing around re-enabling all of my normally enabled programs, I've run into a curious situation. I have a pair of programs that I have disabled and they are still triggering based on the change in state of a state var. I have enabled/disabled them again and they still trigger. As a test, I created another simple program that triggers on a state var, disabled it and tested, it does NOT trigger when I change the variable state. Here is the program that should not be running Note that it shows as disabled. I have searched using the find feature for anything that might call this program and everything that references s.DryerRunning and there is nothing else that would trigger this to run. #Washer Notifier-Tracker is also triggering while disabled based on the change in it's state var. There are no folder conditions present in the Washer-Dryer folder. Now here is my test program: This one does not trigger when I set s.test to 1. This is the behavior I expect from a disabled program. Here is my version info: isy-5.7.0_5 Name : isy Version : 5.7.0_5 Installed on : Mon Nov 6 08:09:02 2023 CST And to maintain some continuity with the posts above, my Sunrise/Sunset times are correct today! -Xathros

Well, thanks to the DST kerfuffle today, I had to restart my systems. I have lost access to all 3 of my My-Q doors. Just ordered the YoLink Garage Door stuff. I'm already using YoLink for motion and temp sensing and am quite happy with the performance and stability of their devices. Can't say I'm going to miss Chamberlain, My-Q and their issues. I'll keep the My-Q node server installed for now in case Goose and the others can get it working again. -Xathros

Sunrise/Sunset are an hour early on my system as well. I'm in Central Timezone. DST checkbox is checked and grayed out. -Xathros

Hey @DreamerI90, You're not alone. This morning all of my programs were disabled. Quite sure this has to do with DST change. Over the years, I have had odd issues with the ISY and DST changes. This I think is the first time all of my programs went disabled though. It wasn't too hard for me to recover as I have all of my disabled program names begin with a # so I can sort on the summary screen select all but the #programs and re-enable all at once. A trick I learned a while back on these forums. Interestingly, I restarted IoX before discovering that all the progs were disabled and any program that was set to run at startup did in fact run as well as any that were called by my startup programs. I get that the programs that were called by others should have ran. Not sure if a DISABLED program that is set to run at startup should actually run at startup. @Michel Kohanim or @Chris Jahn - Thoughts, comments? Thanks. -Xathros

FWIW, My My-Q instance has been running trouble free for nearly 2 weeks now. Based on the chatter above, I don't dare restart it. -Xath

@Andy C First let me say I use beeps for doors opening all the time! I absolutely love the feature and am disappointed to be losing this capability as I move from Insteon to Kasa wall switches. I'm keeping a bunch of Insteon plug modules mostly just to keep my beeps! I'm not sure if this will help with your freezing problem or not but may I suggest that you create a scene containing all of the devices that you want to beep and then have your program beep that single scene rather than all of the devices individually. This will greatly reduce the Insteon traffic and make things much smoother. In addition, all of the devices will beep simultaneously rather than each in turn which I found I prefer. Hope this helps. -Xathros

Updated to new MyQ poly this morning and I'm back up and running. For those who updated and tried to restart right away, stop the poly for 30 minutes then restart. Thanks @Goose66for the quick response and update! -Xathros

I have both an ! and an @ in my PW but same without and they work in the MyQ app just fine. I did see someone in the Home Assistant world claiming to have solved it by changing user agent in the request to none. See below: JGrantman commented last month OK... this sure looks like an issue with Home Assistant. MyQ working via app without issue. Had been working in Home Assistant without issue for months or more... maybe 18 months? Update to Home Assistant 2023.9.1 and it broke. Same unauthorized error in logs. Following steps fixed issue for several days (until update to Home Assistant 2023.9.2). docker exec -it homeassistant bash cd /usr/local/lib/python3.11/site-packages/pymyq/ cp request.py request_bup.py vi request.py i to enter insert mode Modify line 34 Was self._useragent = None Is self._useragent = str("none") Esc key to exit insert mode :w + enter to write the changes :x + enter to exit VI Restart Home Assistant After update to Home Assistant 2023.9.2 after restart MyQ not working (again). Didn't even bother checking logs and just popped open ssh and executed the same steps (above) and restarted. MyQ now working as expected. Line 34 in /usr/local/lib/python3.11/site-packages/pymyq/request.py appears to be the culprit. Did not check if it changed with Home Assistant 2023.9.1 or if something else changed resulting in line 34 becoming an issue? Does it matter? There is enough discussion and detail confirming the change to line 34 fixes MyQ and persists (until Home Assistant update reverts the fix back to not working state). What is the impact or risk to using the line 34 update going forward? Obviously someone closer to the code and with sufficient understanding of the entire code could weigh in on any non-obvious negative impact if line 34 in /usr/local/lib/python3.11/site-packages/pymyq/request.py is changed -- but it seems like low hanging fruit and easy fix to big impact issue. (Big impact if you use MyQ for garage door). Dunno if this helps with the MyQ poly or not but figured I'd share what I found. -Xathros

Like @Chris McKean, @dbwarner5 and @glarsen above, a 30 minute shutdown did not solve the issue. I left if shutdown overnight and still a problem on startup today. For what its worth, the MyQ app on my iPhone is working just fine using the exact same credentials. Any other ideas? Thanks! -Xathros

Hello, I am having an issue with the MyQ Nodeserver this morning. After upgrading PG3x to the latest version (3.2.9), the node server cannot log into the MyQ service. I don't believe this is related to the PG3x update other than for the fact that the upgrade caused a restart and the node server needed to re authenticate with MyQ. I'm guessing MyQ changed something on their end? Here is an excerpt from my log: Network/server error logging into MyQ service: 401 Client Error: Unauthorized for url: https://partner-identity.myq-cloud.com/connect/token Any ideas? Thanks in advance. -Xathros

Hi DennisC, Thanks. I figured out which node the file belongs with and then removed the file. The node still appears to operate normally and now my backup completes. I'll watch for any other anomalies and hope that I haven't done any damage by removing the file. -Xathros

Hello everyone, I just tried to take a backup of my system this afternoon and ran into a problem. See attached screenshot. I have tried multiple times and the backup failed at the same point on each try. Any advice? Here is an excerpt from the error log at the point of failure: Thu 2023/09/07 12:35:56 PM 0 -170001 <s:Envelope><s:Body><u:GetSysConf xmlns:u="urn:udi-com:service:X_IoX_Service:1"><name>./FILES/CONF/NODES/UN0109.BIN</name></u:GetSysConf></s:Body></s:Envelope> Thu 2023/09/07 12:35:56 PM 0 -110007 0 Any advice? Thanks in advance. -Xathros

Hello GSutherland, Open the Terminal app on you Mac. It's a native app provided with MacOS. Type: ssh admin@<the-ip-address-of-your-eisy> (and press return) Password is admin unless you have changed it. You wont see the password characters as you type them. (and press return) From there, enter the commands that bmercier posted above. (followed by the return key) There may be errors or warnings reported, don't worry. When completed, type: exit (and press return) Then, return to the PG3x dashboard and start your noderserver(s) Hope this helps. -Xathros

I also have performed the reinstall of aioquic and also had build errors along the way (log excerpt below). My node servers are also now reconnected and appear to be working as expected. Thanks! -Xathros

I just discovered a better place for this at: Sorry for the extra topic. Admins feel free to delete this thread. -Xathros

Ditto. Just created a new thread on the subject before I discovered this thread. Sorry for muddying the waters. Here is the text of my other post: I saw the announcement for 3.2.3 and decided to upgrade packages. I waited 35 minutes then logged into PG3x to find all my node servers disconnected. I have tried restarting the node servers, reinstalling all node servers and finally a full system reboot but all remain disconnected. Any advice? Thanks in advance. -Xathros

I saw the announcement for 3.2.3 and decided to upgrade packages. I waited 35 minutes then logged into PG3x to find all my node servers disconnected. I have tried restarting the node servers, reinstalling all node servers and finally a full system reboot but all remain disconnected. Any advice? Thanks in advance. -Xathros

I love how things get done around here! Issue discovered and a change in the pipeline less than 6 hrs later. Nowhere else does this happen! What about updates/new versions to/of already installed node servers? Or re-installs of existing node servers? Just curious. I suspect I'll/We'll be fine with 30 days of logs as long as they aren't set to debug for normal ops. -Xathros

After this, I will endeavor to only set debug level for debugging and not for normal daily operations. 10Gb of uncompressed text is still an awful lot of text. It should be more than enough. I do think 1 to 2 weeks of retained logs should be sufficient. Just curious though, why not compress on rotation? -Xathros

I totally agree. During setup of a new poly, I like to see everything to get a feel for what's going on under the hood. I know the logs would be larger but, it's just text and compresses well and it's on a *nix platform so they'll rotate and it will be fine - or so I thought. Everything is set to error now and I've learned once again to never assume anything As usual, Michel and UDI's support is second to none. -Xathros

Thanks all. Michel remoted in and helped me out today. It was mostly my Kasa node server. I have 7 polys running and had all of the logs set to debug. Kasa with 50 nodes is *VERY* chatty and filled the 10G allotment for the polyglot filesystem. Between Kasa and the other 6 polys, it ran out of space with less than 2 weeks of logs! With no free space, pg3 would not start. It appears to me that in the current version, logs are not being compressed daily if at all. We deleted all the logs and I have set my log levels to error instead of debug. I think there will be some changes coming to prevent this sort of thing from happening again. -Xathros

Hello everyone, pg3 is down on my eISY. After some research, I have determined that pg3 is not starting because it has exceeded its disk quota. Looks like the database has ballooned and I've reached the 10G limit. Pretty sure this is my fault for having the log level set to debug on my Kasa node server. I didn't realize that the log data was stored in the database. My bad. How to clean up the log data, compact the DB and get back online? Any assistance is greatly appreciated. -Xathros