-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
VisibleTesla
- Thread starter jpasqua
- Start date
-
- Tags
- Model S User Interface
dirkhh
Middle-aged Member
I keep looking at dsmith's charts trying to figure out whether it's a buy or sell trend for the stock.
You are on TMC. Whatever the data, it's a strong buy...
hans
P631
I keep looking at dsmith's charts trying to figure out whether it's a buy or sell trend for the stock.
Need to add Bollinger Bands to the chart ;-)
dirkhh
Middle-aged Member
For the past 2 or 3 days Visible Tesla has not been able to connect. The iPhone app also wouldn't connect from my home Wifi network. I just found that it connects fine via cellular service. Could this be because my IP address has been blocked by Tesla due to too many requests by VT? I have no other explanation ... MyTesla login on the main website works fine from my home network.
Hi Klaus,
I use VT pretty continuously and have not had that problem. I did get turned off temporarily earlier in the development process when a bug caused a large number of requests to the Tesla servers before I shut it off. I was contacted by Tesla about it via email the same day.
Since then I haven't had any difficulty. Are you back online yet? If not I would contact Tesla to ask about it.
BTW, these days I leave VT in the Graphs Tab when I'm away. That causes the lowest request rate tot he Tesla servers.
VisibleTesla 0.20.00
A new experimental version of VisibleTesla, version 0.20.00, can be downloaded here.
I will not update the first post of this thread with an announcement of this version until it has some further testing. You should not use this version unless you are comfortable using beta software - even more beta than VT already is!
If you use this version, please do not delete your old version or old data files. You may copy your cookies.txt file and your VIN.stats.log file from your old VisibleTesla folder to the new one. The .aux file is no longer used and need not be copied.
VisibleTesla 0.20.00 [2013-09-25]
A new experimental version of VisibleTesla, version 0.20.00, can be downloaded here.
I will not update the first post of this thread with an announcement of this version until it has some further testing. You should not use this version unless you are comfortable using beta software - even more beta than VT already is!
If you use this version, please do not delete your old version or old data files. You may copy your cookies.txt file and your VIN.stats.log file from your old VisibleTesla folder to the new one. The .aux file is no longer used and need not be copied.
VisibleTesla 0.20.00 [2013-09-25]
- User-Visible Changes
- General
- A disclaimer dialog is displayed one time when first using the application. It will pop up after you successfully log in and displays a disclaimer like the one that can be found in the documentation. I added this in conjunction with the addition of the Scheduling functionality to remind users that they are using the application at their own risk. This dialog will be displayed once on each machine where the application is run.
- The Excel file produced by the "File->Export Graph Data..." menu item now gets and includes the system time zone in the formula to determine the human readable time column.
- Login
- Fixed: Unusual usernames could cause login failures. That has been addressed.
- Overview
- HVAC
- Location
- Charge
- Graphs
- Graphs can now be drawn with markers (dots) corresponding to every actual reading. Thin, semitransparent lines connect the dots for clarity, but do not represent readings. They represent the trendline between readings. Please refer to the documentation to learn how to select whether dots, lines, or both should be displayed using the context menu.
- Fixed: The app used to throw away intermediate duplicate values in a sequence of readings. For example, if the Voltage reading was the same 10 times in a row, it would only store the first and last of those ten duplicate readings. This lead to odd looking graphs in isolated cases and made it impossible to show markers where the actual readings took place, or gaps in the collection of data.
- Scheduler
- Added a very basic scheduling mechanism that allows users to do things like starting and stopping the HVAC system at certain times on certain days. Please refer to the documentation for more details.
- General
- Under-the-covers
- Completely reworked the way statistics are stored. The new mechanism is compatible with older data files but stores the data in a manner that allows all data points to be maintained while not significantly increasing storage requirements. The ".aux" file is no longer required and will not be created by the application. To ensure you have all data values when you copy the VIN.stats.log from your old app to the new one, please quit the current version of VisibleTesla, restart it, then quit it again. This will guarantee that your VIN.stats.log file contains all previous readings.
- Known problems
- The context menu in the Graphs tab should only ever show one checked item at a time. Occasionally it will show a check mark next to both the currently selected value and the last selected value. Moving your mouse over the last selected value will make it refresh and display correctly. The application functions properly, but the display can be confusing. This appears to be a problem with the underlying JavaFX system. I am looking for a workaround.
Last edited:
No change at this point. VT tries to connect, and spins the spinner for a fraction of a second. I threw away the cookie file, no change. Tried 0.20 too, same.
Laumb
smrtass.
It's been a while since I visited this thread. I'm using an earlier version of VT, and have been enjoying it... I'll definitely check out your latest! Again much thanks for the effort.
Please accept this as a feature suggestion, and not a greedy "Hey do this for me!" comment :
Have you given any thought to user alerting/notifications? Specifically now that you are tinkering with event scheduling, some feedback of missed events would be helpful. For example, if a scheduled charging session was unable to start for some reason (such as when I forget to plug in :redface: ) then an email or text alert would be useful.
I'd even suggest that alerts/notifications be separate entities from the existing actions you have implemented. That way if I have 2am scheduled charge via the car GUI... I could have a 10pm VT scheduled event that looks to see if the car is plugged in, and if not sends an alert while it's still early enough in the evening that I'm likely to be awake.
I can think of MANY cases where alerts based on the data you are able to pull (car unlocked, charge port open, car in motion, SOC below a threshold, temp exceeds threshold, etc...) would be useful even if not associated with any specific scheduled action.
Thanks for listening...
Please accept this as a feature suggestion, and not a greedy "Hey do this for me!" comment
:Have you given any thought to user alerting/notifications? Specifically now that you are tinkering with event scheduling, some feedback of missed events would be helpful. For example, if a scheduled charging session was unable to start for some reason (such as when I forget to plug in :redface: ) then an email or text alert would be useful.
I'd even suggest that alerts/notifications be separate entities from the existing actions you have implemented. That way if I have 2am scheduled charge via the car GUI... I could have a 10pm VT scheduled event that looks to see if the car is plugged in, and if not sends an alert while it's still early enough in the evening that I'm likely to be awake.
I can think of MANY cases where alerts based on the data you are able to pull (car unlocked, charge port open, car in motion, SOC below a threshold, temp exceeds threshold, etc...) would be useful even if not associated with any specific scheduled action.
Thanks for listening...
Since the official app won't connect either, I would definitely contact Tesla at this point.
ToddRLockwood
Active Member
This is just awesome. It's great that you took the time to do it.
I have one question that may have been addressed already... When charging, is the Rated Range derived differently than when not charging? I noticed that the Rated Range dropped 2.7 miles immediately after charging ended. (I was charging my P85 to 90%.) Perhaps the Tesla smartphone app derives Rated Range differently while charging.
After all of your code is nailed down, you might consider a final UI polish. Functionality seems great, though.
I have one question that may have been addressed already... When charging, is the Rated Range derived differently than when not charging? I noticed that the Rated Range dropped 2.7 miles immediately after charging ended. (I was charging my P85 to 90%.) Perhaps the Tesla smartphone app derives Rated Range differently while charging.
After all of your code is nailed down, you might consider a final UI polish. Functionality seems great, though.
Hello Laumb,
Something is definitely wrong. Have you ever successfully run a version of VisibleTesla, or is this your first use?
The file that has grown out of control is the log file. If you are comfortable with the command prompt in Windows you can look at the beginning of this file pretty quickly. The easiest way to do this is to hold down the SHIFT key while you right-click anywhere in the VisibleTesla folder. A menu will pop up and you'll see a menu item that's not usually there: "Open command window here". Select that and a new command prompt window will open up. It will be waiting for you to enter a command. Type:
more tesla.log
and hit the ENTER key. This will print a window full of text and then pause. Hit ENTER again and you'll see another window full of text. You can keep doing this to see more of the file. Another option is to download a program like Large Text File Viewer (Large Text File Viewer 5.2 - Features) and use it to view the file.
Either way I would greatly appreciate it if you would send me a chunk of the beginning of the file so I can try to diagnose the problem. I suspect that the file is just a repeating set of the same content over and over again. It sounds like it's in some sort of error loop. Please PM me for more detailed instructions if you need them.
- - - Updated - - -
Hi Todd, I've noticed the same thing w.r.t. range vs. charging. Since I don't massage the numbers that I receive from Tesla, I suspect whatever is going on here is happening at their end (or in the car). It's possible that the smartphone app is doing something smarter than VT (or just different), but I don't have an easy way to determine what that might be. I'd be happy to hear from the teslams folks or any other API users to get their experience on this issue.
steve841
Active Member
Jpasqua ...
Absolutely perfect implementation of a schedule!!!!
So far, so good.
TESLA - are you listening? Someone put him on the payroll!!!
Absolutely perfect implementation of a schedule!!!!
So far, so good.
TESLA - are you listening? Someone put him on the payroll!!!
dsmith2189
Active Member
I think the option to display datapoints is a good idea. is there a way to make the lines thicker when displaying only the lines. having the thin lines is good when displaying the datapoints but they get a bit hard to see when they are on their own. (I'm old)
I am seeing the same large log file as Laumb, trying to connect to a EU car that has gone to sleep.
Same thing happening with both 19.04 and 20.00. I see in the process explorer that the javaw process uses a lot of CPU and hangs even after quitting the app and i have to kill it from there to make it stop.
Here are the first few lines of the log file, it just keeps repeating:
Code:
<?xml version="1.0" encoding="windows-1252" standalone="no"?>
<!DOCTYPE log SYSTEM "logger.dtd">
<log>
<record>
<date>2013-09-26T21:27:23</date>
<millis>1380223643072</millis>
<sequence>0</sequence>
<logger>org.noroomattheinn.tesla.Tesla</logger>
<level>INFO</level>
<class>org.noroomattheinn.tesla.APICall</class>
<method>honorRateLimit</method>
<thread>18</thread>
<message>Throttling request rate. Requests: 30, Millis: 16*859
</message>
</record>
<record>
<date>2013-09-26T21:27:28</date>
<millis>1380223648088</millis>
<sequence>1</sequence>
<logger>org.noroomattheinn.tesla.Tesla</logger>
<level>INFO</level>
<class>org.noroomattheinn.tesla.APICall</class>
<method>honorRateLimit</method>
<thread>18</thread>
<message>Throttling request rate. Requests: 30, Millis: 21*875
</message>
</record>Oh, thanks for the scheduler, looks great!
hans
P631
Yes. When the car is charging (or in use) it is much more difficult to estimate the Rated Range since this value is derived from measuring the voltage of the battery, and the voltage is effected by the charging. You will often notice a 2-3 mile drop in range immediately after charging stops.
Good idea. I'll look into that. It should be straightforward but there are some really surprising limitations with the JavaFX charting library. Some things that should be trivial turn out to be a PITA. Hopefully this won't fall into that category.
Thanks hans. I'll add this to the documentation or an FAQ or something.
- - - Updated - - -
...
Please accept this as a feature suggestion, and not a greedy "Hey do this for me!" comment
Have you given any thought to user alerting/notifications? ...
I have thought about alerting, but not with all of the functionality you described (which sounds useful). It seems like it might be a pretty involved UI to be able to specify all the potential events and conditions. I'll think about it in the background add it to the list for consideration.
Well I appreciate the work thus far, and your willingness to share it with the community. Appreciate the willingness to consider it as a back-burner idea.
I actually was giving some thought to the UI, and found that email alert/rules seemed pretty analogous. A row similar to one of your "schedule" rows that says:
"If @ <TIME> <PARAMETER> is <OPERATOR> to <VALUE> then <VERB> <OBJECT> [<SET_VALUE>]"
Each of the fields is a drop down, and when setting them from left to right, the appropriate selections for the remaining fields become available in their drop down lists (thus preventing illegal rule creation. The time filed is a selector that can set/hours/mins/intervals.
Example values (these are just a few off the top of my head):
| PARAMETER | OPERATOR | VALUE | VERB | OBJECT | SET_VALUE |
| CABLE_ATTACHED | <> | TRUE | EMAIL_TO | HVAC | 0-XXX |
| SOC | >= | 0-XXX | TEXT_TO | CHARGER | ON |
| INTERIOR_TEMP | <= | NORTH | SET | TEXT_ADDR | "TEXT' |
| DRIVE_SELECTED | = | ON | TURN_OFF | SUNROOF | SMTP_ADDR |
"IF @11:00PM CABLE_ATTACHED IS <> TRUE THEN TEXT_TO (703)555-1234 "Cable Not Plugged In!"
"IF @4:55PM INTERIOR_TEMP IS > 75 THEN SET HVAC 70"
"IF @EVERY_HOUR SOC IS < 50 THEN SET CHARGER ON"
Obviously some tings may take some configuration elsewhere in the UI, such as setting the SMTP server, etc...
As things progress it might be desirable to allow multiple boolean evaluations per rule. It also may be useful to have your schedule be able to fire a rule at a specific time.
Just thoughts...
dsmith2189
Active Member
Similar threads
