Vendor Official Tessie app talk

[gtg465x]

If this value matches what the car displays on the screen, then it will be wrong, as was pointed out.

It is pretty well understood and documented that the “energy added” value on the screen is incorrect, and can be made correct for most Model 3 (no idea how it works in the presence of a varying buffer size for the LFP) by multiplying that value by 0.955.

So it would seem preferable to do that, otherwise it is just very confusing.

I guess the API does not provide this “correct” value, so the difficulty is understood - and users will wonder why the value does not match the screen if this change were made, of course.

But: With the current reporting, users will continually wonder why they get 5% less energy out (energy including heat losses) than the car measures was put in (net). So confusion there too.

Still, seems better to just report the correct value which the BMS has (which fortunately is available after the translation).

I guess it depends on objectives but reporting the correct value and then providing a little “I” information note explaining the discrepancy seems best.

To be clear the energy added is not strictly the energy added even after this correction. It is the net energy difference in the battery that the BMS detects since the car was plugged in. If you use 20kWh with the heat while plugged in, none of that will be counted, of course. It’s not metering the input energy.

It is just miles added reported by the BMS (the delta) times the constant as @AAKEE indicates. The number can decrease while plugged in if the BMS decides to do so. Though I think it probably cannot go negative (a special case which is possible but unlikely).

I guess in a sense it is arbitrary here. As currently reported, users will see they have 4.5% better charging efficiency than they actually have, with 4.5% worse driving efficiency than “expected” (when they total up all their drives over time they’ll see the energy is low by 5%, neglecting standby losses - so this mismatch will likely be interpreted as phantom drain even though it is not).

Is this why my lifetime trip meter in the car shows 215 Wh/mi and Tessie shows 229 Wh/mi? I have a 2023 RWD with LFP battery, so dynamic buffer I guess. At first I assumed the difference was because I didn’t install Tessie until 45 miles on the odometer, but after 1000 miles, I realized they don’t seem to be getting any closer. Then I started to suspect the car was only counting Wh used for moving the car and not for climate and accessory usage, but Tessie was including all energy consumed during drives. Now I just have no clue which is right.

 

[James@Tessie]

Is this why my lifetime trip meter in the car shows 215 Wh/mi and Tessie shows 229 Wh/mi? I have a 2023 RWD with LFP battery, so dynamic buffer I guess. At first I assumed the difference was because I didn’t install Tessie until 45 miles on the odometer, but after 1000 miles, I realized they don’t seem to be getting any closer. Then I started to suspect the car was only counting Wh used for moving the car and not for climate and accessory usage, but Tessie was including all energy consumed during drives. Now I just have no clue which is right.

Both are estimates so neither are truly accurate (it takes special lab equipment to really accurately figure this stuff out.)

The in-app energy meters skews the results downward with its various secretive maths

Here's an example of Tessie's calculation, which is pretty straightforward:

If your battery is charged to 100% and has a 100 kWh capacity, and your battery goes from 100% to 75% after a drive, that means the drive used 25 kWh.

If the drive was 75 miles: 25 (total kWh used) / 75 (total miles driven) = 0.333 kWh/mi = 333 Wh/mi.

 

[AlanSubie4Life]

Is this why my lifetime trip meter in the car shows 215 Wh/mi and Tessie shows 229 Wh/mi?

I have no idea how the Tessie number is calculated so I don’t know. (One way would be to count all the charge sessions’ energy added according to the car and divide by miles traveled and assume same SOC at both ends of measurement - this would give a high result by 4.5%, and you’d have to account for phantom drain somehow - I have no idea like I said…)

The 215Wh/mi number is closer to correct (if you want to know your driving efficiency not including phantom drain). It may be slightly low relative to the energy drawn from the battery. I usually see it being about 1% lower than what the CAN bus readers say the consumption was. Though I do not have a CAN reader so have to rely on others’ data. (Or just use the 234Wh/rmi (displayed) number for my vehicle as gospel, which it is.)

If your battery is charged to 100% and has a 100 kWh capacity, and your battery goes from 100% to 75% after a drive, that means the drive used 25 kWh.

Edit: Ok. Yes. So this very logical method would result in a number about 5.5% (not 4.5%) higher than the trip meter displays, in my experience. Seems to match the observation above.

The trip meter is closer to correct, if you want to know how much energy you used. As I said it seems to read about 1% low as compared to the CAN bus delta. (Explains the 5.5% vs. 4.5%) And it is not really secret, to be fair! It is quite straightforward!

Anyone can observe this themselves without any apps or CAN bus (that’s what I did several years ago and used the CAN bus data from other owners to confirm my observations).

You just need to compare rated miles used to the trip meter on long trip segments. (Though I think they may have removed a significant digit recently so it is harder now?)

Separately the car provides the true charging constant, via the energy screen, which can be determined via one of about four different methods from the data provided there. (I’ve listed them elsewhere.)

Then you’re done. It’s very simple. There are just three or four numbers and some division/multiplication. If you search around I’ve shown examples about 100 times, I would estimate.

 

[AAKEE]

If your battery is charged to 100% and has a 100 kWh capacity, and your battery goes from 100% to 75% after a drive, that means the drive used 25 kWh.

It is not that easy.

For a model 3, if the battery had a 100 kWh capacity and went from 100 to 75% the drive used 25% of the capacity exluding the buffer. Each displayed percent is 0.955% of battery capacity.

That would be 0.25 x 0.955 x 100, so 23.875 kWh.

If the drive was 75 miles: 25 (total kWh used) / 75 (total miles driven) = 0.333 kWh/mi = 333 Wh/mi.

The above of course 0.955 affects the consumtion value as well.

 

[James@Tessie]

It is not that easy.

For a model 3, if the battery had a 100 kWh capacity and went from 100 to 75% the drive used 25% of the capacity exluding the buffer. Each displayed percent is 0.955% of battery capacity.

That would be 0.25 x 0.955 x 100, so 23.875 kWh.


The above of course 0.955 affects the consumtion value as well.

Yeah, for sure, was just simplifying. Would certainly be nice to know the buffer programmatically so it could be included in the breakdown.

 

[AlanSubie4Life]

If your battery is charged to 100% and has a 100 kWh capacity, and your battery goes from 100% to 75% after a drive, that means the drive used 25 kWh.

If the drive was 75 miles: 25 (total kWh used) / 75 (total miles driven) = 0.333 kWh/mi = 333 Wh/mi.

Yeah, for sure, was just simplifying. Would certainly be nice to know the buffer programmatically so it could be included in the breakdown.

Yeah, it is kind of insane that the API doesn’t let you pull the trip meter! (Apparently.)

What else is available in the API that would be relevant? It sounds like there is no way to deduce the buffer size with available API data? This must be why all the apps have such a difficult time with this!

 

[James@Tessie]

Yeah, it is kind of insane that the API doesn’t let you pull the trip meter! (Apparently.)

What else is available in the API that would be relevant? It sounds like there is no way to deduce the buffer size with available API data? This must be why all the apps have such a difficult time with this!

Yeah, there's not (yet, anyway.) Maybe with a reaaaallly big data set and a lot of confidence that the BMS is well-calibrated you could deduce it, but certainly nothing that would be even close to reliable enough.

 

[AlanSubie4Life]

Yeah, there's not (yet, anyway.) Maybe with a reaaaallly big data set and a lot of confidence that the BMS is well-calibrated you could deduce it, but certainly nothing that would be even close to reliable enough.

Yeah. It’s interesting that they provide less information to the API in this regard than they do to the driver. So the driver can work it out, but not the app!

Have to scrape the CAN bus data from all the different models using all the screenshots posted on the internet I guess. Then use that correction factor.

 

[Mobile3228]

Can't you make it so that you can enter the buffer size manually for those who are concerned about this?

 

[AAKEE]

Is this why my lifetime trip meter in the car shows 215 Wh/mi and Tessie shows 229 Wh/mi?

The explanation james@tessie gave will cover most of the difference.

The car measures the energy that goes from the battery. Should be fairly correct (most probable within 1% of true value).

The Tessie way of calculating this use a value of [added energy] that is not correct, as it includes a bit of the buffer that actually was not used. Tessie calculates the energy by using 1% of the totalt capacity (incl. buffer) but each 1% displayed is only 0.955% of the battery capacity.

1/0.955 —> 4.7% to high consumption in tessie due to this.

229/225 = 6.5% too much, but phantom drain and AC/heating when in park is not included in the cars displayed consumption.

Most probable, the remaining 1.8 % in your case is probably AC in park etc. as described above.

 

[AAKEE]

Can't you make it so that you can enter the buffer size manually for those who are concerned about this?

For all M3 Long range and Performance so far, its 4.5%.
If the wording ”usable” is used in the app, the buffer should be exluded from the number shown. This because more or less anyone on the planet interpret this as ”excluding the buffer”.
Even if we know the bigger part of the buffer can be used for driving, *any* Tesla owner will read “usable” as excluding the buffer.


Some model S use a more fixed buffer in kWh. I havent studied it enough to say.

 

[AlanSubie4Life]

Most probable, the remaining 1.8 % in your case is probably AC in park etc. as described above

If you assume Tessie can accurately determine when the car enters Park (including when not exiting the vehicle), the consumed miles (or % corrected for capacity loss) the app measures should be able to include only the driving use in the reported value.

This is poorly phrased. Anyway I am saying that theoretically the comparison here should be direct - should compare driving rated miles used tabulated by Tessie (converted to kWh), divided by miles traveled (gathered by Tessie). And that can be compared directly to the trip meter.

No phantom drain theoretically should enter into it - with the key assumption that the app knows when to stop counting rated mile use (knows exactly when the car enters and exits park).

Not knowing anything about the API details or app implementation, I have no idea where the count might get disturbed. But presumably apps try to keep track of energy use (and spontaneous gain) while in park and tabulate that separately.

(To be clear that conversion of rated miles to kWh is key and the 0.955 factor you mention certainly does enter into it!)

 

[AAKEE]

Anyway I am saying that theoretically the comparison here should be direct - should compare driving rated miles used tabulated by Tessie (converted to kWh), divided by miles traveled (gathered by Tessie). And that can be compared directly to the trip meter.

No phantom drain theoretically should enter into it - with the key assumption that the app knows when to stop counting rated mile use (knows exactly when the car enters and exits park).

When using the [added energy] (the buffer question not relevant) you measure what goes into the battery. Any battery has heat losses, that heat the battery.

The car itself measures the energy out from the battery and this will not include the heat losses.

We will see a difference here, how big is is will depend on for example the speed driven (higher speed - higher battery power - higher losses).
If I remember ut correctly you ( @AlanSubie4Life) usually add some 1% to the calculations for this reason?

I tried to simplyfy the answer by using phantom drain instead of a long description
(I’m known for loooong explanations, but every time I try shorten them, I fail
In the Swedish Air Force there a drink called up after me: Long drink )

Not knowing exactly, as you say how precise Tessie ( = the API) can define drives it is probable that some parked time is included.
If selecting park but not exiting the vehicle the drive do not reset the counters for “this drive” in the car. Still, it seem like the energy does not count.
I think selecting park but not exiting the car does not trigger “a new drive” in teslafi that I use. But exiting the vehicle even briefly, for like 30s does. I think.

[Edit] I checked a drive from a few days back in teslafi. I went up on a ski resort, before driving back from a mountain, I put in park and exited the vehicle for like 1 minute. Then drove back.
It is counted as one single drive in this case in teslafi.

 

[insaneoctane]

...

James, I've seen @AlanSubie4Life answering Battery/BMS/capacity math/ questions for years now and would consider him very knowledgeable and a SME on this topic. He would be a great resource to consider exchanging methods and approaches to increase the accuracy of Tessie's battery reporting methodology. Utilizing his advice will likely make your product better for all of the users! Just an opinion.

 

[AlanSubie4Life]

James, I've seen @AlanSubie4Life answering Battery/BMS/capacity math/ questions for years now and would consider him very knowledgeable and a SME on this topic. He would be a great resource to consider exchanging methods and approaches to increase the accuracy of Tessie's battery reporting methodology. Utilizing his advice will likely make your product better for all of the users! Just an opinion.

Thanks for the shoutout.

I am happy to help here privately if desired. However, I have no experience with the API or other subtleties that may arise in coding such an app.

I just know how things actually work (empirically, based on SMT observations combined with in-car observations).

Unfortunately in this case I think there are limitations to the API (but maybe not - just am not familiar enough with it - but sounds like that was confirmed) which make certain things difficult or impossible to actually get the correct data gathered from the car using only the API.

So if so, then the only solution left is to hard code certain scalings based on identified vehicle type into the code. And it sounds like that is not desired by this developer since it requires certain empirical knowledge based on CAN reads about every vehicle.

The suggestion to allow user scalings is an interesting one but that is kind of a support issue as well.

It would be best if the car API just provided the right info.

 

[AAKEE]

Thanks for the shoutout.

It would be best if the car API just provided the right info.

Yes, it would. I guess Tesla wont listen…

The next best would be the apps to be as accurate as possible with the available data.

 

[insaneoctane]

... However, I have no experience with the API or other subtleties that may arise in coding such an app.

I just know how things actually work (empirically, based on SMT observations combined with in-car observations).

Unfortunately in this case I think there are limitations to the API (but maybe not - just am not familiar enough with it - but sounds like that was confirmed) which make certain things difficult or impossible to actually get the correct data gathered from the car using only the API.

So if so, then the only solution left is to hard code certain scalings based on identified vehicle type into the code. And it sounds like that is not desired by this developer since it requires certain empirical knowledge based on CAN reads about every vehicle.

The suggestion to allow user scalings is an interesting one but that is kind of a support issue as well.

It would be best if the car API just provided the right info.

I was just thinking of the math behind the available data. James@Tessie seems to understand the buffer and confusion it creates. I actually like your idea about reporting it accurately with an (i) or *...Maybe even a user-selectable option between matching the car GUI (but inaccurate) or accurate. I like the idea of making the reporting as accurate as possible.

 

[coco135]

Just found this thread, Tessie has the best design and features by far and well worth the sub cost.

Personally I am VERY excited for a proper Apple Watch app that use BT, I know some others already have that but I'm sure Tessie will out do them.

If you need Beta testers on Apple Watch Ultra...i'm here.

 

[James@Tessie]

Just found this thread, Tessie has the best design and features by far and well worth the sub cost.

Personally I am VERY excited for a proper Apple Watch app that use BT, I know some others already have that but I'm sure Tessie will out do them.

If you need Beta testers on Apple Watch Ultra...i'm here.

Me too! It's coming along.

 

[johnny_cakes]

Original capacity is the average BMS measurement taken at ~0 mile odometer of all Tesla owners with the same configuration. If Tesla changes battery manufacturing processes in the middle of the year, you replace your battery, etc. then it'll be wrong. You can fix it by tapping the capacity.

If this value matches what the car displays on the screen, then it will be wrong, as was pointed out.

It is pretty well understood and documented that the “energy added” value on the screen is incorrect, and can be made correct for most Model 3 (no idea how it works in the presence of a varying buffer size for the LFP) by multiplying that value by 0.955.

So it would seem preferable to do that, otherwise it is just very confusing.

James@Tessie, given that the "Usable Capacity" on the health page includes the buffer, should we be using the nominal original capacity in order to get an accurate before and after capacity comparison? For example, for my 2019 Model 3 SR+, Tessie recommends 51.6 kWh for the original capacity:

...but I believe that would be the "original usable capacity" and does not include the buffer. So should I bump that to the original nominal capacity to include the buffer to match the current capacity which also includes the buffer? If so, does anyone know what the original nominal capacity of my model would be?