TeslaFi.com

[Cyclone]

*Tesla fudging the numbers it's reporting.

If you really want to know the actual numbers, third party device is the best way to go, of course you have to validate the calibration of that device. No logger can unfudge the numbers.

I wouldn't say Tesla is fudging the numbers. What is listed is indeed the energy at the chargeport. However, there are losses before getting to the chargeport that the Sense is "seeing".

Consider converting music to MP3s. From a master source, it is converted to a format suitable for CDs. Then this CD format is often read in and converted to MP3s. Let's say you are using 256 kbps , 16-bit MP3 audio conversion. Then you send that from your MP3 player over Bluetooth to a premium sound system. Let's say the Bluetooth profile on the sound system supports 128 kbps , 8-bit MP3 audio. While surely you can blame the Bluetooth connect (predominantly the profile at the receiver) for some conversion losses, you would show even greater losses when comparing it to the CD or the master source. It is unfair to blame the Bluetooth receiver for those losses as they are beyond it's control.

So, if you want to complain about any losses between the chargeport and the battery, go right ahead. But don't blame Tesla for losses between the meter and the chargeport. You may want to yell at Tesla for any losses the UMC causes, but those numbers aren't being reported, so you still shouldn't turn around and say they are fudging the numbers.

 

[cvrcv]

I wouldn't say Tesla is fudging the numbers. What is listed is indeed the energy at the chargeport. However, there are losses before getting to the chargeport that the Sense is "seeing".

No, they are REALLY REALLY fudging the numbers, many things you can confirm, but one example I know of that directly impacts logging:

They have some algorithm that goes like:

If UMC {
secret_currentdraw = pilotcurrent - 1;
reported_currentdraw = pilotcurrent;
}

So UMC charging will report low efficiency, when in fact it never pulled that much current.

 

[ohmman]

No, they are REALLY REALLY fudging the numbers, many things you can confirm, but one example I know of that directly impacts logging:

They have some algorithm that goes like:

If UMC {
secret_currentdraw = pilotcurrent - 1;
reported_currentdraw = pilotcurrent;
}

So UMC charging will report low efficiency, when in fact it never pulled that much current.

While you may have valid information, your pseudocode doesn't bolster your argument. How about showing us the direct information instead of some intensely simplified lines? You're using a lot of CAPS so I'm assuming you've got some data that are interesting. We're not dummies here, bring us the full juice.

 

[cvrcv]

While you may have valid information, your pseudocode doesn't bolster your argument. How about showing us the direct information instead of some intensely simplified lines? You're using a lot of CAPS so I'm assuming you've got some data that are interesting. We're not dummies here, bring us the full juice.

I don't have the time or patience, I got my own test hardware and confirmed a myriad of ways in which tesla data is fudged, which by the way seems to be getting worse over time, an ever increasing byzantine maze (like the current draw fudging, which didn't exist until ~summer 2016). The base fact remains, if you try to make absolute sense of the data you will not, at best you will apply your own fudge factor or dismiss the math not working as some sort of loss somewhere.

So you want direct information? How about "kWh & Wh/m(km) Factor" anti-fudge factor built into Teslafi.com?

*mic drop*

 

[ohmman]

So you want direct information? How about "kWh & Wh/m(km) Factor" anti-fudge factor built into Teslafi.com?

As discussed above, this is due to TeslaFi estimating based off of rated miles used, and has nothing to do with Tesla "fudging." You may want to pick that mic back up.

I find it odd that you're unwilling to give us details. I wouldn't be surprised if the vehicle isn't reporting as accurately as we'd all like, but prefer data over hype. As it stands, the only thing we know for sure is that there are charging losses between the wall and car that are explainable.

 

[cvrcv]

As discussed above, this is due to TeslaFi estimating based off of rated miles used, and has nothing to do with Tesla "fudging." You may want to pick that mic back up.

Yes it does. Analyze the situation more deeply. Rated miles is a proxy for battery energy. Even with miss-estimation, errors must add up to 0, think of it as a fixed pool of integers. You takes some miles out, you have to put them back in, otherwise you end up with either negative range when charged, or a million miles of range when charged. Ending up with the same rated miles after charging demonstrates this is not happening. So even if not accurate over a single drive, over many drives it is mathematically guaranteed to be accurate, you can't cheat here. This is your clue that something is wrong. BTW latest firmware seems to much worse than it used to be. Even if you attribute differences to thermal losses in the pack before the measurement block, doesn't account for it. Just took a very lazy and low speed on the freeway yesterday achieving 295Wh/mi reported (minimizing thermal losses), discrepancy in reporting was ~16%, worse than it's ever been on any firmware previously. Can't even use the teslafi fudge factor, because the value is constantly changing.

I find it odd that you're unwilling to give us details. I wouldn't be surprised if the vehicle isn't reporting as accurately as we'd all like, but prefer data over hype. As it stands, the only thing we know for sure is that there are charging losses between the wall and car that are explainable.

Well you dismissed the pseudocode without actually testing it yourself, and you're dismissing the trip meter fudging, so what else could I possibly add that you'd accept? You can search the other hundreds or thousands of posts on the rest of this forum explaining the details if you're truly interested.

 

[bmah]

So to perhaps get back on topic, I'm wondering if there are some known issues in TeslaFi with how the AP version is detected / parsed with respect to the firmware tracking pages.

My S85D is currently running 8.1(17.11.10). This appears to be one of the oldest versions of all the cars being tracked on TeslaFi. Maybe the easiest way to see this is on TeslaFi.com Firmware Tracker on the Version Details section. I see where there's exactly one S85D running 17.11.10, but TeslaFi seems to think it's a pre-AP car. I know my car has AP1 capabilities. (If I actually log into the main site and drill down on the data, that cars odometer, partial VIN, and update history matches mine). So something's wrong here.

Actually now that I look around the page there are several places where S85D cars are identified as pre-AP or AP2, neither of which is correct. All S85Ds have AP1 hardware (whether it's activated or not is a different matter, but does TeslaFi detect that?).

Bruce.

 

[Jdeck]

So to perhaps get back on topic, I'm wondering if there are some known issues in TeslaFi with how the AP version is detected / parsed with respect to the firmware tracking pages.

My S85D is currently running 8.1(17.11.10). This appears to be one of the oldest versions of all the cars being tracked on TeslaFi. Maybe the easiest way to see this is on TeslaFi.com Firmware Tracker on the Version Details section. I see where there's exactly one S85D running 17.11.10, but TeslaFi seems to think it's a pre-AP car. I know my car has AP1 capabilities. (If I actually log into the main site and drill down on the data, that cars odometer, partial VIN, and update history matches mine). So something's wrong here.

Actually now that I look around the page there are several places where S85D cars are identified as pre-AP or AP2, neither of which is correct. All S85Ds have AP1 hardware (whether it's activated or not is a different matter, but does TeslaFi detect that?).

Bruce.

I think my detection code got out of sync between some of the pages. It looks like it's identifying it correctly at the bottom of the settings page but not on the actual firmware page. I'll fix it tonight. Thanks.

 

[Gforce1]

Is anyone else showing odd sleeping patterns on the 2017.28 c528869 update? My car mostly seems to be waking and sleeping over and over. Vampire drain doesn't seem too bad, almost like it's not really waking up, but the data shows it tossing and turning all day and night now. I've tried a reboot but it doesn't seem to help.

 

[kort677]

Is anyone else showing odd sleeping patterns on the 2017.28 c528869 update? My car mostly seems to be waking and sleeping over and over. Vampire drain doesn't seem too bad, almost like it's not really waking up, but the data shows it tossing and turning all day and night now. I've tried a reboot but it doesn't seem to help.

View attachment 237693

it could be that some app you've installed is polling the car and causing this

 

[StefanSarzio]

Sometimes, but also prior to 2017.28 c528869.

 

[X Fan]

As discussed above, this is due to TeslaFi estimating based off of rated miles used, and has nothing to do with Tesla "fudging." You may want to pick that mic back up.

I find it odd that you're unwilling to give us details. I wouldn't be surprised if the vehicle isn't reporting as accurately as we'd all like, but prefer data over hype. As it stands, the only thing we know for sure is that there are charging losses between the wall and car that are explainable.

+1....Teslafi is a great product and has been very beneficial in building an assured travel DB during my trips up and down FL-NC.

 

[Gforce1]

it could be that some app you've installed is polling the car and causing this

I'll try changing my password but I haven't added or changed anything in a while. Seems odd.

 

[hiroshiy]

Is anyone else showing odd sleeping patterns on the 2017.28 c528869 update? My car mostly seems to be waking and sleeping over and over. Vampire drain doesn't seem too bad, almost like it's not really waking up, but the data shows it tossing and turning all day and night now. I've tried a reboot but it doesn't seem to help.

View attachment 237693

In my experience, it usually does that while downloading the software update.

 

[animorph]

Is anyone else showing odd sleeping patterns on the 2017.28 c528869 update? My car mostly seems to be waking and sleeping over and over. Vampire drain doesn't seem too bad, almost like it's not really waking up, but the data shows it tossing and turning all day and night now. I've tried a reboot but it doesn't seem to help.

Not specific to 17.28.cx (I think), but I can see my car waking up on TeslaFi (and through a garage window) every time I walk into the kitchen or master bathroom. Both are closest to the garage. The parking lights come on, but the car doesn't unlock if I don't actually enter the garage. The times it gets knocked out of sleep mode in TeslaFi match my activity.

I also had it never sleep when cabin overheat protection was on.

 

[hybridbear]

TeslaFi isn't working for me today. Is anyone else getting this error?

I am getting it on both Firefox and Chrome.

 

[StaticDischarge]

Firefox and Chrome - both working ok.

 

[Jdeck]

TeslaFi isn't working for me today. Is anyone else getting this error?
View attachment 239267
View attachment 239268
I am getting it on both Firefox and Chrome.

Is it working correctly now? I’m in the middle of getting prepared to move things over to AWS and moved the nameservers over to Cloudflare today. The Cloudflare move is supposed to be seamless but apparently not.

 

[Off Shore]

Is it working correctly now? I’m in the middle of getting prepared to move things over to AWS and moved the nameservers over to Cloudflare today. The Cloudflare move is supposed to be seamless but apparently not.

Nothing about DNS is seamless. It always involves pain.

 

[HankLloydRight]

Is it working correctly now? I’m in the middle of getting prepared to move things over to AWS and moved the nameservers over to Cloudflare today. The Cloudflare move is supposed to be seamless but apparently not.

Nothing about DNS is seamless. It always involves pain.

Not always! I've moved several sites over to Cloudflare (which is awesome, BTW) and never had a problem with the transition. Although, CF does warn that it can take a little time to get the SSL cert generated, it's usually instantaneous. I don't think this was a DNS problem, but rather an SSL cert caching problem.