I created this post to track alternatives.
This was mainly for my benefit but I hope others will find it useful.
Confirmed worked as well
I wasn’t keeping track. I figured this to be the most salient, so I hope folks will notice and not simply “bump” the other posts wondering if there’s a fix yet.
Fixed with 2020.12.2
Hi, after updating to the latest 2020.12.2, the MyQ was working great again.
However i just saw that it is back to broken for me.
I doubled checked the Home Assistant version and I am indeed running version 2020.12.2.
Anybody else having the same problem ?
EDIT 1: Nevermind, it is working again.
EDT 2: I indeed found some errors in the logs:
Error requesting data from https://api.myqdevice.com/api/v5.1/Accounts/xxxxx/Devices: Server Error
Probably a temporary problem.
1 Like
The connection to the MyQ server appears to be intermittent, cutting in & out randomly. Anyone experience this ? HA Ver 2020.12.2 installed.
Same here. Started flaking out last night at 11:20pm ET:
I’ve had this issue since about the same time as you. Logs show the following:
2021-01-05 14:17:30 WARNING (MainThread) [pymyq.api] Device update failed; trying again in 2 seconds
2021-01-05 14:17:32 WARNING (MainThread) [pymyq.api] Device update failed; trying again in 4 seconds
2021-01-05 14:17:36 WARNING (MainThread) [pymyq.api] Device update failed; trying again in 5 seconds
2021-01-05 14:17:42 ERROR (MainThread) [pymyq.api] Error requesting data from https://api.myqdevice.com/api/v5.1/Accounts/<ACCOUNT>/Devices: Server Error
2021-01-05 14:17:42 ERROR (MainThread) [homeassistant.components.myq] Unexpected error fetching myq devices data: Error requesting data from https://api.myqdevice.com/api/v5.1/Accounts/<ACCOUNT>/Devices: Server Error
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 144, in async_refresh
self.data = await self._async_update_data()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 132, in _async_update_data
return await self.update_method()
File "/usr/local/lib/python3.8/site-packages/pymyq/api.py", line 223, in update_device_info
devices_resp = await self.request(
File "/usr/local/lib/python3.8/site-packages/pymyq/api.py", line 154, in request
return await self._send_request(
File "/usr/local/lib/python3.8/site-packages/pymyq/api.py", line 119, in _send_request
raise RequestError(message)
pymyq.errors.RequestError: Error requesting data from https://api.myqdevice.com/api/v5.1/Accounts/<ACCOUNT>/Devices: Server Error
It works intermittently… not completely down.
Ditto, mine has been on and off over 100 times since mid-last night.
Unfortunately it is setting all sorts of alerts off on security. I’ve completely disabled it for now.
Yes. On the one hand, it’s showing that the new approach is working. (Chamberlain is locking out some User Agent and the revised HA code is creating a new one that works. You get disconnected and then reconnected.) I might hope that Chamberlain will get tired of doing this and just stop.
On the other hand, we get this off-again / on-again operation that’s annoying, especially if it’s in an off phase when you want it to work.
I may end up writing a not-so-nice letter to Chamberlain telling them why I’ll never buy another Liftmaster/Chamberlain product.
(This will probably accomplish nothing.)
What I’m (ultimately) going to do is toss out the myQ add-on hardware and determine which of the various by-passes that actually work reliably I’ll use.
Please check the MyQ Alternatives thread or post to that one if you feel the need to point to your favority alternative.
2 Likes
Maybe… I just substituted home_assistant_user_2021 as my user agent instead of the random string and I’m starting to see the same disconnect/reconnect behavior. So could be independent of the user agent and something else with their API.
Can confirm in the past 2 hours (with user agent hardcoded as home_assistant_user_2021) I have approximately the same amount of random disconnects and reconnects as I have since first disconnect at 10:06:49pm Central last night, Jan 4th.
I’m not sure what kind of procedure Chamberlain is using to lock out User Agents (assuming that’s still what they’re doing). It can’t be a white-list exactly or our “invalid” UAs would never work. Whatever they’re doing, the disconnect/reconnect behavior seems to be a symptom. I’ve at least stopped getting a new status message each time this happens by adding an ignore a transition from “Unavailable” to my automation.
Given the regularity of the server errors since last night, with errors smeared somewhat smoothly over time, I’m wondering if Chamberlain started rate-limiting requests on a per-user basis. That would match the symptoms we’re seeing. E.g. allowing 10 requests per user over a 1-minute time window (hypothetically), so if number of requests exceeds that, server returns an error for the remainder of that time window until the next window begins. (Technically, if they’re rate-limiting they should return a 4XX response like 429 rather than a 5XX server error. But they don’t seem to care about that level of detail.)
I’m not familiar with the MyQ integration code, but looking at pymyq/api.py there’s a global variable that at first glance seems to control the update frequency:
DEFAULT_STATE_UPDATE_INTERVAL = timedelta(seconds=5)
I’m busy at the moment, but others might try increasing that value (e.g. to 15 or 30 seconds) to see if that reduces or eliminates the server errors.
Or, maybe Chamberlain’s servers aren’t able to handle the load, or are configured to rate-limit globally, and that’s causing a fraction of requests to get errors. Individuals updating DEFAULT_STATE_UPDATE_INTERVAL in their pymyq/api.py file would help isolate whether there’s some rate-limit enforcement per user vs a global issue.
I may be reading the code wrong but, I think DEFAULT_STATE_UPDATE_INTERVAL appears to act as a throttle, ensuring requests don’t happen more often than this value. However, the actually update frequency is managed by the Home Assistant component in myq/const/UPDATE_INTERVAL, which is set to 61 by default.
At any rate, I’ve set my DEFAULT_STATE_UPDATE_INTERVAL to 30 seconds. We’ll see if that resolves anything.
I don’t think this is the solution. I’ve got 2 instances of Home Assistant running (for testing). One with the standard myq and one with the modified myq. Both of them connected to the same myq account. The modified myq is currently having issues (with the usual “Server Error”) while the unmodified myq is not. If it was rate limiting and if DEFAULT_STATE_UPDATE_INTERVAL affected that rate, then I should either see it on both or on the unmodified myq first.