Hacker News Reader

Comment by rohansingh | Hacker News Reader

I'm working on a IoT device and this is something that my cofounders and I have discussed a fair bit. While we want to succeed, we know that most businesses fail, and we don't want to put out products that become waste.

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'd like to see more companies follow this approach. I've at least a handful of IoT devices that are effectively bricked, which sucks because I know they have decent and usable innards.

View on HN

I worked at an ultimately unsuccessful IoT startup a few years ago. Our first product was a wireless leak detector with remote notifications, it was definitely better than the what the market currently had on offer but it only "worked" if its base-station could contact a service via the internet. On the software side of the project had a lot of time to think about the long term future while the hardware team was working through manufacturability and so on. Watching other hardware+service companies go under I realized there's a need for some sort of "continued service insurance" in this industry. I'm imagining some company that, for a fee, would take delivery of service software images and guarantee its continued operation for the reasonable life of the hardware (say 5 to 10 years) if the company folds. No improvements/bug fixes/etc., just a guarantee that whatever sort of phoning-home the hardware was doing before could continue after. With no new sales, so no growth to worry about, seems like it should be pretty easy to predict the total cost to run the thing for the promised duration on a cloud service like AWS.

> No improvements/bug fixes/etc., just a guarantee that whatever sort of phoning-home the hardware was doing before could continue after. With no new sales, so no growth to worry about, seems like it should be pretty easy to predict the total cost to run the thing for the promised duration on a cloud service like AWS.

For devices that are air-gapped the idea may be workable, but not in the form you’ve outlined for internet-connected devices. What happens when a major vulnerability is discovered? Who is liable when a vulnerable device gets exploited in a well-orchestrated breach?

Such a company would eventually be confronted with the reality of lawsuits.

I reason this differently in a couple ways: 1) most IoT devices/base stations (though not all) do not expose an interface to the internet, they simply make outbound calls across the internet to some service to report stats, send messages, get commands, etc. (In the case of Automatic I believe the "thing" relied on the user's phone to act as the basestation) 2) any device that does expose an interface to the internet will still be exposed even if the central service shuts down. Now if someone actually manages to hack the service itself and use it for malicious purposes (like sending bad commands to the things) that would probably fall on the operator, but securing such services is a problem they could probably get really good at solving.

Do you think that Automatic needed to have a cloud service? Their primary use case seems to have been uploading mileage data to a variety of expense reporting systems. I don't see any reason that has to go from the OBDII dongle through the now-discontinued Automatic servers, and only then pass to the actual endpoint.

These IoT devices (and especially the phones and PCs that typically act as intermediaries) are abundantly capable of storing the configuration data and doing the API calls necessary to communicate with online services.

Is it just about the control?

> Do you think that Automatic needed to have a cloud service? Their primary use case seems to have been uploading mileage data to a variety of expense reporting systems.

Honestly, that kinda seems like something that makes sense to do server-side, especially if they were forced to implement some of those integrations in very kludgy and fragile ways (like screen scraping/form filling). Even if the calls were made directly from the customer's device, there's probably a background hum of development work needed just to keep the integrations working.

The devices just collected bread crumbs of data (for example, GPS points or 1 second samples of the vehicles speed). You need some horse power to process these into higher level objects like trips.

In theory, it could be done on a cellphone, but a ton of extra data is needed inc volumetric models of an engine (to calculate fuel usage accurately). Doing it server side makes it possible to build this in an agile method vs going to every single make/model and getting this right the first time.

It's probably more about control than cost. Our company's product is similar to Automatic's, in that, in theory, you could have everything be done on-device and not need a proprietary backend at all.

Other than the fact that this is difficult to keep up-to-date and working, it increases the hardware cost significantly. Instead of having a very cheap microcontroller handling everything, you might need something more capable and more expensive.

Development cost goes up too, since instead of writing your integrations in Python, Go, JS, or whatever, you need to write your integrations on your embedded system.

There are a lot of really nice frameworks, like elixir with nerves, which make iot development a breeze. I'm sure it's not a pancea, but it's easier than coding in C or something like that for your firmware. With nerves, you can write your backend and firmware in the same language (elixir) and you don't need to worry too much about embedded things like memory insufficiency since nerves handles it all. I'm sure there are cases where you have to use a low level language, but those will decrease over time as hardware gets better and more efficient.

> 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.

> 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.

You should also consider open sourcing your cloud service in the event of shutdown. A repo with a Dockerfile should be sufficient, that could be turned into Digital Ocean droplet configs and similar one-click launches.

If you're spending a lot of time figuring out how to fail in such a way that your product doesn't become waste, you're probably working on the wrong things.

Perhaps the choices you make and the time you spend on mitigating the possibility of your product becoming e-waste will make you more likely to fail, leading to a higher probability of your product becoming e-waste because most people won't bother re-flashing the hardware you're making.

Work on improving your product and making sure that you succeed.

It's not a binary choice, and honestly it doesn't take a whole lot on our part to make the product open.

Also consider:

1. The choices we make on mitigating the possibility of the product being waste can actually improve our product. For example, because the product can be reprogrammed easily, we can enter verticals that wouldn't be possible otherwise. Or because our hardware is well-architected and documented, it's easier for us to iterate on it.

2. If we fail because we couldn't figure out a way to make the product responsibly, that's a good thing. I'd rather we fail early than put out waste.

Reply on news.ycombinator.com