Xathros

@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

Hello all- All working now for me too. I did need to enable SNI on all of my web hook resources which is new but now they work after IFTTT's patch rollout. Thanks all for the community support! -Xathros

Hello guags99, My first failure was: Tue 2021/11/30 04:23:52 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 Also CST and was the first time a maker event was called since the week before as we were away and the events would not have fired while we were gone. I saw mention of 11/29 earlier in this thread as well so I suspect your right. -Xathros

Found the dashboard - here are my client settings:

Hello all, I have tested with SNI checked and unchecked. Timeout set to 20,000 - no noticeable difference in time to failure from timeout of 1000. Where do I find the Client settings to check (or uncheck) the Verify box? Seems like something changed outside the scope of the ISY for this to all of a sudden be affecting so many clients. Probably something at the IFTTT host side but that'd just a guess on my part. Thanks in advance for any guidance. -Xathros

Hello all, I'm seeing the same thing with all of my outbound maker network resources. Get, Post, URL Encoded or not, SNI or not, they all fail. Every failure results in the same error in my error log - example follows: Wed 2021/12/01 04:45:49 PM System -170001 <s:Envelope><s:Body><u:TestNetResource xmlns:u= Wed 2021/12/01 04:45:49 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 5 I can call the web hook just fine from a browser on my computer. Any insight would be appreciated. -Xathros

Me Too! Spent about an hour troubleshooting. Should have come here first... Thanks all!

All, Thanks to everyone that jumped in here to help. I just completed a remote support session with UDI. Looks like the database had become corrupted likely due to a power failure. They very quickly had it repaired and I'm back up and running with no lost config or anything. As always, the support offered by UDI is unmatched by anyone! -Xathros

Ugh. Lets see if my second attempt to open a ticket was a success... Thanks. -Xath