Yep - also noticing this happening. Just started last night.
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.
As of a few minutes ago (1/8/2021 8:30a PT) I’m getting this error:
2021-01-08 08:25:44 ERROR (MainThread) [homeassistant.components.myq] Unexpected error fetching myq devices data: Error requesting data from https://api.myqdevice.com/api/v5.1/Accounts/xxxx/Devices: 400, message=‘Bad Request’, url=URL(‘https://api.myqdevice.com/api/v5.1/Accounts/xxxx/Devices’)
Anyone else seeing this?
Yup, I’m seeing 400/‘Bad Request’ too, since 11:21am ET.
Ditto for me
1 Like
Thank you for sharing this with the community.
I am running into an issue as the current myqservice webpage doesn’t show any options for device management that I am seeing, only subscription maintenance.
Am I missing something of did myq in there usual “wisdom” neuter thing even more since you went through this?
Thanks,
T.
I get three different errors:
Unexpected error fetching myq devices data: Error requesting data from https://api.myqdevice.com/api/v5.1/Accounts/87927721-d545-4f6d-bcfd-effa5762e717/Devices: Server Error
12:04:51 PM – MyQ (ERROR) - message first occurred at 9:52:27 AM and shows up 48 times
Error requesting data from https://api.myqdevice.com/api/v5.1/Accounts/87927721-d545-4f6d-bcfd-effa5762e717/Devices: Server Error
12:04:51 PM – /usr/local/lib/python3.8/site-packages/pymyq/api.py (ERROR) - message first occurred at 9:52:27 AM and shows up 48 times
Device update failed; trying again in 2 seconds
12:04:45 PM – /usr/local/lib/python3.8/site-packages/pymyq/api.py (WARNING) - message first occurred at 9:52:15 AM and shows up 144 times
It basically means what we’ve mentioned above, that Chamberlain is blocking the current user agent and that the new myQ integration is working around that. (This, by the way, is happening when “official integrations” like the myQ app and Amazon Key function without any issues.)
same here
Logger: pymyq.api
Source: /usr/local/lib/python3.8/site-packages/pymyq/api.py:118
First occurred: 8:43:37 AM (10 occurrences)
Last logged: 8:53:56 AM
- Error requesting data from https://api.myqdevice.com/api/v5.1/Accounts/xxxxDevices: 400, message=‘Bad Request’,
I’m getting really tired of this. I know it’s an unsupported method for MyQ but they just need to let this happen.