4 ms·

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 shoul

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.

h2zizzle 1y ago
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.
- gazpacho 1y ago
  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.
  - ajmurmann 1y ago
    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
- dragonwriter 1y ago
  > 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.
- throwaway2037 1y ago
  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.
- JustExAWS 1y ago
  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-cultures https://www.warp.dev/blog/problems-with-promotion-oriented-c... https://news.ycombinator.com/item?id=31261488 https://news.ycombinator.com/item?id=31261488
  - lodovic 1y ago
    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.
    - JustExAWS 1y ago
      https://killedbygoogle.com/ https://killedbygoogle.com/
  - RHSeeger 1y ago
    > 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.
user_7832 1y ago
> 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
- idorosen 1y ago
  Liability.
  - anonym29 1y ago
    Isn't this exactly what the mountain of liability waivers already included in the ToS are for?
    - rcyeh 1y ago
      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.
doctorpangloss 1y ago
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?
briHass 1y ago
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-engineering/ https://www.softscheck.com/en/blog/tp-link-reverse-engineeri...
throwaway2037 1y ago
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?
- ajmurmann 1y ago
  "Why does an old Nest need an updated Linux kernel?" Old versions that no longer receive security updates is a major issue
  - andybak 1y ago
    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?
    - ajmurmann 1y ago
      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.
KingOfCoders 1y ago
"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.
- dare944 1y ago
  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.
deleted 1y ago
[deleted]
ExoticPearTree 1y ago
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?

h2zizzle 1y ago

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.

gazpacho 1y ago
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.
- ajmurmann 1y ago
  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
dragonwriter 1y ago
> 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.
throwaway2037 1y ago
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.
JustExAWS 1y ago
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-cultures https://www.warp.dev/blog/problems-with-promotion-oriented-c... https://news.ycombinator.com/item?id=31261488 https://news.ycombinator.com/item?id=31261488
- lodovic 1y ago
  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.
  - JustExAWS 1y ago
    https://killedbygoogle.com/ https://killedbygoogle.com/
- RHSeeger 1y ago
  > 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.

user_7832 1y ago

> 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

idorosen 1y ago
Liability.
- anonym29 1y ago
  Isn't this exactly what the mountain of liability waivers already included in the ToS are for?
  - rcyeh 1y ago
    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.

doctorpangloss 1y ago

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?

briHass 1y ago

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-engineering/ https://www.softscheck.com/en/blog/tp-link-reverse-engineeri...

throwaway2037 1y ago

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?

ajmurmann 1y ago
"Why does an old Nest need an updated Linux kernel?" Old versions that no longer receive security updates is a major issue
- andybak 1y ago
  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?
  - ajmurmann 1y ago
    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.

KingOfCoders 1y ago

"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.

dare944 1y ago
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.

deleted 1y ago

[deleted]

ExoticPearTree 1y ago

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?