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

VisibleTesla

This site may earn commission on affiliate links.
Hi Joe,

Now that email notifications are working, i would prefer that I can receive them more often. Now it is limited to one per 30 min time interval. Would it be possible to set this time interval myself. And/or mayby also have the option to select your own smtp server.
 
Last edited:
Hi Joe,

Now that email notifications are working, i would prefer that I can receive them more often. Now it is limited to one per 30 min time interval. Would it be possible to set this time interval myself. And/or mayby also have the option to select your own smtp server.

Hi fmda, the only 30 minute limit is on the frequency of "speed hits or exceeds" updates. Otherwise you could receive dozens of notifications per minute if you are hovering near the trigger speed. This is not only annoying to the user, but will cause me to exceed the limits of the mail-sending service.

If you're seeing 30 minute delays for other notifications while the car and app are awake, then it's a bug. If so I would appreciate details.
 
Hi fmda, the only 30 minute limit is on the frequency of "speed hits or exceeds" updates. Otherwise you could receive dozens of notifications per minute if you are hovering near the trigger speed. This is not only annoying to the user, but will cause me to exceed the limits of the mail-sending service.

If you're seeing 30 minute delays for other notifications while the car and app are awake, then it's a bug. If so I would appreciate details.

Hi Joe, I was referring to charging. Did some testing in charging a bit. Got notification that the car started charging, but not that it stopped. I did change previously the setting from "Allow daydreaming" to "Allow sleeping". Maybe this is the problem. I will do some more testing and let you know.
 
- - - Reply to scaesare - - -
I've downloaded the code, and have a quick question about the new mode: Given that the Allow Sleep mode for the car attempts to intelligently gather data when the car is awake, and yet allow it to also sleep when inactive, how does this interact with the Idle Threshold setting in Prefs?

It would seem that if the app idles after 15 minutes, then it would never really probe the vehicle at 30 minute intervals while it's awake?

Should we crank the idle threshold up past 30 minutes? Although even in that case it would seem that if we maxed out the idle threshold at 90 minutes, the app could go to sleep while the car is parked for a couple of hours, and then miss if the car wakes back up...

Or am I misunderstanding the idle behavior?

Thanks again for the effort and any insight.

Idle Threshold solely determines what interval of user inactivity will cause the app to change state from Awake to either Allow Daydreaming or Allow Sleeping. It does not directly impact the rate at which VT will probe the car. When the car enters "Allow Sleeping" mode either due to a period of inactivity longer than the threshold or because a scheduler command explicitly causes a mode change, then the sleep related heuristics come into play. The Idle Threshold is not used in any part of those heuristics.

Let me give a concrete example with a timeline:


  • 10:00 PM: User starts VisibleTesla. The app is in Allow Sleeping mode (Options->Inactivity Mode->Allow Sleeping)
  • 10:05 PM: The user stops interacting with VT
  • 10:20 PM: The Idle Threshold has been reached so the app goes into "Allow Sleeping" mode. This means that tabs will no longer be auto-refreshed and the collection of stats is suspended
  • 10:22 PM: This is the next time stats would normally have been collected.
    • VT notices that it is in "Allow Sleep" mode.
    • It checks to see if the car is awake - it is
    • It gathers to sets of stats, 30 seconds apart
    • It remembers not to bother the car for 30 minutes (2:52)
    • BUT it tells itself to wake up again in 5 minutes
  • 10:27 PM: VT checks whether the car is still in "Allow Sleep" mode. It might not be, the user could have started interacting with it. In this example we'll assume that it is still in"Allow Sleep" mode
    • VT tests to see whether the car is still awake. In this example we'll assume the car is still awake
    • VT remembers that it shouldn't probe the car until 2:52 so it does nothing.
    • This process repeats at 5 minute intervals (2:32, 2:37, 2:42)
  • 10:52 PM: VT is still in "Allow Sleep" mode, but now the car is Asleep
    • We don't probe it, but remind ourselves to check again in 5 minutes
    • This process repeats, never waking up the car
  • 11:02 PM: VT is still in "Allow Sleep" mode, but now the car is awake and charging
    • We gather 2 sets of stats, 30 seconds apart
    • Since we're charging, we remind ourselves to wake up in 2 minutes (the normal stat collection interval)
  • 11:04 PM: VT is still in "Allow Sleep" mode, but the car is still awake and charging
    • We collect more data, wait, then repeat
  • More of the same...
  • 12:32 AM: VT is still collecting stats as the car charges and it notices that the SOC has risen to a level that one of the notifications should trigger, so it sends the notification.
  • 01:15 AM: VT is still in "Allow Sleep" mode, but the car is finished charging and back to sleep.
    • We go back to periodic polling to see if the car is awake, but don't request any data so that we don't wake the car up again
  • 07:30 AM: The scheduler issues a command to take the App out of Allow Sleep mode and put it into Awake mode.
    • This will start requesting data from the vehicle which will cause it to wake up

As you can see, the Idle Threshold had nothing to do with the sleep-handling process other than determining when the activity began. That could just as easily have been triggered with a Scheduler "Sleep" command.

Also, if you look at visibletesla.log, you'll notice a bunch of log entries that basically trace the process. As mentioned in the release notes, once I'm satisfied that it's working well, I will stop emitting those log entries. I hope this helps. A diagram representation of a few sample timelines would be worth 1000 words here, but I only have scrawls on scratch paper that I used to plan this out.

- - - Reply to fmda - - -

Hi Joe, I was referring to charging. Did some testing in charging a bit. Got notification that the car started charging, but not that it stopped. I did change previously the setting from "Allow daydreaming" to "Allow sleeping". Maybe this is the problem. I will do some more testing and let you know.

How do you have the notification configured? If you want notifications when charging begins and ends, then you must enable "Charge State Becomes" and set the target to "Anything". If you have it set to "Charging" then you'll get the notification when charging starts, but when the charge state changes to "Complete", "Disconnected", or "Unknown", you won't get a notification.

Joe
 
Hi SteveW25561,
If you schedule an "HVAC: On" command then the app will wake up the car if necessary as part of issuing the command. Waking the car up takes about a minute. I know some folks are using this feature regularly. Give it a try and let me know if you have any problems.

Thanks for the reply. Actually, I have used the HVAC on command to basically have the car warm up in the mornings, but I was looking for a way to just have the car awake and ready to receive commands from the ios app whenever I wake up -- whether it's to check the battery state, turn on the HVAC or check or change charge, without needing to activate the whole HVAC via VisibleTesla. Does the new "plugged in" check force the car to wake up and cn it be used in a scheduler?
 
Joe, very good... I like it! I think that set of heuristics really make the app useful while at the same time allowing for the car to powersave.

This morning I see a number of events that the car triggered (charging, charge complete, etc...) despite the app and the car both sleeping. Very nice! I also had set the "Speed exceeds" threshold to 50, knowing that I'd easily hit that on my commute. I got one notification during my ~45 min commute this morning (whh was largely above 50MPH).

I'm going to do some refining of my settings now...

Again your sharing this with us is appreciated.

(I already have a set of items that I think would further add utility, but I hesitate to come across as demanding...)
 
Thanks for the reply. Actually, I have used the HVAC on command to basically have the car warm up in the mornings, but I was looking for a way to just have the car awake and ready to receive commands from the ios app whenever I wake up -- whether it's to check the battery state, turn on the HVAC or check or change charge, without needing to activate the whole HVAC via VisibleTesla. Does the new "plugged in" check force the car to wake up and cn it be used in a scheduler?

Hi SteveW25561, I should have been more explicit. In talking about the Scheduler I said: " 'Awake' means that it should collect data as usual and auto-refresh tabs on a regular basis even if the user is not interacting with the app." Because VT will start collecting data from the car, it will wake up the car as a side-effect. This usually takes about a minute from the time the scheduler command is issued. For example, I have an Awake command issued every morning at 7AM. If I look at the Graph tab I start seeing readings come in at about 7:02 showing that the car is awake. I believe that's what you want right?

As an aside, the answer to your other question is yes - the new "plugged in" Scheduler item also causes the car to wake up.
 
So I've been using 25.01 for a few days now and am going to be using it even more ;) One thing I noticed so far after the road trip is this:

Screen Shot 2013-12-26 at 21.22.25.png


It says the trip was 116.1 km yet it was 186,8 km. The thing is the real km distance is 116.1 miles ;) So I guess there's some unit conversion stuff happening ;)
 


- - - Reply to fmda - - -



How do you have the notification configured? If you want notifications when charging begins and ends, then you must enable "Charge State Becomes" and set the target to "Anything". If you have it set to "Charging" then you'll get the notification when charging starts, but when the charge state changes to "Complete", "Disconnected", or "Unknown", you won't get a notification.

Joe


Hi Joe, yes charging was set to anything. I changed to "allow daydreaming" and it seems to work fine now.

I will check some more. Maybe it was just a temp problem.
 
Hi, Joe

Thanks -- this is indeed what I'm looking for.

If I understand correctly, if I leave VT running, VT will actually keep the car awake and not allow it to sleep as a side effect of collecting data (assuming no Daydream or Sleep command is set)?

Thus, I want to allow sleep mode overnight, should I set the scheduler to allow the car to sleep say at 9 pm, then set an "awake" command at 7am?

- Steve


Hi SteveW25561, I should have been more explicit. In talking about the Scheduler I said: " 'Awake' means that it should collect data as usual and auto-refresh tabs on a regular basis even if the user is not interacting with the app." Because VT will start collecting data from the car, it will wake up the car as a side-effect. This usually takes about a minute from the time the scheduler command is issued. For example, I have an Awake command issued every morning at 7AM. If I look at the Graph tab I start seeing readings come in at about 7:02 showing that the car is awake. I believe that's what you want right?

As an aside, the answer to your other question is yes - the new "plugged in" Scheduler item also causes the car to wake up.
 
Ok, maybe it can already be done, but what I'd like is for VisibleTesla to be as unobtrusive as possible yet gather as much data as possible. So for example once I park the car (i.e. speed 0, no odometer increase in X minutes) the app would allow the car to go to sleep. Once the app determines that the car has gone to sleep (I hope it's possible to determine this without waking it) the app would just periodically ping Tesla to find out if the car is sleeping or not and once it's not it goes back full blown logging mode. This way I know that maximum time that the car is kept from sleeping is ~X minutes per drive. If the "Is car sleeping?" query is low overhead, then I'd run that relatively frequently to detect restart of car as soon as possible.

Is this already possible or is this a feature request? :) 99% of the time I'm not keeping the car in sleep mode at all instead just live with the vampire, but on a road trip I'd probably want the sleep mode, but also would like the app being at home to gather as much details as possible.

Second feature request (not sure if this is already possible again). Can you add a few options to the statistics export. First one would be date range selection for export. The second would be to somehow remove lines that have empty ntries. For example I had multiple where the speed was fluctuating between 90km/h and 0 in consecutive lines at the start of a drive. Had to remove ca 100 lines manually to make charts look nice.
 
Interesting- Last night at my specified time (11pm) VT appears to have woken the car successfully to query it to see if it was plugged in:

2013-12-26 23:01:22
Activity related to the Scheduler. Details:Unplugged?: succeeded


VT seemed to think the car was unplugged:


2013-12-26 23:01:21
Your car is not plugged in!


Unfortunately, that was not the case. I confirmed last night physically the car was plugged in, and the car did indeed charge over night.

Ideas?


Also I've noted that the trips tab list 3 very short (> 1 mile) trips for yesterday, despite two commute legs of 45 minutes or more, during which time the car was obviously awake.

VT is currently in Allow Sleep mode, but I don't believe this is correct behavior?
 
- - - Reply to Mario Kadastik - - -
...It says the trip was 116.1 km yet it was 186,8 km. The thing is the real km distance is 116.1 miles ;) So I guess there's some unit conversion stuff happening ;)

Thank you for reporting this. I fixed it in my current development version.

- - - Reply to SteveW25561 - - -

Hi, Joe

Thanks -- this is indeed what I'm looking for.

If I understand correctly, if I leave VT running, VT will actually keep the car awake and not allow it to sleep as a side effect of collecting data (assuming no Daydream or Sleep command is set)?

Thus, I want to allow sleep mode overnight, should I set the scheduler to allow the car to sleep say at 9 pm, then set an "awake" command at 7am?

- Steve

Exactly, you can schedule it to go into sleep mode at 9 and awake mode at 7. Sometime after 9 the car will decide to go to sleep as long as there is no other external factor keeping it awake. Daydreaming mode will not allow the car to go to sleep. It just lowers the load on Tesla's servers when the app is not actively being used.

- - - Reply to Mario Kadastik - - -

Ok, maybe it can already be done, but what I'd like is for VisibleTesla to be as unobtrusive as possible yet gather as much data as possible. So for example once I park the car (i.e. speed 0, no odometer increase in X minutes) the app would allow the car to go to sleep. Once the app determines that the car has gone to sleep (I hope it's possible to determine this without waking it) the app would just periodically ping Tesla to find out if the car is sleeping or not and once it's not it goes back full blown logging mode. This way I know that maximum time that the car is kept from sleeping is ~X minutes per drive. If the "Is car sleeping?" query is low overhead, then I'd run that relatively frequently to detect restart of car as soon as possible.

This is pretty much the current behavior as of 0.25.01. Please check out post #564 where it talks about "A fairly significant change has been made to the way VisibleTesla handles sleep mode" and post #585 where it shows a concrete example of the algorithm in practice. Whenever people indicate a strong interest in telemetry I always like to mention teslams described in this thread. It's a more sophisticated way to capture data on an ongoing basis.

Second feature request (not sure if this is already possible again). Can you add a few options to the statistics export. First one would be date range selection for export. The second would be to somehow remove lines that have empty ntries. For example I had multiple where the speed was fluctuating between 90km/h and 0 in consecutive lines at the start of a drive. Had to remove ca 100 lines manually to make charts look nice.

Allowing the selection of date range on export is on my list. Are you interested in arbitrary starting/ending dates or something more like the preference for graph tab import: Last 7 days, Last 14 days, Last 30 days, last week, last month, all?

Can you say more about the second request? When you say empty "lines" do you mean a row in the exported Excel file that has any empty value in a column? If you would provide 5 to 10 sample rows that contain rows that should not be removed and rows that should be removed, that will help me understand your request.
 
Is the notification for speed in mph or km/h? I have my car set to metric and the HVAC and Charge seems to be showing up as metric in VT but my speed notifications come in and seem to be triggered in imperial (i.e. I have a speed notification for 63 and it only gets triggered once I am on the highway. If it was metric, 63 Km/h would get triggered on regular roads much before I got on the highway).
 
Interesting- Last night at my specified time (11pm) VT appears to have woken the car successfully to query it to see if it was plugged in:

2013-12-26 23:01:22
Activity related to the Scheduler. Details:Unplugged?: succeeded


VT seemed to think the car was unplugged:


2013-12-26 23:01:21
Your car is not plugged in!


Unfortunately, that was not the case. I confirmed last night physically the car was plugged in, and the car did indeed charge over night.

Ideas?

That's quite odd. You don't happen to have a timer on your outlet do you? I know that's an odd question, but the way that VT determines if your car is plugged in is that it checks the Pilot Current and looks for a non-zero value. If it sees 0, it asks the car again just to be sure. Only then does it send a notification message. Is there any reason that the Pilot current would be 0 at 11PM but then non-zero later? Also, on the Overview tab, does it show the power cord connected to the car? That uses the same check to determine whether it is plugged in.
 
That's quite odd. You don't happen to have a timer on your outlet do you? I know that's an odd question, but the way that VT determines if your car is plugged in is that it checks the Pilot Current and looks for a non-zero value. If it sees 0, it asks the car again just to be sure. Only then does it send a notification message. Is there any reason that the Pilot current would be 0 at 11PM but then non-zero later? Also, on the Overview tab, does it show the power cord connected to the car? That uses the same check to determine whether it is plugged in.

No, it's a HPWC hardwired directly to a a 50amp breaker in my panel. No timers or any other disconnects involved, I installed the circuit myself.

As I was awake last night after 11pm, I saw the email so went out and verified the car was indeed plugged in. I also verified the green power indicator LED on the HPWC was lit.

I deliberately did NOT wake up the car, or interact with VT, as I wanted to see what would happen later when my 2am charge time came and went. As such, I didn't switch VT tabs to take a look at pilot current.

Interestingly, I did NOT get the "charge started" and "charge completed" notifications last night as I had previously with the 0.25.00
flavor of the app.

I'll take a look at the pilot current values and the cord plugged status tonight as you mention above...

Thanks.
 
I have tried searching but can't seem to find anyone else with this issue (if its an issue at all) but when it comes to the trips tab, I only get trips when the app is not in "daydream" mode.
I leave the app running on my desktop at my office since it's logged in all the time. When I leave work I get the trip work-->home logged in the app. But since the app goes into daydream mode I don't get any other trips taken after that. Is this intended or am I doing something wrong?

Thanks
 
Thanks scaesare. did you happen to keep your visibletesla.log from last night? There is a bunch of debug output in there right now relating to when it is probing the car while the app is in sleep mode.
 
I have tried searching but can't seem to find anyone else with this issue (if its an issue at all) but when it comes to the trips tab, I only get trips when the app is not in "daydream" mode.
I leave the app running on my desktop at my office since it's logged in all the time. When I leave work I get the trip work-->home logged in the app. But since the app goes into daydream mode I don't get any other trips taken after that. Is this intended or am I doing something wrong?

Thanks
me too, I am still trying to figure it all out, but this seems to be the case. I get 1 trip then daydream and no more logging after.

Also, how exactly does this work when there are 2 instances of this application running on different computers? Some of the graph data seems to show up on each but not all of it. It is dependent on each applications logging of the cars data, correct?

thanks
 
Last edited:
I've been playing around with the notification settings as well. A couple of days ago I got a notification at 10 PM that the MS was unplugged (which it was not.) When I looked on the overview tab (which is where I leave VT by default) the charge cable was not drawn. After I refreshed it, the cable appeared. I've noticed that on other occasions that it looks unplugged, and then updates correctly once refreshed. Something doesn't seem to work consistently in determining the plugged-in status.

I know it sounds vague, and next time I see it, I'll make sure to save the log. I may have the log from the time of the erroneous notification in Time Machine. I'll look when I get a chance.