Whereas I joined the club, now I get to comment as part of the experience.
- What is it?
- What’s the vision/value prop. of the service/product?
- What does it do for me?
- Is it worth it? (will it be worth it if/when I pay for it)?
Still assessing OnStar RemoteLink App as
Reading device status off of the car works. That’s a neat convenience. “Neat,” but worth $0/month because it ought to be doable with this technology (Android) without server-side support and at zero cost to GM.
Actualities of success:
Critique & Review
They are not kidding about the admonishment of incompatibility:
Requires Android OS 2.1 or later. Resolution must be one of the following: FWVGA (480×854), 3.5″-4.0″ diagonal. WVGA (480×800), 3.3″-4.0″ diagonal. HVGA (320×480), 3.0″-3.5″ diagonal. Check your owner’s manual for details.
This paragraph is a very fancy way of declaring
- Does not work on GED device tablets
- Does not work on the Xoom
- Does not work on the Nexus 7
- Does not work on anything but teensy tinsey little screens.
When people talk about the “fragmentation of Android” this is the problem that they are talking about. It’s not a problem with Android but a problem with the developers, who typically are time-and-materials consultants. There is absolutely nothing in the functionality of the app that can’t be delivered on a varying-sized screen, even a screen as large as a tablet. Absolutely nothing. Yet they precluded it from even running in a fat-font mode on the current-generation Android hardware, however ugly that might be. There ought to be a tablet-class variant of this app. The Play Store’s device compatibility system prevents the app from being visible on your tablet or from being remote-provisioned onto your tablets.
The app is very slow to start, sign in to OnStar and to acquire data. It seems to do synchronous lock-step communication to the servers. Nothing is asynchronous or “in the background.” The data is never “at the ready” or “waiting for you.” You wait for the app, you wait for the data.
- When you fire up the app, there is a “waiting to connect stage” that is long enough that you put the phone down and come back.
- When the app fires up, the car’s status is not “at ready.” The status exhibited to you is the dataa that was last acquired from the car, stored locally on a cached-copy basis. That is, it is the data from the last time you ran the app. Frequently this irrelevant and your first act is to press “refresh.” And then you wait, you put the phone down, you go away, you come back, unlock the phone and see if your car status is ready.
- Refresh is synchronous and you wait.
The waiting issue is long enough that you would never be able ot use the app as a substitute for the keyfob controls (see above). You’d never get signed in in time.
Buggy unto Does.Not.Work.
- The alerts system is busted. It will not “sync alerts” onto the vehicle.
- Recovering status out of the vehicle does work.
- Therefore it is not a “connectivity problem”
- Ticket 24 ‘OnStar RemoteLink’ cannot set alerts on presented.recondite on Jelly Bean [access is limited]
Summary: includes actualities of traceroute4 and tcpdump of the https traffic into onstar server head-end; the app communicates to OnStar servers, but fails to set email & SMS alerts; it can & does recover the Volt’s dashboard data (as shown above).
Peer-to-Peer versus Client-to-Server
Embarassingly, you may be standing standing right next to the car when you ask for the car’s status. The app and still has to communicate back to the servers in Detroit, MI which then may or may not “dial” into the car to pick up the latest data set.
This is an architecture issue. This problem is not unique to OnStar. It is endemic in the mobile world where device-to-server communication over IP (IPv4) is device-independent, cheap, secure and reliable (as these things go), but slow, inefficient and backhaul route dependent; in contrast device-to-device connectivity via any of WiFi ad hoc, Bluetooth or NFC is substantially unused and unproven except as kids’ toy remote controls or as audio headset controllers. Peer-to-peer device-to-device still isn’t trusted-reliable enough to do device-to-device data movement where one cares about the data.
Car design & build cycles are 8 years + 10 years of useful lifetime. Phone & tablet design cycles are 2 years + 18 months of consumer lifespan; app development cycles are measured in “teens” of “sprints” which last two weeks (by definition). So any time now, GM could come out with an Android App that “is great.” (ahem, or they could open source the protocols and let the enthusiast community build such for them; like the other guys are doing with OpenXC).