It’s been fixed in pymyq. If you don’t mind editing your core files, you can fix it yourself:
This is the file:
/usr/local/lib/python3.8/site-packages/pymyq/api.py
This is the commit with the fix, just make the same changes by hand and restart home assistant:
Thanks! I got mine working again!
What’s the command in HassOS through SSH to check the setting to verify that it needs to be changed? Then which command needs to be sent to change it?
For example, on a recent user agent change the command was
docker exec -it homeassistant sed -i 's/okhttp\/3.10.0/pymyq/g' /usr/local/lib/python3.8/site-packages/pymyq/api.py
that fix is already in latest docker if you are running docker.
however still throws error on the logfile
I figured it was redundant but wanted to verify by also checking the setting. Core is a docker image in HassOS so it should be the same as running docker is the way I understand it.
I think a lot of people have MyQ excluded from recorder or they don’t look at their logbook to see the intermittent problem.
I don’t have it excluded in recorder and I have a history-graph below my garage door button in Lovelace so I see the intermittent problem. I also have Unavailable Sensor Detection and Notification which alerts me when a cover, sensor, device or entity goes unavailable.
Fixed? I’ve updated to 2021.1.1 and still see the intermittent myQ server connection errors with the garage door entities becoming temporarily unavailable.
@ehendrix - Erik, I see in your pymq 2.0.13 update that you removed the random user-header and reverted to “pymyq” as the default header string. You’ve also added a means to specify a custom header string in the api.py call.
How is this custom header configured in Home Assistant during the login?
Does a custom header really solve the problem with the myQ v5 infrastructure apparently crumbling in transition to v6?
I’m still getting the errors on mine as well. I have a telegram bot setup that displays the status of my garage doors when they change. It’s cycling between unavaible (the 400 error) then closed about a minute later every 10-15 minutes since updating to 2021.1.1.
Since updating to 2021.1.1, I get the following error every few minutes:
Unexpected error fetching myq devices data: Error requesting data from https://api.myqdevice.com/api/v5.1/Accounts/<random string>/Devices: 500 - Server Error
Same as @gwaland, my status seems to cycle between the correct status and unavailable.
500 errors are generally an issue with the server, not with the client. Are we polling MyQ too often? Perhaps their infrastructure can’t take it?
Edit: seems to be a known issue with MyQ’s transition from the v5 API to the v6.
I have this in my logs:
Error requesting data from https://api.myqdevice.com/api/v5.1/
Is that what you are talking about?
If you don’t have a MyQ device that supports HomeKit then I don’t think it’ll work for you. There are some details here:
If your opener doesn’t have the feature natively you can add this:
I should add that lots of people have complaints about the HomeKit bridge and say it isn’t reliable though I’ve found it to be pretty good once I added it to Home Assistant.
PR https://github.com/home-assistant/core/pull/44972 has been opened allowing user agent to be set upon setup or afterwards as an option.
I think we should all continue to make it known that the lack of a public API is bad business and will lead to customer retention issues / customer acquisition issues for Chamberlain if they don’t adapt.
I reached out and figured I’d share their response - though I doubt it will move the needle much. The more they see this though, the more they may become open to it? Hopefully…
Yeah, sadly this breaks all this time because MyQ refuses to offer an API, so Home Assistant is using an unofficial API that emulates the MyQ app, so every time MyQ decides to make a change, it stops working, usually it gets patched pretty quickly though.
Are others still getting the constant disconnects and reconnects in the history of the myq devices or did I miss a fix to that as well?
Mine still, and I removed this integration for now.
Mine is working and stopping every few mins 
Interesting note: Mine has been doing exactly as yours and others report (with uptimes ranging from 10-30 minutes, followed by unavailable for roughly a minute) until 10:00:21 PM last night. As of that time, it has stopped going off-line. (No off-lines for 6 hours now.)
I also see that it seams to be polling the door very frequently, is this polling needed ?
I mean you can see that status of the door ? so I dont see the need of polling it ? Maybee they blocking cause all of our packest are polling so much ?
I’m sure it’s related to that. The official word from Chamberlain is that they don’t have an “open” API and so tend to view anything using their servers with a bit of suspicion, but it can’t hurt to cut down the polling period. (I don’t need to know the second my door changes state.)
I’m in the same boat. It was working as of 2021.1.1 (but with the 15- to 30-minute disconnection/reconnection). Now as of 10:00PM last night the connection has been solid.