←back to thread

280 points RyanShook | 1 comments | | HN request time: 0s | source
Show context
briHass ◴[] 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 ◴[] 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 #
h2zizzle ◴[] No.45146253[source]
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.
replies(4): >>45146276 #>>45146297 #>>45146744 #>>45146792 #
1. dragonwriter ◴[] No.45146297{3}[source]
> 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.