Not at the moment. Haven’t really gone looking for it. Without access to the diagnostics screens, it is not at all easy to find that stuff. If we have a screen that says metric X is Y, we can go looking in the data for all the different encoding formats of Y. Then, if we can see Y change over time, we can double-check and confirm we are looking at the right thing. But, without being able to see X or Y, it is hard to know where to start.

At the moment, I’m just looking at basics (drive/park, speed, SOC, charge port, charging/driving, etc). Essential stuff that I can see.

Jason did ‘publish’ a document with quite a few messages decoded:

https://skie.net/uploads/TeslaCAN/Tesla%20Model%20S%20CAN%20Deciphering%20-%20v0.1%20-%20by%20wk057.pdf

and the shack team decoded a bunch more. In particular, the work on 6F2 (which gives individual battery module/brick voltages and temperatures) is impressive. But, that list died down in 2016 and I haven’t seen much on this lately.

I originally started work on Model S support purely because that is the car I drive, and I want OVMS in it. The Tesla App is pretty good, so not much requirement for OVMS. But, a few things have become apparent:

  1. There is a huge amount of valuable data on the bus not available to the Tesla App (or even on user visible screens). Things like battery module voltages and temperatures, actual battery kWh levels, etc.

  2. We can do things like logging of charges/drives, as well as automation. And do it in a way that we aren’t continually worried that Tesla is going to cut off access to their API.

  3. I am hoping to get the available data organised, and use this as a test case for development of the RE tools in OVMS v3. I want to be able to tell RE I am working on DBC (or whatever format) file X - have it load all that in and start capturing data from the car. Then be able to type commands to dynamically change the DBC mappings, so mapped metrics, and have RE keep the actual DBC file up-to-date with those changes (as well as upload the results to a public server where it can be shared). Open Vehicles - our original goal. Now that we have lots of SPI ram, this should be feasible.

  4. The ultimate goal is to be able to code vehicle support without coding. Have an ‘OvmsVehicleDBC’ class (derived from OvmsVehicle) that takes a DBC file (or whatever format we end up with) and produces all the metrics we need automatically. Zero coding. And the RE tools can be used for the engineering to get the values. Imagine looking for SOC in a car. You find it with RE, tell RE that is v.b.soc (this byte, this bit, this format, etc), and the vehicle module using that DBC immediately picks up on the change and sends the SOC to a connected App.

P.S. I did a drive to work this morning with OVMS to hotspot on phone, and phone showing web dashboard (using .local address). Very very cool. The gauge animation is awesome. I even managed to get up to 160kph on the dashboard - now I just need to fix that pesky kph/mph support so that it shows my correct speed (100kph not 160).

Regards, Mark.

On 10 Apr 2018, at 11:38 PM, Tom Saxton <tom@idleloop.com> wrote:

Do you get a calculated amp-hour capacity (CAC) value on the Model S?

    Tom

-----Original Message-----
From: OvmsDev <ovmsdev-bounces@lists.openvehicles.com> on behalf of Mark Webb-Johnson <mark@webb-johnson.net>
Reply-To: OVMS Developers <ovmsdev@lists.openvehicles.com>
Date: Tuesday, April 10, 2018 at 1:30 AM
To: Stephen & Karen Casner <casner@acm.org>
Cc: OVMS Developers <ovmsdev@lists.openvehicles.com>
Subject: Re: [Ovmsdev] ssh: secure mode prompt not set #31


   Thanks, Steve. I will try it in a few minutes.

   P.S. I’m about to drive home in my Model S, with the vehicle module actually running for the first time. I’ve got speed, soc, and park/drive support working on Tesla Model S (probably) so will finally have something to see on the web dashboard.

   Regards, Mark.

On 10 Apr 2018, at 2:41 PM, Stephen Casner <casner@acm.org> wrote:

Mark,

What this really means is that my previous implementation of the
secure mode prompt was in the wrong place.  I've fixed it, isolating
the setting of the prompt into OvmsShell.  This removes the
SetPrompt() API from OvmsWriter, which is good, at the cost of making
SetSecure() virtual.

                                                      -- Steve

On Tue, 10 Apr 2018, Mark Webb-Johnson wrote:


Steve,

Can you have a look at this one:

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/31 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/31>

When connecting to the box via ssh, using a trusted ssh.keys mechanism, it seems that the session is correctly put into secure mode (enable). But, the prompt is OVMS> (should be OVMS#). The full set of enable commands is shown, so pretty sure the session is in enable mode.

I think the issue is purely the prompt being incorrect.

I think (hope) it should be simple.

Thanks, Mark.

   _______________________________________________
   OvmsDev mailing list
   OvmsDev@lists.openvehicles.com
   http://lists.openvehicles.com/mailman/listinfo/ovmsdev



_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev