←back to thread

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

(community.hubitat.com)
280 points RyanShook | 1 comments | 05 Sep 25 21:33 UTC | HN request time: 0s | source
Show context
briHass ◴[06 Sep 25 01:31 UTC] No.45145753[source]▶
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.

replies(11): >>45145799 #>>45145931 #>>45146011 #>>45146180 #>>45146556 #>>45146647 #>>45146754 #>>45146922 #>>45147255 #>>45147650 #>>45150597 #
dare944 ◴[06 Sep 25 02:43 UTC] No.45146180[source]▶
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.

replies(8): >>45146253 #>>45146377 #>>45146476 #>>45146706 #>>45146721 #>>45146737 #>>45147643 #>>45147709 #
KingOfCoders ◴[06 Sep 25 04:59 UTC] No.45146737[source]▶
"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.

replies(1): >>45150850 #
1. dare944 ◴[06 Sep 25 16:48 UTC] No.45150850{3}[source]▶
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.