Consumption will often not shown on drives list, but on drive details

[bobo71dream]

Is there an existing issue for this?

• [X] I have searched the existing issues

What happened?

Hi. I have in my Drives list often not shown field Consumption. In Drives Details the information is shown. For example see screenshots attached. It is possible to fix it. PS: this problem was present in all used versions for me. I use teslamate since 12/2020.

Thank you for your good tool and i hope for your support.

Expected Behavior

No response

Steps To Reproduce

No response

Relevant log output

no log inserted

Screenshots

Additional data

No response

Type of installation

Docker

Version

v1.25.0

[DrMichael]

Might be the same as https://github.com/adriankumpf/teslamate/issues/2193

[cwanja]

Might be the same as #2193

Definitely seems possible. But it shows in the drive details. Cannot recall if mine showed in the drive details or not.

@bobo71dream - can you run the following command from your database / docker installation? select id, efficiency from cars;

Another alternative can be: docker-compose exec database psql teslamate teslamate -c \ "select id, efficiency from cars;"

Note: depending on your installation database might need to be replaced with db.

[cleanev]

Another data point, if it is of any use in identifying why same drive from point A to point B and back, where one of the two is always missing consumption calculation. The drives shown are exactly over same route to and fro. There seems to be some subtle measure that makes this calculation show or otherwise

[niklasfink]

Might be the same as #2193

Definitely seems possible. But it shows in the drive details. Cannot recall if mine showed in the drive details or not.

@bobo71dream - can you run the following command from your database / docker installation? select id, efficiency from cars;

Another alternative can be: docker-compose exec database psql teslamate teslamate -c \ "select id, efficiency from cars;"

Note: depending on your installation database might need to be replaced with db.

Hey @cwanja, thanks for helping debugging the issue. I have the same problem, that I don't have any Consumption shown (not even on trip details), but I do have the Efficiency column filled for drives above 5mins.

select id, efficiency from cars; gives:

 id | efficiency 
----+------------
  2 |           
  1 |           
(2 rows)

I have two Model 3 2021 version and the car_type is shown as model3, which should properly be mapped. (Regarding issue #2193)

I have (only) two charging sessions recorded so far, which should be enough according to the FAQ though.

[cwanja]

Might be the same as #2193

Definitely seems possible. But it shows in the drive details. Cannot recall if mine showed in the drive details or not. @bobo71dream - can you run the following command from your database / docker installation? select id, efficiency from cars; Another alternative can be: docker-compose exec database psql teslamate teslamate -c \ "select id, efficiency from cars;" Note: depending on your installation database might need to be replaced with db.

Hey @cwanja, thanks for helping debugging the issue. I have the same problem, that I don't have any Consumption shown (not even on trip details), but I do have the Efficiency column filled for drives above 5mins.

select id, efficiency from cars; gives:

 id | efficiency 
----+------------
  2 |           
  1 |           
(2 rows)

I have two Model 3 2021 version and the car_type is shown as model3, which should properly be mapped. (Regarding issue #2193)

I have (only) two charging sessions recorded so far, which should be enough according to the FAQ though.

How long were the charging sessions? Could have been too short of a session/s to derive an efficiency calculation. Once that efficiency column is populated, data will be back filled.

[niklasfink]

How long were the charging sessions? Could have been too short of a session/s to derive an efficiency calculation. Once that efficiency column is populated, data will be back filled.

Do you know how the efficiency column gets filled or what your efficiency says and when it got there?

This is the full Charges tab. Maybe the problem is due to the first unsuccessful charge (due to the station).

[cwanja]

How long were the charging sessions? Could have been too short of a session/s to derive an efficiency calculation. Once that efficiency column is populated, data will be back filled.

Do you know how the efficiency column gets filled or what your efficiency says and when it got there?

Purely speculation, but it calculates the efficiency based upon the mileage between charges and energy used. And redoes the calculation each charging session to determine the most accurate efficiency number.

Mine is currently 0.15. Was updated at 12-18 which is after my third charge. Each charging session was under or over three hours.

[BabyYeggie]

This is related to #257 and is working as designed.

[niklasfink]

This is related to #257 and is working as designed.

@BabyYeggie could you please elaborate on "working as designed"?

Does that mean, all drives with a snowflake icon won't get calculated? If so, in my case I have no-snowflake drives which still doesn't have a consumption. And in contrast to that, I do have snowflake drives with an efficiency attached:

[BabyYeggie]

@niklasfink You need to look at the code that calculates the "Efficiency" field. start_position.usable_battery_level as start_usable_battery_level, start_position.battery_level as start_battery_level, end_position.usable_battery_level as end_usable_battery_level, end_position.battery_level as end_battery_level, case when (start_position.battery_level != start_position.usable_battery_level OR end_position.battery_level != end_position.usable_battery_level) = true then true else false end as reduced_range, duration_min > 1 AND distance > 1 AND ( start_position.usable_battery_level IS NULL OR end_position.usable_battery_level IS NULL OR (end_position.battery_level - end_position.usable_battery_level) = 0 ) as is_sufficiently_precise, NULLIF(GREATEST(start_[[preferred_range]]_range_km - end_[[preferred_range]]_range_km, 0), 0) as range_diff, car.efficiency as car_efficiency, So, the code looks at start_position.battery_level, end_position.battery_level, and end_position.usable_battery_level. If the starting or ending usable battery level can't be determined due to a cold battery or the ending battery level is higher due to the battery warming up, the the "is_sufficiently_precise" field is set to false. At moderate temperatures 10C or so, the cold battery warning will come on but a long enough drive will warm up the battery where the range is greater than the starting range. This results in efficiencies significantly greater than 100%. My highest is 634% on a short drive. The same thing happens when charging a cold battery as well, with efficiencies as high as 200% being recorded. This sanity check prevents impossible efficiency ratings but also has results in many null efficiencies for those of us who live in cold climates.

reduced_range as has_reduced_range, range_diff * car_efficiency as "consumption_kWh", CASE WHEN is_sufficiently_precise THEN range_diff * car_efficiency / distance * 1000 * CASE WHEN '$length_unit' = 'km' THEN 1 WHEN '$length_unit' = 'mi' THEN 1.60934 END END AS consumption_kWh_$length_unit, CASE WHEN is_sufficiently_precise THEN distance / range_diff ELSE NULL END AS efficiency The above code uses the "is_sufficiently_precise" field to determine whether or not the "Efficiency" field is populated. From above, if the battery is cold, the efficiency field will be null most of the time. If you don't care about unusual efficiency numbers, just change the "else null" to "ELSE distance / range_diff".

You'll also notice the same null values in the Vampire Drain table. Change: CASE WHEN has_reduced_range THEN 1 ELSE 0 END as has_reduced_range, convert_km(CASE WHEN has_reduced_range THEN NULL ELSE (v.start_range - v.end_range)::numeric END, '$length_unit') AS range_diff_$length_unit, CASE WHEN has_reduced_range THEN NULL ELSE (v.start_range - v.end_range) * c.efficiency END AS consumption, CASE WHEN has_reduced_range THEN NULL ELSE ((v.start_range - v.end_range) * c.efficiency) / (v.duration / 3600) * 1000 END as avg_power, convert_km(CASE WHEN has_reduced_range THEN NULL ELSE ((v.start_range - v.end_range) / (v.duration / 3600))::numeric END, '$length_unit') AS range_lost_per_hour_[[length_unit]]

to: CASE WHEN has_reduced_range THEN 1 ELSE 0 END as has_reduced_range, convert_km((v.start_range - v.end_range)::numeric , '$length_unit') AS range_diff_$length_unit, (v.start_range - v.end_range) * c.efficiency AS consumption, ((v.start_range - v.end_range) * c.efficiency) / (v.duration / 3600) * 1000 as avg_power, convert_km(((v.start_range - v.end_range) / (v.duration / 3600))::numeric , '$length_unit') AS range_lost_per_hour_[[length_unit]]

That should take care of most of your null values.