4 ms·

> We're working on mitigating this by having an open hardware platform. The idea being that, even if our cloud service isn't up, you can re-flash the hardware t

by ardy42 7y ago

> We're working on mitigating this by having an open hardware platform. The idea being that, even if our cloud service isn't up, you can re-flash the hardware to do anything you want. And you can use our documentation to do it so you don't have to reverse-engineer everything from scratch. I think that's absolutely great. I've had enough IoT products brick on me that I avoid most out of principle now. I'd change my mind for a product that make it clear they've implemented a customer-friendly plan for when the servers inevitably are shut down. That said, I think your plan really only seems to help tinkerers. There may be no way around that for what you're building, but I think graceful degradation in functionality is preferable, such as having a maximally-functional no-cloud mode. The few smart products I buy have a mode like that.

rohansingh 7y ago
> That said, I think your plan really only seems to help tinkerers. There may be no way around that for what you're building, but I think graceful degradation in functionality is preferable, such as having a maximal-functional no-cloud mode. The few smart products I buy have a mode like that. Great feedback. A limited "no-cloud" mode is something we could possibly do, I'll think about it. I think you are correct that it would really only be a small number of people who would be able to use our docs and write their own firmware for our device. But we want to make it relatively easy to switch between public firmware variants. So even if you're not an engineer, you can choose to try a different flavor for your device. And if we have to completely shut down our services, you could do that as well.