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.
Looking forward to it. I've lost many a data because of nap mode and although I know I could turn it off I don't want to to sacrifice vampire loss in this cold chicago winter...

Sorry folks. This is taking me longer to complete than I would like simply because of life getting in the way ;-)

I still have TODO:
- Time of Day Nap scheduling for streaming.js
- Nap mode support when streaming output to a file (rather than just mongodb)
- patches for supporting reverse proxy for visualize.js
- Open Source my pebble smartwatch app "SimpleTesla"
 
How can I set it for the command line tools to display speed and charge in kilometers instead of miles?
teslacmd - g does output that the car uses kilometers!

The tools just display what is returned by Tesla, which is a mix of both metric and imperial units. For example, the climate commands always return Celsius.

It should be very simple to pipe the output through an awk script or something to convert before printing. What OS and command shell are you using? Which charge measurement do you want?
 
It should be very simple to pipe the output through an awk script or something to convert before printing. What OS and command shell are you using? Which charge measurement do you want?
That still makes me believe it could be an option on the command line for this software ;). Instead of creating a hack with a pipe through an awk script... I use Debian 6.0. I use bash, and I'd like kilometers. And I'm not good with sed or awk ;).

- - - Updated - - -

I have a problem with visualize.js. It complains that:
Unable to load /home/<user>/.teslams/config.json; web server authentication turned off
didn't find 'visualize' property in config file, authentication turned off

But the file is there at this location and looks like:
{
"username": "****",
"password": "****"
"visualize":
[
{ "id": 1, "username": "****", "password": "****" },
]
}
 
That still makes me believe it could be an option on the command line for this software ;). Instead of creating a hack with a pipe through an awk script... I use Debian 6.0. I use bash, and I'd like kilometers. And I'm not good with sed or awk ;).

How is your JavaScript? Always happy to accept pull requests on GitHub ;-)
I do have a couple sample apps in TeslaMS called 'chargebar' a 'climatemon' which do check the GUI settings and display the range (or temperature) in the selected units of measure. Shouldn't be too hard to reuse that code over to teslacmd.js and expand it to the speed measurement as well.

I have a problem with visualize.js. It complains that:
Unable to load /home/<user>/.teslams/config.json; web server authentication turned off
didn't find 'visualize' property in config file, authentication turned off

But the file is there at this location and looks like:
{
"username": "****",
"password": "****"
"visualize":
[
{ "id": 1, "username": "****", "password": "****" },
]
}

I didn't write this piece and a don't use it personally. Is this something that just recently stopped working (perhaps a version issue) or have you never been able to get it work?

--update--
Looks like there may be a missing comma between the end of "password": "****" line and the start of
the "visualize" line that makes this invalid JSON.
 
Last edited:
I didn't write this piece and a don't use it personally. Is this something that just recently stopped working (perhaps a version issue) or have you never been able to get it work?

--update--
Looks like there may be a missing comma between the end of "password": "****" line and the start of
the "visualize" line that makes this invalid JSON.
I wrote that code and your analysis is correct. The error reporting of the config file code is surely lacking, but once you give it a correct JSON file it should work.
 
Assuming the car is not asleep, this will print the range in kilometers

Code:
teslacmd -c | grep 'battery_range:' | grep -v '_battery_range' | cut -d : -f 2 | sed 's/,//' | awk '{printf "range = %4.2f km\n",$1*1.609344}'

I will put a --metric flag on the TODO list for teslacmd.js. I would have to leave the existing fieldnames and values for backward compatibility and just add new field names for "metric_battery_range"
 
just published version 0.9.4 which adds a --metric (or -M) flag to teslacmd for adding metric fields where tesla has hardcoded miles instead of kilometers.

"teslacmd -cM" will now include three new field: "metric_battery_range", "metric_est_battery_range", and "metric_ideal_battery_range"
"teslacmd -dM" will now include one new field called "metric_speed".

Also added a "teslacmd --version" flag to print the current version of teslams that is installed on the system.
 
It's been I while but I finally have something new to share.

It's a visual tool for building logic using the Tesla REST API commands. The framework is based on an open source Internet of Things tool called Node-RED. You can install Node-Red using "npm install node-red" or from github (node-red/node-red). I have made a set of TeslaMS "plug-ins" available using "npm install node-red-contrib-teslams" or from github (hjespers/node-red-contrib-teslams).

Once you have node-red running you can drag and drop items and connect them together to make very useful flows. Node-Red comes with built in support for reading and writing to files, mongodb, mysql, sending email, tweets, instant messages, calling out to REST services on the internet, or controlling devices such as an Arduino or Raspberry Pi. There is a growing number of useful third party user contributed plugins (called "nodes") for Node-Red.

I have included an example flow that polls for drive state data and appends it to CSV file.

Screen_Shot.png


Please start with the documentation and getting started tutorial provided with Node-Red.

There is a short demo video of Node-Red (without the TeslaMS nodes) on YouTube.

My hope is that this kind of tool with enable non-programmers to creatively built new Tesla applications with the building blocks provided by the Node-red community.
 
Last edited:
Hi. I first want to congratulate Hans and Dirk on their jobs. This is really a nice way of tracking my data.

However, in the visualise stats, the Maximum Charger Power seems not to take into account 3 phase charging.

I charge at about 16kW at home, while the power line is at 21kW on the graph, but the mouseover display shows 4.9kW.
The energie block on the first chart however seems to display it correct.
Max_Charger_power_miscalculation.png
Max_Charger_power_miscalculation_2.png


I'm interested in the way how you transform your MongoDB data into these charts. Is there a possiblity to shed some light on that?
 
I'm interested in the way how you transform your MongoDB data into these charts. Is there a possiblity to shed some light on that?

Dirk did pretty much all of the visualize stuff so I can only point you to the code without having the level of understanding that the original author would have.

The chart data is retrieved using jquery and there are some conversions of units (metric vs imperial) as well as multi-lingual support (English and German) in the javascript libraries.
The main energy chart page is driven from the file ~teslams/examples/visualize/energy.html. This parses parameters in the url to tell if its supposed to display metric or german or whatever and then uses the conversion scripts in ~teslams/examples/visualize/otherfiles/lib.js to get the right values and language.

The first chart (bottom one in your post) uses data collected using the streaming API and the other chart (top one in your post) used data collected by polling the REST API. Unfortunately Tesla does not have consistency in the data they return from various sources. After all, this is just for their own mobile app so it's not designed to be for third party developers.

The streaming API reports power pulled from the battery pack while driving, or put into the battery pack while charging or under regen braking. It only reports power in kW, not separate values for Voltage and Current. The point of collection for this data in somewhere internal to the car after the onboard charger (i.e possibly DC power from the battery pack or some place between the battery and the electric motor). Since the battery and motor are the same worldwide, these numbers are the same for all cars anywhere in the world.

The REST API reports AC power, going into the onboard charger, which differs throughout the world. The REST API does report separate values for Voltage and Current and I think the Power value in the chart is calculated. In North America it is sufficient to just multiply the voltage by the current to get the power (P = V*I). In cars with three phase chargers Tesla under reports the current by a third. I'm not an electrician but I suppose its just the current represented in one of the three phases. I'm pretty sure that ALL metric countries do not use 3-phase power (Canada for example does not) so it's not sufficient to just key off the existing parameter for metric. This one chart need to be updated to take another parameter to indicate the presence of a three phase charger and multiply the power value by 3 when the REST API is the data source. The all the other navigation menus that call this HTML page need to be updated to supply the proper URL will this parameter.

If anyone is up to the task of tackling the coding I would be happy to help them out but I do not have a car with a 3-phase charger on board nor do I have a 3-phase power source for testing.
 
Last edited:
Dirk did pretty much all of the visualize stuff so I can only point you to the code without having the level of understanding that the original author would have.

The chart data is retrieved using jquery and there are some conversions of units (metric vs imperial) as well as multi-lingual support (English and German) in the javascript libraries.
The main energy chart page is driven from the file ~teslams/examples/visualize/energy.html. This parses parameters in the url to tell if its supposed to display metric or german or whatever and then uses the conversion scripts in ~teslams/examples/visualize/otherfiles/lib.js to get the right values and language.

The first chart (bottom one in your post) uses data collected using the streaming API and the other chart (top one in your post) used data collected by polling the REST API. Unfortunately Tesla does not have consistency in the data they return from various sources. After all, this is just for their own mobile app so it's not designed to be for third party developers.

The streaming API reports power pulled from the battery pack while driving, or put into the battery pack while charging or under regen braking. It only reports power in kW, not separate values for Voltage and Current. The point of collection for this data in somewhere internal to the car after the onboard charger (i.e possibly DC power from the battery pack or some place between the battery and the electric motor). Since the battery and motor are the same worldwide, these numbers are the same for all cars anywhere in the world.

The REST API reports AC power, going into the onboard charger, which differs throughout the world. The REST API does report separate values for Voltage and Current and I think the Power value in the chart is calculated. In North America it is sufficient to just multiply the voltage by the current to get the power (P = V*I). In cars with three phase chargers Tesla under reports the current by a third. I'm not an electrician but I suppose its just the current represented in one of the three phases. I'm pretty sure that ALL metric countries do not use 3-phase power (Canada for example does not) so it's not sufficient to just key off the existing parameter for metric. This one chart need to be updated to take another parameter to indicate the presence of a three phase charger and multiply the power value by 3 when the REST API is the data source. The all the other navigation menus that call this HTML page need to be updated to supply the proper URL will this parameter.

If anyone is up to the task of tackling the coding I would be happy to help them out but I do not have a car with a 3-phase charger on board nor do I have a 3-phase power source for testing.
Thanks for the info Hans. I'll try to contribute something to this project.
 
I put up TeslaMS 1.0 on github and the npm repository. This release uses the new "6.0" REST API and folds in a few enhancements to visualize.js thanks to Chris Crewdson. There might still be a few items to debug but it's very backward compatible and the example apps all work for me. I am looking for volunteers to try it out for compatibility as well as access (since I know some owners are experiencing a lack of access to the REST API from most third party apps). There _may_ be issues for those outside the US so if this breaks things for you and you are in Europe then contact me and we can try and set the "locale" correctly to make things work for you.

If you use the teslams functions to build your own apps, the biggest change to watch out for is that the "id" of the vehicle is now an integer that is too big for JavaScript to handle natively. Strange but true. I used the json-bigint module to handle this and convert the "id" field into a string in all the JSON returned by teslams functions with the exception of teslams.all() which was added explicitly to return the raw JSON as sent by Tesla.
 
Last edited:
I put up TeslaMS 1.0 on github and the npm repository. This release uses the new "6.0" REST API and folds in a few enhancements to visualize.js thanks to Chris Crewdson. There might still be a few items to debug but it's very backward compatible and the example apps all work for me. I am looking for volunteers to try it out for compatibility as well as access (since I know some owners are experiencing a lack of access to the REST API from most third party apps). There _may_ be issues for those outside the US so if this breaks things for you and you are in Europe then contact me and we can try and set the "locale" correctly to make things work for you.

If you use the teslams functions to build your own apps, the biggest change to watch out for is that the "id" of the vehicle is now an integer that is too big for JavaScript to handle natively. Strange but true. I used the json-bigint module to handle this and convert the "id" field into a string in all the JSON returned by teslams functions with the exception of teslams.all() which was added explicitly to return the raw JSON as sent by Tesla.

Works nice with p85d on new servers against 6.1.113. One issue I found. Could not get information for charging graph - ie. started charging car and no information was being recorded into MondoDB. Car tracking worked well (up until this MBP decided to go to sleep that is ;-)).. Playback of truncated data seems good.

Let me know if you need additional info / help.

btw - First time using these. Very useful. Thank you all for your efforts here.

Cheers, Mike
 
Lately, the recording of charging voltage/current/power has been unreliable. Here's an example over the past two weeks - we plug in and charge every single day, but you can see plenty of occurrences where we've driven but the data hasn't saved.

Today, in particular, we drove the car on 3 separate trips, charging 3 different times, and it wasn't captured. Anything that has changed here?

See the graph below -- the day lines line up:

Capture.PNG
 
Lately, the recording of charging voltage/current/power has been unreliable. Here's an example over the past two weeks - we plug in and charge every single day, but you can see plenty of occurrences where we've driven but the data hasn't saved.

Today, in particular, we drove the car on 3 separate trips, charging 3 different times, and it wasn't captured. Anything that has changed here?

See the graph below -- the day lines line up:

View attachment 78502

Most likely this is Tesla throttling the requests for charge data via the REST API. The streaming data doesn't get throttled but the REST data does, hence the difference you see when comparing the two data sources.