←back to thread

280 points RyanShook | 2 comments | | HN request time: 0.452s | 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 #
user_7832 ◴[] No.45146377[source]
> 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

replies(1): >>45146515 #
idorosen ◴[] No.45146515[source]
Liability.
replies(1): >>45146571 #
1. anonym29 ◴[] No.45146571[source]
Isn't this exactly what the mountain of liability waivers already included in the ToS are for?
replies(1): >>45146719 #
2. rcyeh ◴[] No.45146719[source]
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.