None of the auth methods work

[homersdonut]

None of the auth methods work for me, I get a 400 error in HomeBridge when I try the cookie method. When I use the access token, it only lasts for about 30 mins, and then stops working. I've noticed both of these mentioned in other "Issues", however, Google discontinued "Works with Nest" on Sept 29th, and up until around this date, the access token worked flawlessly for me, did something change disallowing access?

[cvalord]

It work try chrome on incongnito mode a just makes a one week ago !!

[fadicode]

Same here, I am now reauthenticating everyday using cookies. It only works for 30 minutes or so. I tried with Edge and Chrome with cleared cache and incongnito, nothing works!

[jaysi1001]

Same here. I have to reauthenticate cookies many times a day. I've disabled the plugin for now since it's not useable.

Hopefully there's a fix for this!

[guillochon]

Same here. Pinging @adriancable, any idea how long it'll take for a fix?

[adriancable]

Hi @guillochon - it does appear that Google has shortened the cookie expiry time for some users/accounts. Unfortunately this isn't something I have any control over - I appreciate this is frustrating.

[cvalord]

Did you have a Google Account or Nest I did with google account and it’s working , the only side that doesn’t work is HomePods but on iPhone iPad and Apple TV thermostat work

[guillochon]

So, I was using the refresh token before, which despite the docs here (which say Oct 2022) was working for me up until a few days ago. I then tried the Nest approach and that didn't work. I'm doing the cookie approach now and it's working, for now...but based on other replies here it sounds like it might spontaneously stop working after a short time.

I wish there was a hybrid approach where SDM is used for most of the communication with Nest devices (since that's the official sanctioned way), but with some unofficial extensions for things that are blatantly missing (e.g. Nest temperature sensors, which aren't supported by the SDM). As it stands right now my choice seems to be a) continue using this plugin, which I may potentially have to reset on a regular basis, or b) use the SDM plugin, which doesn't fully support the Nest ecosystem.

[adriancable]

@guillochon - refresh tokens should continue to work until you change your Google Account password or similar, so maybe this is what's happened. The bit that doesn't work is generating a new refresh token.

I don't know Google allows the 'native' Nest APIs that the plugin uses to be called using a refresh token obtained for an SDM 'app', but if you are able to get an SDM refresh token it might be worth trying that with this plug-in.

[starlessblack]

When I try the refresh token method, I'm getting an "Access blocked: Nest's request is invalid" message in the browser from Google. Is this a known issue?

Also, with the previous cookie method, I am also periodically seeing the Nest plugin unable to auth during Homebridge bootup. This is what led me try the refresh token method.

[adriancable]

Yes, #575 is pinned so it stays at the top of the issues list so you can’t miss it. Also the README says that the refresh token no longer works.

[pipeeeeees]

Cookie expiration seemed to impact me today. I did get about 2 weeks of use after setting up with the cookie method for the first time. Wondering if that's par for the course or if I will start having to redo cookies a few times a day now too.

[alexkokkinos]

This is not related to cookie expiration, but if you have trouble logging into home.nest.com using Incognito mode and your Google login, change your Chrome settings to allow third-party cookies in incognito or make exceptions for Nest/Google domains for third-party cookies. The Nest/Google login flow won't work without third-party cookies enabled.

If your browser blocks third party cookies, you'll end up logged in to your Google account but with Nest's website not proceeding with the login, and the issueToken never showing up in your network activity.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dignoe]

Has anyone gotten this plugin to work reliably since early October? We have the First Alert HomeKit-enabled smoke detectors, which have been discontinued (probably because they are terrible) and are failing one by one. I recently bought six Nest Protects to replace them, but I want to install them only if we can integrate them with HomeKit/Matter.

[mbierman]

Yes, I have it working. But I do worry that the developers seem to not be maintaining this anymore.

[adriancable]

@mbierman - the issue is that, with the exception of Google cookies, which for some people (but not all) have a short lifetime, there are no longer any auth methods available that can be initiated from a NodeJS or browser environment. If you know a workaround (like any alternative auth methods) then feel free to share.

[jnubz]

This is why I've never converted from my old Nest account to Google. I haven't touched my settings in HomeBridge for more than a year, and it's still solid.

I'll be buying an ecobee or a different HomeKit option once it stops working. I only ever had Nest equipment because it came with my last and current houses.

The nest keeps rescheduling my temperatures even tho I've turned everything off. Tired of the terrible UX the Google has turned Nest in to.

[mbierman]

@adriancable, first, thank you for all the hours you must have put into creating and maintaining this plugin. Any idea what makes the lifespan of the cookies different for different people?

Maybe I'm missing something, but I don't see any details about this in the docs. It would be great if this was mentioned so people could have better exceptions.

More than that though... Since everything in the instructions can be done in the browser, I wonder why this couldn't be done with curl and some parsing for example. For an old neurio unit I had done somehing similar and added the info into the config file and restarted it nightly. I know, a bit of a hack, but I didn't want to try to learn and edit the plugin code.

[adriancable]

@mbierman - let me explain a little bit about how Google logins work.

Google provides two different methods to log into services like Nest. One is used by web apps (that run in a browser), and produces cookies. The other is used by native apps (iOS and Android), and produces a refresh token.

When you log in via a browser, it isn't just a browser sending HTTP requests (which can be replicated via curl). There is also a human in front of the device operating the browser. Google (along with every other login provider) goes to great lengths to make sure there's really a human there. Otherwise for example, someone could write a tiny program to create a million Google accounts, log into each of those automatically, and send out a ton of spam. So the log-in page runs a sophisticated piece of code (called Botguard in the Google case) which measures how you type, how you move the mouse, other things about the browser environment etc. to make sure you are really a person entering the credentials, and not an automated system. Google has invested a lot of resource in making this system work very well, and it means that it's practically impossible to add an automated login system to something like homebridge-nest which could "programmatically" log in, gather cookies as needed and so forth, in the way you are thinking/hoping. So we are left with manual 'cookie scraping' as per the instructions in this plug-in's README. But cookies eventually expire, and you have to do the whole thing again. How Google determines cookie expiry is not documented and is likely very complicated, and incorporates a bunch of heuristics which are intended to make sense as to whether it is 'safe' to allow logins to persist for a long time or not. For example, a lot of log-ins to different Google accounts from the same IP in a short space of time will lead to cookies that expire quickly. This makes sense because this circumstance may arise from (for example) when multiple people are logging in sequentially from a public device. You don't want long-lasting cookies here or people could 'reactivate' logins from earlier users of the device. But there are other circumstances that look very similar to Google. For example if your ISP uses CGNAT, then a large number of customers may share the same IP address, which will also lead to short-lifetime cookies. Note this has nothing to do with homebridge-nest, people using the official Nest web app at https://home.nest.com will see exactly the same effect, with some people being able to stay logged in for months at a time, but others need to log back in every few hours. So that's how cookies log-in works and why it doesn't work well for some people.

Now onto the other method. When you log in via a native app on iOS or Android, Google uses a different system which makes use of capabilities which are not available or allowed in standalone web browsers (for example, redirects to custom URL schemes), which instead of producing cookies produces a refresh token, which lasts effectively forever. In the past, there was a mode this system could be run in (intended for debugging during development) which could work in a standalone browser, and would produce a refresh token (this was called the 'OOB redirect flow'), and this is what homebridge-nest historically used. But Google discontinued it over a year ago because it had various security issues, so we can no longer do things this way.

There may be other log-in approaches that the plug-in could use. I don't know of any, but if anyone comes up with something which appears to work better than the current method, of course I will incorporate it.

[starlessblack]

Does anyone know how the nest starling device works with googles login API? https://www.starlinghome.io

[adriancable]

Starling Home Hub's iOS app uses the app-based auth method (same as any iOS apps that log into Google services), which produces refresh tokens that generally last indefinitely. Unfortunately this cannot be done in a NodeJS or browser environment (see my post above).

[mbierman]

@adriancable Thank you. I guess another reason never to buy hardware associated with Google again.

[adriancable]

@mbierman - not really. What Google do for authentication is pretty standard and you really wouldn’t want them not to do it, as it opens the whole account system to abuse. The Botguard system to make programmatic logins difficult is, for example, what makes it very difficult to brute force Google account logins. So yes, it creates challenges for homebridge-nest which I don’t like, but rising above my and this plugin’s self-interest for a moment it’s a good thing.

So yes, Google is the absolute worst, except for all the other vendors …

[mbierman]

@adriancable We will have to agree to disagree on this one. Google could:

1. Offer APIs.
2. Offer app-specific passwords. These would be more than adequately secure for the purpose.

This isn't the first issue I have had with Google hardware. Google tends to have a short attention span. When they aren't excited by a market anymore, support drops for a product.

[adriancable]

@mbierman - I disagree about the short attention span - Google's support for most of its products is longer than most other vendors. For example Google has supported Dropcams for 10+ years, and guarantees that smart home products will have updates and support available for at least 5 or 7 years after launch. I don't know of any other smart home vendors that have any such guarantee.

But to your first point, strongly agreed! If everyone in the world had the same viewpoint, the world would be a very dull place.

[dignoe]

Luckily, I created my Nest account over a decade ago, so I could sign in using the Nest auth code technique. It has been working for a day... we'll see how long that lasts.

For anyone using Nest Protects, it seems that Google is still working on moving them over to the newer API (and the Home app). Since the underlying technology Nest used (Weave) is the same standard as Thread, it might be possible that someday these could become Matter-enabled. But I guess we'll have to wait and see.

[ACWAKKERMANS]

I have been lucky so far and have had things working using the refresh token, however, I’m still on Buster, and will need to update my Rpi soon. Will I run into this authorisation issue if I create a HomeBridge backup, do a fresh install on a Rpi, install HomeBridge and then “restore” HomeBridge with my backup?

[adriancable]

@ACWAKKERMANS - the refresh token should continue to work indefinitely unless you change the security settings on your Google account (e.g. password change, enable/disable 2FA). You can move the refresh token to a different machine.

[ACWAKKERMANS]

@ACWAKKERMANS - the refresh token should continue to work indefinitely unless you change the security settings on your Google account (e.g. password change, enable/disable 2FA). You can move the refresh token to a different machine.

Thank you kindly for the quick answer!

[Edit] And I confirm that it did indeed work after restoring HomeBridge on a fresh install.

[homersdonut]

Just to chime in here - I’ve decided I'm going to get a Starling Hub to solve this problem (I’m using it for Nest Protects). It just seems like this will be a more long term, stable solution, I’m getting kind of tired of Homebridge solutions getting kicked to the curb by an API update.

[etrikp]

Dug around a bit on this and turned up some potential paths forward. Regarding the legacy OOB flow deprecation, it looks like all sessions that are using the OOB flow will be block Jan 31st 2024. https://developers.google.com/identity/protocols/oauth2/resources/oob-migration#key-compliance-dates This means that anything OOB flow that is working now will likely not work next month. The OOB flow is inherently insecure, so this does make sense.

It seems they want to push everyone to using the google SDM API. https://developers.google.com/nest/device-access/reference/rest/ with the official SDK for the API https://github.com/googleapis/google-api-nodejs-client . The catch is they want a one time $5 fee for any account to use the API. In the case of Starling Home, they likely pay $5 one time to provide access to their end users. That being said, it does look like individuals can pay the $5 and get access to the API on a personal account basis, https://developers.google.com/nest/device-access/get-started. This should mean that as long as the official SDK is used and the $5 fee is paid, we should be able to access the API and get a functional refreshToken use the Client Side auth method, example app https://developers.google.com/nest/device-access/samples/web-app

If I can make the time I'll pay the $5 and see if it can work for the homebridge plugin.

[jaysi1001]

There already is a Homebridge Nest plugin that use the Google SDM API - https://github.com/potmat/homebridge-google-nest-sdm

I paid the $5 and use that plugin for my cameras, it works, and no auth problems. However, the Google SDM doesn't support Nest Protect (smoke detectors) so I still would need this plugin for that.

So it seems there's no solution for users who want to use Nest Protect in Homebridge.

[homersdonut]

There already is a Homebridge Nest plugin that use the Google SDM API - https://github.com/potmat/homebridge-google-nest-sdm

I paid the $5 and use that plugin for my cameras, it works, and no auth problems. However, the Google SDM doesn't support Nest Protect (smoke detectors) so I still would need this plugin for that.

So it seems there's no solution for users who want to use Nest Protect in Homebridge.

I would highly recommend Starling Hub, I've been using it since I opened this thread and gave up on HB support. It works great - same as this plugin used to and had been pretty flawless (as I would expect for an “officially, unofficial” product.

[JurgenLB]

@jaysi1001 maybe you can ask the maintainer of that repository to include these devices. As you already paid him.

[jaysi1001]

@jaysi1001 maybe you can ask the maintainer of that repository to include these devices. As you already paid him.

I didn't pay the developer, I paid Google to access their Smart Device Management (SDM) API.

It's not the developers of these plugins that don't support the Nest protects, it's Google. They don't provide them in the Google SDM API

[jaysi1001]

There already is a Homebridge Nest plugin that use the Google SDM API - https://github.com/potmat/homebridge-google-nest-sdm I paid the $5 and use that plugin for my cameras, it works, and no auth problems. However, the Google SDM doesn't support Nest Protect (smoke detectors) so I still would need this plugin for that. So it seems there's no solution for users who want to use Nest Protect in Homebridge.

I would highly recommend Starling Hub, I've been using it since I opened this thread and gave up on HB support. It works great - same as this plugin used to and had been pretty flawless (as I would expect for an “officially, unofficial” product.

Yeah, it does look good and I nly hear great things about it. I'm not in the USA and the exchange rate + shipping makes the cost-to-value ratio for me not worth it.

[KarlLivesey]

This is so frustrating my tokens very often don't last an hour never mind a day or month I don't logout I just close the window even when I leave the window open it still just sucks

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.