-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Awesome iOS App called Stats
- Thread starter mswlogo
- Start date
Yes please!!
I don’t think I would want the app to independently set the charge higher than I did... but if we could play with the settings, I would be happy with that.
Can’t wait for this feature.
Especially with these single digit temps lately. I’ve noticed something weird with my battery health and rated range at 100% SOC. Had the snowflake icon last night and the app recorded an abnormally low number data point of 280 in the battery health graph. I put the car on the charger....and as the battery charged and heated..the Rated range at 100% on the first screen (top right dial) started going back up to over 300 as the car charged and battery warmed up. This morning another data point of over 300 (but still lower than usual) was recorded in the battery health.
My issue is I feel like that 280 on the battery health graph artificially lowers the trend line. Is there a way to delete those data points? It seems like when its cold I get lower data points (low 300’s) and when its warmer I get data points back up closer to 310. Is this typical? Or is my battery really taking a dump?
My issue is I feel like that 280 on the battery health graph artificially lowers the trend line. Is there a way to delete those data points? It seems like when its cold I get lower data points (low 300’s) and when its warmer I get data points back up closer to 310. Is this typical? Or is my battery really taking a dump?
Yeah, I had not observed this until the latest update (perhaps occasionally I would see the mile tick up by a mile or so when I was sitting in the car, but nothing like this - it always went down!).
To be clear, this was the rated range indication that changed; it was the battery bar at the top of the screen. 210 miles last night, 217 miles this morning, unplugged overnight. The available energy seemed to "stick" - I had to drive about 10 miles (downhill a bit from Scripps Ranch to the I-15/CA-163 merge) to get back to 209 miles).
Did you have a snowflake when you parked it? I believe when the battery is cold and presents a snowflake it will subtract miles of range that are “temporarily” unavailable. When the battery warms up, those miles of range are recovered. The App needs to be aware of the “snowflake” and not mix that with vampire drain.
Also when you turn on cabin heating it now appears to do some battery heating ( like it or not ). I have not figured out all the criteria of when it decides to heat battery along with cabin heating yet. I suspect (and hope) it’s only when there is a snowflake. I do know it will pre heat battery with remote cabin heat even when not plugged in (which I don’t like at all).
AlanSubie4Life
Efficiency Obsessed Member
Outside temp was 57 degrees when I parked. About 60 something in the morning in the garage. I have never seen the snowflake and probably never will unless I go on a winter road trip.
There was no remote heating done.
I had lost 12 miles in 3 hours earlier in the day, so I am sure that had something to do with it. State of charge estimation just lost track of a couple kWh somehow.
In the picture below, I started at 254 miles earlier, at work, and I did not use HVAC at all in those 17 miles of driving. Full details posted elsewhere.
My plan is to reduce the charge limit for overnight charging and then increase it to the usual limit close enough to the specified end time.
This is a big feature and requires a lot of code and testing.
The trend line is computed in such a way that outliers do not influence it much.
It is normal to lose some range at the beginning (first few thousand miles). The rate of loss decreases. See the attached image.
Here is the source of the attached plot:
TESLA BATTERY RANGE DATA
Attachments
A new version of the app was released today.
Two new features:
Two new features:
- The app now computes the cost saving vs. a gas car. You specify the gas price and the MPG for the gas car against which you want the comparison to be made (screenshot attached)
- If the auto-lock fails for some reason and you are not in the car, the app can now lock the car for you. This is optional and controlled by a switch in settings.
Attachments
AlanSubie4Life
Efficiency Obsessed Member
Cool. Thanks!
It's great that you account for charging losses for this calculation (I had 0.12 cents/kWh for my cost, I added 315.7kWh in January, cost worked out to $44.56 (rather than $37.89). So it looks like you're assuming 85% efficiency? Or perhaps it is not an assumption - it looks like you do track the kW into the car vs. SoC so that would be enough to figure out the efficiency..I guess both the input power and the added miles are available in the API...so no assumptions needed...
Seems like that efficiency number goes up and down a couple % depending on the charging session. No idea why.
Efficiency is independent of charging sessions. Efficiency is ratio of estimated and rate range (both of which are reported by Tesla)
Yes, charging efficiency is 0.85 (meaning that 15% of energy is converted to heat during charging).
AlanSubie4Life
Efficiency Obsessed Member
Thanks, yes, I meant charging efficiency. So that charging efficiency is derived from observation / data you gather - it is not a fixed scalar you use when calculating the energy cost, right?
AlanSubie4Life
Efficiency Obsessed Member
@Stats App , I couldn't figure out the reported phantom drain numbers reported in the Stats app so I exported them.
TL;DR - I think your "mi/hr" drain rates might be misleadingly high (at least, if people are using them to figure out how many miles they are using per day).
There are three columns in the exported data set:
Phantom Drain (mi) (My total number of miles is 123.2 mi over 48 days of using the app)
Drain Duration (for each gathered datapoint)
Drain Rate (presumably a calculated value based on the miles/duration)
Two issues:
Issue 1 (minor) :
If I multiply drain duration by drain rate and sum up it doesn't match the total drain. I think it's just due to rounding error (in my case it comes to 117 miles vs. 123 miles, over 48 days), but 5% is fairly large. I assume Phantom Drain in the first column are the "correct" values.
Issue 2 (less minor):
However, the Phantom Drain Rate you report in the app may not be correct. I think this value (in mi/hr) is high, because you're not counting all the hours - only the hours reported by the API.
For example, my total phantom drain over 48 days is: 123mi/48days = 2.56mi/day. That works out to ~0.1mi/hr. This is pretty close to my perception of what my phantom drain actually is.
However, the Stats app reports my average to be 0.37mi/hr (which one might interpret to be 8.88mi/day) But my drain is definitely nowhere near that bad (based on the Stats app "Phantom Drain" column total). I was able to use my data to come up with close to the 0.37mi/hr number you report by taking the weighted average of the drain rates in the exported data set. However, note that the total reported number of hours (Drain Duration) over 48 days was 331 hours (which is only 13.8 days). Hence, it's not correct to extrapolate the 0.37mi/hr number to 24hr/day*0.37mi/hr = 8.88mi/day. (And the hour discrepancy accounts for the issue with the reporting: day ratio = 48/13.8 ~ 3.48 , drain rate ratio = 8.88/2.56 ~ 3.46 )
Not sure what was intended here for this number. I'm not saying that it is wrong, I just can't use your reported mi/hr numbers to figure out what my actual phantom drain is per day (which I think would be a reasonable use of the number...).
TL;DR - I think your "mi/hr" drain rates might be misleadingly high (at least, if people are using them to figure out how many miles they are using per day).
There are three columns in the exported data set:
Phantom Drain (mi) (My total number of miles is 123.2 mi over 48 days of using the app)
Drain Duration (for each gathered datapoint)
Drain Rate (presumably a calculated value based on the miles/duration)
Two issues:
Issue 1 (minor) :
If I multiply drain duration by drain rate and sum up it doesn't match the total drain. I think it's just due to rounding error (in my case it comes to 117 miles vs. 123 miles, over 48 days), but 5% is fairly large. I assume Phantom Drain in the first column are the "correct" values.
Issue 2 (less minor):
However, the Phantom Drain Rate you report in the app may not be correct. I think this value (in mi/hr) is high, because you're not counting all the hours - only the hours reported by the API.
For example, my total phantom drain over 48 days is: 123mi/48days = 2.56mi/day. That works out to ~0.1mi/hr. This is pretty close to my perception of what my phantom drain actually is.
However, the Stats app reports my average to be 0.37mi/hr (which one might interpret to be 8.88mi/day) But my drain is definitely nowhere near that bad (based on the Stats app "Phantom Drain" column total). I was able to use my data to come up with close to the 0.37mi/hr number you report by taking the weighted average of the drain rates in the exported data set. However, note that the total reported number of hours (Drain Duration) over 48 days was 331 hours (which is only 13.8 days). Hence, it's not correct to extrapolate the 0.37mi/hr number to 24hr/day*0.37mi/hr = 8.88mi/day. (And the hour discrepancy accounts for the issue with the reporting: day ratio = 48/13.8 ~ 3.48 , drain rate ratio = 8.88/2.56 ~ 3.46 )
Not sure what was intended here for this number. I'm not saying that it is wrong, I just can't use your reported mi/hr numbers to figure out what my actual phantom drain is per day (which I think would be a reasonable use of the number...).
Re issue 1:
Yes, that's rounding error. I increased the number of digits after decimal point and now drain_rate x drain_duration matches up (see attached).
Re issue 2:
Each bar has a duration and a drain value (the ratio is the drain rate). It is incorrect to multiply drain rate by 24 hours and conclude that the result is the number of miles lost in 24 hours. That's why the bar-chart shows the number of miles lost in a particular day _and_ and a particular location. In other words, there is no need to extrapolate from the duration rate to obtain the range loss: the range loss is shown explicitly in the app for the location and time where the loss occurred. The drain rate corresponds to the particular date and location shown on the map.
Attachments
Last edited:
Tesla API doesn't make this information available. I'll add it once/if they do add it to the API.
SpudLime
Active Member
Thats interesting idea. I’d love to know this also. The Mini Cooper convertible tracks mileage with the top down. It’s a fun stat.
Whisky
Member
Possible to get Siri commands for battery charging, like “Hey Siri, charge car to 90%” similar to what you have with HVAC? That be terrific for days when I want to preheat the battery!
That's awesome. I dated a girl with a Mini Cooper and while I always thought it was a death trap (I live in TX where the bumpers from lifted trucks are at a Mini driver's face level) I thought it was a really fun car.
ok, I'll add that Siri Shortcut
Similar threads
