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.
brianman is correct, CW00 it is.

Also a small update on curl calls, I now receive an error code:

Code:
$ curl -b cookie.dat  -i https://portal.vn.teslamotors.com/vehicles/15xxx/command/vehicle_state   # Now using "id" instead of "vehicle_id"

{"error":"vehicle unavailable (408)"}

Car is at work, charging, a five minute walk away, so I am not able to check if it is sleeping just now. I'll bring along the Mac and try within a couple hours. When I parked the car a little while ago, I made sure remote access is ON.
 
Honestly I would be shocked if it worked well. JavaFX (which I'm using) uses resources (CPU and memory) like there is no tomorrow. I'd be happy to be wrong and see it work well. It could be a cool demo. I won't be trying this for a while. I'm on the road for a few weeks and have some other issues to deal with when I get free cycles after work. I would be happy to look at any logs you can send in test form.

Joe

I made a little progress loaded JavaFX which is rumored to run well on the pi. Here is what I get now.
Code:
/opt/jdk1.8.0/bin/java -jar VisibleTesla.jar
Exception in Application start method
Exception in Application stop method
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:491)
        at com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:351)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:491)
        at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:299)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:491)
        at sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:767)
Caused by: java.lang.RuntimeException: Exception in Application start method
        at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:868)
        at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:55)
        at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:157)
        at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.NoClassDefFoundError: javafx/fxml/FXMLLoader
        at org.noroomattheinn.visibletesla.VisibleTesla.start(VisibleTesla.java:44)
        at com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:811)
        at com.sun.javafx.application.PlatformImpl$7.run(PlatformImpl.java:331)
        at com.sun.javafx.application.PlatformImpl$6$1.run(PlatformImpl.java:297)
        at com.sun.javafx.application.PlatformImpl$6$1.run(PlatformImpl.java:294)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.sun.javafx.application.PlatformImpl$6.run(PlatformImpl.java:294)
        at com.sun.glass.ui.lens.LensApplication$RunnableEvent.dispatch(LensApplication.java:197)
        at com.sun.glass.ui.lens.LensApplication._runLoop(LensApplication.java:880)
        at com.sun.glass.ui.lens.LensApplication.access$1700(LensApplication.java:56)
        at com.sun.glass.ui.lens.LensApplication$4.run(LensApplication.java:933)
        ... 1 more
Caused by: java.lang.ClassNotFoundException: javafx.fxml.FXMLLoader
        at java.net.URLClassLoader$1.run(URLClassLoader.java:359)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:348)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:347)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
        ... 12 more
Exception running application org.noroomattheinn.visibletesla.VisibleTesla
 
VT is built on Java 7 and JavaFX 2.2. It's never been compiled or built against Java 8 and the corresponding JFX library. If v7 is available for the rpi, you might try that. Otherwise you could download everything from github and try porting it. I don't have any perspective on how big the changes are.

I'd love to hear about any progress you make or roadblocks you hit.
 
Last edited:
Excellent. Obviously a mistake on my part. I'll update the client library with the newly discovered options and send a note to the document maintainer to add the info.

--- Update ---

I left a comment listing the four newly discovered options on the google doc that's maintained by John Tamplin. He usually checks and integrates comments pretty quickly. I also updated TeslaClient and pushed a new version out to GitHub.

A new version of VisibleTesla will be forthcoming. I've been on the road for the last 10 days or so (doing my real job - launching a new version of our product!).

I haven't had time to do much. I've mostly still been doing battle with the Graphs Tab. I finally gave up and decided to subclass some of the key JavaFX classes to to speed them up for the use cases I care about.

Also, the new version will load data into the graph into two phases. It will first load the series that you have selected as visible, then it will load the other series in the background. The chart is usable the whole time, you'll just see the data being loaded from newest to oldest. Selecting and deselecting which series are displayed will also be much faster.
 
Last edited:
VT is built on Java 7 and JavaFX 2.2. It's never been compiled or built against Java 8 and the corresponding JFX library. If v7 is available for the rpi, you might try that. Otherwise you could download everything from github and try porting it. I don't have any perspective on how big the changes are.

Is love to hear about any progress you make or roadblocks you hit.

I'll keep playing with it.

It looks like there are quite a few versions avaliable.

Oracle just released JRE and JDK 7 for the pi and they have a "fxarmpreview" version 8 avaliable.

There is also versions of OpenJDK 7 and 8...
 
brianman is correct, CW00 it is.

Also a small update on curl calls, I now receive an error code:

Code:
$ curl -b cookie.dat  -i https://portal.vn.teslamotors.com/vehicles/15xxx/command/vehicle_state   # Now using "id" instead of "vehicle_id"

{"error":"vehicle unavailable (408)"}

Car is at work, charging, a five minute walk away, so I am not able to check if it is sleeping just now. I'll bring along the Mac and try within a couple hours. When I parked the car a little while ago, I made sure remote access is ON.

That will definitely stop VT from doing anything useful. Hopefully you can get some input from Tesla on what's going on.
 
For those who build VT on their own from sources: DO NOT UPGRADE to the latest (jdk-7u45) with the latest NetBeans (7.4)!

I've had nothing but grief and have had to painstakingly revert back to jdk-7u25 and NetBeans 7.3.1 to make things work reliably.

The newest release hangs at the drop of a hat. If I was lucky I could get a build done between hangs, and there were actually some bugs that are fixed in the latest version (eg context menus work better), but overall it is unusable (on a Mac anyway).
 
That will definitely stop VT from doing anything useful. Hopefully you can get some input from Tesla on what's going on.

Yep, have an appointment with Tesla SC Monday to upgrade firmware. The technician I spoke with on the phone also claimed there were issues outside Tesla's control, related to the 3G provider Telenor in Norway. So hopefully they'll figure everything out on Monday.
 
Streaming Location Support

I've been experimenting with adding streaming support to the Location tab. In the experimental version the behavior is as follows:

  • When you first go to the tab it updates as usual and shows a map with the car's current location. The only difference you'll notice is that you won't see the "spinner".
  • If the car is moving, the app will receive location updates at a rate of up to 4 per second. This rate is not guaranteed. The app keeps reading updates as long as Tesla sends them.
  • The car's position on the map is updated at a rate of up to twice per second (again, not guaranteed). The marker remains centered on the map. I.e., the map moves, the car stays in the center of the map area. That's the same as it works today, but the updates are 20 seconds apart rather than 0.5 seconds apart.
  • If the car stops moving for over 5 seconds, streaming will cease. This can also happen if the car is in motion, but Tesla's servers simply are not sending updates for some reason (e.g. they are backed up).
  • At the next auto-refresh interval (20 seconds), the app will check the car's location again and will begin streaming again if the car is moving.
  • Of course if you manually hit the refresh button this will happen sooner.
  • If the app enters sleep mode or daydreaming mode, location updates (including streaming updates) will cease just as they do now.

The map updates are a little jerky right now, but I believe there is a way to make the map smoothly pan locations rather than jump. Any hints from Google Maps experts are appreciated.

I'd also love to hear from the teslams folks or any REST API experts regarding how long one can stream data from Tesla before they feel that their servers are being overtaxed. I apply rate limits on the REST calls, but there is just a single call to set up the streaming and then their servers can return data for minutes.

I'm back on a plane tomorrow morning and I haven't been able to test tonight's changes yet so I won't release this until I get back. It's time-consuming to test this stuff because the car needs to be in motion and I need to be at a computer.

I had an interesting thought and have no idea whether this is possible - virtual driver mode. Right now you see a birds eye view of where the car is. Imagine going into Google's Street View mode. You'd see on the screen what the driver is seeing out the windshield! Of course there aren't street view images for every location, but it could be pretty cool in areas that have coverage.

Anyway, that's just a thought for the future. I've got to get the basics working first and find a few brave souls to try it out.
 
I had an interesting thought and have no idea whether this is possible - virtual driver mode. Right now you see a birds eye view of where the car is. Imagine going into Google's Street View mode. You'd see on the screen what the driver is seeing out the windshield! Of course there aren't street view images for every location, but it could be pretty cool in areas that have coverage.

Anyway, that's just a thought for the future. I've got to get the basics working first and find a few brave souls to try it out.

Ooh... that would be cool. And isn't it possible to control direction with street view? So you could virtually look out the front, side or back windows?
 
Ooh... that would be cool. And isn't it possible to control direction with street view? So you could virtually look out the front, side or back windows?

I have built something very similar using the Google Earth API V3. It looked very cool. I remember that there is a limit to how many images Google will let your app download per day without a Business license.

dirkhh's "visualize" app allows Google street view but it doesn't follow the car. You can position yourself as if you were a pedestrian and watch the pushpin drive past you.
 
For those who build VT on their own from sources: DO NOT UPGRADE to the latest (jdk-7u45) with the latest NetBeans (7.4)!

I've had nothing but grief and have had to painstakingly revert back to jdk-7u25 and NetBeans 7.3.1 to make things work reliably.

The newest release hangs at the drop of a hat. If I was lucky I could get a build done between hangs, and there were actually some bugs that are fixed in the latest version (eg context menus work better), but overall it is unusable (on a Mac anyway).
I just had a note come across my desk to day wrt a problem that some people were having with a java application not working properly after upgrading to the latest Java. this may or may not help with VT.
their java.policy file (at C:\Program Files (x86)\Java\jre7\lib\security\ in win7) was missing a permission line.
the solution was (as an administrator) to add the following line to the list of permissions inside the grant {...} block.
permission java.util.PropertyPermission "user.timezone","write";
then save the java.policy file.
Remember to back up your file before making changes.
 
Is there a way to choose between different cars associated with one set of log on credentials?

I think that function isn't in the current release of the software, but the Author is working on a solution.

A current work around is to have two instances of the program open and have each one point to one of your cars, but I don't know multiple cars, so I don't know if it will actually work.
 
Is there a way to choose between different cars associated with one set of log on credentials?

Yes, when you start the app you'll be presented with a dialog asking you which car you want to connect to. A user with two vehicles confirmed that this works. At this point I can't confirm any way of switching vehicles other than quitting and restarting. Logging out and in again should work, but I can't test it. If you check earlier in this thread you'll see a discussion about this. This feature wasn't added until a fairly recent version.
 
Is there a way to choose between different cars associated with one set of log on credentials?

Yes, when you start the app you'll be presented with a dialog asking you which car you want to connect to. A user with two vehicles confirmed that this works. At this point I can't confirm any way of switching vehicles other than quitting and restarting. Logging out and in again should work, but I can't test it. If you check earlier in this thread you'll see a discussion about this. This feature wasn't added until a fairly recent version.

Hi Bill,

I can verify that if you have more than one car associated with your Tesla account, a dialog box will appear upon login which will present you with options to choose which car you wish to connect to. As suggested earlier in this thread, the best way not to mix up the data between the 2 cars is to make a duplicate copy of VT from the start and log into each car separately.
 
VisibleTesla 0.21.00

Version 0.21.00 is available here. As always, thanks to the pioneers out there who try this first.

VisibleTesla 0.21.00
[10-27-13]
  • User-Visible Changes
    • General
      • Various small bug fixes.
      • Added "Check for Updates" functionality. This is the first step towards auto update. When the app launches it will check the web for a newer version. If there is one, a dialog box will be displayed with a download link and a link to the new release notes. It will only do this once per week. If you want to check for a newer version earlier than that, use the "Help->Check For Updates" menu item.
      • Additional error handling if VisibleTesla is unable to communicate with the car. For example, if the car is sleeping and can't be awoken.
      • Fixes to a few edge cases in the way inactivity is handled.
      • Updated the look of dialog boxes to be more native to the platorm (Windows, Mac, Linux) than they used to be. This primarily affects the window borders and controls. The content of the dialog boxes remains the same.
    • Login
      • Added additional error handling and feedback for failed login attempts.
    • Overview
      • Added statistics to the Details dialog that reflect the amount of calls to Tesla's servers over the last 10 seconds, the last minute, and the last hour.
      • Several new vehicle options are now recognized and will be displayed in the Details dialog. These include things like the Cold Weather Package, the Parking Sensor option, the Lighting package, and the Security Package.
    • HVAC
    • Location
      • Experimental support for streaming updates to the map location. In this version the location of the marker will update in near-real-time as the car is moving. The frequency of updates is a maximum of 4 times/second, but may not be at that rate. There may be times when Tesla's servers do not stream at that rate or network delays slow down the updates. It will continue to auto-refresh every 20 seconds as usual.
    • Charge
    • Graphs
      • More work to overcome limitations in the underlying graphing library. Statistics are now loaded in the background starting from the present time and working backwards to the oldest statistics. This allows the user to see and start interacting with the most recent data in the graph right away.
      • While loading, the Graphs tab now displays a two-part progress bar along the bottom of the tab. The first part of the progress bar represents the progress in loading the visible series. Those are the series that are selected in the "Show Items" drop down list. Visible series are loaded first. The second part of the progress bar represents the progress in loading the currently hidden series. The size of these two parts are proportional to the number of hidden and visible series. For example, if 4 of the 8 possible series are visible, then the two parts of the progress bar will be the same size. If 2 of the 8 are visible, then the first part will be a quarter of the total size and the second part will be three quarters.
      • The goal of all of this is to make the Graphs tab provide useful information as quickly as possible while loading all other data in the background.
    • Scheduler
  • Under-the-covers
    • Changes to the TeslaClient library: Remove unused code, add usage statistics, update tests.
    • Changes to the JavaFX LineChart and XYChart classes for better performance. This is achieved through subclassing, not changes to the core library.
    • Fairly major changes to the code to work around graphics performance issues - at least to make performance tolerable for "large" datasets.
    • Forked the javafx-dialogs code to add the ability to get a more native look on each platform. Updated the README.md file to reflect where to download my forked version. Trying to figure out how to get it integrated into the main repository.
  • 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. This appears to be fixed with the latest version of Java (1.7u45). This version is not recommended for developers, but seems to be fine for users.
 
Last edited:
My VT 0.21.00 locks up on the graph page. the data loading bar on the bottom only gets to about 60% and the entire window goes blank.
If you'd like, you can send me your data file, your OS type and version (e.g. Windows 7 64bits or Mac OSX 10.8.5), and the version of java you're running, and I will try to reproduce the problem. Also, if you have the tesla.log file, that could help too.


--- Update ---

Thanks for sending me your files. I was able to load your data on my Mac with no problems. When I tried to load it in Windows (running in a Virtual machine) it hung - same as for you. Upon further investigation it appeared to be a memory issue. By allocating more memory to java it ran properly on Windows. Initial investigation shows a massive amount of memory being allocated as the graph is being loaded. The memory tops off when the graph completes loading and stays level at that point. I haven't been able to determine yet whether there is a memory leak, or that's just how much memory JavaFX uses for the graph. I will investigate this further.

If you'd like to try an experiment, you can use the CMD prompt to CD to your VisibleTesla folder and then type the following command:

java -Xmx1500m -jar VisibleTesla.jar

This runs the application but tells the system to provide more memory (1.5GB in this example). When I tried this in Windows it worked just fine. With your data set it appears that the actual memory used stabilizes at about 500MB, but it grows larger than that temporarily.

I'll pursue the problem further to determine whether this amount of memory usage is "normal" or whether references are being left laying around so that memory is accumulating.

I appreciate learning about this problem - sorry it's causing you grief.
 
Last edited: