core: MyQ fails to setup with 401 or 429 error

Hello everyone - I am closing this issue as it has been resolved with #101852 and will be included in 2023.10.2 #101871 I would highly recommend not doing any kind of manual solutions - and instead just wait for 10.2 to come out which will probably be later today.

I won’t ask for this thread to be locked, but please restrain from commenting so others can see this

As a reminder - please upvote the original post if you are having the same problem, do not add extra comments stating that you have the same problem - instead upvote the original post. I get buried in notifications and it is extremely difficult to separate helpful information and just chatter.

I don’t have a ton of time this week to try to look at it, but I will try my best. As a reminder to everyone - I don’t own one of these devices, and I am always looking for a new codeowner, I have had one user step forward and attempt to diagnose some problems, I will give them as much support as I can with my limited time this week and if they aren’t able to figure it out, I will try to solve what I can with my limited time

Going to see if I can capture what the iOS app is doing on login, there must be some detail that’s missing.

Did something change yesterday? I went to close my garage door in HA and it showed disconnected. I restarted HA and checked the MyQ app (on IOS) and that still works. I signed out of MyQ in HA and now when i try and sign back in it says “Failed to Connect”

Was working perfect after the core update till this morning

How did you manage to install HomeAssistant while being unable to read?

My MYQ just went 429 a minute ago

Fixed by updating api.py so that the call to get the OAuth token more closely represents a valid OAuth token call. Changes highlighted in yellow:

• Add an authorization header to specify the client ID (base64 encoded value for IOS_CGI_MYQ:)
• Add an Accept header with */*
• Remove the unnecessary client_id, client_secret, and scope form fields since they’re not supposed to be sent on the get token call in the first place
• Added [0] to the line extracting the code form field to get the code as a string rather than as an array

As text:

            resp, data = await self.request(
                returns="json",
                method="post",
                url=OAUTH_TOKEN_URI,
                websession=session,
                headers={
                    "Authorization": "Basic SU9TX0NHSV9NWVE6",
                    "Content-Type": "application/x-www-form-urlencoded",
                    "Accept": "*/*",
                },
                data={
                    # "client_id": OAUTH_CLIENT_ID,
                    # "client_secret": OAUTH_CLIENT_SECRET,
                    "code": parse_qs(urlsplit(redirect_url).query).get("code", "")[0],
                    "code_verifier": self._code_verifier,
                    "grant_type": "authorization_code",
                    "redirect_uri": OAUTH_REDIRECT_URI
                    # "scope": parse_qs(urlsplit(redirect_url).query).get(
                    #     "code", "MyQ_Residential offline_access"
                    # ),
                },
                login_request=True,
            )

This might be a little easier.

docker exec -it homeassistant /bin/bash
pip install https://github.com/Python-MyQ/Python-MyQ/releases/download/v3.1.13/python_myq-3.1.13-py3-none-any.whl

Restart HA

Okay I got it working. The key I think is adding the following params to the login call:

Brand: myq
UnifiedFlowRequested: True
ReturnUrl: <dynamic return URL from oauth call>

Also changing the login POST call from /Account/Login to /Account/LoginWithEmail` is probably key. I’ll post a link to my updated Go package for reference when I’m finished with it. Shouldn’t be too far out, assuming it doesn’t break again.

Did something change yesterday? I went to close my garage door in HA and it showed disconnected. I restarted HA and checked the MyQ app (on IOS) and that still works. I signed out of MyQ in HA and now when i try and sign back in it says “Failed to Connect”

Was working perfect after the core update till this morning

Ok, verified – the login code as it existed in Homebridge’s api_myq (and in my C# gist from earlier) works with three changes:

• Forcing those additional fields (Brand and UnifiedFlowRequested), into the login POST even though they’re not in the HTML
• The ReturnUrl argument is in the HTML as a hidden field, but the code was previously written to exclude that from the login POST, so it was just a matter of no longer excluding it
• Changing the client_id from IOS_CGI_MYQ to ANDROID_CGI_MYQ; and the callback url from com.myqops://ios to com.myqops://android.

Updated gist of C# code is here. Since it’s so close to the existing code this should be straightforward to integrate into python_myq too.

Reverse engineering Android apps isn’t in my wheelhouse but no better time than the present to learn something new. I’m taking a stab at it, but don’t let that discourage anyone who actually already knows how to do this to do it instead.

It is simultaneously a super annoying thing and a super fun thing. Feel free to message me on discord (Same username as here in HA discord) if you have any questions or if I can help you in anyway. Like I said I don’t have a ton of time right now to really dive into things, but I have enough time to answer questions

(Thrusting hips violently) “Corporate Greed!!”

I wouldn’t draw any conclusions from testing like that. They have Cloudflare’s bot protection on pretty sharply, so as soon as you start getting 429 errors, all bets are off until the heat on you cools down. The 429s aren’t really traditional rate limiting; it’s Cloudflare detecting a potentially automated access and throwing up a challenge page with a 429 status code.

There isn’t really a good workaround for that for Home Assistant, because even if you do an initial authentication request from a browser and grab some cookies to plug into HA (like some other integrations do), those cookies are only good for a relatively short period of time before Cloudflare will start challenging again; so unless you want to be authenticating manually every few hours it’s not worth doing.

Honestly, at this point, just tell everyone you know not to buy any MyQ devices, give them one star reviews on every online storefront you can find; and then wire up a Shelly or a ratdgo or some other roll-your-own solution and give up on using MyQ automation entirely. Short of a significant policy change with MyQ management, that’s going to be the only reliable solution.

@mstberto same for me… I disabled the integration when the “problem” reappeared on October 17. I just saw your post, re-enabled the MyQ integration. I’m back in business. until the next time 😉

edit 1: (one day later) it’s back!!! 429 errors. I’ve disable the MyQ integration and ordered 2 of these: https://www.athom.tech/blank-1/garage-door-opener-for-esphome … nice packaging, pre-flashed, No blinking warning light when closing.

I’ll follow along to see how this saga turns out, but my garage doors will work reliably from HA in the meantime.

Mine was not working yesterday but appears to be working again today.

Now that the patch has been merged, you should be able to just run this command from your HA install/container.

pip install Python-MyQ==v3.1.13

This might be a little easier.

docker exec -it homeassistant /bin/bash
cd /config
wget https://github.com/justinlindh/Python-MyQ/archive/refs/heads/fix-403-forbidden.zip
unzip -o -j fix-403-forbidden.zip -d /usr/local/lib/python3.11/site-packages/pymyq

Restart HA

@sanctas Edit your orig post (very nice instructions by the way) but replace step 4 with these commands. followed by exit and docker restart homeassistant and that should be less steps and less room for error. Vim can give people fits who aren’t used to it.

What about those of us not running HA in Docker?

I’m running HA OS, not the docker. Follow instructions above to install Terminal.

1. cd /root/config
2. wget https://github.com/justinlindh/Python-MyQ/archive/refs/heads/fix-403-forbidden.zip
3. unzip -o -j fix-403-forbidden.zip -d pymyq
4. Restart HA

I just did the above and I’m back online with MyQ as before.

Here are the steps I used to successfully sign in and use my garage door in the MyQ integration. Someone will probably make an easier guide with better commands but I’m not super well-verse with the CLI. I tried to make this as literal and noob-friendly as possible since I know there’s a lot of normies reading this thread wanting help.

Update: Simpler Method

1. Install the Advanced SSH & Web Terminal Add-On in the Official Add-On Store
2. On the Info Page of the Advanced SSH & Web Terminal, switch the “Protection Mode” switch to the OFF position. (You can turn this back on when you’re done.)
3. Start the add-on and click Open Web UI (it may take a moment for the UI to actually load)
4. Once the terminal appears type the following commands:
   • docker exec -it homeassistant /bin/bash
   • pip install https://github.com/Python-MyQ/Python-MyQ/releases/download/v3.1.13/python_myq-3.1.13-py3-none-any.whl
5. Restart home assistant.

My original comment

1. Install the Advanced SSH & Web Terminal Add-On in the Official Add-On Store.
2. On the Info Page of the Advanced SSH & Web Terminal, switch the “Protection Mode” switch to the OFF position. (You can turn this back on when you’re done)
3. Start the add-on and click Open Web UI (it may take a moment for the UI to actually load)
4. Once the terminal appears type the following commands:
   • docker exec -it homeassistant bash
   • cd /usr/local/lib/python3.11/site-packages/pymyq/
   • vi api.py
5. Press i on your keyboard to enter “insert mode”.
6. Using arrow keys, scroll down to line 401. (it should be blank) (this will take awhile to scroll that far down)
7. Add the following two lines of code on lines 401 and 402 respectively:
   • 401: data.update({"brand": "myq"})
   • 402: data.update({"UnifiedFlowRequested": "True"})
8. Press the Esc key on your keyboard.
9. Type :w (literally hit shift + colon and then hit w) and then press Enter on your keyboard. This will write the changes you made to storage.
10. Type :x and then press Enter on your keyboard to exit the VI editor.
11. Back in the command line, type vi const.py.
12. Press i on your keyboard to enter “insert mode”.
13. Using arrow keys, scroll down to line 3.
14. Edit line 3 from OAUTH_CLIENT_ID = "IOS_CGI_MYQ" to OAUTH_CLIENT_ID = "ANDROID_CGI_MYQ"
15. Using arrow keys, scroll down to line 7.
16. Edit line 7 from OAUTH_REDIRECT_URI = "com.myqops://ios" to OAUTH_REDIRECT_URI = "com.myqops://android"
17. Press the Esc key on your keyboard.
18. Type :w and then press Enter on your keyboard.
19. Type :x and then press Enter on your keyboard to exit the VI editor.
20. Restart home assistant.

You will now be able to sign into MyQ using the MyQ integration.

Long Live 3rd Party Integrations

Reverse engineering Android apps isn’t in my wheelhouse but no better time than the present to learn something new. I’m taking a stab at it, but don’t let that discourage anyone who actually already knows how to do this to do it instead.

I mean, it’s an issue for me. I have a Special Needs son who gets home from school at a certain time, and if my wife isn’t home, I need access to the garage door to let him in. Previously, HA has been more reliable than the MyQ phone app - but no longer. Now I’m stuck with whether or not I can get the app to work properly - sketchy at best. This is becoming a safety issue for my family (not merely convenience). I fear that the entire industry is going to go this way, which will destroy our HA community.

I’m sorry to hear that. If it’s that critical for you then I would suggest reviewing the thread and going with one of the mentioned local only options. It’s probably better for you to prepare well ahead of time instead of MyQ completely pulling the plug and you scrambling because the integration is permanently broken. No idea if that’ll ever happen, but I’d personally prepare for that potential.

They would sell more of these boxes if they also opened up a local API to talk to the devices on your local network from your HA server rather than force the cloud service API dependency. I can’t image it would be any more or less security. If your cloud account can be hacked your garage can be opened from anywhere in the world. If you protect your home network, someone would have to break into your home network to talk to the device locally to open your door.

Yeah, but now they can double-dip by charging you for the garage door opener AND access via the app - it’s what they’re doing with Tesla, and what they’re doing with IFTTT. Their argument will be “You can ALWAYS just open the MyQ app and open/close for free, and you can ALWAYS fall back to the clicker/remote you put in your car.” If you want access to the API for any other reason, you have to pay.

The fact is that the HA integration (along with NodeRed, Homebridge, etc) are all reverse-engineered capabilities to get something for free. It’s only a matter of time before Chamberlain puts the API behind a tokenized URL and you have to subscribe to use it. I am personally not skilled enough in programming/coding to resolve this issue, so i’m putting my efforts into an alternate solution (ratgdo). I only use MyQ in HA to monitor status from work, and an automation to automatically close when no motion is detected in the garage after a period of time.

Has anyone reached out to MyQ directly? HomeAssistant is a big enough community/product that they’d probably be willing to work with us, so that A) we are happy, and B) we don’t break their API.

They’d be happy to charge us, like they do every other integration.

Can confirm the homebridge myq-api implementation works. There’s some stuff that needs to change in python-myq around authentication to mirror it – namely:

• The cookie handling across the process isn’t standard (there used to be cookie handling in the python-myq code until earlier this month that looked like it was trying to do what myq-api does, but it wasn’t doing it correctly), homebridge myq-api manually collects and uses cookies in a certain way and that seems to be important for the login process working – only some requests get some cookies from certain previous requests, and other requests don’t get cookies at all; and that matters.
• myq-api also does the final get token call differently (it’s not OAuth-compliant, but it seems the willful deviation from the spec is necessary; the extra data seems to be needed now when it wasn’t a few hours ago).
• And the most important difference is that myq-api will automatically retry requests on the myq API’s east and west domains to try to work around failures and there’s no infrastructure for that in python-myq currently. (Right now partner-identity-east.myq-cloud.com gives me tokens, but partner-identity.myq-cloud.com does not; but myq-api’s documentation seems to suggest myq’s API is very unreliable and it’s not unusual for one region to work while the other domains don’t.)

Python-myq also does some automatic user-agent generation that the homebridge implementation doesn’t do, but as far as I can tell, passing one doesn’t cause a failure.

I poked a bit at my local homeassistant to see if there was a quick fix that would get things working without being too impactful on the code and couldn’t get success, and I’m neither fluent enough in Python to do it well, nor set up for easy homeassistant dev/debugging work to tackle a bigger effort, so I’ll leave this in the hands of someone better positioned to work on it with hopefully the info above is a good starting point.

Also note that because they seem to require weird cookie behavior and non-standard arguments to the get token endpoint, tools that do standard OAuth stuff, like Postman, no longer work to log into the API (they did earlier today before the last round of API breakage). It must be done non-standard.

(And if it’s helpful, during my investigation I implemented a straightforward working login flow in C#, gist here.)

It doesn’t seem to be specific to HomeAssistant version. I rolled back to 2023.9.3 and the issue persists.

@home-assistant rename MyQ fails to setup with 401 or 429 error

The latest batch of 429 errors are from the https://partner-identity.myq-cloud.com/connect/authorize endpoint and appear to be Cloudflare anti-bot challenges, which require cookies and javascript to get past. It might be necessary to kick out to a browser to get past these.

My MYQ just went 429 a minute ago

Same. Things looked OK but went to 429 when I ‘reloaded’ the integration

My homebridge has the same issue

You’d want to add the params (data updates) here and replace the url line here

edit: Use @justinlindh 's PR below, apparently that’s a more up to date repo than pymyq.

can someone post where the lines in the api.py go so the rest of us can test this out please?

Can confirm that I’ve got this working after adding the changes that @brchri and @drysart mentioned above.

My changes are as follows (I can submit a PR later, if nobody else beats me to it): const.py:

OAUTH_CLIENT_ID = "ANDROID_CGI_MYQ"
OAUTH_REDIRECT_URI = "com.myqops://android"

api.py

data.update({"brand": "myq"})
data.update({"UnifiedFlowRequested": "True"})
...
url=f"{OAUTH_BASE_URI}/Account/LoginWithEmail",

I can work on a proper PR later tonight, if nobody beats me to it (feel free to).

I was finally able to intercept the token call. So a couple of things to note about the current successful auth flow via (Android) app:

1. The initial call to /connect/authorize returns a 302 to Location: /Account/Login, which when followed returns a 200. I believe the subsequent form submission used to call to this /Account/Login path, but now it’s posting to /Account/LoginWithEmail
2. Here is the body to the /connect/token POST call:

code=AC0958D...<redacted>
grant_type=authorization_code
scope=MyQ_Residential offline_access
redirect_uri=com.myqops://android
client_id=ANDROID_CGI_MYQ
code_verifier=OMNfhq...<redacted>

Note that the client_secret is not present in this body. Also, the following request header was added:

MyQApplicationID: D9D7B...<redacted>

idk if that’s significant or sensitive.

So far I’m still getting a 401 on the /connect/token call despite setting the same parameters, so I’m still troubleshooting, but thought this info might help someone else that’s also looking into it.

Note: I am not debugging against the pymyq package, so some of my assumptions about how that package behaves may be a bit off.

Blackstone bought Chaimberland a couple years ago. Anything they buy turns into a paywalled pile of useless dog crap.

I second the PR.( I can wait like the 403 change)  I am a novice on Modifying .py files. Any help is appreciated. Sent from Mail for Windows From: Luke LashleySent: Tuesday, October 10, 2023 3:48 PMTo: home-assistant/coreCc: atruest; AuthorSubject: Re: [home-assistant/core] MyQ fails to setup with 401 or 429 error (Issue #101763) Hey @drysart Thanks for your insight. That's rather interesting - it is my understanding that basically everything the maintainers before me have in this library is just a port from the homebridge myq api. They use scope, client_id, secret, etc.I have a dummy account with no devices that I have used for testing for logging in before - I can give this a try in a bit and see if I get similar results. Where do you get your "Basic SU9TX0NHSV9NWVE6" from?Feel free to make a PR on the python-myq repo I'd be more than happy to directly merge in your changes if it works for me as well—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***> 

It’s just base64 encoded IOS_CGI_MYQ: so I assume it’s what the IOS app uses.

Most likely. I grabbed it from a Postman login request to MyQ.

Can confirm after changes and after the timeout expired I was able to authenticate correctly. The interesting thing now is to see if we get 429’s since it is calling more frequently than once per minute.

I don’t think it will. The 429s were arising in the first place because the login logic basically spams the service with retries when the login fails (it retries 5 times, then homeassistant restarts the integration which causes it to do it again right away). Without that issue, the API usage should be well below the rate limits.

And as an aside, it seems that MyQ is slowly tightening their API validations; the code needs a thorough once-over to make sure it’s actually compliant with OAuth properly and it isn’t doing any other extraneous/incorrect stuff; because given the history of this integration over the past month or so, any further deviations from the spec lurking in the code are likely to result in additional breakage in the future.

And also to add, if you apply this fix you may continue to receive 429 errors until your rate limiting on the MyQ API (caused by the broken code previously running and having sent too many requests to the API and getting your IP temporarily blocked for a while). Those issues should clear up within an hour or two.

I am having the same issue as well. I recently hooked an ESP32 up to my garage door opener and added 2 reed switches to the garage door so I can control it locally. Very glad I did it.

FYI go ahead and disable your MyQ addons until this is resolved.

@NukeThemTillTheyGlow and @matthewrosner, I recommend you start a new GitHub issue for not being able to get the integration running after installation.

For some reason, I can’t update to 2023.10.2. When I go to System -> Updates -> check for updates, it doesn’t find any. I ran ha core update --version 2023.10.2 --backup from Advanced SSH and rebooted HA. The process was completed successfully, but the version is still Home Assistant 2023.10.1 Supervisor 2023.10.0 Operating System 10.5 Frontend 20231005.0 - latest

What am I doing wrong?!

I believe this will be part of 10.2… Not released yet… Hopefully later today.

@home-assistant close

I’m guessing this is maybe part of the issue - the repo needs a new maintainer …

https://github.com/Python-MyQ/Python-MyQ/issues/15

Bonjour; I have as well the same issue: I’ve tried to install (pip install Python-MyQ==v3.1.13) Restrated HA ent tried to reconfigure MyQ integration, no sucess, 401 error

Logger: pymyq.api Source: components/myq/config_flow.py:37 First occurred: 09:45:29 (2 occurrences) Last logged: 09:51:52

Authentication failed: Error requesting data from https://partner-identity.myq-cloud.com/connect/token: 401 - Unauthorized

As a dumy test, I’ve tried to connect to https://partner-identity.myq-cloud.com I get there a menu proposing “to secure page” --> https://partner-identity.myq-cloud.com/Account/LoginWithEmail?returnUrl=%2FHome%2FSecure My user name and password works fine on this page so the account is valid. From Chrome, accesing ttps://partner-identity.myq-cloud.com/connect/token give an error {“error”:“invalid_request”}

Egh. I was getting the 429. But my account was locked out. Tried to reset the pw and myq freaked out and never sent me an email, but locked me out of the password reset as well without sending the email. pure comedy.

so 429 means just wait for cooldown?

Yes and anyone reading this thinking I’ll fix it later or I’ll wait for the official fix should at least DISABLE the integration in the meantime. I disabled it when I realized it was broken and saw this thread and knew it would not be a quick fix. And whenever I failed to fix it I immediately disable again. So I never had to deal with the 429’s. If you leave it enabled and broken it will retry to aggressively and get you throttled every time.

thank you for that info, will disable in the meantime

This might be a little easier.

docker exec -it homeassistant /bin/bash
cd /config
wget https://github.com/justinlindh/Python-MyQ/archive/refs/heads/fix-403-forbidden.zip
unzip -o -j fix-403-forbidden.zip -d /usr/local/lib/python3.11/site-packages/pymyq

Restart HA

@sanctas Edit your orig post (very nice instructions by the way) but replace step 4 with these commands. followed by exit and docker restart homeassistant and that should be less steps and less room for error. Vim can give people fits who aren’t used to it.

What about those of us not running HA in Docker?

I’m running HA OS, not the docker. Follow instructions above to install Terminal.

1. cd /root/config
2. wget https://github.com/justinlindh/Python-MyQ/archive/refs/heads/fix-403-forbidden.zip
3. unzip -o -j fix-403-forbidden.zip -d pymyq
4. Restart HA

I just did the above and I’m back online with MyQ as before.

I tried this as I’m running HA OS but it did not work for me. This is driving me nuts as i use home assistant in our building and all of our employees use the companion app for control of our warehouse garage door, time clock, alarm etc…

“it did not work for me” is probably not going to get you much of a response. maybe throw in the error message or more details or a screenshot even?

Where could i find the error log that you mention? I still get a 429 error that I’ve been getting.

429 means “Too many requests” and it looks like they implement a 15-minute cooldown period. So try in 15.

I still get a 429 error that I’ve been getting.

You may just need to wait for the cooldown period to expire. The 429 error should tell you how long you have to wait. It may start working after that.

This might be a little easier.

docker exec -it homeassistant /bin/bash
cd /config
wget https://github.com/justinlindh/Python-MyQ/archive/refs/heads/fix-403-forbidden.zip
unzip -o -j fix-403-forbidden.zip -d /usr/local/lib/python3.11/site-packages/pymyq

Restart HA

Thank you guys for all your hard work!!! You really make this a great community to be a part of.

A proper, non-rushed fix would be to carefully ensure we’re closely mirroring all of the headers/params with the Android app data that you dumped. I have no doubts that Chamberlain will continue to make changes which inevitably break this again, and maybe that would help a bit.

I did see some stuff in the app’s decompilation when I was digging through it that looked like functionality for them to forcibly deprecate old versions of the app, which makes me fearful they’re going to pursue a policy of aggressively requiring app updates that include protocol changes. Time will tell if and how often they’re going to fire that gun.

Sorry for the crappy details in comment above. The working fix is posted here: https://github.com/Python-MyQ/Python-MyQ/pull/22

I’m unsure whether the Android specific changes are needed. I’m going to evaluate that now, before asking for merge.

Right, it’s a POST with the body as the populated form fields, via hidden input params. Here’s my full list of changes. I just hit my 429 throttling so I can’t test further atm. 😒

Correct, and for further clarity, they are not headers, they are body params.

where can I find this api.py file?

Don’t bother, it doesn’t work anymore. Furthermore, the Homebridge and Node-Red integrations are also now failing.

FWIW I collected ios calls to myq using the charles proxy app. I’m not sure if it helps much. I redacted the cookie and response code but I’ll include them in a DM to a maintainer if need-be

Login Call:

HTTP/1.1 302 Found Date: Wed, 11 Oct 2023 17:11:52 GMT Content-Length: 0 Connection: keep-alive Cache-Control: no-cache pragma: no-cache expires: Thu, 01 Jan 1970 00:00:00 GMT location: /connect/authorize/callback?redirect_uri=com.myqops%3A%2F%2Fios&code_challenge=[REDACTED]&scope=MyQ_Residential%20offline_access&client_id=IOS_CGI_MYQ&acr_values=unified_flow%3Av1%20brand%3Amyq%20app_version%3A5.242.0.38913&code_challenge_method=S256&prompt=login&response_type=code&ui_locales=en-US&suppressed_prompt=login set-cookie: idsrv=[REDACTED COOKIE TOKEN]; path=/; secure; samesite=none; httponly request-context: appId=cid-v1:0e843709-4fd8-4c8a-a52a-7eb45ba4930b x-xss-protection: 1; mode=block myq-correlationid: fb95fc49-9db0-44d3-a18e-966494621d24 strict-transport-security: max-age=15724800; includeSubDomains strict-transport-security: max-age=63072000 CF-Cache-Status: DYNAMIC Server: cloudflare CF-RAY: 8148b98af9b253bb-ATL alt-svc: h3=“:443”; ma=86400

Callback Call:

HTTP/1.1 302 Found Date: Wed, 11 Oct 2023 17:11:53 GMT Content-Length: 0 Connection: keep-alive location: com.myqops://ios?code=[REDACTED RESPONSE CODE]&scope=MyQ_Residential%20offline_access&iss=https%3A%2F%2Fpartner-identity.myq-cloud.com Cache-Control: no-store, no-cache, max-age=0 pragma: no-cache request-context: appId=cid-v1:0e843709-4fd8-4c8a-a52a-7eb45ba4930b x-xss-protection: 1; mode=block myq-correlationid: b695cbe2-70f3-4f0f-ac1e-ebd041ee09ff strict-transport-security: max-age=15724800; includeSubDomains strict-transport-security: max-age=63072000 CF-Cache-Status: DYNAMIC Server: cloudflare CF-RAY: 8148b990daaa53bb-ATL alt-svc: h3=“:443”; ma=86400

edit2: Of course as soon as I say that, my regionalized updates stopped working as well. They may have just gotten around to updating that region. Back to square 1. @drysart I’d be curious if your C# login flow is still working.

Nope, the C# code no longer works for login.

@Lash-L I’m not sure region domain cycling is going to fix the problem anymore, it looks like they may have updated the east and west regions to the newer code that doesn’t let us in. The homebridge myq-api no longer works either.

I have a feeling this is going to boil down to someone doing some new captures from the iOS or Android apps to see what’s required. I spent a little bit of time on it yesterday but I don’t have the tools to do it right so I was limited to just looking at decompiled obfuscated code from the Android app and trying to make sense of it, and that only goes so far. It does look like they’re sending additional HTTP headers to the get token endpoint (MyQApplicationId, BrandId, App-Version, and they do send a User-Agent header); but I couldn’t find the values they’re passing. I wouldn’t be surprised if they’re checking those headers now.

There is an example.py in the root of the Python-MyQ project, that can be used to test any changes without HA. I will try to take a look later and see if I can implement the changes described from @drysart

https://github.com/Python-MyQ/Python-MyQ/tree/auth_fixes

This branch may be a good starting point for you - it was what I was able to do on my lunch break, but I’m timed out so I can’t test it further.

I did add domain cycling in the past, but I made it rather limited. I moved it to request so that it is now global for all requests that are made.

I’m timed out right now, so I can’t further test it and I’m almost done w/ my lunch so I need to get back to work

cc @jiffyjaff as well

@brchri

I “regionalized” as follows: const.py … added -east OAUTH_BASE_URI = “https://partner-identity-east.myq-cloud.com”

then I got the follow error messages at initialization time:

Logger: homeassistant.config_entries Source: components/myq/init.py:42 First occurred: 11:16:56 AM (1 occurrences) Last logged: 11:16:56 AM

Error setting up entry for myq Traceback (most recent call last): File “/usr/src/homeassistant/homeassistant/config_entries.py”, line 388, in async_setup result = await component.async_setup_entry(hass, self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/src/homeassistant/homeassistant/components/myq/init.py”, line 42, in async_setup_entry myq = await pymyq.login(conf[CONF_USERNAME], conf[CONF_PASSWORD], websession) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/local/lib/python3.11/site-packages/pymyq/api.py”, line 594, in login await api.authenticate(wait=True) File “/usr/local/lib/python3.11/site-packages/pymyq/api.py”, line 480, in authenticate await self._authentication_task File “/usr/local/lib/python3.11/site-packages/pymyq/api.py”, line 493, in _authenticate token, expires = await self._oauth_authenticate() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/local/lib/python3.11/site-packages/pymyq/api.py”, line 421, in _oauth_authenticate “code”: parse_qs(urlsplit(redirect_url).query).get(“code”, “”)[0], ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^ IndexError: string index out of range

Restored const.py to OAUTH_BASE_URI = “https://partner-identity.myq-cloud.com”

(now I’m back to the 403 errors. (the only change I made was adding -east as shown above. honest.)

edit 1: now I see that regionalization stopped working for you…

They would sell more of these boxes if they also opened up a local API to talk to the devices on your local network from your HA server rather than force the cloud service API dependency. I can’t image it would be any more or less security. If your cloud account can be hacked your garage can be opened from anywhere in the world. If you protect your home network, someone would have to break into your home network to talk to the device locally to open your door.

Hear Hear!!

They would sell more of these boxes if they also opened up a local API to talk to the devices on your local network from your HA server rather than force the cloud service API dependency. I can’t image it would be any more or less security. If your cloud account can be hacked your garage can be opened from anywhere in the world. If you protect your home network, someone would have to break into your home network to talk to the device locally to open your door.

Yeah the endpoint was just updated again, my previously working Postman OAuth login isn’t working anymore either and failing with a 403. If you’re getting 429 it’s because of the previously mentioned issue that when login fails, homeassistant repeatedly hits the endpoint until it gets rate-limited.

Can confirm this resolved my issue as well.

• After updating to 2023.10, my MyQ issues went away, but came back today (cover.garage_door was unavailable, logs reported 401 error).
• I found this ticket, and found that there was a code update (thanks @drysart!)
• Logs said the issue was at /usr/local/lib/python3.11/site-packages/pymyq/api.py (your installation may vary)
• I docker exec’d into my HA container, backed up the file, opened the file in vi, found the code string referenced above within the file
• I deleted all of the code referenced in the above snippet, then copy/pasted the plaintext version into the file, then saved it
• Restarted HA
• Once HA came back up, the MyQ integration began working instantly, both with status and commands.

You guys are the best. Keep up the great work!

@Lash-L See https://github.com/Python-MyQ/Python-MyQ/pull/18

Where do you get your “Basic SU9TX0NHSV9NWVE6” from?

It’s just base64 encoded IOS_CGI_MYQ: so I assume it’s what the IOS app uses.

I applied drysart’s change and am still throttled, but maybe it just needs to clear.

I am on 2023.9.2 but the latest MyQ code and it is failing

I actually used an ESP32 soldered to my wireless garage door opener.

Do you have a link handy explaining how this gets wired up/flashed? I’d like to do the same.

Edit: Found this. It should work for me.

I lost connect in the last 30 minutes due to 429 Too Many Request but phone app still works:

Config entry ‘xxx@xxx.com’ for myq integration not ready yet: Got 429 error - stopping request until 2023-10-10 16:30:38.802025. there were 1 request; Retrying in background