-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
TeslaMS tools for telemetry data visualization
- Thread starter dirkhh
- Start date
-
- Tags
- Model S User Interface
hans
P631
Just published version 0.8.0 with sleep mode support for streaming.js. Just use the --zzz option to enable sleep checking mode and the streaming data collector will pause to allow the car to fall asleep and avoid waking it up once it has done so.
hans
P631
I found a race condition in the sleep mode code in streaming.js that can cause too many requests (and possibly getting your IP blocked by Tesla). I think I have fixed it. Even though I am still testing the fixed version 0.8.2 I thought it would be better to publish the changes before anyone else experienced the problem.
hans
P631
Not yet Aaron, sorry. I have been on the road for work so I haven't had the time or the car.
Thank you guys so much for your work on TeslaMS. It truly unleashes some of the promise and potential of the software and data driven Model S.
I have been tracking my S85 for about a month or so now on my Mac Pro system. Ideally, I'd like to be able to run this on something like a Raspberry Pi or other small type of system that could just be running as an appliance for this purpose. I saw comments earlier in this thread about a raspberry pi not being powerful enough to serve up several months worth of data in a reasonable time. I also saw that (I think it was dirkh) working on a caching mechanism in the mongo db to ease some of query slowdown. Just wanted to check on when you may be working on that. No pressure, just curious.
Do you have any other suggestions on possible appliance type solutions? I thought about a hosted solution, but that seems a bit overkill and expensive since I am assuming you would need a custom server (VM or hardware based).
I wish I had the skills and time to help on this project, myself.
Thanks again for all of the incredible work you have done for the Tesla community.
I have been tracking my S85 for about a month or so now on my Mac Pro system. Ideally, I'd like to be able to run this on something like a Raspberry Pi or other small type of system that could just be running as an appliance for this purpose. I saw comments earlier in this thread about a raspberry pi not being powerful enough to serve up several months worth of data in a reasonable time. I also saw that (I think it was dirkh) working on a caching mechanism in the mongo db to ease some of query slowdown. Just wanted to check on when you may be working on that. No pressure, just curious.
Do you have any other suggestions on possible appliance type solutions? I thought about a hosted solution, but that seems a bit overkill and expensive since I am assuming you would need a custom server (VM or hardware based).
I wish I had the skills and time to help on this project, myself.
Thanks again for all of the incredible work you have done for the Tesla community.
Berkut
Member
Excellent news!
Please tell us how you did it.
I have a ReadyNAS and would love to put teslams on it.
IIRC, I built node on the ReadyNAS from source, but ran into issues with compiler features trying to get mongo built, so I had to use a precompiled binary, which worked flawlessly. Once node is up and running, npm can install teslams and your can try "forever" to keep streaming and visualize running.
I have two Raspberry Pis sitting at home, waiting for me to have the time to get all this up and running. I am hoping to simply release an image that people can use and plug those little babies into their home network.
But real work and another open source project that I am maintaining and that's about to have a major release are sucking my time away. Oh, and travel (I'm away from my Model S again...)
hans
P631
I wrote the original streaming.js to log telemetry to an output file but it was dirkhh that added MongoDB support to streaming.js and *all* of the visualize.js code to the project. I want to thank Dirk for his massive contributions to this codebase. His efforts turned a small development framework and some command line tools into a full blown GUI application that I and others use every day. Dirk, I appreciate the huge amount of effort you put into this thing we call "teslams" and you should be very proud of what you built.
Unfortunately Dirk is unable to continue contributing and maintaining code for this project. I'm not going to discuss all his reasons other than to say I understand completely and we will do the best we can to maintain and improve on his contributions.
I understand that some people have experienced issues with streaming.js and/or visualize.js. I can help as best that I can, but it will take me some time to truly understand the visualize code. If anyone is interested in helping to track down any bugs or adding enhancements, please PM me or send me pull requests on github with your improvements.
If you are unsure if a problem with the data collection or the data visualization then the first thing you want to check is if the data is in your MongoDB database.
$ mongo
> use tesla
switched to db tesla
> show collections
system.indexes
tesla_aux
tesla_stream
trip_data
> db.tesla_stream.count()
808538
> db.tesla_stream.find()
...all records in the tesla_stream collection, use "it" to iterate over the full set of results...
> db.tesla_stream.find( { ts : { $gt : 1387152133617 } })
...all streaming data records with a timestamp greater than 1387152133617
> db.tesla_stream.find( { ts : { $gt : 1387152133617 }, { $lt : 1387152500601 }} )
...all streaming data records with a timestamp between 1387152133617 and 1387152500601
> db.tesla_stream.find( { ts : { $gt : new Date("Dec 14 12:00:00 PST 2013").getTime(), $lt : new Date("Dec 15 12:00:00 PST 2013").getTime() }} )
..similar to above but with human readable date/timestamps
> db.tesla_aux.find( { chargeState.battery_level : { $gt : 98} } )
..all tesla_aux records of type 'chargeState' with battery_level field greater than 98
If you need help with timestamp conversion to/from something humanly readable try http://www.epochconverter.com
I think I have streaming.js working well now with the new sleep mode. I understand the data collection piece inside and out. Same with the teslams javascript library, teslacmd, chargebar, climatebar, restla, and other command line tools.
Unfortunately Dirk is unable to continue contributing and maintaining code for this project. I'm not going to discuss all his reasons other than to say I understand completely and we will do the best we can to maintain and improve on his contributions.
I understand that some people have experienced issues with streaming.js and/or visualize.js. I can help as best that I can, but it will take me some time to truly understand the visualize code. If anyone is interested in helping to track down any bugs or adding enhancements, please PM me or send me pull requests on github with your improvements.
If you are unsure if a problem with the data collection or the data visualization then the first thing you want to check is if the data is in your MongoDB database.
$ mongo
> use tesla
switched to db tesla
> show collections
system.indexes
tesla_aux
tesla_stream
trip_data
> db.tesla_stream.count()
808538
> db.tesla_stream.find()
...all records in the tesla_stream collection, use "it" to iterate over the full set of results...
> db.tesla_stream.find( { ts : { $gt : 1387152133617 } })
...all streaming data records with a timestamp greater than 1387152133617
> db.tesla_stream.find( { ts : { $gt : 1387152133617 }, { $lt : 1387152500601 }} )
...all streaming data records with a timestamp between 1387152133617 and 1387152500601
> db.tesla_stream.find( { ts : { $gt : new Date("Dec 14 12:00:00 PST 2013").getTime(), $lt : new Date("Dec 15 12:00:00 PST 2013").getTime() }} )
..similar to above but with human readable date/timestamps
> db.tesla_aux.find( { chargeState.battery_level : { $gt : 98} } )
..all tesla_aux records of type 'chargeState' with battery_level field greater than 98
If you need help with timestamp conversion to/from something humanly readable try http://www.epochconverter.com
I think I have streaming.js working well now with the new sleep mode. I understand the data collection piece inside and out. Same with the teslams javascript library, teslacmd, chargebar, climatebar, restla, and other command line tools.
Last edited:
Hans / Dirk, awesome work on this package. Been using it for about 3 weeks now running both on a Ubuntu VPS and home windows machine.
I'm running into a strange problem: big chunks of my tracking data disappear eventhough my streaming.js is running 24/7 (albeit with the sleep mode -z enabled).
Symptoms:
- When looking at the energy data or map, chunks of my route will be missing (I checked in the original mongo data and there are no entries for that timeperiod in the db)
- Example of a route with about 20 minutes of data missing in the middle of the route (note I'm driving from the center out to the ring road, but the track suddenly jumps to the ring road):
Eliminated possible causes / performed tests:
- problem occurs both with 0.8.1 and 0.8.4 versions
- problem occurs both on windows and Ubuntu instances. Interestingly, sometimes chunk is missing in either one (changes which one), sometimes in both.
- chunks are not only missing at beginning of trip (possible sleep mode delay) but also mid trip so unlikely car is truly asleep
- chunks are also missing when 3G connection is fine: they show up in the other instance and by coincidence in some cases I was checking things online in the exact period the data is missing.
To do - but hesitant:
- Starting tonight I'm going to run the streaming.js without sleep mode to see if I have the same problem. This is no fix however as it will likely increase the vampire draw of my car and points to an issue with the sleepmode.
Is anyone else experiencing these problems when running in sleep mode? Does anyone have an idea on how to fix this or diagnose it further?
Thanks for any help!
I'm running into a strange problem: big chunks of my tracking data disappear eventhough my streaming.js is running 24/7 (albeit with the sleep mode -z enabled).
Symptoms:
- When looking at the energy data or map, chunks of my route will be missing (I checked in the original mongo data and there are no entries for that timeperiod in the db)
- Example of a route with about 20 minutes of data missing in the middle of the route (note I'm driving from the center out to the ring road, but the track suddenly jumps to the ring road):
Eliminated possible causes / performed tests:
- problem occurs both with 0.8.1 and 0.8.4 versions
- problem occurs both on windows and Ubuntu instances. Interestingly, sometimes chunk is missing in either one (changes which one), sometimes in both.
- chunks are not only missing at beginning of trip (possible sleep mode delay) but also mid trip so unlikely car is truly asleep
- chunks are also missing when 3G connection is fine: they show up in the other instance and by coincidence in some cases I was checking things online in the exact period the data is missing.
To do - but hesitant:
- Starting tonight I'm going to run the streaming.js without sleep mode to see if I have the same problem. This is no fix however as it will likely increase the vampire draw of my car and points to an issue with the sleepmode.
Is anyone else experiencing these problems when running in sleep mode? Does anyone have an idea on how to fix this or diagnose it further?
Thanks for any help!
hans
P631
Hans / Dirk, awesome work on this package. Been using it for about 3 weeks now running both on a Ubuntu VPS and home windows machine.
I'm running into a strange problem: big chunks of my tracking data disappear eventhough my streaming.js is running 24/7 (albeit with the sleep mode -z enabled).
Symptoms:
- When looking at the energy data or map, chunks of my route will be missing (I checked in the original mongo data and there are no entries for that timeperiod in the db)
- Example of a route with about 20 minutes of data missing in the middle of the route (note I'm driving from the center out to the ring road, but the track suddenly jumps to the ring road):
View attachment 38421
Eliminated possible causes / performed tests:
- problem occurs both with 0.8.1 and 0.8.4 versions
- problem occurs both on windows and Ubuntu instances. Interestingly, sometimes chunk is missing in either one (changes which one), sometimes in both.
- chunks are not only missing at beginning of trip (possible sleep mode delay) but also mid trip so unlikely car is truly asleep
- chunks are also missing when 3G connection is fine: they show up in the other instance and by coincidence in some cases I was checking things online in the exact period the data is missing.
To do - but hesitant:
- Starting tonight I'm going to run the streaming.js without sleep mode to see if I have the same problem. This is no fix however as it will likely increase the vampire draw of my car and points to an issue with the sleepmode.
Is anyone else experiencing these problems when running in sleep mode? Does anyone have an idea on how to fix this or diagnose it further?
Thanks for any help!
This is indeed odd and unexpected behavior. I do not see this at all and I run streaming.js 24x7 as well. My only gaps come when I take the laptop that usually runs this code with me to a meeting. You will sometimes see missing periods of data at the beginning of a trip because streaming.js is trying to let your car fall asleep and you just happened to start your drive in the 30 minute "nap" period. When you run without '-z' sleep option you should not see missing data at the beginning of a trip either.
Is there any chance you can collect the detailed log output that gets printed on stdout for a period that spans before and after the lost data. If the code is mistakenly going into "nap" mode then it will print timestamps every minute informing that the Aux REST calls are being skipped. It would look like this
18 Dec 00:23:46 - Info: car is napping or sleeping, skipping auxiliary REST data sample
If there is some other reason it can't communicate with the Tesla servers you will also see some HTTP Error messages logged.
Hans,
Here's a sample of the output in the terminal (note that this is a different trip from the map but same problem of mid trip missing chunk). De frst and last line are "correct" polling of the car with data coming back. Everything inbetween does not give me any data in the mongodb.
Between 19:11 en 19:41 streaming.js thinks the car is asleep while I'm driving over the A4 I have removed tokens and vin myself so that's not a bug.
1387131077988,18,1292.1,70,5,93,52.117654,4.370658,24,D,199,143,94
15 Dec 19:11:17 - Info: car is napping, skipping tsla_poll()
15 Dec 19:11:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:12:17 - Vehicle state is: online
15 Dec 19:12:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:13:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:14:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:15:17 - Vehicle state is: online
15 Dec 19:15:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:16:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:17:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:18:17 - Vehicle state is: online
15 Dec 19:18:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:19:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:20:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:21:17 - Vehicle state is: online
15 Dec 19:21:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:22:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:23:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:24:17 - Vehicle state is: online
15 Dec 19:24:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:25:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:26:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:27:17 - Vehicle state is: online
15 Dec 19:27:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:28:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:29:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:30:17 - Vehicle state is: online
15 Dec 19:30:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:31:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:32:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:33:17 - Vehicle state is: online
15 Dec 19:33:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:34:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:35:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:36:14 - 0 of 6 REST requests since 1387132519479
15 Dec 19:36:17 - { color: null,
display_name: null,
id: 17081,
option_codes: bla bla
user_id: 18377,
vehicle_id: 1056789056,
vin: 'x',
tokens: [],
state: 'online' }
15 Dec 19:36:17 - Info: calling /charge_state to reveal the tokens
15 Dec 19:36:19 - getting charge state Aux data
15 Dec 19:36:19 - getting climate state Aux data
15 Dec 19:36:19 - Debug: charge_state request succeeded (Disconnected).
Reinitializing...
15 Dec 19:36:20 - 2 of 6 REST requests since 1387132579491
15 Dec 19:36:24 - { color: null,
display_name: null,
id: 17081,
option_codes: bla bla
user_id: 18377,
vehicle_id: 1056789056,
vin: 'x',
tokens: [ 'x', 'y' ],
state: 'online' }
ss = "nap"
lastss= "nap"
napmode= false
zzz= true
15 Dec 19:37:19 - getting charge state Aux data
15 Dec 19:37:19 - getting climate state Aux data
15 Dec 19:38:19 - getting charge state Aux data
15 Dec 19:38:19 - getting climate state Aux data
15 Dec 19:39:19 - getting charge state Aux data
15 Dec 19:39:19 - getting climate state Aux data
15 Dec 19:40:19 - getting charge state Aux data
15 Dec 19:40:19 - getting climate state Aux data
15 Dec 19:41:19 - getting charge state Aux data
15 Dec 19:41:19 - getting climate state Aux data
15 Dec 19:41:25 - Poll return HTTP OK and body is this:
1387132586808,52,1319.3,57,-2,106,52.337284,4.837366,11,D,156,104,106
Here's a sample of the output in the terminal (note that this is a different trip from the map but same problem of mid trip missing chunk). De frst and last line are "correct" polling of the car with data coming back. Everything inbetween does not give me any data in the mongodb.
Between 19:11 en 19:41 streaming.js thinks the car is asleep while I'm driving over the A4
I have removed tokens and vin myself so that's not a bug.1387131077988,18,1292.1,70,5,93,52.117654,4.370658,24,D,199,143,94
15 Dec 19:11:17 - Info: car is napping, skipping tsla_poll()
15 Dec 19:11:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:12:17 - Vehicle state is: online
15 Dec 19:12:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:13:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:14:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:15:17 - Vehicle state is: online
15 Dec 19:15:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:16:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:17:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:18:17 - Vehicle state is: online
15 Dec 19:18:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:19:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:20:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:21:17 - Vehicle state is: online
15 Dec 19:21:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:22:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:23:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:24:17 - Vehicle state is: online
15 Dec 19:24:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:25:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:26:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:27:17 - Vehicle state is: online
15 Dec 19:27:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:28:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:29:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:30:17 - Vehicle state is: online
15 Dec 19:30:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:31:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:32:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:33:17 - Vehicle state is: online
15 Dec 19:33:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:34:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:35:19 - Info: car is napping or sleeping, skipping auxiliary REST data sample
15 Dec 19:36:14 - 0 of 6 REST requests since 1387132519479
15 Dec 19:36:17 - { color: null,
display_name: null,
id: 17081,
option_codes: bla bla
user_id: 18377,
vehicle_id: 1056789056,
vin: 'x',
tokens: [],
state: 'online' }
15 Dec 19:36:17 - Info: calling /charge_state to reveal the tokens
15 Dec 19:36:19 - getting charge state Aux data
15 Dec 19:36:19 - getting climate state Aux data
15 Dec 19:36:19 - Debug: charge_state request succeeded (Disconnected).
Reinitializing...
15 Dec 19:36:20 - 2 of 6 REST requests since 1387132579491
15 Dec 19:36:24 - { color: null,
display_name: null,
id: 17081,
option_codes: bla bla
user_id: 18377,
vehicle_id: 1056789056,
vin: 'x',
tokens: [ 'x', 'y' ],
state: 'online' }
ss = "nap"
lastss= "nap"
napmode= false
zzz= true
15 Dec 19:37:19 - getting charge state Aux data
15 Dec 19:37:19 - getting climate state Aux data
15 Dec 19:38:19 - getting charge state Aux data
15 Dec 19:38:19 - getting climate state Aux data
15 Dec 19:39:19 - getting charge state Aux data
15 Dec 19:39:19 - getting climate state Aux data
15 Dec 19:40:19 - getting charge state Aux data
15 Dec 19:40:19 - getting climate state Aux data
15 Dec 19:41:19 - getting charge state Aux data
15 Dec 19:41:19 - getting climate state Aux data
15 Dec 19:41:25 - Poll return HTTP OK and body is this:
1387132586808,52,1319.3,57,-2,106,52.337284,4.837366,11,D,156,104,106
hans
P631
The car is going into nap mode in the middle of a trip. That is a bug, it should not do that. Can you PM me more of the beginning of the log? I am looking for something that says "30 minute nap starts now" and a few dozen lines before that.
You should not get this problem when you don't use the '-z' sleep mode flag. Sorry folks but this sleep mode is a pain in the a@$ to work around. I'll get it sooner or later.
You should not get this problem when you don't use the '-z' sleep mode flag. Sorry folks but this sleep mode is a pain in the a@$ to work around. I'll get it sooner or later.
hans
P631
I think I should explain how sleep mode support works for the streaming.js data collector as it has to work around some serious limitations of the Tesla APIs.
The problem is that when you collect telemetry from the car, it will never fall asleep. To get around that major limitation I implemented a concept called a "nap".
When streaming.js says its "napping" it means that it has determined that you have parked the car (and that it is not charging) and it will not make any requests to the Tesla APIs for up to 30 minutes in order to allow the car enough time to naturally fall asleep.
Once the car falls asleep it can be monitored to see if it ever wakes up again and goes 'online'. It can do this with the one and only REST API call that doesn't wake the car, and will tell the app what state the car is in (asleep, waking, or online). If the car is out of 3G or WiFi coverage it will report as being in 'unknown' state.
So what's the problem?
Well if you drive your car. Stop for 5 minutes to get a coffee, and then get back into your car and drive, you hit an unfortunate set of circumstances.
- the car is parked while you get your coffee so the code goes into nap mode
- the car never has time to fall asleep.
- the code can't tell that you are back in the car driving (it just sees 'online') so it continues to wait to see if sleep will set in.
- after 30 minutes it gives up waiting for the car to sleep and starts polling for more data to check what's really happening
- it discovers you are now driving the car and it has missed the past 25 minutes of your trip.
If you stop for 15-20 minutes for a coffee, and don't check on your car with the mobile app, the car will likely fall asleep. No problem because the code can see the car fall asleep, and then see it wake back up, and it will immediately cancel nap mode and being collecting data. Nothing but perhaps 1 minute of data is missing.
Sometimes a car falls asleep as fast as 11 minutes. Sometime it takes 25 minutes. That is why 30 minutes is the safest amount of time to "nap" to always let the car fall asleep (if undisturbed).
Now I could delay the start of nap time until the car has been parked for 10 minutes, or 30 minutes, or whatever. I think that might just move all the numbers around but still cause the same problems, or make them worse. If human nature is that there are a lot of stops that are <20 minutes then perhaps it would help.
Let me know what you think.
The problem is that when you collect telemetry from the car, it will never fall asleep. To get around that major limitation I implemented a concept called a "nap".
When streaming.js says its "napping" it means that it has determined that you have parked the car (and that it is not charging) and it will not make any requests to the Tesla APIs for up to 30 minutes in order to allow the car enough time to naturally fall asleep.
Once the car falls asleep it can be monitored to see if it ever wakes up again and goes 'online'. It can do this with the one and only REST API call that doesn't wake the car, and will tell the app what state the car is in (asleep, waking, or online). If the car is out of 3G or WiFi coverage it will report as being in 'unknown' state.
So what's the problem?
Well if you drive your car. Stop for 5 minutes to get a coffee, and then get back into your car and drive, you hit an unfortunate set of circumstances.
- the car is parked while you get your coffee so the code goes into nap mode
- the car never has time to fall asleep.
- the code can't tell that you are back in the car driving (it just sees 'online') so it continues to wait to see if sleep will set in.
- after 30 minutes it gives up waiting for the car to sleep and starts polling for more data to check what's really happening
- it discovers you are now driving the car and it has missed the past 25 minutes of your trip.
If you stop for 15-20 minutes for a coffee, and don't check on your car with the mobile app, the car will likely fall asleep. No problem because the code can see the car fall asleep, and then see it wake back up, and it will immediately cancel nap mode and being collecting data. Nothing but perhaps 1 minute of data is missing.
Sometimes a car falls asleep as fast as 11 minutes. Sometime it takes 25 minutes. That is why 30 minutes is the safest amount of time to "nap" to always let the car fall asleep (if undisturbed).
Now I could delay the start of nap time until the car has been parked for 10 minutes, or 30 minutes, or whatever. I think that might just move all the numbers around but still cause the same problems, or make them worse. If human nature is that there are a lot of stops that are <20 minutes then perhaps it would help.
Let me know what you think.
Last edited:
Hans, thank you for the detailed explanation (also in your email)! This seems to be a tricky issue. In my case I missed data after an even longer pause, likely because the car didn't fall asleep because I'm running Virtual Tesla (not collecting trip data) at the same time. VT is set to fall asleep at night but not during the day.
Sounds overall like Tesla may have to come up with a better API modification to deal with sleep, now that it really works ...
Sounds overall like Tesla may have to come up with a better API modification to deal with sleep, now that it really works ...
jvonbokel
John VonBokel
Could you set certain days/times when a "nap" is allowed? I have a fairly predictable driving pattern M-F, so if I could restrict naps (and thus car sleep) to certain hours of the day, I could get some of the benefits of sleep mode without sacrificing logging integrity.
hans
P631
That is a great idea. Sounds similar to the Daydream mode in VisibleTesla.
I will work on a method to configure customizable napping periods by time of day and day of the week.
On a completely separate subject I am adding in support for deploying to Heroku and running mongodb in the cloud. This will allow easy deployment into platform-as-a-service environments.
---update---
I did manage to deploy streaming.js to Heroku (for free) and have it working with MongoLabs mongodb also running in the cloud (for free). Both the Heroku dynos and the MongoLabs database are running in Amazon Web Service.
I also managed to capture and instance were my own car's data was missing in the middle of a trip. I am pretty sure that some rare condition is not handled properly in my code and the car is entering "nap" mode in the middle of a trip. It is quite possible that the drive state data can incorrectly return "null" a couple times, mid-trip, and fool the current logic that tries to detect when the car is parked. Since I now have lots of telemetry I can debug this problem better. Sorry guys that this is one isn't as nailed as I had thought.
Almost exactly 60 minutes missing so it must be two consecutive "nap" periods. I know the car was parked in the middle of that missing data so really this is just one mistaken 30 minute mistaken "nap at the wheel"
---second update---
Think I figured this out. The streaming.js code was allowing one last poll for data AFTER entering nap mode. If you started driving right after napping began, you could get up to one HTTP long poll's worth of streaming data logged before the nap mode flag would stop the additional polling.
This bug turned out to be a feature because it's a way that I can implement a final check to see of the car remains parked or not, without keeping the car awake.
I have implemented this logic and will test it out after the holidays. I am excited to see if this will work.
Last edited:
Similar threads
