-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
TeslaLog.com - Your hosted Tesla Data Logger - Announcement / Support threads
- Thread starter mochouinard
- Start date
-
- Tags
- Model S User Interface
pupik
Member
When I've seen that, it typically has meant that Tesla thinks your car is online and active, but is having problems reaching it using a real-time link. Most of the API calls are handled by the car via the VPN tunnels from Tesla's servers.
If Tesla blocks you, you'll know it. It'll say something like "blocked for 86400 due to too many requests" with an HTTP error msg, and will come from the front-end.
Hi everyone !
I just wanted to let you know that we just passed the 400 car being track and over 1.4 millions kilometers recorded where there were only 30 car back in December !
This is crazy !
Lot of changes coming up, but I do have to take some time in optimization so the next 400 car added don't slow things down
Keep asking for new features even if I don't have the tiime to do them right now, I'm keeping a document with them and will see about adding them when time allow !
Marc
I just wanted to let you know that we just passed the 400 car being track and over 1.4 millions kilometers recorded where there were only 30 car back in December !
This is crazy !
Lot of changes coming up, but I do have to take some time in optimization so the next 400 car added don't slow things down
Keep asking for new features even if I don't have the tiime to do them right now, I'm keeping a document with them and will see about adding them when time allow !
Marc
Andyw2100
Well-Known Member
Hi everyone !
I just wanted to let you know that we just passed the 400 car being track and over 1.4 millions kilometers recorded where there were only 30 car back in December !
This is crazy !
Lot of changes coming up, but I do have to take some time in optimization so the next 400 car added don't slow things down
Keep asking for new features even if I don't have the tiime to do them right now, I'm keeping a document with them and will see about adding them when time allow !
Marc
Congratulations, Marc!
I really enjoy using TeslaLog! Keep up the great work!
Peter_M
Member
I think I made this suggestion earlier: why not provide a setting to let users choose how often to poll the car? Actually, maybe three settings: one while parked, one while charging and one while driving. I think it polls about every 15 seconds now. For my purposes, polling every 15 minutes while parked, every 5 minutes while charging and every 2 minutes while driving would probably be enough and it would drastically reduce the data volume. I'm also concerned that Tesla might do something to shut you down and I'd like to keep using TeslaLog!Hi everyone !
I just wanted to let you know that we just passed the 400 car being track and over 1.4 millions kilometers recorded where there were only 30 car back in December !
This is crazy !
Lot of changes coming up, but I do have to take some time in optimization so the next 400 car added don't slow things down
Keep asking for new features even if I don't have the tiime to do them right now, I'm keeping a document with them and will see about adding them when time allow !
Marc
Andyw2100
Well-Known Member
I'm no expert, but I think one potential problem with what you are suggesting is that if the polling is much less frequent when parked than when driving, the first part of drives is going to be missed regularly.
pupik
Member
Unfortunately I have to agree :redface:
My daily way to work takes 8 minutes :biggrin:
so, for now (1min. refresh) missing 15-20% from the route :wink: mostly
Marc -
Curious if you keep any kind of "audit" log on your end showing when geo action keeps HVAC on?
I was sitting in my car waiting for the wife to come out of a store. I had turned my HVAC off a few minutes prior. While I was sitting waiting (Car was on and in park), the HVAC turned on. Weird. I turned it back off. Minute or two later, it turned back on again. Did this a few times. Wife came out, started to drive away and it came on again. Turned it off. Didn't come back on again afterwards.
I do have some geo locations setup to keep the HVAC on, and I was "close" to one of the locations. Looking at Google maps, I was 200 meters away from the edge of the nearest geo location circle I have setup.
Curious if you keep any kind of "audit" log on your end showing when geo action keeps HVAC on?
I was sitting in my car waiting for the wife to come out of a store. I had turned my HVAC off a few minutes prior. While I was sitting waiting (Car was on and in park), the HVAC turned on. Weird. I turned it back off. Minute or two later, it turned back on again. Did this a few times. Wife came out, started to drive away and it came on again. Turned it off. Didn't come back on again afterwards.
I do have some geo locations setup to keep the HVAC on, and I was "close" to one of the locations. Looking at Google maps, I was 200 meters away from the edge of the nearest geo location circle I have setup.
MarcG
Active Member
Agreed, but if you know you're not going to take a drive in the middle of the night there's no point in polling the car every minute!
Which is why I suggested way upthread a user setting to define the times between which the polling can go up to several minutes, or even half an hour like VisibleTesla does. For example, I'd set the "sleep time" to midnight and the "awake time" to 6am.
Right now the only way to do this is to manually turn off polling, which is cumbersome to do on a regular basis and easy to forget.
I would love for Marc Olivier (mo!) to implement this simple function soon so we can reduce the load on Tesla's servers and avoid getting shut out! (hint hint :wink: to Marc)
I pool Tesla server for a few different api call once every minute. There is also the streaming data that give me about 4 sample per second of the car position, drive state, speed, heading and kW usage.
I could increase the delay for the 1 minute pool without affecting the instant driving recording. I could 1 sample every 15 second for the driving condition... But then lot of the graph I've build wouldn't show correct information (like the Wh/km(miles)).
If you want your car to have less power drain, then you would have to increase the pooling to once every hour or more and disable real time car position check. But that mean you could drive for more than 1 hours before the car detect you are driving.
The only possible solution to this would be to create an Android application that would detect your car bluetooth connection and enable logging only when that happened. Also with that idea, I could also detect the car driver and allow for different logging fields on the site so you could mask only a single driver trip. I started the android app, but a part of a basic login process I haven't done much more ! If your on the dark side (apple), your out of luck
So it depend if your goal is to reduce the vampire drain, or lower the number of entry into my DB. I'll say the number of entry in the DB have an impact, but the number of user who would want to miss out on the feature wouldn't help the overhaul load on the servers.
I could increase the delay for the 1 minute pool without affecting the instant driving recording. I could 1 sample every 15 second for the driving condition... But then lot of the graph I've build wouldn't show correct information (like the Wh/km(miles)).
If you want your car to have less power drain, then you would have to increase the pooling to once every hour or more and disable real time car position check. But that mean you could drive for more than 1 hours before the car detect you are driving.
The only possible solution to this would be to create an Android application that would detect your car bluetooth connection and enable logging only when that happened. Also with that idea, I could also detect the car driver and allow for different logging fields on the site so you could mask only a single driver trip. I started the android app, but a part of a basic login process I haven't done much more ! If your on the dark side (apple), your out of luck
So it depend if your goal is to reduce the vampire drain, or lower the number of entry into my DB. I'll say the number of entry in the DB have an impact, but the number of user who would want to miss out on the feature wouldn't help the overhaul load on the servers.
Andyw2100
Well-Known Member
Yes, I remember seeing your suggestion and liking it. As you know, I also use VT, and also make use of the ability to have VT "sleep" in the middle of the night, when I know we won't be driving. I agree that the sooner he implement something like this, the better. I was merely pointing out why basing the polling on park, driving, etc., in and of itself wouldn't work well.
If Marc were to implement your user-defined times for polling frequencies, I'd suggest adding an aspect of it that automatically prevents the car from switching to a lower polling frequency if it is driving, and also automatically switching to the highest frequency when it is found to be driving, or at least the options to do this. So, for example, if you have your normal "sleeping" times set, but are coming home late one night, TeslaLog won't suddenly lose a lot of data at the end of your drive because you hit a different polling frequency.
TeslaLog and all the hits on the Tesla servers may be flying under the radar for now, but as the number of users continue to grow the chances of that continuing becomes less and less likely. I think this feature would be an important safe-guard that could make the likelihood of TeslaLog being able to continue to function in the future more probable.
Edit: I was posting at the same time Marc C. was, so perhaps none of my post is relevant.
Edit 2: Marc C--If we know the car will be sleeping from midnight to 6:00 AM, would there be any harm in turning off the polling completely during that time? Essentially you'd be building us a way to automate what you have already given us with respect to the ability to turn off logging. We would just be turning it off on a schedule, ahead of time, and the "turning off" would be overridden if the car was actually being driven when it was supposed to turn off.
Edit 3: I just thought of a problem with my plan in Edit 2. I'm not sure charging data would be recorded properly (or at all if the entire charge took place while no polling was taking place.)
- - - Updated - - -
The only possible solution to this would be to create an Android application that would detect your car bluetooth connection and enable logging only when that happened. Also with that idea, I could also detect the car driver and allow for different logging fields on the site so you could mask only a single driver trip. I started the android app, but a part of a basic login process I haven't done much more ! If your on the dark side (apple), your out of luck
This goes along with my question in Edits 2 and 3 in my post above. If one were to use the app you are building, and only log when there is a bluetooth connection, what would happen with respect to logging charging activity?
Last edited:
Normally you start charging a few minute after you finish a drive so it would be fine and I can keep monitoring until charging is done. If you start charging out of no where, in some scenario I could detect it (For example, there is some API I can query to see if the car is alive or not. if it went to sleep and went back online, then something happen. So I could have a 5 minute pooling on that one which wouldn't wake up the car.
There is solution, but I know that the day I do it, tesla will provide push capability which will render all that pointless... hehe
There is solution, but I know that the day I do it, tesla will provide push capability which will render all that pointless... hehe
Andyw2100
Well-Known Member
Thanks, Marc.
I don't know what others do, but I know I almost never start charging as soon as I finish a drive. All my charging is set up to happen at night rates, and in the winter I try to time it manually each night, based on the next morning's departure time, such that the charging finishes just before my wife plans to leave for work (so that the battery is warm from charging.) So in my case the charging really would be starting "out of no where!"
I can only say that I think it was driven on the morning on 16th (it's in Tesla's hands right now - different story); the app has been working all along so the car has been online ok. That's UK morning by the way.
logging started working again on 19th. I tried using safari not chrome (on iPad); it worked when chrome would not. After a few hours of working fine on safari it now works again on chrome.
I expect the car to be driven again this coming Tuesday; I will check to see if the logging works.
redevries
René de Vries
Let's not mess with assumptions about when and when not to poll.
The thing I really like about TeslaLog, is that it captures everything and makes it available for analysis. It does a great to job determining when a trip end and starts.
Why should we worry about Tesla's network load? They have API limits to manage that. Things may change in the future but my guess is they will make sure this scales well, especially when Model III arrives.
The thing I really like about TeslaLog, is that it captures everything and makes it available for analysis. It does a great to job determining when a trip end and starts.
Why should we worry about Tesla's network load? They have API limits to manage that. Things may change in the future but my guess is they will make sure this scales well, especially when Model III arrives.
Hi, mochouinard,
Congrats for reaching 400 cars tracking! I introduced your app to my friends in Japan so some might have registered. If you need additional help to solve above issues regarding wrong rated range display, please let me know and I'm happy to help.
Similar threads
