Automatic (Car Adapter) Shutting Down
automatic.comI sent an email to their support team asking if they had plans to open source their apps and they said, "there are no plans".
What a shame, it was a nice piece of hardware that could have had a few more years of life.
Thank you for doing that. I really wish they did open source their apps also.
I'd imagine that domain name is worth some serious case. Automattic (WordPress) and many others would probably love to scoop that up. I wonder if that's their most valuable asset now?
Automattic probably derived from "Matt" (The name of the founder) so probably better to keep using the brand.
Automatic Labs is owned by SiriusXM (market cap $25B).
I was just thinking that Automattic should buy the domain and just point it to theirs. I guess it doesn't matter though, most people don't know what Automattic is, they know what Wordpress is.
This really sucks. I have two Automatics, and they are just awesome. I've already used them to diagnose car issues, and tracking is great.
Luckily I got a lot of use out of them, but definitely said to see them go.
Whew, not Automattic (WordPress).
I always really liked this approach: Instead of every car smart by replacing them, make dumb cars (a bit) smarter with a connected device. Even once pitched a competitor to this service. That said, I'm wondering what the impact of Covid was on this: A regular SAAS service shouldn't see a huge impact, or would all customers cancel when not using their car for a month?
I've been thinking for a while now that we could expect to see a lot of "incredible journeys" for which COVID-19 is both the stated reason, and a very useful cover for the true causes. Not speculating on whether this is one of those, but I'll admit I wouldn't be astonished if it were.
I suspect they weren't doing well and are using this as a cover. With many states opening up as we speak, the could have ridden out a small down turn and come out the other end. You might argue that a lot of people are going to be without work and won't be buying new cars in the next while, however, were those their customers in the first place?
Wow. This is hard to believe. Big-time Automatic user - have been for about 6 years. The crash-alert feature provides peace of mind in a somewhat older vehicle. If anyone else knows an alternative, please share!
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.
Couldn't that go both ways though? Why would I want to sign up for "yet another subscription" when they can just go belly up and render my investment worthless (vs an alternative with a one-time payment)?
If it had been a "buy the whole package outright, no cloud nonsense" service then having the company go belly up wouldn't render your purchase useless.
Having a subscription means it can disappear on you at any point.
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.
It's hard to believe they weren't acquired. The amount of driving data they have must be huge.
They were, SiriusXM acquired them just over three years ago: https://blog.automatic.com/automatic-siriusxm-4dfbc9a6885c
SiriusXM not shutting down yet?
They are kept alive by how annoying it is to cancel the service and avoid future 'complimentary' reactivations.
If you live in California, you can require them to delete your information so that they can't contact you about your radio ID any longer.
Highly unlikely. The big money sink is already spent (launching the satelites).
The satellites are likely much cheaper than the ongoing costs for content.
It looks like they are spending over $2B annually on content fees. They could launch a lot of satellites with $2B per year.
Wow, they spend $2B/year on content and somehow manage to only have Clearchannel garbage stations? They're getting ripped off.
SpaceX should strike a deal with Spotify (StarLink “Constellation” as a competitor to SiriusXM)!
Why would spotify even need spacex? I mean... it's just the internet...they already have access to that, and so does everyone else. 4g connectivity to your car is probably simple and could be done if needed or a lot of people just link their phone to the radio.
Just as XM has use case specific hardware just for audio in cars and semi trucks, you’d need a StarLink terminal to get just audio content over StarLink’s constellation. Hence, a deal with a content provider (Tesla did this with Slacker radio in their cars).
Not every vehicle might need or want a full blown satellite ground terminal that can provide IP service.
Satellites cost a ton to maintain, and need to be replaced eventually.
They just launched two fresh ones last year so they’re good for the next 15-20 years
Perhaps there is better datasets for sale.
The added information compared to what Google or Apple are collecting is perhaps ODB metrics, but I'm not sure whether ODB metrics of gaz cars have a lot of value.
> With fewer consumers purchasing and leasing vehicles and drivers on the road, we unfortunately do not see a path forward for our business.
Said like nobody will ever drive cars again.
I'm perplexed at how quickly these businesses are deciding to fold.
I think it's a cop out. Sirius XM purchased them and then pivoted to rental car fleets. Guess that didn't work out, so blaming the Covid economy is an easy way out.
I was nervous Sirius would shut them down. Guess my worry was not misplaced.
There's very little money on the hardware space... plus if you're not charging an ongoing premium it may not be worth it.
What upsets me is seeing this hardware just become e-waste. I really dislike seeing perfectly functional hardware become unusable just because the company folds or something newer comes out. I ranted about the iphone 4 and how it's no longer possible to build software on that platform, especially since it's low power and could be used for any small project. My old Nexus 7 is still kicking (just slooow)
I used to work (sort of) in this space. A lot of the functionality that companies want to tie to their ODB hardware is getting rolled into the cars themselves by the auto manufacturers and app platforms like CarPlay and Android Auto. Companies like this had 5-10 years before facing obsolescence.
Most startups rely on industry growth. If you have 100 drivers today and 110 tomorrow, you will have the climate for startups. If you have 100 drivers today, and 90 tomorrow, you only have room for the entrenched players.
The adapter may still function over Bluetooth to read SAE PID [1] data using OBD Fusion[1] or a similar app.
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...
Oh that really sucks. I have an older one (Gen 1 I think) that a friend gave me when he upgraded. I don't really make much use of it but it was nice being able to see basic OBD codes the one time my car was acting up and the check engine light was on. Helped me figure out the likely issue before even taking it to the mechanic (saving time spent having them figure out the issue).
I could surely get a different BT ODB reader but I already have this one.
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.
Thanks for the info, sorry about the outcome. I enjoyed having mine.
Why wouldn't you have pushed an update that removed the DRM?
"Former"
They made my unit end of life, and then found themselves at end of life.
This is IoT.
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.
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.
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.
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.
> 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.
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.
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.
I just bought one of these about a month ago,
I read about how the company had just discontinued the old version of the product in the reviews on Google play of their app figured I'd have some decent time with it since they just rolled out the version I bought...
Jokes on me!
Any chance there's some way we could get the data out of them with something open source?
They do seem to have an export feature[1]. The dashboard has been "Loading trips..." for minutes to download into a CSV a measly number 2K trips I had.
I'm sorry that people are losing jobs over such closure, but usually the writing is on the wall.
[1]: https://help.automatic.com/hc/en-us/articles/360000599847-Ho...
Sorry - the servers are overloaded right now with everyone grabbing their data. And yes, we did scale things up! Hitting RDS limitations :(
What did they make? Their site doesn't have any info on their products.
an ODB port device, which connects with bluetooth to your phone.
It records how gas-efficient your driving is, as well as beeping when you go over 80 mph or have a hard break.
It tried to gamify your driving behavior to be more efficient and safe. And I think it was effective but from the start it's been tied to the cloud.
At the start they'd send weekly reports of driving behavior, congratulating or saying what could be done better. As well as tracking (with location data on the phone) where you drove. I once used it to expense milage for a conference.
However the emails soon stopped coming as frequently or reliably, then a year later when the emails stopped they said they were discontinuing my unit, encouraging me to buy the new one. I did not, as they failed to provide me with the service they promised.
EDIT: to clarify, the phone app would start upon bluetooth connection, and send the data to Automatic. I'm not sure if it was realtime or not.
That's the first version. The second and third versions connected directly over the cell networks. The second version allowed third party apps over bluetooth. The third version removed that feature.
Wow, the service stops on May 28th, less than a month away.
Just out of curiosity, have there been more (relatively successful) companies with a paid subscription plan that announced that they would, within a couple of weeks, shut their services down? As an outsider it seems quite drastic to me, given that the daily costs of keeping the servers running a bit longer is negligible.
Just buy the Torque Pro app for $5 and buy a cheap OBD2 Bluetooth adapter to go with it. No subscription needed.
https://play.google.com/store/apps/details?id=org.prowl.torq...
That only replaces the "vehicle data inspection" use cases, not the other use cases such as "call me when my vehicle is crashed by my kid".
I wonder how many companies are going to be claiming covid related issues to mask other deeper issues.
> mask
I see what you did there :D
Anyone know a good alternative to this that isn't meant to be fleet-scale? Getting OBD data over Bluetooth is widespread enough, but their service also made it super easy to generate mileage expenses. Also downloading a CSV of all my trips made for some fun data crunching. I'd love to keep those things going even if it means self-hosting something.
What cars do you have? I'm the founder of Smartcar.com and we might be able to help. No OBD devices needed.
Would be great to get an export that preserves the image of the trip map showing the path, even as a zipped folder full of thumbnails. Now do I write a script to scrape a screen shot of the 1700 trips, or write some code to use the exported encoded polyline (lose brake/mph/accel data on map)?
I have an older unsupported device still connected to my car. Any open source ideas for it?
I haven't read the article but I wonder how GeoTab worked into this (for the small fleet customers, large fleets would never consider this product)
This sucks. I use Automatic to track business miles. Is there a good alternative that's not phone based?
I panicked thinking this was the company behind Wordpress. It's not, it's just a car assistant thing.
Anyone have an alternative that they use for GPS tracking? I have 3 of these, argh.
If anyone has a device they’d like to sell, please contact me (in bio).
[EDIT] Thank you to the wonderful hackers who reached out to me. I think that I am all set now.
If you manage to hack this, let me know (retiring VP Eng here)! The latest device contains a custom ASIC with hardware security :)
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?
A couple of examples of hard problems might be the best approach.
- loss of ground
A vehicle OBD connector can at times, loose its GND pin. There are actually two GND pins - chassis and electrical that can sometimes disagree. Its possible for one of either of them to either (a) loose connectivity (b) bias towards the signal level or head towards a negative signal level (-2v was our typical observation).
To prevent an OBD protocol pin from dumping current down the channel, a complex HW/SW solution is needed to monitor and react quickly to prevent downstream ECUs from being fried.
- security
We built a custom debug tool based on CM-DAP (ARM debugger technology) that included OOB security paths to unlock a device for re-flashing / debugging. I think we made 500-1k of these in total for manufacturing/RMA/logistic purposes. This was super fun to work on :)