Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

TeslaMS tools for telemetry data visualization

This site may earn commission on affiliate links.
Still not up to 2.9.x firmware but I did manage to find and fix some issues with the help of another user who has more up to date firmware.

I have published teslams 1.0.3 to both github and the npm repository.

Versions 1.0.3

fixes problem with charge state command not working in teslacmd with 2.9.x firmware cars
fixes problem with streaming not working with 2.9.x firmware cars
adds multi-vehicle support to teslacmd and the streaming apps.

To specify which vehicle to use for multi-car owners, add the flag "--vehicle 1" or alternatively "-O 1" for the second car (the default is "--vehicle 0").

If someone has two or more cars and is willing to help me test please PM me and let me know if "teslacmd -i --vehicle 1" works for you and prints the information for your second car.

If you want to use the streaming app to collect data on more than one car you will have to make sure to run two copies of streaming and give each car a unique mongodb database name so the data is not all mixed up in the same database. This allows you run specify the right database for visualize to display. For now it still only shows one car at a time.
 
Still not up to 2.9.x firmware but I did manage to find and fix some issues with the help of another user who has more up to date firmware.

I have published teslams 1.0.3 to both github and the npm repository.

Versions 1.0.3

fixes problem with charge state command not working in teslacmd with 2.9.x firmware cars
fixes problem with streaming not working with 2.9.x firmware cars
adds multi-vehicle support to teslacmd and the streaming apps.

To specify which vehicle to use for multi-car owners, add the flag "--vehicle 1" or alternatively "-O 1" for the second car (the default is "--vehicle 0").

If someone has two or more cars and is willing to help me test please PM me and let me know if "teslacmd -i --vehicle 1" works for you and prints the information for your second car.

If you want to use the streaming app to collect data on more than one car you will have to make sure to run two copies of streaming and give each car a unique mongodb database name so the data is not all mixed up in the same database. This allows you run specify the right database for visualize to display. For now it still only shows one car at a time.

Just in time (hopefully) for the Model X delivery! Thanks!
 
Found and fixed a problem with Google Maps not displaying properly in visualize.js. The API key from the previous author was no longer valid so I created a new one.

Also added multi-car option to restla.js and made it work more reliably.

Published as version 1.0.6
 
Found and fixed a problem with Google Maps not displaying properly in visualize.js. The API key from the previous author was no longer valid so I created a new one.

Also added multi-car option to restla.js and made it work more reliably.

Published as version 1.0.6

I think I had modified mine for my own API key, but thanks for that!

I'm still lobbying for better sleep state handling, so I miss less data at the beginning of drives. :)
 
I think I had modified mine for my own API key, but thanks for that!

I'm still lobbying for better sleep state handling, so I miss less data at the beginning of drives. :)

If you can think of a way to check if the car is driving without waking it up (or keeping it from sleeping) then I would be more than happy to implement the algorithm.
For now the only enhancement I can do is to turn off sleep mode during 6am to 11pm or whatever the new sleep schedule is for a car with energy saving turned off.
 
If you can think of a way to check if the car is driving without waking it up (or keeping it from sleeping) then I would be more than happy to implement the algorithm.
For now the only enhancement I can do is to turn off sleep mode during 6am to 11pm or whatever the new sleep schedule is for a car with energy saving turned off.

I started working through some of the scenarios and realized that any of them had deficiencies - if I suggested you wait for a period of 15 minutes of a null shift-state (to alleviate the case where I stop the car, run in the house to get something, then get back in the car within a couple of minutes), then you create a problem where the stops are just over 15 minutes in length. I'll give some more thought to it.

(At the moment my car is being stubborn and refuses to go to sleep, so I can't do any testing.)
 
It's not a big deal - I can modify the code, but it would be good I think to make it configurable and perhaps tighten it up from 30 minutes.

I added a -n (or --naptime) flag and put the code on github. streaming.js is the only file that changes. I left the default at 30 minutes but if you find that 20 or some other lower value is working fine I will change the default as well.

The code already detects if the car falls asleep faster than the configured nap time, and once the car does fall asleep the code switches to a mode where it checks every minute to see if the car has woken up again (presumably because its driving again). That way you don't end up loosing the full 30 minutes at the beginning of every trip.

The problematic situation is the one where you park the car and grab a coffee or something and then get back into the car and start driving before the car falls asleep. That's the situation that I find creates the most gaps in the telemetry and for which I know of no way to prevent other then turning off sleep mode altogether and just living with the extra vampire drain associated with continuously monitoring the car.
 
I basically had the same issue when I started working on Tesla log... Getting quite a lot of user now and some complaint about the vampire drain... So I'm back at trying to offer something that fool proof but I don't think there is any so far. Even worst, I can't even get my car to sleep right now, so pretty hard to test anything :) I was hoping that within the car listing, the state become offline pretty quickly it goes into sleep mode, but that doesn't seem to be the case... Till I figure out why my car wont sleep, not going to be able to find out much about it.
 
The problematic situation is the one where you park the car and grab a coffee or something and then get back into the car and start driving before the car falls asleep. That's the situation that I find creates the most gaps in the telemetry and for which I know of no way to prevent other then turning off sleep mode altogether and just living with the extra vampire drain associated with continuously monitoring the car.

Right. Initially, I thought "well, it's simple - you just ensure the car is idle for an hour before you start going into that 'nap' mode"... then I realized that you go to the store, take 62 minutes inside the store, then start driving, you'll lose a chunk of the time.

What do you think about geofencing the sleep? e.g., If I tell the tools that I typically park at 38.0500, -89.0500, then if the car is +/- .0001 (~700 feet), then allow for sleep checking, otherwise keep the polling going? Perhaps we could feed it an array of "home" locations in the config file where nap could take place, otherwise we want no sleep checking? If no array, keep existing behavior (sleep everywhere).

And, if the car is at home, wait for 10 minutes or so of inactivity before you start the nap timer - in case you pull the car out of the garage, run in the house to grab something, then take off again.

That might be the best thing to do.
 
Last edited:
I basically had the same issue when I started working on Tesla log... Getting quite a lot of user now and some complaint about the vampire drain... So I'm back at trying to offer something that fool proof but I don't think there is any so far. Even worst, I can't even get my car to sleep right now, so pretty hard to test anything :) I was hoping that within the car listing, the state become offline pretty quickly it goes into sleep mode, but that doesn't seem to be the case... Till I figure out why my car wont sleep, not going to be able to find out much about it.

I have a pretty good handle on what keeps a car from going to sleep. Basically any REST request other than one to /vehicles will keep it awake. In the /vehicles response you can see if the car in "online" or "offline" state but unfortunately you cannot tell if its driving or what its position is.

Right. Initially, I thought "well, it's simple - you just ensure the car is idle for an hour before you start going into that 'nap' mode"... then I realized that you go to the store, take 62 minutes inside the store, then start driving, you'll lose a chunk of the time.

What do you think about geofencing the sleep? e.g., If I tell the tools that I typically park at 38.0500, -89.0500, then if the car is +/- .0001 (~700 feet), then allow for sleep checking, otherwise keep the polling going? Perhaps we could feed it an array of "home" locations in the config file where nap could take place, otherwise we want no sleep checking? If no array, keep existing behavior (sleep everywhere).

And, if the car is at home, wait for 10 minutes or so of inactivity before you start the nap timer - in case you pull the car out of the garage, run in the house to grab something, then take off again.

That might be the best thing to do.

I like this idea. Let the car sleep at home but keep it awake everywhere else. Two locations would allow for sleep at home and at work (or other important location like a second home). Wish I could query the car or Tesla for the configured Home and Work locations it uses for the nav.
 
I have a pretty good handle on what keeps a car from going to sleep. Basically any REST request other than one to /vehicles will keep it awake. In the /vehicles response you can see if the car in "online" or "offline" state but unfortunately you cannot tell if its driving or what its position is.

That the things, it will not necessarily go offline. I've reset and changed my tesla password so no token are valid and the android app cannot get a new one. I've set the to go to sleep mode and to not always be connected. The car is not plugged in, and even after 1 hours, the car is still alive. I've tried with wifi off with same result. So it might work for some people, but not for me !

I'm thinking to only offer a long term offline mode support, so if left idle ~24 hours, then disable all logging until we see the car go offline (or keep checking every 12 hours).

I've got a user who I'm tracking that left his car unused for a while. He started with a 82% battery. 15day later he was at 50% (His minimum charge level), the car charged for 20 minute every two days to bring back from 45% to 50%.

So about 1.75kWh of energy per day just for monitoring. Tesla electronic is not very low power :) My Nexus 6P have 12Wh battery ! It can last 2 to 3 days in background activity check only. But let take it having the display, GPS activated and all the other sensors on it. Then it will last 3 hours. So that mean my Nexus 6P would need 96Wh ! That 0.096kWh ! You can power 18 Nexus 6P like that all day !

So 1.75kWh might sound big, and wonder why Tesla didn't do better... But when you check it out, that 72W of energy being use. Let say you travel at 100kph, so that come down to 0.72Wh per KM. That 1.2Wh/miles

Anyway, I'm rambling now...
 
That the things, it will not necessarily go offline. I've reset and changed my tesla password so no token are valid and the android app cannot get a new one. I've set the to go to sleep mode and to not always be connected. The car is not plugged in, and even after 1 hours, the car is still alive. I've tried with wifi off with same result. So it might work for some people, but not for me !

That's all you can control. Tesla does keep the car awake to do software downloads, log downloads, etc., and I don't think anyone has ever established a pattern for it. I went to the store last night and while outside in the parking lot and no app open, it never went to sleep. You can't control that, and it makes programming for it difficult, but you can't worry about it too much.

As for the Nexus comparison, you can't easily make that comparison. When the car is awake, it does more than just monitoring. It's just that your monitoring is keeping it awake.
 
As for the Nexus comparison, you can't easily make that comparison. When the car is awake, it does more than just monitoring. It's just that your monitoring is keeping it awake.

The calc I've made was that the Nexus 6P only lasted 3 hours,... But in reality, with it screen off, and in standby mode, it can last, 2 to 3 days, and let say 1 full day of constant background data check... There isn't much the car can do than just do monitoring when the car is off :) Especially over a period of 15 days. The things, it Tesla just didn't bother taking the time to use system and components that are low power... Most of that system haven't change since 2012 as well, and they were probably designed and dating back from 2010. Again, in general it not a big deal, since it use less than 1Wh/km of driving.

One of my grind at Tesla is that they haven't put a AC2DC 12 volt charger in their car so when the car is plugged in and the charge is completed, the 12volt battery is not draining the 400volt pack ! This wouldn't be too bad if I could control the Charging AMP via the API, so I could change the AMP so the charge take the whole night
 
That the things, it will not necessarily go offline. I've reset and changed my tesla password so no token are valid and the android app cannot get a new one. I've set the to go to sleep mode and to not always be connected. The car is not plugged in, and even after 1 hours, the car is still alive. I've tried with wifi off with same result. So it might work for some people, but not for me !

I'm thinking to only offer a long term offline mode support, so if left idle ~24 hours, then disable all logging until we see the car go offline (or keep checking every 12 hours).

I've got a user who I'm tracking that left his car unused for a while. He started with a 82% battery. 15day later he was at 50% (His minimum charge level), the car charged for 20 minute every two days to bring back from 45% to 50%.

So about 1.75kWh of energy per day just for monitoring. Tesla electronic is not very low power :) My Nexus 6P have 12Wh battery ! It can last 2 to 3 days in background activity check only. But let take it having the display, GPS activated and all the other sensors on it. Then it will last 3 hours. So that mean my Nexus 6P would need 96Wh ! That 0.096kWh ! You can power 18 Nexus 6P like that all day !

So 1.75kWh might sound big, and wonder why Tesla didn't do better... But when you check it out, that 72W of energy being use. Let say you travel at 100kph, so that come down to 0.72Wh per KM. That 1.2Wh/miles

Anyway, I'm rambling now...

Unfortunately changing your Tesla login and password does not invalidate any existing tokens that were issued under the old login/password. Those remain valid for 90 days so there could be something using them still. I just don't know a way of checking. Also make sure your car's web browser is not on a web site that auto-refreshes like the tesla waze site or some sports, news sites.
Other than that I can;t think of anything else that would be keeping your car from sleeping other then perhaps Tesla themselves doing extra monitoring or a bug in your particular version of firmware.

- - - Updated - - -

Hey folks, all this talk about Nexus phones gave me an idea. How about a TeslaMS companion app that detects when your Bluetooth is connected to the Tesla, or does the geo-fencing mentioned earlier, and triggers the streaming logger to go into (or give up on) nap time. I know for my android phone this can be done easily with Tasker. The only trick would be how to send the signal from the phone to an instance of streaming.js running behind a firewall somewhere. I could maybe use a public messaging service as an intermediary so the phone and the streaming app don't need to talk to one another directly. I will think about this more and maybe prototype something with Tasker.
 
Unfortunately changing your Tesla login and password does not invalidate any existing tokens that were issued under the old login/password.

Every single time I changed my tesla password to something different than what it was before, my key got revoked.

- - - Updated - - -

Hey folks, all this talk about Nexus phones gave me an idea. How about a TeslaMS companion app that detects when your Bluetooth is connected to the Tesla, or does the geo-fencing mentioned earlier, and triggers the streaming logger to go into (or give up on) nap time. I know for my android phone this can be done easily with Tasker. The only trick would be how to send the signal from the phone to an instance of streaming.js running behind a firewall somewhere. I could maybe use a public messaging service as an intermediary so the phone and the streaming app don't need to talk to one another directly. I will think about this more and maybe prototype something with Tasker.

You could do that, but then you got to start maintaining a piece of software on people phones :) And then you got complain from apple user, and windows user... :) Also you need all your Tesla user to have that with them.

I was thinking to do it so you can have driving stats different per driver. Also, I was thinking about doing an android app only so people can keep their tesla password on it, and if the key is about to be expired, or is expired, the phone can do the key request to tesla and send it to me.

The problem is if I start going that, then apple user will feel left out :)