The architecture of Eight Sleep is that the "Pod" – despite having a full Linux system running – is treated as nothing but a sensor and actuator. Absolutely zero decision-making happens on the device itself; it's all controlled by commands received from the mothership via an AWS service.
My cynical take has always been that this is their justification for charging a subscription fee for features that shouldn't require one (e.g. an alarm clock or the ability to change the temperature on a schedule).
There are a couple of open-source projects around jailbreaking it:
I found this to be a very strange architectural decision.
We work in the neurotech/sleeptech space (https://affectablesleep.com) and have a subscription service as well. We know when your subscription runs out, and have built the device to run completely offline, and even have a buffer of days if it can't connect to check you have a valid subscription.
Say what you will about subscription services, but being actively hostile to your user base because the device can't connect to a service on one night, seems like very poor planning.
I actually quite look up to 8Sleep as one of the better companies in this space, so I'm surprised this happened to them.
No WiFi, no AWS (as far as the mattress is concerned). "Works without WiFi" would be sufficient but not necessary for functioning through the AWS outage.
https://archive.is/fNNCg
The architecture of Eight Sleep is that the "Pod" – despite having a full Linux system running – is treated as nothing but a sensor and actuator. Absolutely zero decision-making happens on the device itself; it's all controlled by commands received from the mothership via an AWS service.
My cynical take has always been that this is their justification for charging a subscription fee for features that shouldn't require one (e.g. an alarm clock or the ability to change the temperature on a schedule).
There are a couple of open-source projects around jailbreaking it:
- Probably the original attempt: https://github.com/bobobo1618/ninesleep
- The much more polished and usable application built from that starting point: https://github.com/throwaway31265/free-sleep
The latter is even able to do the signal processing needed for heart rate on-device.
I found this to be a very strange architectural decision.
We work in the neurotech/sleeptech space (https://affectablesleep.com) and have a subscription service as well. We know when your subscription runs out, and have built the device to run completely offline, and even have a buffer of days if it can't connect to check you have a valid subscription.
Say what you will about subscription services, but being actively hostile to your user base because the device can't connect to a service on one night, seems like very poor planning.
I actually quite look up to 8Sleep as one of the better companies in this space, so I'm surprised this happened to them.
[dupe]
Discussion: https://news.ycombinator.com/item?id=45658056
And update: https://news.ycombinator.com/item?id=45677351
>“I still plan to continue to use it,” he said. “The main friction point is, really, the mattress should work even without Wi-Fi.”
I appreciate the drifting semantics of names, but Wi-Fi and AWS are really not the same thing.
I'd venture to say that the person meant that these kind of devices should be designed to work "locally first".
No WiFi, no AWS (as far as the mattress is concerned). "Works without WiFi" would be sufficient but not necessary for functioning through the AWS outage.
Right, but during the AWS outage that took these beds out presumably most of the owners had functioning WiFi.
Yeah, "works without any internet connection at all" is perhaps overkill for an AWS outage but I'll allow it.
But it should still work without functioning WiFi.
I think perhaps they mean it should just run locally, rather than without an internet connection at all