I find it absurd to invest half a year's salary on a new car. Instead of more expensive German craftsmanship, I opt for second-hand Japanese cars with screaming VTEC engines from the 1990s. Alas, this type of car won't get you the electronic bells and whistles nowadays commonly associated with the "connected car." In my adopted home of San Francisco, a startup company called Automatic has developed a connector to the car's on-board diagnostic (OBD) port [1] (Figure 1) that continually reads data from the car's on-board computer and feeds the data either to the driver's cell phone or straight to an account in the cloud via the 3G mobile network.

Figure 1: The Automatic adapter is plugged into the car's OBD-II port and wirelessly transmits the engine data over the 3G network.

The data is collated on Automatic's servers. From this data, the driver can then check out their driving route, how often they stepped on the gas like a madman or hit the brakes in the same way, how much gasoline the car consumed, and what the trip cost.

Figure 2 shows that the Integra GSR under my care achieved a fuel economy of 27.3 miles per gallon. The low rating of only 29 out of a maximum of 100 points for economical driving could thus be greatly improved.

Figure 2: The Automatic app on the phone gives this spirited driver a meager score of 29 out of 100 when it comes to fuel efficiency.

Even for Fleets

If someone has several cars, like me, each needs its own Automatic connector. The OBD-II port is often found under the dash in the footwell area, usually on the driver side, but sometimes also on the front passenger side (Figure 3). Once registered, the adapter then integrates seamlessly with various family cell phones on which the Automatic app is installed.

Figure 3: The OBD-II port for plugging in the adapter is usually below the dashboard.

The adapter comes in two versions: Automatic Lite, a less expensive one that connects itself with the driver's cell phone via Bluetooth, and Automatic Pro, which has its own GPS unit, 3G mobile network card, and transmits data directly to the cloud. I've had the El Cheapo version for a while, but found it to work unreliably. At least 20 percent of the time, the adapter would fail to find the phone and not record any data at all. The Pro version is much better; it still misses the occasional trip, but it's probably 99 percent accurate.

Upon arrival at the destination, the adapter notices that the car is no longer moving; it then saves the current address as the destination of the trip and automatically uploads the data via the Internet to the server, without the driver even noticing.

You can display the trip data later via the app or on request in the browser on a desktop computer (Figures 4 and 5). Automatic also provides an API that returns machine-readable data via JSON to registered users for downstream script processing and viewing.

Figure 4: On the Automatic website, the user can see when they drove what car, where they drove to, how much fuel their car consumed, and how their performance was rated.

Figure 5: The drive to the beach in Pacifica took 18 minutes for a distance of 13.4 miles and cost me $1.28 for gas.

Now, Where Did I Park?

We urbanites tend to crawl around the block endlessly until we finally find a free parking space. But later on, an important question often arises: "Now, where did I park?" Thanks to the Automatic connector, the answer is easy as pie; after all, in the Automatic universe, the car must be parked at the geographical end of a trip, unless it happens to be driving around somewhere in the meantime.

You can retrieve the data with the help of the Automatic API, for example, by using a Perl script at the command line. This requires the user first to register the application on the Automatic developer site at https://developer.automatic.com. After an OAuth token dance, you are then assigned an access token with which an API client, such as the one in the script in Listing 1 [2], can retrieve private data from the server on behalf of its user.

01 #!/usr/local/bin/perl -w
02 use strict;
03 use OAuth::Cmdline::Automatic;
04 use JSON qw( from_json );
05
06 my $oa = OAuth::Cmdline::Automatic->new();
07 $oa->raise_error( 1 );
08
09 my $vehicles =
10   from_json $oa->http_get(
11      "https://api.automatic.com/vehicle" );
12
13 for my $car (
14     @{ $vehicles->{ results } } ) {
15
16   my $trips =
17     from_json $oa->http_get(
18         "https://api.automatic.com/trip",
19         [ vehicle => $car->{ id } ]
20     );
21
22   for my $trip (
23       @{ $trips->{ results } } ) {
24     printf "%20s: %s\n",
25       "$car->{ make }-$car->{ model }-" .
26       "$car->{ year }",
27       $trip->{ end_address }->{ name };
28     last;
29   }
30 }

Listing 1 first uses the API call to vehicle to pick up the descriptions of all of the user's registered cars in lines 10 and 11. The for loop from line 13 then iterates through the fleet and calls the trip API method for each vehicle in lines 17 to 19 with the ID of the current vehicle. The API calls deliver data in JSON format to the client, and the from_json() function exported from the CPAN JSON module then converts the data to Perl's internal format, in which the code can poke around by accessing hashes or arrays.

The output in Figure 6 shows that the Acura Integra GSR, a model typically driven by belligerent urban youth, is now parked on 24th Street in San Francisco, whereas the Honda Fit, the commuter vehicle used by my better half, is currently parked in Oakland, where my wife works.

Figure 6: A Perl script fetches the car data from the Automatic server and determines where the user's vehicles are parked.

Logging a Trip

The resulting data is stored under the results key as an array, and, in the case of the call to trip, each of the elements contains a series of trip objects that in turn contain the coordinates of a trip, with information on the speed, the number of acceleration and braking maneuvers, and even the street addresses of the starting point and trip destination. The trips appear in reverse chronological order; thus, the first trip in the list is the last one to have been completed.

The destination stated under the end_address entry is the address at which the vehicle was last parked. The only task remaining now is to distinguish between the different vehicles in the fleet and output the brand, the model, and the year of manufacture of the automobile in question. (My garage actually used to accommodate two Integras of different vintages a while back.) Armed with this information, plus the name field containing the trip destination, it is then clear where the respective car is located. The last command in line 28 stops processing the trip data after the first record; the for loop in line 13 starts a new round with the next car in the fleet.