4 ms·

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 s

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?

rohansingh 7y ago
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.
- battery_cowboy 7y ago
  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.
ardy42 7y ago
> 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.
mrlambchop 7y ago
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.

rohansingh 7y ago

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.

battery_cowboy 7y ago
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.

ardy42 7y ago

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

mrlambchop 7y ago

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.