Look of the trip summary

[gm27271]

Hi, I was hacvng holidays, so not much involved, but when I was playing with ChatGPT, it proposed me some nice layout summary of the trip. Would you be able to implement something like this? I know this is only your decision, but this looks like more structured.

I’d suggest separating the information into three clear areas:

1. A general trip summary with the total distance and duration.
2. A visual comparison showing how many kilometres and what percentage of the trip were driven in electric mode versus using the combustion engine.
3. Two separate sections for electricity and fuel, each showing the energy/fuel used, average consumption, distance covered and cost.

The total trip cost should remain clearly highlighted, while the battery and fuel level changes could be moved into a smaller, less prominent section at the bottom.

One important point is how average consumption is calculated. Currently, 15 kWh over the full 333 km gives 4.5 kWh/100 km. However, if the car covered only part of the journey in electric mode, the consumption calculated specifically for the electric distance would be different. The same applies to fuel consumption. We should therefore clearly label whether each value is calculated over the entire trip or only over the distance covered in the relevant driving mode.

The values shown in the mockup for electric and fuel distance are only examples. They should, of course, be replaced with the actual values calculated by the application.

Here is sample scenario with 100% electric trip. Of course, the values are dummy, not the real from the car.

[ProtossBlaster]

Hi,

Sorry for the delay — your post is two days old and I missed it.

On the layout: I like it, and I'll take my time deciding. The three separate areas and keeping the total cost prominent are reasonable. I'm not promising a date.

But I owe you a precise answer on the technical point, because it is more interesting than the layout.

The "km in electric vs km on the engine" split does not exist on this car. It is a series range-extender: the combustion engine never turns the wheels. It spins a generator, and the wheels are always driven by the electric motor alone. The figure you see as "generator on" is the distance covered while the generator was running — not the distance it pushed.

And the car sends no drive-mode signal at all: that tag in Mate is typed in by hand.

Consumption over the whole distance is a choice, not an oversight. The L/100 km is worked out over the full trip because that is the same basis the car's own display uses (oc100km, which the cloud hands us already computed) and therefore what you see in the official app. We changed it deliberately: dividing by the generator-on kilometres alone, another tester's trip read 15.9 L/100 km while his own arithmetic and his own app both said 2.2. Two different answers under one word.

That said, you have put your finger on something real — just not where you think.

The electric figure (⚡ kWh/100 km) is the energy that left the battery, divided by all the kilometres. The energy the generator sends straight to the motor never passes through the pack, so Mate cannot see it: it is not divided wrongly, it is missing entirely.

The best proof is one of your own bundles: 645 km against 20 kWh reported — 3.1 kWh/100 km. A C10 does not cover 645 km on 20 kWh. What is missing is everything that arrived as petrol.

So the share you want to see can be computed — not in kilometres, in energy. The kWh the generator put in over a trip is getEC − ΔSoC: two measured quantities, no efficiency invented. That is the right road to the "electric vs engine" panel you have in mind, and it is something we have not built yet.

One thing I will fix regardless: the trip detail already carries a note explaining what that electric figure means; the trip list prints the number and nothing else. The note belongs there too.

Thank you — your bundles are the reason we know getEC is blind to the generator at all.

[gm27271]

No worries at all about the delay.

The app already calculates the distance travelled while the generator was running. Therefore, if we subtract that figure from the total trip distance, we get the distance travelled with the generator off — in other words, using energy from the battery only.

I understand that you may have some reservations about the accuracy of this calculation. However, since we already display this information on the screen, my suggestion is simply to present the same data in a clearer and more visually appealing way.

So we can still calculate and display this split, as long as we label it accurately as “distance with generator on” versus “distance with generator off / battery only,” rather than “electric vs engine-driven distance.”

[ProtossBlaster]

Hi,

Here is what I measured.

The kilometres driven on electricity alone cannot be identified: no sensor tells us. I took all 89 signals the car sends and looked for one that separates "generator on" from "generator off". The best four looked excellent, 85–88% — but they were gear, parking brake, ignition and speed: they say the car is driving, not that the generator is running, and the generator runs almost only while driving. Looking at only the minutes where the car is already moving, the best of all 89 separates at 61% — barely better than a coin toss. In the cloud the generator does not exist as a state.

What we do is infer it from the petrol. We count a stretch as generator-on when, in the same sample, the odometer rises and the fuel level falls.

And that is where the limit is. It is not the float in the tank: the value the car sends is already filtered, and you can see it — over the whole period the fuel level never rises while the car is moving, and the only rises are with the car stopped and as large as refuelling. The problem is the rhythm. We ask for data every 30 seconds; the fuel value changes every 12, but the odometer only every 60. In roughly half the samples the odometer is unchanged because it has not refreshed yet, and that stretch's fuel drop is discarded. The count is always wrong in the same direction — short: against a photograph of another tester's dashboard, the car said 60.2 km and we counted 54.0.

What that means for the subtraction you propose. The generator-off kilometres are the difference between the distance and an estimate that runs about 10% short, so they inherit all of that error — and precisely where the remainder is small, which is the long generator trips. Over 32 real trips, correcting for that 10%, 8 remainders out of 32 go to zero or negative. On your own 176 km trip the figure shown would be 25 km with the generator off, where the corrected arithmetic gives about 8.

Your labels are right, and the figure you circled really is what we have. But it is also all we have: a number that is inferred, short, and a subtraction that multiplies its error.

[michapr]

What we do is infer it from the petrol. We count a stretch as generator-on when, in the same sample, the odometer rises and the fuel level falls.

Only idea/question:
How about we determine the electric driving mode this way:
when the vehicle is moving and the SoC drops, we drive electrically; the rest of the time, we use the generator.
What would the error rate be in that case?

[gm27271]

Regenerative braking might impact this. In my opinion, whenever fuel starts to drop, then we should count this as engine kms. Confirmed from @ProtossBlaster this is the approch. The only issue is frequency of these payloads, that confirm fuel is decreasing.

[ProtossBlaster]

You are right on all three points, and two of them I measured this morning.

Regenerative braking does affect it, and it is measured. In the C10 bundle there are 55 minutes out of 692 where the car really was running on electricity but the SoC was flat or rising — downhill stretches and regen. The SoC rule would call those "generator". On michapr's B10, zero: it depends on where you drive, which is already a reason not to trust it.

And yes, the approach is the one you describe: we count a stretch as engine kilometres when the fuel level falls. More precisely, when in the same sample the fuel falls and the odometer rises — because the fuel also drops with the car standing still, when the generator charges the pack in place, and those litres must not be charged to any distance.

And you put your finger exactly on the real problem: the frequency. Here are the numbers, from michapr's bundle and from the other tester's:

Mate asks for data	every 30 seconds
the fuel value changes	every 12 seconds (median)
the odometer value changes	every 60 seconds (median)
odometer samples with a fuel reading at the same instant	45%

More than half the stretches cannot be judged, and they end up among the "generator off". The error is always in the same direction, short: against a photograph of a tester's dashboard, the car said 60.2 km and we counted 54.0.

One thing that turns out better than expected: the fuel value itself is not noisy. It moves in steps of 1–12 mL, and over seventeen days it never rises while the car is moving — the only rises are with the car stopped and as large as refuelling. So it is not the float that troubles us, nor the slope: the car sends us a value that is already filtered. It is only the rhythm at which it arrives.

[michapr]

Additional some data, for the collection ;) Longer trips last days with "fuel mode", others with EV.
mate-beta-bundle-1787047239.zip

[ProtossBlaster]

Hi,

Good question, and asked the right way round — "what would the error rate be" rather than "is it a good idea". I measured it, on your bundle and on another tester's.

On yours (B10, 913 minutes with the car moving):

	SoC falling	SoC flat or rising
generator on	95	167
generator off	651	0

The rule would call "electric" 95 of the 262 minutes in which the generator was running: 36%. Over everything, it gets 10% of the minutes wrong.

On the other bundle (C10, 1285 minutes): same shape, worse numbers — 310 of 593, i.e. 52% — plus 55 genuinely electric minutes called "generator" (downhill stretches and regenerative braking). 28% wrong overall.

Two things come out of the comparison.

The error is all on one side: recognising electric works well (0% on yours, 8% on the other car), recognising the generator does not — between a third and a half of those minutes land in the wrong box. And the generator is precisely what the rule is meant to find.

And the rate is not stable: 10% on one car, 28% on the other. It is not a threshold to be tuned; it moves with the car and with how it is driven.

The reason is physical: the generator does not cover the whole demand, so the pack keeps discharging while it runs. A falling SoC does not separate the two situations.

A limit I should state: I am comparing your rule with ours, not with the truth. The "truth" here is the fuel level falling, which is itself an estimate. What I measured is how much the two methods disagree. The difference between them is that petrol burned is burned, while a falling SoC can have two causes.

Thank you for the bundle — long trips with and without the generator were exactly the sample that was missing.

One last thing: you are on 3.10.4, fifteen releases back. One of them concerns the very number we are discussing — v3.11.1 fixed the generator distance, which was being counted on the coarse fuel signal and lost 42% of it. On your screen that number is still the old one. The current release is 3.14.5.

[gm27271]

OK, whatever. Then let's display this distance in crappy comment after loads of text like today.

[ProtossBlaster]

You are right, and we never answered it.

The three answers you got were about the measurement. Your question was about the layout. Two different things, and we only ever answered one.

I opened the page and measured it. On a generator trip, in v3.14.23:

• the generator distance was printed at the end of a 41-word note, joined to it by a ·;
• 10px type, colour #64748b — the same treatment as the build number in the sidebar corner.

"Crappy comment after loads of text" was an accurate description of the page.

In v3.14.24 that figure has a line of its own, above the note:

⛽ 25 km with the generator running
at least — counted from the fuel drop, not from a sensor

13px, the figure in white. The number itself did not change: only where it sits. In all eight languages, and on a phone it fits on one line.

The second line is there for a reason. A figure on its own line claims a confidence a footnote does not, and this count has a limit: there is no "generator on" signal in the cloud — we checked all 89 signals, and the best of them separates at 61% once the car is already moving. Those kilometres are counted from the samples where the odometer rises and the fuel falls; the stretches where the odometer has not refreshed yet cannot be judged, and they land on the other side. So the count is short in one direction only: 54.0 km against the 60.2 the dashboard showed in the measurement.

And on the rest of your proposal, here is where each point stands today:

your request	where it is
1 · summary with distance and duration	at the top, the two large tiles
2 · electric vs engine kilometres	not there — this is the part we measured
3 · two sections with energy, average consumption and cost	ENERGY USED: 28.5 kWh · ⚡ 16.2 kWh/100km · ⛽ 2 L · 1.1 L/100km — COST: 8.38 € · ⚡ 4.80 € · ⛽ 3.58 €
4 · total cost highlighted	8.38 €, in green, the largest number in the column
5 · battery and tank in a smaller section	🔋 78%→34% · ⛽ 63.2%→59.0%, 12px

Four of the five points were already on the page — scattered, and not separated. The fifth is the measured one.

The update arrives with the normal button: Add-on Store → ⋮ → Check for updates → Update.

Tell me how it reads on your own trips.

[gm27271]

My request was only releate dto the layout of the view. All the velues are alredy there and I knew it. It's just the layout that is not user friendly.

[ProtossBlaster]

You were right, and it took us three replies to see it: we kept answering about the measurement when the question was the layout.

In v3.15.15 the card is in three areas. The trip — distance, duration, and the total cost, now the largest figure on it. The electricity. And the fuel, with the litres, the L/100 km and the generator's distance, which sits beside the petrol that produced it instead of at the bottom. The Avg consumption tile that showed a dash on a generator trip is no longer printed. Battery and tank start→end stay at the foot of the card, smaller, as you asked.

No figure is computed differently and none was dropped — this release moves them. The one thing that is not there is the electric-vs-generator share, for the reason measured further up this thread.

The update arrives with the normal button: Add-on Store → ⋮ → Check for updates → Update.

[michapr]

Anyway, I would really prefer the layout @gm27271 suggested. Using the same data - even if some of it is just estimated, just like before.

But design is a matter of taste - I understand that opinions differ on this.

[michapr]

I made a layout for REEV cars only - BEV untouched.

files.zip

@gm27271 if docker installation you can test it (will be lost after next update ;-)... ):

docker cp trip_detail.html mate-beta:/app/web/templates/trip_detail.html
docker cp en.json mate-beta:/app/web/locales/en.json
docker cp de.json mate-beta:/app/web/locales/de.json
docker restart mate-beta

@ProtossBlaster - what do you think about it?

EDIT: just have seen there is duplicate "km" in electric/fuel box - should be removed ;)

[ProtossBlaster]

Thank you for building it — two of the three are in v3.15.16, out today:

• the cost per distance, on the line under the total it comes from: 12.87 €/100 km under
  12.48 €. It uses the same helpers as the Statistics card, so a reader whose distances are in
  miles gets it per 100 mi.
• the block of secondary readings at the foot of a trip folds. It ships open — the fold is
  offered, nothing is hidden from someone who never touches it.

First, something I got wrong in this thread. On 17 August I wrote that the kWh the generator put
in is getEC − ΔSoC, "two measured quantities, no efficiency invented". That was wrong, and I have
now measured how wrong. Across the three range-extender bundles we have, that formula accounts for
0.08 kWh per litre burned, against the 2–2.7 kWh/L a generator actually delivers. The reason is
written further up this same thread and I failed to apply it to my own suggestion: on a series
hybrid the generator feeds the motor directly, and getEC only sees what leaves the pack. One
trip states it plainly — 53 km, 3.50 L, 52 km with the engine running, getEC 0.2 kWh: the pack
balance closes to ±0.01 kWh and reports no generator at all, while the car crossed 53 km on petrol.

And where the generator does charge the pack, the same formula cannot tell it from a charging cable.
On another bundle a 48 km trip whose SoC went 26% → 86% on 2.52 L comes out as +37.9 kWh from the
generator — 15 kWh per litre, more energy than petrol contains.

So the split is not available in energy either. In kilometres it was already measured, above.

On your file. I ran it against the real trips in those three bundles. Three things are yours to
fix, one is not:

1. A per-mode distance sits next to a whole-trip rate. In your own screenshot: 4.8 kWh,
   4.9 kWh/100km, 35 km. 4.8 over 35 km is 13.7, not 4.9 — the 4.9 is over the full 97 km,
   and it is our figure, not yours. Same on the fuel side: 5.28 L over 62 km is 8.5 L/100km,
   printed as 5.4. A reader who divides gets a different answer from the one printed above it.
2. 100% ELECTRIC appears on trips that burned petrol. The gate is engine_km > 0.5; when the
   generator ran but its distance was not detected, the else branch prints the full green bar while
   the fuel column beside it prints the litres. It happens on 5 trips in those bundles — 0.30 L,
   0.20 L, 0.10 L, 0.04 L and 0.33 L.
3. dist() already carries the unit, so {{ … | dist(0) }} {{ dist_unit() }} renders
   "35 km km" — in four places.
4. The bar itself, which is the one that is not yours. max(distance − engine_km, 0) inherits
   everything that is wrong with engine_km, and engine_km is a floor. Correcting it by the 10%
   already measured against a dashboard photograph (54.0 against 60.2), over the 44 generator
   trips in those bundles the green slice is 4.7 points too large on average, up to 10.1, and
   on 8 trips the true electric share is about zero while the card still shows one.

The layout is right. It is the number underneath it that is not there.

[michapr]

A per-mode distance sits next to a whole-trip rate. In your own screenshot: 4.8 kWh,
4.9 kWh/100km, 35 km. 4.8 over 35 km is 13.7, not 4.9 — the 4.9 is over the full 97 km,
and it is our figure, not yours. Same on the fuel side: 5.28 L over 62 km is 8.5 L/100km,
printed as 5.4. A reader who divides gets a different answer from the one printed above it.

This is right. It is the trip statistics, so the comsumption over the trip distance.

100% ELECTRIC appears on trips that burned petrol. The gate is engine_km > 0.5; when the
generator ran but its distance was not detected, the else branch prints the full green bar while
the fuel column beside it prints the litres. It happens on 5 trips in those bundles — 0.30 L,
0.20 L, 0.10 L, 0.04 L and 0.33 L.

ok, would change wording in this case: "nearly 100% electric" or "≈ 100% electric"

The bar itself, which is the one that is not yours. max(distance − engine_km, 0) inherits
everything that is wrong with engine_km, and engine_km is a floor. Correcting it by the 10%
already measured against a dashboard photograph (54.0 against 60.2), over the 44 generator
trips in those bundles the green slice is 4.7 points too large on average, up to 10.1, and
on 8 trips the true electric share is about zero while the card still shows one.

it is not a measurement, I know. It is for visualization purposes only. Using the same values as printed below. Could use again the "≈" with values

[ProtossBlaster]

No, and the reason is the short one: we do not have those kilometres. The car never sends them.
We infer them from the fuel level falling, and that count comes out short — always in the same
direction.

The bar divides the trip using an inferred number. And where the inference is weakest, the bar is
most confident: on 8 of the 44 generator trips in those bundles the electric share is about zero
and it still shows a slice, and on 5 more the generator's distance was not detected at all.

On those 5, "≈ 100% electric" does not help. One of them is 1 km on 0.10 L — a kilometre driven
entirely with the engine running. "About 100% electric" is not an approximation there.

"For visualization purposes only" is the part we cannot take. We print the generator's distance with
"at least" beside it, because it is a floor. Subtracting a floor from the total gives a ceiling
for the other side, and a coloured proportion does not carry that word with it. A reader sees a fact.

On the consumption: yes, it is the trip statistic, and it is correct. The objection was only the line
under it — 4.8 kWh above 35 km reads as 13.7. Nothing to settle there: it is your file.

Your other two stand, the wording and the unit. And thank you — the two changes we did take are in
v3.15.16, with your name on them in the changelog.

[michapr]

Summary of Changes — Trip Detail Page, REEV Top-Left Card

1. New "Trip Summary" layout for REEV vehicles ({% if is_reev %} branch; BEV layout untouched)

• Distance / Duration as two boxes
• Driving Mode bar (green/orange split by electric vs. generator-driven km)
• Electric / Fuel boxes side by side
• Total trip cost row (with cost/km)
• Collapsible "Battery & fuel levels"
• Existing Convert-EC / Revert-EC buttons, unchanged logic, moved into the new card

2. 100% Electric handling

• No fuel used at all → plain "100% ELECTRIC"
• Fuel used but engine_km not detected (5 known trips: 0.30/0.20/0.10/0.04/0.33 L) → "≈ 100% ELECTRIC", since the plain claim was wrong for these

3. ≈ prefix on every engine_km-derived figure

• engine_km is a floor estimate (≈10% low per dashboard-photo check; green slice averaged 4.7 points too large, up to 10.1, across 44 generator trips)
• Applied to: split-bar captions and (originally) the boxes' km lines — never to ec_kwh, fuel_used_l, or cost, which are measured

4. Fixed duplicate unit bug

• dist() already includes the unit; the extra {{ dist_unit() }} was removed from all 5 places that had it (was rendering "35 km km")

5. Column-width fix (measured: ~87 px/column at 1024px viewport, 148 px at 1600px)

• First tried: stacked Electric/Fuel boxes (full column width each)
• Reverted to side-by-side per your request, made compact instead:
• Dropped 24px .stat-value → 16px text-base font-bold
• Removed the km line from each box (now redundant with the bar caption above)
• Smaller secondary text (10px), tighter padding/gap, truncate + min-w-0 as a safety net

6. Variable decimal precision on the main Electric/Fuel figures

• dec(1) normally ("16.0 L", "15.0 kWh") — one character narrower than the previous nice filter
• dec(2) when the value is under 1 (e.g. "0.04 L") — so the same 5 mini-fuel trips still show their real amount instead of rounding to "0.0"

All changes validated: Jinja2 template parses cleanly, en.json/de.json are valid JSON. Two new translation keys added (trip_summary_title, driving_mode_label, battery_fuel_levels_label, driving_mode_100pct_electric, driving_mode_approx_100pct_electric) to en.json and de.json; other locales fall back to English automatically.

trip_detail.zip

[ProtossBlaster]

A correction to my own count: the duplicated unit was in five places, not four. You counted right.

[ProtossBlaster]

Two things about the new file.

The "≈" does not reach the bar. _elec_pct is the exact percentage, and it ends up inside
style="width: {{ _elec_pct }}%" — the green rectangle is drawn with that number. The "about" is
only on the captions below it. On the trip where the true electric share is about zero, the bar
still draws a piece of green; and in the "≈ 100%" case it is full green across its whole width, on
trips that were driven entirely with the engine running. A bar is a geometry: "about" cannot be
drawn.

The zip has only trip_detail.html in it. The locale files are not there. The template uses five
keys that do not exist in the locales — trip_summary_title, driving_mode_label,
battery_fuel_levels_label, driving_mode_100pct_electric,
driving_mode_approx_100pct_electric. The fallback to English does not help here, because without
en.json in the zip there is no English either: whoever applies it sees the key names instead of the
labels. If you send it again, put en.json and de.json in with it.

[michapr]

the locales are the same as before, I thought you will take it frome here. Now included again.
trip_detail.zip

No, and the reason is the short one: we do not have those kilometres. The car never sends them.
We infer them from the fuel level falling, and that count comes out short — always in the same
direction.

I know; you’ve written and emphasized that several times.
But if we can display the value, then we can also use it in a bar - with the same status (i.e., the same level of inaccuracy); surely it makes no difference whether it’s written out or visualized, right?
We could even add your explanatory line below "Electric: ... Fuel: ..." if that makes it seem more accurate.
("xxx km at least — counted from the fuel drop, not from a sensor")
It’s a nice graphical element that @gm27271 and I—as REEV drivers—like and find useful as an overview, even if it can be imprecise. But if you aren't okay with it, then naturally we have to accept that.

[michapr]

files.zip

Latest Changes — Summary

1. Bar text moved out of the bar entirely

• Root cause of "too long for the bar": text was centered inside a 10px-tall bar with no reliable width guarantee.
• Fix: the bar itself never carries text anymore. All labels now sit in the caption row below it — the same pattern already proven to fit in the two-color (mixed) case.

2. New third state: "Mixed — split unknown"

• test case (7 km / 0.10 kWh / 0.30 L) was wrongly landing in "≈100% electric" — fixed.
• fuel_used_l now branches three ways:

Case	Condition	Bar	Label
True	100% electric fuel_used_l = 0	green	"100% ELECTRIC"
Trace fuel	fuel_used_l < 0.05 L (e.g. 0.04 L)	green	"≈100% ELECTRIC"
Meaningful, undetected fuel	fuel_used_l ≥ 0.05 L (e.g. 0.30 L)	neutral gray	"Mixed — split unknown"

Root cause: reev_elec_kwh_100km is deliberately None when the engine never ran (per _reev_trip_elec()'s own docstring: "Inert on a BEV / pure-electric... trip").

Fix: falls back to trip.efficiency_kwh_100km when reev_elec_kwh_100km is None — that field is populated normally on a pure-electric trip (it's only blanked while the generator is running).

Two new translation keys added (driving_mode_split_unknown), one shortened (driving_mode_approx_100pct_electric: "≈ 100%" → "≈100%") in en.json/de.json. Jinja2 and both JSON files validated again — all clean.

[michapr]

@ProtossBlaster
Hi, any thoughts on this?
Regarding the beam, as already mentioned:
It’s a nice graphical element that @gm27271 and I—as REEV drivers—like and find useful as an overview, even if it can be imprecise. But if you aren't okay with it, then naturally we have to accept that. Then remove it...

[ProtossBlaster]

Hi michapr,

your boxed card is in v3.17.2, released today, and it applies to every car: distance and duration, then electricity and fuel side by side, then the total with the cost per 100 km. On an electric car it is the same card without the fuel.

The bar is not there, as you suggested if it did not convince us: its electric share would be the distance minus a minimum, that is, a maximum drawn as a fact.

Compared with your file:

• the price per litre is back, on a line of its own;
• the generator's kilometres have a full-width line under the boxes, with their "at least" note;
• the electric consumption of generator trips stays in the beta only, in blue as before: on real trips it read 46, 82.7 and 386 kWh/100 km, with the battery not going down;
• with a 1024 px window each box has about 73 px, and distance and duration wrapped, in yours too: at that width the type is now smaller.

Thanks for the work, and thanks to @gm27271, who started the request.

[ProtossBlaster]

We are closing the BetaTester threads: please move to the official version of Mate. Since 4.7.0 the range-extender pages are on the official build. How to move with your history (a backup and a restore): From the BetaTester build to the official one. New reports and ideas go to leapmotor-mate.

🇮🇹 Chiudiamo le discussioni della BetaTester: per favore passa alla versione ufficiale di Mate. Dalla 4.7.0 le pagine del range extender sono nella build ufficiale. Come spostarsi con il proprio storico (un backup e un ripristino): Dalla build BetaTester a quella ufficiale. Nuove segnalazioni e idee vanno su leapmotor-mate.