These choices Nest has made simplifies the SW stack, UX & provides for better security at the cost of mandating a physical fallback rather than a LAN fallback. You may see things differently but that doesn't mean these aren't valid engineering tradeoffs.

Well it sounds like tradeoffs that make the engineer's life easier.

Maybe they should actually tackle the harder challenge of getting their supposedly smart devices to work in a heterogenous networking environment.

That would be a real innovation.

I'm also unclear why you are claiming the only gains are in maintenance. Security is a real end-user benefit & having devices not allow arbitrary incoming network connections is a security choice. Similarly, arbitrating everything through the web results in a simpler, more reliable, enrolment process & makes it easy to add customer features like family control more easily, securely & reliably. These are all customer-facing advantages.

2 hours out of a year is still 3, almost 4, 9s of uptime. That's probably better than your home network/ISP.

I get it. You personally would prefer they traded off for supporting direct connection to your phone. However, that doesn't invalidate that there are legitimate engineering reasons someone might choose other tradeoffs.

I could totally understand why the Nest team wouldn't view it as a compelling product requirement. You need the cloud anyway because people regularly control the thermostat outside their home (e.g. to pre-warm/pre-cool when they're heading home). It's all the same infrastructure that's leveraged to run products beyond the thermostat (doorbell, security) that also have a compelling remote use-case. The isolated LAN approach could still require a cloud component for managing access. The C&C UX could become quite confusing trying to support both isolated LAN & cloud. If the cloud part fails you're no worse off than if you had a non-smart thermometer/doorbell with a good UX.

Now you could obviously have remote abilities without the cloud but the UX story becomes even trickier because you need to figure out how to rendezvous & punch through a wide variety of firewall configurations. These are all things technical users could solve given the appropriate settings exposed (eg. dynamic DNS) but it's totally unnecessary for the less technically minded users Nest is targeting (or even technical-minded users who don't want to care about managing every single smart device on their network).

The only reason these "smart" devices can exist is because the market hasn't matured and customers don't know any better.

A bit off topic, but I am hoping one day the always-on in-home server takes off for the average user so that my ability to expose my in-home server to the public internet is no longer a minority skill.

For the equivalent effort to implement, most customer's revealed preferences are for new/better features rather than robust local intelligence.

This kind of event just doesn't happen very often.

While it may not happen very often, I wonder how many customers (like me) they lose because the customers do not want their devices to even have internet access but still want local remote control (and are willing to sacrifice non-local remote control).

I guess ideally they would utilize a more localized protocol when you're nearby and then fall back to control->remote server->device when you're not.

(In case it's not clear, many of the reasons devices use cloud rendezvous have to do with NATs and firewalls and the difficulty of doing direct node-to-node communication in today's very fragmented Internet. Not all - some are security and complexity.)

Instead of your apps having to detect if they're local or remote to the device and then implementing a different protocol based on locality, they instead just always call out to a cloud based location.

They don't have to devote resources to maintaining 2 APIs for every product and can instead focus on reliability and robustness of the one interface.

> it's just a crap design from a usability standpoint.

I would argue the opposite. By having to support both cloud and local communication, you're introducing complexity and the possibility that APIs could diverge in functionality and reliability.

Either a cloud app is going to go out, or my home internet is going to go out. I don’t expect 100% uptime because I’m realistic, and expecting non-cloud infra devices with no time commitment is a pipe dream.

Plus, if your batteries run out, then you wouldn't be able to change the temperature anyway. You have far bigger problems than the device being online only.

I believe that's how Apple does it. The local host device is either an AppleTV, or an iPad.

All it takes is for Snake Farm to pay to find out how many times your smoke detector goes off. Or even if it doesn't fully go off, how often it senses anything.

With your thermostat data, it's possible to build a profile of when you're home and away. Hmmm... he seems to work an overnight shift. Better jack up his premium!

So in your case, better buy that smart device.

Companies already do: https://www.progressive.com/auto/discounts/snapshot/

In this case, Progressive gives you a discount in exchange for monitoring you.

But I've seen articles where other insurance companies (often in the UK for some reason) raise rates for things as seemingly innocuous as posting the wrong thing, or being "friends" with the wrong people on social media.

i don't necessarily care that much about that, but i do want such a product to work perfectly fine whether there's a connection to their servers or not.

Local connectivity seems to present all sort of silly issues that make the user experience a bit inconsistent. Heck, look at Chromecast, it works great about 90-95% of the time. That 5-10% of the time it doesn't work, it becomes a complete pain.