I want to see the postmortem, although I'm sure we never will.
> Eight Sleep's system, which relies on backend servers for everything from real-time adjustments to data syncing, had no fallback. "It's unacceptable," fumed one early complainant on X, echoing the frustration of many who shelled out for "seamless" smart sleep only to face analog purgatory.
I'm guessing that this is a typical "smart" device setup where the cloud is essentially a tunnel between the app and the device that also saves a copy of all transmitted state for backup and data mining. The simplest design from the company's POV, but the worst design for resilience.
The real question: Was this an explicit or implicit product decision? ie, was it an explicit PM decision that local comms didn't match product requirements, or did they outsource it to the lowest bidder and have no idea this was a ticking time bomb, or did eng have to cut features to make some deadline, etc? If Eight Sleep doesn't have an at least an internal postmortem then someone should lose their job.
As a user, I would prefer the devices communicate locally and use a cloud tunnel only as backup. But this means engineering has to support two communication stacks, which is obviously more expensive than one. And the local network option is probably harder to build since cloud-based has so much tooling available.
My baseline expectation - that I can't believe I'm actually typing out - is that an appliance should operate as expected without Internet access. My only smart device is a door lock because a PIN is easier than a house key for our lifestyle, but even that isn't connected to Wi-Fi.
Weirdly eightsleep apparently is sending 16GB of data per month worth of telemetry. It's been pointed out that that's about enough for a live audio stream of everything that happens in your bedroom. It can't be cheap to process that much data.
These wifi based smart home devices just fundamentally don't serve their customers.
1. You pay money for a device
2. You pay money for monthly service
3. They sell your private data on the backend, not to worry though, it's "anonymized", but of course it gets sold and then deanonymized
4. AWS goes down and your house doesn't work
5. Eventually they go out of business or get bored and you have to buy and install all new stuff.
I mean not to defend the telemetry philosphy (my smart home setup is local only with a couple of tell-tale heart exceptions[1]) but I'd expect that any cheap sensor net where your trying to infer data from indirect sensors would be grabbing as much data as possible especially if it didn't have strong local processing.
But yeah don't buy products that don't work local only, if they require online the temptation will be to great at some point to abuse that requirement.
[1] They're slowly driving me insane and I'll destroy them for the peace of mind at some point if an update doesn't brick them first.
> Eight Sleep's system, which relies on backend servers for everything from real-time adjustments to data syncing, had no fallback. "It's unacceptable," fumed one early complainant on X, echoing the frustration of many who shelled out for "seamless" smart sleep only to face analog purgatory.
I'm guessing that this is a typical "smart" device setup where the cloud is essentially a tunnel between the app and the device that also saves a copy of all transmitted state for backup and data mining. The simplest design from the company's POV, but the worst design for resilience.
The real question: Was this an explicit or implicit product decision? ie, was it an explicit PM decision that local comms didn't match product requirements, or did they outsource it to the lowest bidder and have no idea this was a ticking time bomb, or did eng have to cut features to make some deadline, etc? If Eight Sleep doesn't have an at least an internal postmortem then someone should lose their job.
As a user, I would prefer the devices communicate locally and use a cloud tunnel only as backup. But this means engineering has to support two communication stacks, which is obviously more expensive than one. And the local network option is probably harder to build since cloud-based has so much tooling available.
My baseline expectation - that I can't believe I'm actually typing out - is that an appliance should operate as expected without Internet access. My only smart device is a door lock because a PIN is easier than a house key for our lifestyle, but even that isn't connected to Wi-Fi.