Works with Nest Retiring (Sept 29, 2023)

Just received this email from Google/Nest, what are my options for OH 3.2 to continue to use Nest within OH?


Thank you for being a valued customer and a part of the Nest family.

Works with Nest was created in 2014 as a way for other smart home device makers to take what Nest knows and personalize your experience with their products, such as turning off the device maker’s smart lights when Nest detects you’re away. The connected home has evolved significantly since then, and we’ve implemented numerous updates to enhance how you interact with and manage devices with Google Home.

In 2019, we made the decision to eventually retire Works with Nest to unify our efforts around third-party connected home devices under a single platform for developers to build features for a more helpful home – with a focus on compatibility, security, and privacy. The goal is to simplify the developer experience and give you more control over how your data is shared.

We’re reaching out to let you know that after extending support for Works with Nest for the last few years, it will wind down and no longer work as of September 29, 2023.

What this means for you.
Through September 28, 2023, all current Works with Nest connections will remain active, and you can continue to use Works with Nest as you do now.
In the coming months, you’ll be able to use a script editor to create advanced home automations that will offer new features and capabilities. We’re also working closely with our partners to provide replacement integrations where possible. Learn about the changes and options available to you.
Starting September 29, 2023, the connections will no longer work and you will lose access to them.
We’re committed to helping you and minimizing disruptions. If you need help, our support agents are standing by.

The Nest team

Best, Jay

Review the add-on docs. It supports both the Works with Nest API and the Smart Device Management API. You’ll just need to migrate your account to Google and follow the instructions for activating the SDM API. SDM support has been in place for a number of years now.

As Google does not mention using SDM as alternative there may already be plans to also drop support for it as well. :frowning_face:

Anyhow I’ve created an issue to remove WWN from the binding when it stops working:

Sad and uacceptable, but expected. Goodbye Nest Protect integration controlling recuperator on smoke detection (boost when oven is on, turn off otherwise). :frowning: I really hope Matter will be successful and can facilitate getting rid of cloud devices.

Wait, do you think that Nest products are connected to the cloud because there was no way to connect otherwise and Matter will solve that? Do you know that my 11 year old Nest thermostat contains a Zigbee radio that is inactivated? Products are very often cloud devices for two reasons (and others):

  1. The manufacturer wants your data, or they want you to pay a subscription, or both.
  2. The general public cannot be trusted to put something onto the external-facing internet (for control when not at home) and secure it in any way / shape / or form.

Matter solves none of the reasons so many devices have no local control. There have been control protocols for decades ranging from X10, Insteon, ZWave and Zigbee just to name a few.

I do. How else would people control their thermostats remotely? Doesn’t matter if it’s 11 years ago or today–Zigbee isn’t going to do that.

I suspect that the Zigbee radio was meant for future use with something like the Nest Temperature Sensor, but Bluetooth LE turned out to be a better solution. I’m just guessing, though.

Companies want to sell products, make money, and make better products that make more money. User data doesn’t generate profit unless you do something with it. In Nest’s case, they’ve tried to improve the user experience with firmware updates, and they’ve tried to make a cheaper thermostat. Seems to me that this is a pretty good use of data.

If anything, we’ve seen more evidence–in the form of confusing and outright bad products, services, and decisions–that companies aren’t doing enough with the data they have. I find it much easier to believe that many of them don’t care about data at all.


Local control has nothing to do with protocols–it’s about having a method to provide control. All of the protocols you listed rely on a central coordinator. You can associate Z-Wave devices directly (and I think Zigbee devices as well?), but you still need a controller to get started, and a server to provide the intelligence.

Matter’s border routers will provide the ability to coordinate local communication between devices, whether they use WiFi or Thread. That’s a big deal. However, the intelligence will still come from the cloud…unless you use something like openHAB.

Matter will also free companies from having to provide proprietary clouds/apps, which simplifies the user experience and puts less burden on them. Suddenly, a small startup doesn’t have to build, secure, and maintain their own cloud services. That’s a significant savings in time/money/headaches, and a very compelling reason to use Matter.

It’ll be interesting to see which direction established players go. Belkin (ugh) has already paused on Matter, while TP-Link just announced their first Matter-ready smart plug.

1 Like

I did not know your Nest thermostat has a Zigbee radio. Even more so, what a shame this was never used to enable local connectivity.

There are many reasons why cloud-only products exist, and you have correctly described two of those reasons. However, what I meant with my comment is that Matter could potentially make such products less attractive, because it could provide an alternative.

I’ll mention a few examples…

Many years ago Miele introduced connected appliances through a dedicated slot in the appliances where you could insert a communication module which could then communicate with a gateway over powerline. This gateway then had a (primitive) local API. They might have sold a few hundreds of those modules and gateway, I don’t know. :slight_smile: Then later they introduced a Zigbee gateway and new Zigbee modules you could retrofit into the communication module slots. To me it seemed that they were moving in the right direction, although the functionality was very limited. The communication module slots seems like a good idea for appliances that could last 20 years. But, of course, not many people wanted to buy a 300 € gateway just to have a primitive API to mostly monitor your appliances.

So they migrated to Wi-Fi, and at the same time abandoned the slots for communication modules (at least to my knowledge). My dishwasher came with built-in Wi-Fi. And at the same time they dropped the local API and introduced Miele Cloud. For me, as a consumer and home automation enthusiast, this certainly went into the wrong direction. Now I have a slow-performing solution completely out of my control and at the mercy of Miele. I can use it as long as it’s not down for maintenance, and as long as it will be able to communicate with my Wi-Fi access point without compromising security or speed.

Next example: Velux Active. I will make this one short: Provides a cloud integration (Velux with Netatmo), closed, to be used with their app. Integrations not supported. And also the gateway supports HomeKit, which then provides a local integration possibility (not yet supported by openHAB though).

Next, Danfoss Link. A proprietary Z-Wave solution with thermostats and a controller. Local communication between thermostats and gateway, but no local API. Cloud solution for getting online (via app). The cloud solution is anonymous, i.e. no account needed. This solution was later dropped in favour of a new Zigbee-based solution, Danfoss Ally.

To be honest, I believe these companies really tried to reach as many “average” users as possible and just “app-enable” their solutions.

The Miele Zigbee solution was of course terrible, since it required users to buy an expensive gateway just to get a washing machine online without many reasons to do so. It could have been made cheap, but I think even then, it wouldn’t appeal to many, as it needs to be connected to the router with cable and turned on all the time. Migrating to Wi-Fi and cloud seems like a logical move, because all users could then instantly connect with their phones. Unfortunately the communication module slots and local API died on the way.

With Velux I think they also just wanted a simple solution that could appeal to as many users as possible. I believe they even also provided a “Google Assistant” logo in the box. In this case I’m not so sure data collection or subscriptions was even a priority.

The same with Danfoss. Like with Velux, simplicity (for the user) and taking care of security in their cloud backends, as you mentioned.

So if we assume that they were not ill-intended, I think these kind of companies would happily strive for Matter compatibility if they could put that on the box label and they believed it would help them sell more products (by making them more attractive than the competitors’ products). This could also save them some money, as they probably would have less integrations to support, and in some cases wouldn’t need to provide a cloud infrastructure. But then again, this is based on the assumption that they actually have good intentions and just never saw a feasible way to actually provide something which would not be cloud-based, have an open API and still attract average users. So far this has been almost impossible to accomplish.

It will be the chicken and egg. Only when Matter is successful and adopted, it will be attractive to provide Matter compatibility. So, I’m not as positive as I was maybe one year ago, but I do still hope that both Matter and Thread will grow and reach some kind of critical mass that could get things rolling. And then we would again be able to buy products which would work until they break, which we could integrate with, and which would be fast.

EDIT: Google is of course a completely different type of company than those I just mentioned. They have a completely different business model, so you are spot on with your data collection and subscription points. It would have been interesting to see where Nest would be today without the Google takeover.

For those making the change from Works with Nest API to Smart Device Management API due to the cut off of 9/29/23 announcement, please be aware of this.

I ONLY had many Nest Protect Smoke/Co2 detectors across 3 locations and these devices do NOT migrate over to Google’s SDM API which means ALL the things, items, rules for Nest Protect stop working immediately within OH after migrating to the SDM API feature.

Best, Jay

1 Like

And who will run this cloud infrastructure? A small startup or a large tech giant such Microsoft, Google or Amazon? Who will benefit from further centralization of such cloud services, if not them? If you look at infrastructure providers small startup usually is locked in with one of these. Europe and other continents (except maybe China which manufactures a lot of stuff) has very little to say in this regard.

I don’t know what you mean. I said that companies won’t need to provide cloud services, in which case they won’t need cloud infrastructure.

I’ve been waiting for SDM to expose Home/Away as well as the protect status. But Looking at how Google is moving towards migrating everything under Google Home and thus the Google Home API. I think it’s going that way. Google Home has Away/Home status exposed but we don’t have a binding for that yet.
And now Google’s rolled out this new script editor:

I took think SDM will eventually be brought under the Google Home umbrella. Like many of you who have relied on WWN for so long this really stinks.

If they don’t make it friendly for us soon, I’m going to be moving away from Google and Nest. My Protects are 2 years from that 10 year replacement mark.

I don’t think that’s the case, purely because they haven’t already added the Nest Protect to Google Home and show no signs of doing so. It seems to me that they’ve left the Nest Protect entirely untouched.

There’s a trick to use the Home/Away status in openHAB: use a Google Assistant routine to toggle an openHAB item, which can then run an OH rule. It’s not instantaneous, but the change is picked up within a minute or so (Google home geofence example).

It’s been long enough that I see no reason to expect to expect anything to change. Personally I’m not too bothered by it, because the Nest Protect is (in my opinion) the best smoke detector available. It’d be nice if it integrated with openHAB, but I don’t feel like I’ll gain that much from doing so. And with any other smoke detector, I’d lose features like the built-in notifications (via the Nest app), the nightlight, the “I’m about to sound the alarm” warnings, and the reminders to test it periodically.

It might actually be a good thing that Google hasn’t messed around with the Protect, because the odds are that they’d just make it worse. :wink: