hans
P631
Was hoping to get upgraded to 2.9.x but I'm still on 2.7.x. Perhaps now that its new year they will continue pushing more updates. Worst case is I get it at my upcoming 3 year annual inspection.
You can install our site as a web app on your iOS device by utilizing the Add to Home Screen feature in Safari. Please see this thread for more details on this.
Note: This feature may not be available in some browsers.
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.
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.
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 think you can reduce the timeout to 15-20 minutes. I'm showing the car sleeps in 14.
I can make it a configurable option so you can pick 15 minutes if that works for you.
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.
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.
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 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 !
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.
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.
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.
Every single time I changed my tesla password to something different than what it was before, my key got revoked.