Model S REST API

[jpasqua]

5.8 vs. Heading

I updated yesterday from 4.5 to 5.8 and I've noticed one difference (so far) in the behavior of the APIs. If I wake the car from sleep mode and then interrogate the heading via the streaming api, it seems to have forgotten the last heading value. Instead I get a seemingly random value. The heading field from the drive_state seems to be correct.

Is anyone else seeing this?

 

[hans]

I updated yesterday from 4.5 to 5.8 and I've noticed one difference (so far) in the behavior of the APIs. If I wake the car from sleep mode and then interrogate the heading via the streaming api, it seems to have forgotten the last heading value. Instead I get a seemingly random value. The heading field from the drive_state seems to be correct.

Is anyone else seeing this?

That could be a sign that this is a value derived from previous position values and not a direct compass measurement. When the car sleeps, it likely forgets the previous dead reckoning data samples. Is the streaming value for "est_heading" any better than "heading"?

 

[jpasqua]

That could be a sign that this is a value derived from previous position values and not a direct compass measurement. When the car sleeps, it likely forgets the previous dead reckoning data samples. Is the streaming value for "est_heading" any better than "heading"?

I went out and got into the car to see whether putting it into drive would force it to take a new reading. I was surprised to find that the vehicle heading was wrong on the in-car nav display as well. It was the same value I was seeing in my App. It did not correct itself until I backed out of my driveway and drove about 20 feet. In fact, it showed the car going sideways until it got its act together. I parked and went back to my app and of course it was then showing the proper heading.

To recap, after sleep mode I get an incorrect heading value from set_heading in the streaming API. I get a correct value in the heading field of the drive_state query.

It looks like this is something Tesla's going to need to fix since it also impacts their in-car system. I might be able to work around it by doing something like:

• Get the drive_state heading and est_heading from the streaming api
• if they are different, give preference to the drive_state value
• Continue to prefer the drive_state value until there is a change in the est_heading value returned from the streaming API. This presumably indicates that it is starting to take readings.

 

[hans]

I went out and got into the car to see whether putting it into drive would force it to take a new reading. I was surprised to find that the vehicle heading was wrong on the in-car nav display as well. It was the same value I was seeing in my App. It did not correct itself until I backed out of my driveway and drove about 20 feet. In fact, it showed the car going sideways until it got its act together. I parked and went back to my app and of course it was then showing the proper heading.

To recap, after sleep mode I get an incorrect heading value from set_heading in the streaming API. I get a correct value in the heading field of the drive_state query.

It looks like this is something Tesla's going to need to fix since it also impacts their in-car system. I might be able to work around it by doing something like:

• Get the drive_state heading and est_heading from the streaming api
• if they are different, give preference to the drive_state value
• Continue to prefer the drive_state value until there is a change in the est_heading value returned from the streaming API. This presumably indicates that it is starting to take readings.

I am not sure I understand correctly. The streaming API will return BOTH est_heading and heading. Are you seeing that they are both wrong and different from the REST drive_state value?

 

[brianman]

Moving from 5.6 (1.45.45) to 5.8 (1.49.22), no observed differences in my log files in the fields (name/value pairs) or format (streaming) of the query methods in the REST API.

- - - Updated - - -

I went looking back through my logs. I found the first DAT file that recognized 5.6 (1.45.45) and I looked at the previous log. Why look at the previous log? The way my logger works is that it interrogates all the non-streaming data and then streams until the token expires; after the token expires, it begins a new log file and starts the process again. So looking at the previous log file to the one that reports the new version shows me the streaming transition point.

So I looked at the log that contains 4.5 and the initial streaming data for 5.6 looking to see if I could see a "Rated Range" or "SOC" change across the transition (they changed the algorithm right?).

The only interesting transition point in the file:

1383165239969,,18429.1,82,67,89,47.626050,-122.161845,0,,196,160

1383165480838,,18429.1,82,[U]83[/U],89,47.626050,-122.161845,0,,196,[U]158[/U]

‎1‎:‎33‎:‎59‎ ‎PM -> ‎1‎:‎38‎:‎00‎ ‎PM
elevation increase 67 -> 83 (raised on lift, presumably)
est_range decrease 160- > 158 (without any delta in the odometer or GPS coords)


A 4 minute update from 4.5 to 5.6? That's kind of remarkable if accurate.

- - - Updated - - -

I also decided to look at the 5.6 -> 5.8 transition (this time in my garage instead of at the service center). Unfortunately, the transition point isn't as clear cut (I think my streaming token timed out during the update).

 

[jpasqua]

I am not sure I understand correctly. The streaming API will return BOTH est_heading and heading. Are you seeing that they are both wrong and different from the REST drive_state value?

Hmm. I thought that the list of fields available for return by the streaming API are: odometer, speed, soc, elevation, est_heading, est_lat, est_lng, power, shift_state, range. I just looked at teslams to compare. It seems to have the same list:

exports.stream_columns = [ 'speed'
                          , 'odometer'
                          , 'soc'
                          , 'elevation'
                          , 'est_heading'
                          , 'est_lat'
                          , 'est_lng'
                          , 'power'
                          , 'shift_state'
                          , 'range'
                          ];

I don't see heading (in addition to est_heading) in the list. What am I missing?

UPDATE: Upon further testing, it appears that drive_state/heading may return different faulty values under the same circumstances

 

[hans]

Hmm. I thought that the list of fields available for return by the streaming API are: odometer, speed, soc, elevation, est_heading, est_lat, est_lng, power, shift_state, range. I just looked at teslams to compare. It seems to have the same list:

exports.stream_columns = [ 'speed'
                          , 'odometer'
                          , 'soc'
                          , 'elevation'
                          , 'est_heading'
                          , 'est_lat'
                          , 'est_lng'
                          , 'power'
                          , 'shift_state'
                          , 'range'
                          ];

I don't see heading (in addition to est_heading) in the list. What am I missing?

UPDATE: Upon further testing, it appears that drive_state/heading may return different faulty values under the same circumstances

I should update that code because there is definitely another field available called "heading". I remember playing with it and seeing that "heading" and "est_heading" don't always match. Try it, you will see. I think that heading values come from a compass (magnetometer) and est_heading is derived from historical position data.

 

[brianman]

streaming API ...
odometer, speed, soc, elevation, est_heading, est_lat, est_lng, power, shift_state, range.

Here's my list:

speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power,shift_state,range,est_range

 

[jpasqua]

I should update that code because there is definitely another field available called "heading". I remember playing with it and seeing that "heading" and "est_heading" don't always match. Try it, you will see. I think that heading values come from a compass (magnetometer) and est_heading is derived from historical position data.

Cool. I'll give it a try. Thanks.

 

[hans]

All the ones I know:

speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power,shift_state,range,est_range,heading

 

[jpasqua]

Thanks guys. I've added both est_range and heading to my list of requested values and I'm getting data for both. I will put a comment on the "Tesla Model S Remote Access Protocol" Google Doc so that heading gets added (I just noticed that est_range is already there).

I'm finding that the heading value is correct when the est_heading is not (off by over 20 degrees). I'll start using heading instead of est_heading. Is there a time when it would be better to use est_heading? Perhaps when the car is in motion?

The difference between range and est_range was less than 1 mile (which was less than 1% for my values).

 

[hans]

Thanks guys. I've added both est_range and heading to my list of requested values and I'm getting data for both. I will put a comment on the "Tesla Model S Remote Access Protocol" Google Doc so that these get added.

I'm finding that the heading value is correct when the est_heading is not (off by over 20 degrees). I'll start using heading instead of est_heading. Is there a time when it would be better to use est_heading? Perhaps when the car is in motion?

The difference between range and est_range was less than 1 mile (which was less than 1% for my values).

Values for est_range depend on prior driving efficiency. It will vary much more than 1% from 'range' if you drive more aggressively .

 

[jpasqua]

Values for est_range depend on prior driving efficiency. It will vary much more than 1% from 'range' if you drive more aggressively .

Do you happen to know whether est_range from the streaming api corresponds precisely to any of battery_range, est_battery_range, or ideal_battery_range from charge_state, or is it yet another range estimate? Thanks.

 

[brianman]

Do you happen to know whether est_range from the streaming api corresponds precisely to any of battery_range, est_battery_range, or ideal_battery_range from charge_state, or is it yet another range estimate?

command/charge_state	streaming
battery_level 90	soc 90
battery_range 217.7	range 218
est_battery_range 173.6	est_range 174
ideal_battery_range 250.57

 

[markb1]

Hey folks,

I was wondering how others that poll with frequency are dealing with sleep mode? My understanding is that if you query anything other than /login and /vehicles that counts as activity and will keep the car awake.

I poll every minute. My poller will back off if the car is already asleep by checking that vehicle state is "online" before getting more detail. That should prevent the poller from waking up a car that is already asleep, but since I normally poll detail every minute it never goes to sleep. I was considering backing off to a 20 minute poll if I see the car is parked and not charging, waiting for sleep mode, then resume one minute polls, but then I could miss something if I park somewhere for less than 20 minutes.

Just curious of other peoples approach?

I just upgraded from 4.5 to 5.8, so I've been working on figuring this out. I'm polling every 5 minutes. If the shift state is empty, I stop polling for 30 minutes. This gives the car a chance to go to sleep. I don't know what the minimum time is, but 30 minutes works. When I poll and see the car state is "asleep", I don't query anything other than the vehicle list, but do continue to poll every 5 minutes. This seems to work so far.

 

[timdorr]

Just curious of other peoples approach?

I'm currently polling in a loop where I wake_up the car to get its streaming token and then connect to the streaming API. If the streaming API times out or closes it's connection, it loops back around.

This is very inefficient and I plan on fixing it up so it doesn't try to wake the car constantly. If the car isn't awake, then there isn't anything coming over the streaming API anyways.

 

[ahimberg]

I noticed with the 5.8 update (was on 5.6) that now when I pre-heat the car in the morning, the resT api is reporting a/c is on where it didn't before. In the car i'm set to 'auto' but it now highlights a/c on instead of off while heating, maybe someone changed a default value somewhere, or they decided to include some a/c on to reduce fogging up inside?

 

[moviemaker2000]

I have been using the streaming.js with the -z switch now that my car has updated to 5.8. With that switch activated it correctly prevents waking an already sleeping car, however once the car is driven it will no longer enter sleep mode until I stop streaming.js. Is this the anticipated behavior of the -z switch or should it let the car go back to sleep once woken up?

 

[hans]

I have been using the streaming.js with the -z switch now that my car has updated to 5.8. With that switch activated it correctly prevents waking an already sleeping car, however once the car is driven it will no longer enter sleep mode until I stop streaming.js. Is this the anticipated behavior of the -z switch or should it let the car go back to sleep once woken up?

Yes this is the expected behavior. I just got upgraded from 4.5 two days ago and I'm traveling so it will take a little more time before I can figure out how best to allow sleep to properly set it on an online car.

 

[J in MN]

Did anyone else see a discontinuity in the charge_state.battery_level value during the first charge after FW v5.8?
timestamp battery_level battery_range
2013-11-17 06:46 44 76.49
2013-11-17 06:47 44 76.84
2013-11-17 06:48 44 77.19
2013-11-17 06:49 44 77.19
2013-11-17 06:50 44 77.89
2013-11-17 06:51 44 78.25
2013-11-17 06:52 49 78.6
2013-11-17 06:53 49 78.95
2013-11-17 06:54 49 79.3

This has resulted in a persistent reduction of 14 miles / 20 km in the displayed rated range for the same SOC compared to FW v4.5.