Nest 1st gen and 2nd gen thermostats no longer supported from Oct 25

I got burned recently by Ecobee in the same way. The problem with 'smart' interfaces for traditionally mechanical devices is that the useable lifetime (support period) of low-end microprocessors and software, especially online APIs, is often far shorter than the mechanical device it's attached to.

Similar to how people that keep cars around for 10+ years are stuck with dated and worthless 'infotainment' systems, Google and Ecobee can't even honor their product for long enough to outlast the HVAC units.

What burns me is that it wouldn't be much of an ask for them to push one final (optional) update that would open LAN-only access to core functionality. I and many others in the HA/ESPHome community have written hardware integrations to devices over RS485/UART with unpublished/black-box protocols, so a simple HTTP API would have an integration within days.

It would maybe cost an engineer at Nest/Ecobee a day or two of work, and the goodwill would make me far more likely to purchase a newer model. As it is, I've committed to avoiding (where possible) devices that aren't local-first.

I got lucky with my 2011 Toyota because the inputs are standard Bluetooth, an aux port, and iPod-style USB. The display is also a VFD pixel display and not some crappy LCD with a resistive touchscreen.

Of course, new devices might use some incompatible Bluetooth standard in the future.

> What burns me is that it wouldn't be much of an ask for them to push one final (optional) update that would open LAN-only access to core functionality.

The last dev who understands the code and the build tooling left years ago.

As an early Nest employee who worked on the first-gen thermostat I can tell you definitively that you're way off base here. That doesn't mean that Google shouldn't have done more to keep these units alive (and indeed that's one of the reasons I left Google). But these devices were designed in 2010-11. Even keeping the Linux kernel up to date with the latest version is a major undertaking. Adding major functionality like Matter compatibility, or even a simple (but secure!) local API, would take a seasoned engineering team a considerable amount of time.

That said, investing in devices that are local first is certainly good advice, provided the APIs are open and well supported.

Recent extreme frustration with Google products in mind, I'm tempted to read the crux of this post as, "Google engineers/designers are incompetent." It might be unfair, but on a day when Google Search, Youtube History Search, and (whaddya know) my Nest Thermostat have all failed me, the temptation is strong.

I think the reality is that the engineers are competent but this was just not a priority they were given and they were not going to spend nights making this happen instead of hanging out with their kids.

> Recent extreme frustration with Google products in mind, I'm tempted to read the crux of this post as, "Google engineers/designers are incompetent."

Engineers don’t make business decisions on when to end support, that’s a management decision; engineers ideally ought to be consulted on what it would take to continue support, but even that isn’t guaranteed. If planned obsolescence has been a business strategy, literally having an obsolescence switch and pulling the trigger on it has to be tempting to certain decision-makers even when support would be practical.

> a simple (but secure!) local API

A bit of an unusual idea, but: if the users of such a thing are folks who're already playing with HA and are tech savvy, why not just expose the API and tell users that they're "only allowed to use the "hacker's update in good faith" if they put the devices on a separate network without internet access?

Your team doesn't need to spend a ton of time on making it super secure, and DIYers can continue to use the hardware for as long as it physically works, me thinks

Okay, but isn’t this really about, why should Google spend money making things work better for iPhone users? It doesn’t like doing that. That’s what Matter support is really about. It’s always been about Apple Home.

And before you accuse me of being “way off base” lemme ask you: why doesn’t Gmail support push for iOS Mail anymore?

Liability.

If your car is old enough to have a standard DIN radio, you can easily replace it with a modern CarPlay/Android Auto unit. And cars that are new enough to have CarPlay/Android Auto built in seem to be generally holding up. It’s really just cars from a specific window (after they started putting nav systems and screens, before adopting CarPlay) that age really badly.

Isn't this exactly what the mountain of liability waivers already included in the ToS are for?

> It would maybe cost an engineer at Nest/Ecobee a day or two of work

I think you misspelled a _year_ or two of work. Especially with the scrutiny that comes with software written at a major corp like Google.

Security is always the excuse, but it's a local device connected to Wifi. Add a setting to the existing menus that is opt in to turn on the new API.

Beyond that, there's what, like 4 or 5 parameters that are useful to set, and a few that can be read. It wouldn't be necessary to over engineer the API, even a few simple, fixed TCP packets to query state and set the basic parameters like mode, fan, room and set temp would be all that is needed. It can be ugly and basic, just release the info and other devs would run with it.

For example, the older TPLink Kasa line of smart devices have a simple TCP packet protocol for local control. The 'security' was easily reverse engineered (simple key autokey cipher), but there wasn't any outrage. Their simple scheme that wasn't meant to be widely known meant it was possible for others to build the integrations.

https://www.softscheck.com/en/blog/tp-link-reverse-engineeri...

Not a lawyer, but liability waivers may not apply if there is determined to be gross negligence or recklessness.

Making a reasonably-designed API available, only if connected to an inaccessible network, doesn't sound dangerous, but the goodwill gained might be hard to weigh against a miniscule chance of malware, which would revise everyone's opinion of the degree of negligence or recklessness.

First, thank you for posting. Insiders can provide unique persepectives.

    > Even keeping the Linux kernel up to date with the latest version is a major undertaking.

Dumb question: Why does an old Nest need an updated Linux kernel?

    > investing in devices that are local first is certainly good advice, provided the APIs are open and well supported.

Do you have any examples that could sufficiently replace old Nests?

"Even keeping the Linux kernel up to date with the latest version is a major undertaking."

To me this sounds always backward. We make a choice of tools, and now we can't support you longer, and blame it on the tools. It's like "I need a car because I've moved out of the city center." Yes, of course you need a car, but because of your choices and actions.

If you prioritize easier development over long term support when choosing tools, then this is what you get.

Of course it's ok and valid to make that tradeoff, but then don't blame it on the tools, but on your choices.

"Why does an old Nest need an updated Linux kernel?"

Old versions that no longer receive security updates is a major issue

I am bit confused by this post.

Let me turn it around. Imagine that you are a Google engineer who worked on Search, YouTube, or Nest. How would you feel reading your own post? You would probably vehemently disagree! I'm not sure your sentiment is relative in 2025. Everyone on HN knows that any "web scale" public product (with billions of users) 100s of engineers behind it. And, it takes very good ones to keep them running and continuously improve them.

Thus, in response to:

    > It might be unfair

I say: Yes, it is unfair and unnecessary to post. It adds very little to the wider discussion.

They might even have gotten in trouble if they had rolled out an update that product management didn't ask for and is perceived to reduce incentive to upgrade to a new device

    > The last dev who understands the code and the build tooling left years ago.

I'm confused. Are you writing this with first hand insider's knowledge? Or is this sarcasm?

    > LAN-only access

Serious question: What does this mean? I'm such a dumbo about networking. Is it simple for an app to distinguish between "LAN" and "WAN" network requests?

If I’m a Google engineer, what motivation do I have to make decisions that keep a device running for a decade?

Even more pertinent, when it gets time to go through the promo process and when I need to prove “impact” and make sure what I’m doing is aligned with the department wide OKRs, why would I want to be on a project supporting old legacy tech that I can’t spin to show how it helped the company’s revenue?

I’ve never worked for Google. But incentives based on the promo culture is endemic to all of BigTech.

And even worse, every company is focused on “AI” these days. If you aren’t part of an initiative that can be said to be AI adjacent, if you care about your career and comp, you shouldn’t touch it with a 10 foot pole.

https://www.warp.dev/blog/problems-with-promotion-oriented-c...

https://news.ycombinator.com/item?id=31261488

I would expect a thermostat to last 15+ years across multiple home owners - it should be an improvement over a mechanical one, after all. If that's not adding to Google's bottom line, they shouldn't have "disrupted" that market in the first place.

> If I’m a Google engineer, what motivation do I have to make decisions that keep a device running for a decade?

Empathy and being a good human being in relation to society. Making devices that look good at first and cause pain later, when it's too late to do anything about it... is bad.

> I need to prove “impact” and make sure what I’m doing is aligned with the department wide OKRs

Fair, and that's a reason to _not_ put in the effort to make longer lasting devices.

> But incentives based on the promo culture is endemic to all of BigTech

And we should be calling them out for it. It's bad in the same way that forced ranking systems are bad; they promote the wrong things.

I assume it means

- You connect directly to the device to tell it what to do

vs

- You connect to some service at google/whatever that then tells your device what to do.

The former still works after google/whatever decide not to support/host the service that handles that.

I don’t get who uses Nest or other non-first party thermostats anymore:

All modern furnaces/ACs/heat pumps require their own smart thermostat to work optimally. So if you install Bryant furnace, you end up with Bryant smart thermostat, and so on. In fact, when choosing new furnace/AC choose brand with good software in thermostat first and foremost - units themselves are pretty identical otherwise.

Say the employee did want to work on the product in spite of it not being in their best interest. How are they going to get the buy in and the team to make the change and the support to get it pushed to devices in the field?

And no one works for a privacy invading ad tech company because they want to make the world a better place. It’s purely about making a shit ton of money.

> And we should be calling them out for it. It's bad in the same way that forced ranking systems are bad; they promote the wrong things.

Despite the newest LP about being the best employer, Amazon has been the shittiest of the BigTech employer as long as I can remember. Their reputation hasn’t changed anything about their profitability or stock price.

Before you ask if I knew that, why did I work there. I was 46 at the time, it was my 8th job out of 10 and it was purely remote and a “field by design role” that was remote until a year after I left. It was purely a money and resume play.

That really isn’t true. I have a split level heat pump with no thermostat, well, there is one in the remote control that sets a mini thermostat on each internal unit. Basically, we don’t have a central thermostat but that isn’t weird for Seattle.

Incidentally, I would love for a better remote control that was easier to use, we might use our heat pump more than a couple of weeks a year in that case.

In the early 2000s, even cars with oddball radios (like a CD slot adjacent to climate controls for example) could have an aftermarket head unit installed because dash trim kits were available to replace the proprietary layout with a DIN slot. Is this not the case for the era you mentioned?

At least HVAC systems have a mostly standard control system and thermostats are easy to swap out. If a thermostat goes out of support and looses functionality, you do not need to replace the entire HVAC system; only the relatively cheap thermostat.

I'm contrast, while it is often possible to replace an infotainment system, the replacement needs to have been designed for a fairly specific set of cars, and actually installing it requires paying a mechanic for most people.

For general purpose computing - yes.

For a thermostat, with presumably an attack surface that could be made arbitrarily small (albeit by removing non essential features) -why?

Surely this means all embedded devices are a serious liability?

> Similar to how people that keep cars around for 10+ years are stuck with dated and worthless 'infotainment' systems, Google and Ecobee can't even honor their product for long enough to outlast the HVAC units

I would never buy a car that doesn’t support CarPlay. The four protocols that Apple created to interface with non Apple devices - the original iPod protocol, AirPrint, AirPlay and CarPlay haven’t had any breaking changes. As of at least three years ago, I could use an old first gen iPad from 2010 (the first to support AirPlay/Airprint) and use it with modern Roku TVs with AirPlay support and modern printers.

My old 2011 Sonic that I had with a USB port that supported the iPod protocol for displaying titles for audio and controlling iPods still worked with every iPhone I had.

But I would never trust Google not to kill a device.

Absolutely nothing is stopping Google from keeping all the integrations working until the thermostats physically break. No one asked for a new kernel and whatnot.

Is keeping alive the infrastructure that servers the 1st and 2nd generation devices online and just proxy the communication between the old features and new features available in HomeKit and other smart home hub apps such as big undertaking that Google balked at it?

Ecobee thermostats do have local control through the homekit api

Nest made an implicit choice of tools back around 2010 when it selected the particular SoC that powers the early thermostat. Options were more limited then, and vendors often provides kernel tools and libraries that included proprietary closed-source components. Over the years most of these tools have been abandoned or EOLed by their providers (as companies will do). Keeping these tools working and building new releases of software in the context of a modern build environment is a full time jobs itself, especially in the context of Google with its highly idiosyncratic internal processes.

While I was at Google I complained bitterly about the repeated killing Nest products. But there was no way I had the bandwidth (or the permission) to serve as the sole lifesaver for any of them.

I’m not sure what the problem is, but there are a lot of cars where you couldn’t buy anything off the shelf to fit a DIN radio. People on forums were hacking solutions together with literal hacksaws.

I'd be worried about any internet-connected IOT device in my home. It the very least it can snoop on traffic. The Nest in particular could a) use it's motion detector to report if you are home b) harass you through temperature changes (and maybe even gaslight you by not showing them) c) maybe overload something (itself?) and cause fire?

That's just what I can come up with sitting here and having no in-depth knowledge. I am sure actual security experts could come up with more scenarios.