One of the less glamorous experiences that has come with Consumer IoT products is a parade of items that cease to work when the company that made them shuts down. The economic down turn of 2020 has seen it’s share of products that have experienced this. In a few days the automotive adapters from Automatic.com will be on the list of causalities.
Automatic.com provided a device that connect to a car through the ODB-II port and would relay information about a vehicle back to the owner that they could view through an application or through the web portal. Through these views someone could see where their car is, read any engine trouble code, view the paths the car has traveled, and view information about hard breaks, hard accelerations, and other car data.
I have three of these adapters and have data from tracking the vehicles for the past 5 years. I would rather keep my information. Looking on Automatic.com’s page about the shutdown there is a statement about exporting one’s data.
To download and export your driving data, you’ll need to log in to the Automatic Web Dashboard on a desktop or laptop computer at dashboard.automatic.com. Click on the “Export” button in the lower right-hand corner of the page.
[…]
Although the number of trips varies between each user, the web app may freeze when selecting “Export all trips” if you are exporting a large amount of driving data. We recommend requesting your trip history in quarterly increments, but if you drive in excess of 1,500 trips per year, please request a monthly export.”
I tried this out myself and found it to be problematic. Indeed, after several years of driving across multiple vehicles the interface would freeze on me. I could only actually export a month of data at a time. Rather than download my data one month at a time across 60 months it was easier to just write code to download my data. Looking through the API documentation there were three items of data that I wanted to download. I’ll be using NodeJS to access and save my data.
To access the data it’s necessary to have an API key. Normally there would be the process of setting up OAUTH authentication to acquire this key. But this code is essentially throw away code; after Automatic completes it’s shutdown it won’t be good for much. So instead I’m going to get a key directly from the developer panel on https://developer.automatic.com. I’ve got more than one automatic account. It was necessary to do this for each on of the accounts to retrieve the keys.
On https://developer.automatic.com/my-apps#/ select “Create new App.” Fill out some description for the app. After the entry is saved select “Test Token for your Account.”
You’ll be presented with a key. Hold onto this. I placed my keys in a comma delimited string and saved it to an environment variable named “AutomaticTokens.” It was an easy location from which to retrieve them where I won’t have to worry about accidentally sharing them while sharing my code. In the code I will retrieve these keys, break them up, and process them one at a time.
var AutomaticTokensString = process.env.AutomaticTokens;
const AutomaticTokenList = AutomaticTokensString.split(',');
function AutomaticAPI(path) {
return new Promise(function(resolve,reject) {
var options = {
host: 'api.automatic.com',
path: path,
port:443,
method: 'GET',
headers: {Authorization:`Bearer ${AuthorizationToken}`}
};
var req = https.request(options,function(res) {
let data = ''
res.setEncoding('utf8');
res.on('data', function (chunk) {
data += chunk;
});
res.on('end',function() {
resolve(JSON.parse(data));
});
});
req.on('error', function(e) {
console.error('error',e);
console.log('problem with request: ' + e.message);
reject(e);
});
req.end();
});
}
function listVehicles() {
return new Promise((resolve,reject)=>{
AutomaticAPI('/vehicle/')
.then(function(d) {
resolve(d);
})
});
}
Let’s take a look at one of the responses from this call.
{
_metadata: { count: 1, next: null, previous: null },
results: [
{
active_dtcs: [],
battery_voltage: 12.511,
created_at: '2017-01-28T21:49:24.269000Z',
display_name: null,
fuel_grade: 'regular',
fuel_level_percent: -0.39215687,
id: 'C_xxxxxxxxxxxxxxxxx',
make: 'Honda',
model: 'Accord Sdn',
submodel: 'EX w/Leather',
updated_at: '2018-07-24T19:57:54.127000Z',
url: 'https://api.automatic.com/vehicle/C_xxxxxxxxxxxxxxxxx/',
year: 2001
}
]
}
From the response I need to id field to retrieve the other information. While this response doesn’t change any ground breaking information I’m persisting it to disc so that I can map the other data that I’m saving to a real car.
The next thing I grab is the MIL. This contains the last set of engine trouble codes with date stamps.
function getMil(vehicleID, limit,) {
return new Promise((resolve,reject)=>{
var url = `/vehicle/${vehicleID}/mil/`;
console.debug('url',url);
AutomaticAPI(url)
.then((data)=>resolve(data));
});
}
Here is a sample response.
{
"_metadata": {
"count": 3,
"next": null,
"previous": null
},
"results": [
{
"code": "P0780",
"on": false,
"created_at": "2019-07-09T20:19:04Z",
"description": "Shift Error"
},
{
"code": "P0300",
"on": false,
"created_at": "2018-02-24T16:05:02Z",
"description": "Random/Multiple Cylinder Misfire Detected"
},
{
"code": "P0306",
"on": false,
"created_at": "2018-02-24T16:05:02Z",
"description": "Cylinder 6 Misfire Detected"
}
]
}
The last, and most important piece of information that I want is the trip data. The trip data contains a start address, end address, and the path traveled. Information about hard stopping and hard acceleration and many other items of data is stored within trips. For the REST API a start time and end time are arguments to the request for trip information. The API is supposed to support paging when there are a lot of trips to return. Some number of trips are returned from a request along with a URL that contains the next page of data. When I’ve requested the second page I get an error response back. Given the short amount of time until the service shuts down it doesn’t feel like the time to report that dependency to the staff at Automatic.com. Instead I’m requesting the travel information for 7 to 9 days at a time. The results come back in an array. I’m writing each trip to it’s own file.
To more easily navigate to a trip I’ve separated them out in the file system by date. The folder structure follows this pattern.
VehicleID/year/month/day
The information within these files is the JSON portion of the response for that one trip without any modification. The meaning of the information in most of the fields of a response are easy to intuitively understand without further documentation. The field names and the data values are descriptive. The one exception is the field “path.” While the purpose of this field is known (to express the path driven) the data value is not intuitive. The data value is an encoded poly line. But documentation on how this is encoded can be found in the Google Maps documentation ( https://developers.google.com/maps/documentation/utilities/polylinealgorithm ).
Now that I’ve got my data saved I may implement my own solution for continuing to have access to this functionality. At first glance I see some products that appear to offer similar services. But the lack of an API for accessing the data makes them a no-go to me. I’m instead am learning towards making a solution with an ELM327 ODB-II adapter, something I’ve used before.
Download Code: https://github.com/j2inet/AutomaticDownload
j2i.net 