6 ms·

What's the right way to design an IoT product to not be dependent on a startup's cloud servers? - Allow the app/device to point to a different host (running an

What's the right way to design an IoT product to not be dependent on a startup's cloud servers? - Allow the app/device to point to a different host (running an open source version of the backend)? - Support LAN connectivity without round-tripping to a third party server? - Allow the user to load their own firmware onto the device? I don't know where the line is for these things, it seems to be a balance of convenience, ownership, and security. What's the ideal way to handle this so it works well even if the backing company disappears?

bigbugbag 10y ago
> What's the right way to design an IoT product to not be dependent on a startup's cloud servers? Not designing an IoT product in the first place seems to me the right way to avoid this issue. The IoT feature can usually be achieved otherwise and seems to be added in so the company can have more power/control over the customer. If you are adamant on making this IoT anyway, the only option is a distributed and/or federated network with an optional offline mode and option use of one's own network and server.
- bschwindHN 10y ago
  > Not designing an IoT product in the first place seems to me the right way to avoid this issue Unfortunately there is demand for these products and companies will always fill that demand if there is money to be made. If users want to control things in their house remotely, the commands need to be routed through a server one way or another. This is a matter of convenience and I'm sure most users would purchase a product they can control remotely vs. one they can only control on their home network. > the only option is a distributed and/or federated network What would a distributed network for this sort of product look like?
usrusr 10y ago
If you don't want to open everything right away, put protocol specifications, keys and the like into escrow somehow, to be published when the service is discontinued (it can't be tied to the company or brand because there will always be some form of legal successor). Run a domain called $productname-support-beyond-the-grave.com or so where the escrowed data would appear and for the time being use it to explain what you are doing and why buyers should be wary of competitors without a similar commitment. Keeping a repository like that up to date costs a lot of money, the shameless self-praise is how you would make it agreeable with budgeting. There should be a service for that, with people who can build experience over multiple client lifecycles and a recognizable brand, maybe even a 3/4/5 star commitment rating that would go down e.g. when there are indications that the repository is getting stale relative to the deployed service/firmware of the still living company.
exDM69 10y ago
> What's the right way to design an IoT product to not be dependent on a startup's cloud servers? How about providing a single board computer like a Raspberry Pi and the software images (or source code if you can) to run the software? This is obviously not a solution for everyone but it would probably work great for the DIY crowd. That said, I'm not buying any IoT devices, self-hosted or not, in the foreseeable future. When I buy a gadget that opens my garage doors, I expect it to last 10-30 years with minimal maintenance. I have zero faith in a startup being able to provide even a fraction of that. The economics just don't add up, why would they give me any service decades from now if I paid them $99? The company will have to sell a whole lot of these in order to be able to keep their servers running and their clients updated to run on most recent iOS/Android. I don't see any technical issues in doing so, just that it's not a viable business.
- bschwindHN 10y ago
  > How about providing a single board computer like a Raspberry Pi The issue is more about connection to external servers than the particular board itself. A product that both runs great out of the box, and is also hackable to the point where it doesn't 100% rely on the original company being around to run is the sweet spot I'm thinking of. I'm mostly just thinking aloud about what features the product needs to have in order to hit that sweet spot. > That said, I'm not buying any IoT devices, self-hosted or not, in the foreseeable future That's cool, but this isn't about the average HN user. Consumers want to, and indeed they do, pay for these devices. I just want a nice model where these products can be sold while not leaving the customer stuck if the original company goes under.
  - exDM69 10y ago
    > The issue is more about connection to external servers than the particular board itself. Oh I meant that the R.Pi would be the server where the IoT gadgets connect to. Located in your home and available through your home network connection. Optionally with some kind of (self-hosted) server in your own VPS. This is obviously a solution for DIY-ers only. > Consumers want to, and indeed they do, pay for these devices. I don't think this will ever work if the customers pay for the devices but not for the service. A $99 gadget doesn't leave much for the company to be running the service. I don't see how the economics would work out without a recurring payment. My gut feeling is that gadget startups such as this one haven't even thought about surviving more than 3-5 years without being acqui-hired to a major corp. Some may bet on getting to be big and thinking that scale will help. But even if every darn garage in the world would have this gadget for the $99 they charge, I can't see how they can keep the servers running and the software up-to-date with a one time purchase for the life expectancy of an average garage door. But consumers complain about recurring fees and there's only so many services you can subscribe to. Paying $2-$10 a month for your garage door, thermostat, cat feeder, plant waterer, etc will add up to a lot of money and hassle. The only way I see forward with cloud-powered IoT gadgets is that a major company with billions of dollars sets up the infrastructure that will scale up to millions of users with a few billion gadgets (and a monthly fee). It's either that or self-hosted DIY. I don't think it's economically viable for a start-up to provide a cloud service for a one-time fee for any meaningful period of time. I'm sure customers don't want to buy and install a new garage door opener every 3 years when their previous IoT gadget startup goes belly up, servers go down and the gadget turns to a brick.
antfarm 10y ago
Looks like Garadget have thought of that (at least for the future): The app requires a server component as does any consumer friendly product with mobile access. There is a plan to add the support for server-less mode, though it will require users to configure domain name service and firewall. The main server component is maintained by the Particle and pre-paid for the life of the device. Additionally, unlike many products bricked by the companies going out if business, Garadget is an open source system so it welcomes third-party solutions. https://www.amazon.com/forum/-/Tx1SJ70QRGDYZAY/ref=ask_dp_dpmw_al_hza?asin=B01KUZ2JPS https://www.amazon.com/forum/-/Tx1SJ70QRGDYZAY/ref=ask_dp_dp...
- bschwindHN 10y ago
  Well that's better than most IoT projects. The hardware is the special part anyway, so it seems fairly reasonable to have backend servers that are easily replaceable with open source software, or are open source themselves.

bigbugbag 10y ago

> What's the right way to design an IoT product to not be dependent on a startup's cloud servers? Not designing an IoT product in the first place seems to me the right way to avoid this issue. The IoT feature can usually be achieved otherwise and seems to be added in so the company can have more power/control over the customer. If you are adamant on making this IoT anyway, the only option is a distributed and/or federated network with an optional offline mode and option use of one's own network and server.

bschwindHN 10y ago
> Not designing an IoT product in the first place seems to me the right way to avoid this issue Unfortunately there is demand for these products and companies will always fill that demand if there is money to be made. If users want to control things in their house remotely, the commands need to be routed through a server one way or another. This is a matter of convenience and I'm sure most users would purchase a product they can control remotely vs. one they can only control on their home network. > the only option is a distributed and/or federated network What would a distributed network for this sort of product look like?

usrusr 10y ago

If you don't want to open everything right away, put protocol specifications, keys and the like into escrow somehow, to be published when the service is discontinued (it can't be tied to the company or brand because there will always be some form of legal successor). Run a domain called $productname-support-beyond-the-grave.com or so where the escrowed data would appear and for the time being use it to explain what you are doing and why buyers should be wary of competitors without a similar commitment. Keeping a repository like that up to date costs a lot of money, the shameless self-praise is how you would make it agreeable with budgeting. There should be a service for that, with people who can build experience over multiple client lifecycles and a recognizable brand, maybe even a 3/4/5 star commitment rating that would go down e.g. when there are indications that the repository is getting stale relative to the deployed service/firmware of the still living company.

exDM69 10y ago

> What's the right way to design an IoT product to not be dependent on a startup's cloud servers? How about providing a single board computer like a Raspberry Pi and the software images (or source code if you can) to run the software? This is obviously not a solution for everyone but it would probably work great for the DIY crowd. That said, I'm not buying any IoT devices, self-hosted or not, in the foreseeable future. When I buy a gadget that opens my garage doors, I expect it to last 10-30 years with minimal maintenance. I have zero faith in a startup being able to provide even a fraction of that. The economics just don't add up, why would they give me any service decades from now if I paid them $99? The company will have to sell a whole lot of these in order to be able to keep their servers running and their clients updated to run on most recent iOS/Android. I don't see any technical issues in doing so, just that it's not a viable business.

bschwindHN 10y ago
> How about providing a single board computer like a Raspberry Pi The issue is more about connection to external servers than the particular board itself. A product that both runs great out of the box, and is also hackable to the point where it doesn't 100% rely on the original company being around to run is the sweet spot I'm thinking of. I'm mostly just thinking aloud about what features the product needs to have in order to hit that sweet spot. > That said, I'm not buying any IoT devices, self-hosted or not, in the foreseeable future That's cool, but this isn't about the average HN user. Consumers want to, and indeed they do, pay for these devices. I just want a nice model where these products can be sold while not leaving the customer stuck if the original company goes under.
- exDM69 10y ago
  > The issue is more about connection to external servers than the particular board itself. Oh I meant that the R.Pi would be the server where the IoT gadgets connect to. Located in your home and available through your home network connection. Optionally with some kind of (self-hosted) server in your own VPS. This is obviously a solution for DIY-ers only. > Consumers want to, and indeed they do, pay for these devices. I don't think this will ever work if the customers pay for the devices but not for the service. A $99 gadget doesn't leave much for the company to be running the service. I don't see how the economics would work out without a recurring payment. My gut feeling is that gadget startups such as this one haven't even thought about surviving more than 3-5 years without being acqui-hired to a major corp. Some may bet on getting to be big and thinking that scale will help. But even if every darn garage in the world would have this gadget for the $99 they charge, I can't see how they can keep the servers running and the software up-to-date with a one time purchase for the life expectancy of an average garage door. But consumers complain about recurring fees and there's only so many services you can subscribe to. Paying $2-$10 a month for your garage door, thermostat, cat feeder, plant waterer, etc will add up to a lot of money and hassle. The only way I see forward with cloud-powered IoT gadgets is that a major company with billions of dollars sets up the infrastructure that will scale up to millions of users with a few billion gadgets (and a monthly fee). It's either that or self-hosted DIY. I don't think it's economically viable for a start-up to provide a cloud service for a one-time fee for any meaningful period of time. I'm sure customers don't want to buy and install a new garage door opener every 3 years when their previous IoT gadget startup goes belly up, servers go down and the gadget turns to a brick.

antfarm 10y ago

Looks like Garadget have thought of that (at least for the future): The app requires a server component as does any consumer friendly product with mobile access. There is a plan to add the support for server-less mode, though it will require users to configure domain name service and firewall. The main server component is maintained by the Particle and pre-paid for the life of the device. Additionally, unlike many products bricked by the companies going out if business, Garadget is an open source system so it welcomes third-party solutions. https://www.amazon.com/forum/-/Tx1SJ70QRGDYZAY/ref=ask_dp_dpmw_al_hza?asin=B01KUZ2JPS https://www.amazon.com/forum/-/Tx1SJ70QRGDYZAY/ref=ask_dp_dp...

bschwindHN 10y ago
Well that's better than most IoT projects. The hardware is the special part anyway, so it seems fairly reasonable to have backend servers that are easily replaceable with open source software, or are open source themselves.