And that’s why the only IoT devices I’ll buy use Zigbee (ZWave works too). You can’t shut down a device that I control internet access to. Sadly this doesn’t scale, it takes specialized skills and time to build out home automation using these technologies.
Same here, I wouldn't touch wifi-devices unless I there was no other alternative (not been the case yet with the exception of my robot vacuum but it runs on a schedule anyways and I manually trigger it 1-5 times a year). Z-wave all the way. I'm currently a SmartThings user but I'm sort of considering switching to Hubitat. Probably wait till my existing hub dies or ST does something shady/anti-consumer.
I’m using Zigbee2mqtt on HomeAssistant. Harder to setup than smart things, but even more personal control.
And that’s why the only IoT devices I’ll buy use Zigbee (ZWave works too). You can’t shut down a device that I control internet access to. Sadly this doesn’t scale, it takes specialized skills and time to build out home automation using these technologies.
It’s gotten easier with Home Assistant but still, even as an engineer I prefer to use the easy APIs for these things sometimes than run my own support system for the Z-stuff
HA isn’t the hardest system I’ve ever setup, but I doubt many non-engineers could do it. I’m thankful it exists, but I’d love to see if someone can create something easier for the general public to setup and use.
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 abunda…
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 c…
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.
According to their App Store description: > We no longer recommend using the Automatic car adapter due to reliability issues. Do you happen to know if this is real or just a CYA? I'd pay $10 to extend the life of my adapter, but not if I needed to buy another device anyway.
Former VP Eng @ Automatic here :( There is an auth component needed for that BT connectivity to work - once the token expires, the BT connection won't authenticate anymore. i.e. if you uninstall the BT apps, change phone etc...
Yeah...I have a Gen 1 adapter, and I found this to be a really annoying limitation. It makes sense from the company's perspective, since it forces you to have their app installed. And at least up until one of the major iOS releases a few years ago (iOS 8 I think?), it was not possible to definitively disable access to Location data for background apps. So you had to decide whether to allow the app to constantly record your location, or instead to delete the app and not be able to use the adapter.
Wow, an ASIC is a big step! I'm impressed you needed to hit that level of (cost down, I assume?). Or was it to get better HW security, perhaps to use it for billing? Anyway, I had an original Bluetooth Automatic until I upgraded to a Pro when it was launched. I love them! Sorry to hear this is the end.
Vehicle compatibility was really the key - building a cross bar that allowed any pin to be mapped for any function (i.e. CAN on any combo of pins). We included a hardware protocol decoder and a ton of electrical safety items as well as security and reliability tools. 200MHz processor, 2MB flash and 256kB of ram in a single QFN package. A great project to work on! One career highlight for sure.
Ahh, interesting. I can see how that combination of features would be easier to fit in an ASIC than as discreet components in the tiny dongle. Pretty cool hardware combination!
Can you comment on what the safety/security/reliability blocks were?
Perhaps next time someone on HN is complaining about "yet another subscription" business, send them to this and 10k other posts as a reminder how good businesses die without proper revenue.
But this subscription business died so doesn't it demonstrate the opposite of what you're saying?
In the good old days, businesses thrived perfectly well off of one-time purchases of products.
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 work…
> 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 in…
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.