Mate 4.15.6 — The MQTT plug sensor follows the cable

Mate 4.15.6 — The MQTT plug sensor follows the cable

Two fixes: the MQTT plug sensor says what the Overview says, and the Overview's car picture shows at once.

---

What changes

The MQTT plug sensor shows the cable the pages show (#429)

Since 4.10.0 the pages show the cable when the charge session says so (signal 1149), or when the AC port
reports one on a parked car (signal 47 at 1). A car that has finished its charge, or waits for its
schedule, ends the charge session with the cable still in, and the AC port is what still shows it.

MQTT kept publishing the session alone. On a C10 with the cable in after its charge, the Overview and the
Leapmotor app said Plugged and Home Assistant's Plug Connected said OFF; it was right only while the
car charged.

Now plug_connected and evcc/plugged publish the cable as the pages do. The rule lives in one place,
events.cable_in_port, which the events read too. The charge session the poller opens and closes charges
on is unchanged.

The Overview shows the car picture at once, also while charging (#427)

While the car charges, the car picture is an animation of the charging cable, which took about 2.5 s to
compose on Home Assistant's 4 cores; the card stayed empty meanwhile. After each restart, the first
picture also waited for the picture package to be downloaded again, about 2 s.

Now, while the car charges, the page shows the car with its cable in first (/api/car-picture?still=1)
and puts the animation in its place once it has come. After a restart, with the package on disk, the
first picture comes from the copy on disk and the once-per-start download runs alongside, so a new colour
shows on a later load. With no package on disk, or on a manual refresh, the request waits for the
download, as before.

Upgrade impact

• Nothing is migrated, and no setting is added.
• With MQTT on, Plug Connected and evcc/plugged turn on in more readings: those where the Overview
  already showed the cable without a charge session. On the test instance's database, 12,410 of 431,332
  readings since June. An EVCC setup reading evcc/plugged sees the car plugged in those readings too.
• After a restart, a new colour of the car shows one load later, and the browser keeps a picture for
  5 minutes.

Verification

• CI green on the tag and on main: 5,685 passed, 1 skipped, plus 48 passed and 2 skipped on the Windows job; the check that the
  released desktop shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added: 5,685 passed, 1 skipped (a local-only reference file the clone does not carry).
• #429: the new test (6 cases, one reading 24 combinations through both MQTT and the pages) failed on
  4.15.5 and passes here; making the rule count a moving car, or the V2L adapter, as a cable each made it
  fail. A patch the reporter attached, applied by hand, gives the same answers.
• #427: of its tests, the 5 new or adjusted ones fail on 4.15.5 and all 10 pass here. On Mate's demo in
  Chromium, with the animation held back by 2.5 s: 4.15.5 shows an empty card at 1.2 s, this release the
  car with its cable in, and the animation afterwards.
• The Docker image, built from this release, ran on the test instance (one car, a real database, MQTT on)
  before the tag: healthy, no errors in the log, every page answers as on 4.15.5.
• Not tried: the sensor in a real Home Assistant, a real EVCC setup, the car picture on Home Assistant's
  hardware.

---

Italiano

Mate 4.15.6 — Il sensore MQTT della presa segue il cavo

Due correzioni: il sensore MQTT della presa dice quello che dice la Panoramica, e la foto dell'auto in
Panoramica compare subito.

Cosa cambia

Il sensore MQTT della presa mostra il cavo che mostrano le pagine (#429)

Dalla 4.10.0 le pagine mostrano il cavo quando lo dice la sessione di ricarica (segnale 1149), oppure
quando la presa AC lo segnala con l'auto ferma (segnale 47 a 1). Un'auto che ha finito di caricare, o che
aspetta la sua programmazione, chiude la sessione con il cavo ancora dentro, e la presa AC è ciò che lo
mostra ancora.

MQTT continuava a pubblicare solo la sessione. Su una C10 con il cavo dentro dopo la ricarica, la
Panoramica e l'app Leapmotor dicevano Plugged e il Plug Connected di Home Assistant diceva OFF; era
giusto solo mentre l'auto caricava.

Ora plug_connected ed evcc/plugged pubblicano il cavo come le pagine. La regola sta in un punto solo,
events.cable_in_port, che usano anche gli eventi. La sessione con cui il poller apre e chiude le
ricariche non cambia.

La Panoramica mostra subito la foto dell'auto, anche in ricarica (#427)

Mentre l'auto carica, la foto dell'auto è un'animazione del cavo di ricarica, che richiedeva circa 2,5 s
per essere composta su Home Assistant con 4 core; nel frattempo la scheda restava vuota. Dopo ogni
riavvio, anche la prima foto aspettava di riscaricare il pacchetto delle immagini, circa 2 s.

Ora, mentre l'auto carica, la pagina mostra prima l'auto con il cavo (/api/car-picture?still=1) e mette
l'animazione al suo posto quando è arrivata. Dopo un riavvio, con il pacchetto sul disco, la prima foto
viene dalla copia sul disco e il download di ogni avvio parte in parallelo, così un colore nuovo compare
a un caricamento successivo. Senza pacchetto sul disco, o con un aggiornamento manuale, la richiesta
aspetta il download, come prima.

Impatto dell'aggiornamento

• Nessuna migrazione e nessuna impostazione nuova.
• Con MQTT attivo, Plug Connected ed evcc/plugged si accendono in più letture: quelle in cui la
  Panoramica mostrava già il cavo senza una sessione di ricarica. Sul database dell'istanza di prova,
  12.410 letture su 431.332 da giugno. Un impianto EVCC che legge evcc/plugged vede l'auto collegata
  anche in quelle letture.
• Dopo un riavvio, un colore nuovo dell'auto compare un caricamento dopo, e il browser tiene una foto per
  5 minuti.

Verifica

• CI verde sul tag e su main: 5.685 passati, 1 saltato, più 48 passati e 2 saltati sul job Windows; il controllo che il guscio
  desktop pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti: 5.685 passati, 1 saltato (un file di riferimento solo locale che la copia non porta).
• #429: il test nuovo (6 casi, uno legge 24 combinazioni sia da MQTT sia dalle pagine) falliva sulla
  4.15.5 e passa qui; far contare alla regola un'auto in movimento, o l'adattatore V2L, come cavo l'ha
  fatto fallire ogni volta. Una patch allegata da chi ha segnalato il problema, applicata a mano, dà le
  stesse risposte.
• #427: dei suoi test, i 5 nuovi o adattati falliscono sulla 4.15.5 e tutti e 10 passano qui. Sulla demo
  di Mate in Chromium, con l'animazione trattenuta di 2,5 s: la 4.15.5 mostra una scheda vuota a 1,2 s,
  questa versione l'auto con il cavo, e poi l'animazione.
• L'immagine Docker, costruita da questa versione, ha girato sull'istanza di prova (una sola auto, un
  database vero, MQTT attivo) prima del tag: sana, nessun errore nel log, ogni pagina risponde come sulla
  4.15.5.
• Non provati: il sensore in un vero Home Assistant, un vero impianto EVCC, la foto dell'auto
  sull'hardware di Home Assistant.

Mate 4.15.5 — The Battery page keeps the views you picked

Mate 4.15.5 — The Battery page keeps the views you picked

Three fixes by @arekm: views that survive a page's own reload, a live chart that no longer blinks, and an
outside temperature that survives a restart.

---

What changes

The Battery health page keeps the views you picked (#426)

Left open, the Battery health page reloads itself every 30 seconds, so a charge that ends or a park that
goes on shows up unasked. The reload also put its two charts back on their defaults: Time on
Estimated capacity per charge, %/day and per stop on Vampire drain.

Now the views picked go into the page's address, as a calendar keeps its month:
battery?capacity_by=distance&drain=lost&drain_per=date, with only the views not at their default. The
page's own reload, a link or the browser's Back draws them again. The page still reloads itself, and
opening it from the menu shows the defaults.

The calendars write their month into the address through the same helper now, lmKeepInAddress in
base.html, with no change in what they do.

The chart of a charge in progress is redrawn without a blink (#422)

While the car charges, the Charges page redraws the chart of the charge in progress every 30 seconds. At
every redraw the card showed for 0.07 to 0.17 s without its chart, and everything under it jumped up by
the chart's height and back. The panel now settles at once (settle:0ms), so the new chart is drawn in
the same step that swaps it in.

A restart keeps the outside temperature the car had (#425)

With the outside temperature switched on, Mate asks Open-Meteo at most once every 20 minutes or 10 km,
and a refused lookup keeps the last reading. That reading lived only in memory: when the first lookup
after a restart was refused (Open-Meteo answers 503 when it sheds load), there was no outside temperature
for up to 20 minutes. On one B10 from 13 to 17 October that happened on 4 of 10 starts.

Now the sampler starts from the reading on the car's newest position, if that position is younger than
20 minutes. The first poll still asks, and a lookup that answers replaces the stored reading at once; how
often Mate asks is unchanged.

Upgrade impact

• Nothing is migrated, and no setting is added.
• The Battery health page's address carries the views picked on it; an address without them shows the
  defaults, as before.
• When the poller starts it reads, for each car, the outside temperature of its newest position: one
  query, 0.02 ms on the test instance's database.
• The manuals gain one sentence on the Battery page's views kept in the address.

Verification

• CI green on the tag and on main: 5,673 passed, 1 skipped, plus 48 passed and 2 skipped on the Windows job; the check that the released desktop
  shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added: 5,673 passed, 1 skipped (a local-only reference file the clone does not carry).
• The new tests fail on 4.15.4's code and pass with the change: the browser test of #426 (back on Time,
  %/day and per stop), the browser test of #422 ("the card was swapped in without its chart") and the 3
  tests of #425 (None == 13.5, and the sampler not taking a stored reading). Those of #426 and #425 were
  checked before their merge, the one of #422 after the release.
• The Docker image, built from this release, ran on the test instance (one car, a real database, the
  outside temperature switched off there) before the tag: healthy, no errors in the log, and every page
  answers 200 as on 4.15.4. The Battery page with the views in its address answers too.
• Screenshots on the demo, before the merges: the Battery page keeps Distance, % lost and per date
  through a reload, where 4.15.4 goes back to the defaults; the card of the charge in progress keeps its
  height (534 px) during an update, where 4.15.4 drops to 123 px.
• Not tried: a refused Open-Meteo lookup after a real restart (covered by the tests and by @arekm on a
  copy of a live database), the add-on behind Home Assistant.

---

Italiano

Mate 4.15.5 — La pagina Batteria tiene le viste scelte

Tre correzioni di @arekm: viste che resistono all'aggiornamento automatico di una pagina, un grafico dal
vivo che non sfarfalla più e una temperatura esterna che resiste a un riavvio.

Cosa cambia

La pagina Salute batteria tiene le viste scelte (#426)

Lasciata aperta, la pagina Salute batteria si ricarica da sola ogni 30 secondi, così una ricarica che
finisce o una sosta che continua compaiono senza chiedere. Il ricaricamento però riportava i suoi due
grafici alle viste predefinite: Tempo su Capacità stimata per ricarica, %/giorno e per sosta su
Consumo da fermo.

Ora le viste scelte vanno nell'indirizzo della pagina, come un calendario tiene il suo mese:
battery?capacity_by=distance&drain=lost&drain_per=date, solo con le viste diverse da quelle
predefinite. Il ricaricamento della pagina, un link o il tasto Indietro del browser le ridisegnano. La
pagina si ricarica ancora da sola, e aprendola dal menu si vedono le viste predefinite.

I calendari scrivono il loro mese nell'indirizzo con la stessa funzione, lmKeepInAddress in
base.html, senza cambiare quello che fanno.

Il grafico di una ricarica in corso si ridisegna senza sfarfallare (#422)

Mentre l'auto carica, la pagina Ricariche ridisegna il grafico della ricarica in corso ogni 30 secondi. A
ogni ridisegno la scheda restava per 0,07–0,17 s senza grafico, e tutto quello che stava sotto saliva
dell'altezza del grafico e tornava giù. Ora il pannello si assesta subito (settle:0ms), quindi il
grafico nuovo viene disegnato nello stesso passo in cui viene sostituito.

Un riavvio mantiene la temperatura esterna che l'auto aveva (#425)

Con la temperatura esterna attiva, Mate chiede a Open-Meteo al massimo una volta ogni 20 minuti o 10 km,
e una richiesta rifiutata tiene l'ultimo valore. Quel valore stava solo in memoria: quando la prima
richiesta dopo un riavvio veniva rifiutata (Open-Meteo risponde 503 quando scarta il carico), la
temperatura esterna mancava fino a 20 minuti. Su una B10, dal 13 al 17 ottobre, è successo in 4 avvii
su 10.

Ora il campionatore parte dalla lettura dell'ultima posizione dell'auto, se quella posizione ha meno di
20 minuti. La prima lettura chiede comunque, e una richiesta che risponde sostituisce subito il valore
salvato; quante volte Mate chiede non cambia.

Impatto dell'aggiornamento

• Nessuna migrazione e nessuna impostazione nuova.
• L'indirizzo della pagina Salute batteria porta le viste scelte; un indirizzo senza mostra le viste
  predefinite, come prima.
• All'avvio il poller legge, per ogni auto, la temperatura esterna della sua ultima posizione: una query,
  0,02 ms sul database dell'istanza di prova.
• I manuali hanno una frase in più sulle viste della pagina Batteria tenute nell'indirizzo.

Verifica

• CI verde sul tag e su main: 5.673 passati, 1 saltato, più 48 passati e 2 saltati sul job Windows; il controllo che il guscio desktop
  pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti: 5.673 passati, 1 saltato (un file di riferimento solo locale che la copia non porta).
• I test nuovi falliscono sul codice della 4.15.4 e passano con la modifica: il test nel browser della #426
  (torna su Tempo, %/giorno e per sosta), il test nel browser della #422 («la scheda è stata
  sostituita senza il suo grafico») e i 3 test della #425 (None == 13.5, e il campionatore che non prende un
  valore salvato). Quelli della #426 e della #425 sono stati controllati prima del merge, quello della #422
  dopo la release.
• L'immagine Docker, costruita da questa versione, ha girato sull'istanza di prova (una sola auto, un
  database vero, la temperatura esterna spenta lì) prima del tag: sana, nessun errore nel log, e ogni
  pagina risponde 200 come sulla 4.15.4. Risponde anche la pagina Batteria con le viste nell'indirizzo.
• Screenshot sulla demo, prima dei merge: la pagina Batteria tiene Distanza, % perso e per data
  dopo il ricaricamento, mentre la 4.15.4 torna alle viste predefinite; la scheda della ricarica in corso
  mantiene la sua altezza (534 px) durante un aggiornamento, mentre la 4.15.4 scende a 123 px.
• Non provati: una richiesta a Open-Meteo rifiutata dopo un vero riavvio (coperta dai test e da @arekm su
  una copia di un database vero), l'add-on dentro Home Assistant.

Mate 4.15.4 — A parked car without GPS keeps its outside temperature

Mate 4.15.4 — A parked car without GPS keeps its outside temperature

A fix to the live outside temperature, for a car whose GPS position the Leapmotor cloud sends as zero.

---

What changes

A parked car without GPS keeps its outside temperature

With the outside temperature switched on (Settings → trip defaults), Mate looks the car's position up
against Open-Meteo, at most once every 20 minutes or 10 km. A reading with no GPS fix, latitude and
longitude 0, is not looked up, so that the weather of a wrong place is never stored. Until now that
left the last value as it was, kept only in memory: after a restart of Mate there was none, every new
position was stored without an outside temperature, and the Overview, after some hours of readings
without one, hid the row.

On 13 October the cloud sent all six GPS signals of a parked B10 as zero for more than 14 hours, with
every other reading normal and the odometer unchanged.

Now:

• with no GPS fix, Mate asks Open-Meteo about the car's last real position, but only while the odometer
  reads what it read there, both known;
• the last real position comes from each reading that has one and, when Mate starts, from the database,
  so a restart no longer leaves the value empty;
• a car driven since its last fix, or a reading without an odometer, is not guessed at: the last value
  stays, as before;
• with a GPS fix nothing changes, and with the switch off Mate asks Open-Meteo nothing, as before.

Upgrade impact

• Nothing is migrated. When the poller starts it reads, for each car, the last stored position with a
  GPS fix: one query, 0.5 ms on the test instance's database.
• With the switch on and the GPS missing, a parked car is looked up as often as one with a fix, at most
  once every 20 minutes, where before nothing was asked.
• Positions already stored are not changed.

Verification

• CI green on the tag: 5,668 passed, 1 skipped, plus 48 passed and 2 skipped on the Windows job; the
  check that the released desktop shell still runs this Mate is green. On main, the same commit's first
  run stopped once on a browser test of the Charges page (a 30 s wait after the 🆓 button, code this
  release does not touch); its second run was green, and the test passed 20 times out of 20 locally.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added: 5,668 passed, 1 skipped (a local-only reference file the clone does not carry).
• The 8 new tests fail on 4.15.3. Putting back, one at a time, the odometer check and the reading of the
  last position at start, each made a test fail.
• The Docker image, built from this release, ran on the test instance (one car, a real database, the
  GPS at zero since the night, the outside temperature switched off there) before the tag: every page
  answers as on 4.15.3 and the log has no errors. On that database, with Open-Meteo's call replaced so
  that nothing was sent, the last reading has no GPS fix, the last position with one has the same
  odometer, and the sampler asks once, about that position.
• Not tried: a real Open-Meteo lookup with the GPS missing, the add-on behind Home Assistant.

---

Italiano

Mate 4.15.4 — Un'auto ferma senza GPS mantiene la temperatura esterna

Una correzione della temperatura esterna dal vivo, per un'auto di cui il cloud Leapmotor manda la
posizione GPS a zero.

Cosa cambia

Un'auto ferma senza GPS mantiene la temperatura esterna

Con la temperatura esterna attiva (Impostazioni → valori predefiniti dei viaggi), Mate chiede a
Open-Meteo il meteo nella posizione dell'auto, al massimo una volta ogni 20 minuti o 10 km. Una lettura
senza posizione GPS, latitudine e longitudine 0, non viene chiesta, così non viene mai salvato il meteo
di un posto sbagliato. Finora questo lasciava l'ultimo valore com'era, tenuto solo in memoria: dopo un
riavvio di Mate non c'era più, ogni nuova posizione veniva salvata senza temperatura esterna, e la
Panoramica, dopo alcune ore di letture senza, nascondeva la riga.

Il 13 ottobre il cloud ha mandato a zero tutti e sei i segnali GPS di una B10 ferma per più di 14 ore,
con tutte le altre letture normali e il contachilometri fermo.

Ora:

• senza posizione GPS, Mate chiede a Open-Meteo il meteo nell'ultima posizione vera dell'auto, ma solo
  finché il contachilometri segna quello che segnava lì, ed entrambi sono noti;
• l'ultima posizione vera viene da ogni lettura che ce l'ha e, all'avvio di Mate, dal database, quindi
  un riavvio non lascia più il valore vuoto;
• un'auto guidata dopo l'ultima posizione, o una lettura senza contachilometri, non viene indovinata:
  resta l'ultimo valore, come prima;
• con la posizione GPS non cambia niente, e con l'interruttore spento Mate non chiede niente a
  Open-Meteo, come prima.

Impatto dell'aggiornamento

• Nessuna migrazione. All'avvio il poller legge, per ogni auto, l'ultima posizione salvata con il GPS:
  una query, 0,5 ms sul database dell'istanza di prova.
• Con l'interruttore acceso e il GPS assente, un'auto ferma viene chiesta tanto spesso quanto una con
  il GPS, al massimo una volta ogni 20 minuti, dove prima non si chiedeva niente.
• Le posizioni già salvate non cambiano.

Verifica

• CI verde sul tag: 5.668 passati, 1 saltato, più 48 passati e 2 saltati sul job Windows; il controllo
  che il guscio desktop pubblicato faccia ancora girare questa Mate è verde. Su main, il primo giro dello
  stesso commit si è fermato una volta su un test del browser della pagina Ricariche (un'attesa di 30 s
  dopo il pulsante 🆓, codice che questa versione non tocca); il secondo giro è stato verde, e in locale
  il test è passato 20 volte su 20.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti: 5.668 passati, 1 saltato (un file di riferimento solo locale che la copia non porta).
• Gli 8 test nuovi falliscono sulla 4.15.3. Rimettendo com'erano, uno alla volta, il controllo del
  contachilometri e la lettura dell'ultima posizione all'avvio, ognuno ha fatto fallire un test.
• L'immagine Docker, costruita da questa versione, ha girato sull'istanza di prova (una sola auto, un
  database vero, il GPS a zero dalla notte, la temperatura esterna spenta lì) prima del tag: ogni pagina
  risponde come sulla 4.15.3 e nel log non ci sono errori. Su quel database, con la chiamata a
  Open-Meteo sostituita così che non partisse niente, l'ultima lettura non ha il GPS, l'ultima posizione
  con il GPS ha lo stesso contachilometri, e il campionatore chiede una volta, per quella posizione.
• Non provati: una vera richiesta a Open-Meteo con il GPS assente, l'add-on dentro Home Assistant.

Mate 4.15.3 — The wallbox's line stays with the charge

Mate 4.15.3 — The wallbox's line stays with the charge

A change by @arekm, #419, which follows
#416, and a fix to the times under the
charts on a phone.

---

What changes

The wallbox's line stays with the charge (#419, @arekm)

With the wallbox enabled in Settings and Home Assistant configured, the chart of a home charge draws the
wallbox's power, the green Wallbox (AC) line, beside the car's. Until now that line was read from Home
Assistant's history each time a chart opened: it disappeared when Home Assistant purged its history
(after about 10 days by default), and reading it made a long charge's chart slow.

Now:

• at every poll of a home charge, the poller keeps the wallbox's power and counter, which it already
  read for the charge's energy, in a new table, ha_samples, dated like the car's readings;
• the line on the Charges page, on the Wallbox page and in the panel of the running charge is drawn from
  these readings alone: opening a chart asks Home Assistant nothing. On @arekm's install the chart of a
  19-hour charge answered in 0.13 s instead of 2.3 s, with the same 2,262 values;
• once after the update, in the background, Mate copies the lines of the finished charges marked Home or
  not yet confirmed, of every car, from what Home Assistant's history still holds. A charge older than
  that history keeps no line, as before. If Home Assistant does not answer, the copy stops and is tried
  again at a later start, at most once an hour; once every charge has been read it does not run again;
• without the wallbox enabled or without Home Assistant, Mate asks Home Assistant nothing, as before, and
  the new table stays empty.

The energy and the cost of a charge are worked out as before, from the wallbox's counter.

A custom-kWh helper that reports in Wh is priced in kWh (#419)

With the Custom kWh (Home Assistant) pricing, Mate reads the kWh to bill from a helper in Home
Assistant. A helper reporting in Wh was read as kWh, so 7,000 Wh were priced as 7,000 kWh. The figure is
now converted, as the wallbox's own readings are. A helper in kWh is read as before.

On a phone, the times under a chart no longer run into each other

The time axis of a charge's and a trip's chart asked for the same number of times on every screen, so on
a phone they were printed on top of each other. The axis now prints as many as its width holds: 4 or 5
on a phone; on a computer and a tablet, as before.

Upgrade impact

• A new table, ha_samples, is created at the first start; nothing else is migrated.
• With the wallbox and Home Assistant: after the first start Mate asks Home Assistant's history for 2
  readings per earlier home or unconfirmed charge, one charge after another, in the background. The
  table grows by about 2,200 rows per home charge in @arekm's figures; at 116 bytes a row, measured,
  about 250 KB per charge. The GPS retention setting does not remove these rows.
• Costs already stored are not recomputed. A charge confirmed or re-priced after the update with a
  helper in Wh is priced in kWh.
• An earlier charge marked as public at the update and changed to Home afterwards gets no line: the copy
  reads only the charges marked Home or not yet confirmed.

Verification

• CI green on the tag: 5,660 passed, 1 skipped, plus 48 passed and 2 skipped on the Windows job;
  the check that the released desktop shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added: 5,660 passed, 1 skipped
  (a local-only reference file the clone does not carry).
• #419, checked on main for the three points found on #416: with the database locked as the web starts,
  the web starts and leaves the copy to a later start; with every history read failing, the copy asks
  for one charge (2 requests, where #416 asked 6) and is not recorded as done; after 50 chart reads
  Python's import path is as it was. Its new tests fail on 4.15.2. Of ten parts of the change put back
  one at a time, nine made a test fail; the tenth, the Wh conversion, now has its own test, which fails
  on 4.15.2 (1,680 instead of 1.68).
• On Mate's demo data in Chromium: a home charge whose readings are in the table draws the wallbox line
  from them, at 1280 and 390 px, in the same time as before, with no page errors. On a phone the times
  under the charge and trip charts ran into each other, by up to 12 px; now 4 or 5 are printed, at least
  16 px apart; at 1280 px the axis is as before. The 4 phone tests of the axis fail on 4.15.2.
• On a copy of a real database (one car, wallbox enabled, Home Assistant not reachable from the copy),
  every page answered as on 4.15.2 and the table was created empty.
• The Docker image, built from this release, ran on the test instance (one car, a real database, the
  wallbox enabled, Home Assistant not set up there) before the tag: every page answers as on 4.15.2;
  ha_samples is created empty and the copy asks nothing, since there is no Home Assistant to ask; the
  charts' script carries the new axis; the log has no errors.
• Not tried: Firefox, a real phone, the add-on behind Home Assistant, a custom-kWh helper on a real Home
  Assistant.

---

Italiano

Mate 4.15.3 — La linea della wallbox resta con la ricarica

Una modifica di @arekm, la #419, che segue
la #416, e una correzione delle ore sotto i
grafici sul telefono.

Cosa cambia

La linea della wallbox resta con la ricarica (#419, @arekm)

Con la wallbox attiva nelle Impostazioni e Home Assistant configurato, il grafico di una ricarica di casa
disegna la potenza della wallbox, la linea verde Wallbox (AC), accanto a quella dell'auto. Finora
quella linea veniva letta dallo storico di Home Assistant a ogni apertura del grafico: spariva quando Home
Assistant cancellava il suo storico (dopo circa 10 giorni, di default), e leggerla rendeva lento il
grafico di una ricarica lunga.

Ora:

• a ogni lettura di una ricarica di casa, il poller conserva la potenza e il contatore della wallbox, che
  leggeva già per l'energia della ricarica, in una tabella nuova, ha_samples, con l'ora delle letture
  dell'auto;
• la linea nella pagina Ricariche, nella pagina Wallbox e nel pannello della ricarica in corso è
  disegnata solo da queste letture: aprire un grafico non chiede niente a Home Assistant.
  Sull'installazione di @arekm il grafico di una ricarica di 19 ore rispondeva in 0,13 s invece di
  2,3 s, con gli stessi 2.262 valori;
• una volta sola dopo l'aggiornamento, in background, Mate copia le linee delle ricariche finite segnate
  Casa o non ancora confermate, di ogni auto, da quello che lo storico di Home Assistant ha ancora. Una
  ricarica più vecchia di quello storico resta senza linea, come prima. Se Home Assistant non risponde,
  la copia si ferma e riprova a un avvio successivo, al massimo una volta all'ora; quando ha letto tutte
  le ricariche non riparte più;
• senza la wallbox attiva o senza Home Assistant, Mate non chiede niente a Home Assistant, come prima, e
  la tabella nuova resta vuota.

L'energia e il costo di una ricarica si calcolano come prima, dal contatore della wallbox.

Un helper «kWh personalizzati» che riporta i Wh viene prezzato in kWh (#419)

Con il prezzo kWh personalizzati (Home Assistant), Mate legge i kWh da fatturare da un helper di Home
Assistant. Un helper che riportava i Wh veniva letto come kWh, quindi 7.000 Wh erano prezzati come
7.000 kWh. Ora il valore viene convertito, come le letture della wallbox. Un helper in kWh viene letto
come prima.

Sul telefono, le ore sotto un grafico non si sovrappongono più

L'asse delle ore del grafico di una ricarica e di un viaggio chiedeva lo stesso numero di ore su ogni
schermo, quindi sul telefono venivano scritte una sopra l'altra. Ora l'asse ne scrive quante ne entrano
nella sua larghezza: 4 o 5 sul telefono; sul computer e sul tablet, come prima.

Impatto dell'aggiornamento

• Al primo avvio viene creata una tabella nuova, ha_samples; nient'altro viene migrato.
• Con la wallbox e Home Assistant: dopo il primo avvio Mate chiede allo storico di Home Assistant 2
  letture per ogni ricarica precedente di casa o non confermata, una ricarica dopo l'altra, in
  background. Nei dati di @arekm la tabella cresce di circa 2.200 righe per ricarica di casa; a 116 byte
  per riga, misurati, circa 250 KB per ricarica. L'impostazione di conservazione dei punti GPS non
  cancella queste righe.
• I costi già salvati non vengono ricalcolati. Una ricarica confermata o ricalcolata dopo
  l'aggiornamento con un helper in Wh viene prezzata in kWh.
• Una ricarica precedente segnata come pubblica al momento dell'aggiornamento e cambiata in Casa dopo
  resta senza linea: la copia legge solo le ricariche segnate Casa o non ancora confermate.

Verifica

• CI verde sul tag: 5.660 passati, 1 saltato, più 48 passati e 2 saltati sul job Windows; il
  controllo che il guscio desktop pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti: 5.660 passati,
  1 saltato (un file di riferimento solo locale che la copia non porta).
• #419, controllata su main per i tre punti trovati sulla #416: con il database bloccato all'avvio
  della web, la web parte e rimanda la copia a un avvio successivo; con tutte le letture dello storico
  che falliscono, la copia chiede una sola ricarica (2 richieste, dove la #416 ne faceva 6) e non viene
  segnata come fatta; dopo 50 letture di grafici il percorso di import di Python è come prima. I suoi
  test nuovi falliscono sulla 4.15.2. Di dieci parti della modifica rimesse com'erano una alla volta,
  nove hanno fatto fallire un test; la decima, la conversione dei Wh, ha ora un ...

Mate 4.15.2 — A charge's chart comes as its row opens

Mate 4.15.2 — A charge's chart comes as its row opens

Two changes by @arekm, #417 and
#418, and a fix to the diagnostic bundle
(#338).

---

What changes

The chart of a charge appears when its row opens, and draws no more readings than it has pixels (#417, @arekm)

The chart under an opened charge on the Charges page was asked for only when its place scrolled into
view. On a phone the opened row runs past the bottom edge with the chart at its end, so nothing was
asked for until a scroll. And the chart drew every reading: a night's charge has two thousand and more,
and drawing them took over a second.

Now:

• the chart is asked for as the row opens, wherever its body lands. A row nobody opens still asks for
  nothing, a row opened and closed asks once, and a link to a charge still opens its row and loads its
  chart;
• the chart draws at most one reading per pixel of its width: every K-th one, the last, and the
  readings on either side of a pause. Each point drawn is a real reading at its own time, and the hover
  box shows it as read, never an average. A pause still breaks the line where it did;
• a charge with no more slots than the chart has pixels (up to about eight hours on a desktop) draws
  every reading, as before;
• the same chart on the Wallbox page and in the panel of the running charge is thinned the same way.

An opened charge row comes into view with its chart (#418, @arekm)

A charge row opened in the lower part of the screen grew below the bottom edge, and its chart had to be
scrolled to by hand. Now, once its chart is drawn, the page scrolls as little as shows the whole row, or
brings the row's top to the top of the screen, below any banner there, when the row is taller than the
screen. A row already whole on the screen does not move; rows opened by Expand all, by a link to a
charge or after a merge or a split stay where they are; a row closed before its chart comes is not
scrolled to.

Diagnostics: "SoC by day" counts a day's own kilometres (#338)

The SoC by day section of the diagnostic bundle took a day's highest odometer minus its lowest. A
reading without an odometer is stored as 0, and before 4.14.1 a reading of the other car on an account
could be filed under this one, so in a bundle on #338 a T03's days read "drove 9228 km", and another
"drove 8573 km" with the other car's 96.8 %. Now a reading without an odometer does not count for the
km, and one more than 1,500 km from the day's median odometer is left out of the day's km and SoC and
counted apart on that day's line ("⚠ 1 reading(s) over 1500 km off the day's odometer, left out
(another car's?)"). Only the bundle changes: no page reads this section.

Also

• Manuals: the 4.15.0 section says a charge under 3 A is a home charge under about 2.2 kW on a C10, at
  about 720 V, where it said "on an 800 V car".
• Tests: the test of the running charge's chart took its plug-in time once, at import, and the LIVE
  badge needs a reading under five minutes old, so a run that reached it more than four minutes in
  failed. The time is now taken as each test starts.

Upgrade impact

• Nothing is migrated: no table, column or setting changes.
• A long charge's chart draws fewer points than before, each a real reading; the lines look the same.
• A row opened by hand near the bottom of the screen moves the page once its chart is drawn.

Verification

• CI green on the tag: 5,639 passed, 1 skipped, plus 48 passed and 2 skipped on the Windows job;
  the check that the released desktop shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added: 5,639 passed, 1 skipped
  (a local-only reference file the clone does not carry).
• On 4.15.1, 8 of the new or adapted browser tests of #417 and #418 fail, and here they pass; the 3 new
  tests of the diagnostics fix failed before it. The test of the running charge's chart failed on
  4.15.1 with the run held 250 s after collecting, and passes with the same hold.
• Measured on Mate's demo data in Chromium, on a 19-hour charge of 2,280 readings: at 1280 px,
  1,943 ms → 440 ms from the click to the chart, with 761 readings drawn instead of 2,280 and the same
  lines; at 390 px the chart comes without a scroll, in 194 ms, with 286 readings. A row opened at the
  bottom edge of the screen: at 1280×800 it ran to 945 px and now ends on the edge, at 800; at 390×844
  it ran to 989 px and now ends on the edge, at 844, chart in view. No page errors.
• The Docker image, built from this release, ran on the test instance (one car) with a real database
  before the tag: every page answers as on 4.15.1; the six latest charges' charts are served with the
  thinning, and the day drawer asks for its chart on the opening; SoC by day reads as on 4.15.1 on
  this car's data, which has no reading of another car; the log has no errors.
• Not tried: Firefox, a real phone, the add-on behind Home Assistant.

---

Italiano

Mate 4.15.2 — Il grafico di una ricarica arriva quando si apre la riga

Due modifiche di @arekm, la #417 e la
#418, e una correzione del pacchetto di
diagnostica (#338).

Cosa cambia

Il grafico di una ricarica arriva quando si apre la riga, e non disegna più letture dei pixel che ha (#417, @arekm)

Il grafico sotto una ricarica aperta nella pagina Ricariche veniva chiesto solo quando il suo posto
entrava nello schermo. Sul telefono la riga aperta va oltre il bordo in basso, con il grafico alla fine,
quindi non veniva chiesto niente finché non si scorreva. E il grafico disegnava ogni lettura: una
ricarica notturna ne ha duemila e più, e disegnarle richiedeva più di un secondo.

Ora:

• il grafico viene chiesto quando si apre la riga, ovunque finisca il suo contenuto. Una riga che
  nessuno apre continua a non chiedere niente, una riga aperta e chiusa chiede una volta sola, e un
  link a una ricarica apre ancora la sua riga e carica il suo grafico;
• il grafico disegna al massimo una lettura per ogni pixel di larghezza: una ogni K, l'ultima, e le
  letture subito prima e subito dopo una pausa. Ogni punto disegnato è una lettura vera alla sua ora, e
  il riquadro al passaggio del mouse la mostra com'è stata letta, mai una media. Una pausa interrompe
  ancora la linea dove la interrompeva;
• una ricarica che non ha più posizioni dei pixel del grafico (fino a circa otto ore sul computer)
  disegna ogni lettura, come prima;
• lo stesso grafico nella pagina Wallbox e nel pannello della ricarica in corso viene sfoltito allo
  stesso modo.

Una riga di ricarica aperta si mette in vista con il suo grafico (#418, @arekm)

Una riga di ricarica aperta nella parte bassa dello schermo cresceva sotto il bordo in basso, e il suo
grafico andava raggiunto scorrendo a mano. Ora, quando il suo grafico è disegnato, la pagina scorre
quanto basta a mostrare la riga intera, o porta l'inizio della riga in cima allo schermo, sotto
l'eventuale banner, quando la riga è più alta dello schermo. Una riga già tutta sullo schermo non si
muove; le righe aperte con Espandi tutto, da un link a una ricarica o dopo un'unione o una divisione
restano dove sono; una riga chiusa prima che arrivi il suo grafico non viene raggiunta.

Diagnostica: «SoC by day» conta i chilometri del giorno stesso (#338)

La sezione SoC by day del pacchetto di diagnostica prendeva il contachilometri più alto del giorno
meno il più basso. Una lettura senza contachilometri è salvata come 0, e prima della 4.14.1 una lettura
dell'altra auto di un account poteva finire sotto questa, quindi in un pacchetto della #338 i giorni di
una T03 dicevano «drove 9228 km», e un altro «drove 8573 km» con il 96,8 % dell'altra auto. Ora una
lettura senza contachilometri non conta per i km, e una che dista più di 1.500 km dal contachilometri
mediano del giorno viene tolta dai km e dal SoC del giorno e contata a parte sulla riga di quel giorno
(«⚠ 1 reading(s) over 1500 km off the day's odometer, left out (another car's?)»). Cambia solo il
pacchetto: nessuna pagina legge questa sezione.

Inoltre

• Manuali: la sezione della 4.15.0 dice che una ricarica sotto i 3 A è, su una C10, a circa 720 V, una
  ricarica di casa sotto i 2,2 kW circa, dove diceva «su un'auto a 800 V».
• Test: il test del grafico della ricarica in corso prendeva l'ora di collegamento una volta sola,
  all'import, e il badge LIVE vuole una lettura con meno di cinque minuti, quindi una suite che arrivava
  a quel test dopo più di quattro minuti falliva. Ora l'ora si prende all'inizio di ogni test.

Impatto dell'aggiornamento

• Niente viene migrato: nessuna tabella, colonna o impostazione cambia.
• Il grafico di una ricarica lunga disegna meno punti di prima, ognuno una lettura vera; le linee
  sembrano le stesse.
• Una riga aperta a mano in fondo allo schermo fa scorrere la pagina quando il suo grafico è disegnato.

Verifica

• CI verde sul tag: 5.639 passati, 1 saltato, più 48 passati e 2 saltati sul job Windows; il
  controllo che il guscio desktop pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti: 5.639 passati,
  1 saltato (un file di riferimento solo locale che la copia non porta).
• Sulla 4.15.1 falliscono 8 test nuovi o adattati, nel browser, della #417 e della #418, e qui passano;
  i 3 test nuovi della correzione della diagnostica fallivano prima della correzione. Il test del
  grafico della ricarica in corso falliva sulla 4.15.1 con la suite fermata 250 secondi dopo la
  raccolta dei test, e passa con la stessa attesa.
• Misurato sui dati dimostrativi di...

Mate 4.15.1 — A charge ends when the energy stops

Mate 4.15.1 — A charge ends when the energy stops

Two changes by @arekm: #414 and
#415.

---

What changes

A charge ends when the energy stops, and a full battery says "Charge complete" (#414, @arekm)

After a charge, with the cable still in, a car keeps its charge session open for a while: in the
diagnostic bundles #414 replayed, for minutes on the B10s and up to hours on the T03s. Mate ended the
charge only with the session, so until then:

• the Overview showed the charging animation and "Charging", and the Charges page "LIVE" at 0.00 kW;
• the charge was filed as lasting until the session closed: its end time and its duration counted
  the minutes, or hours, after the energy stopped.

Now:

• a charge ends where it stopped adding energy: the later of the first reading after its last
  charging sample and its last SoC rise. Its end SoC is that reading's;
• with the cable in, nothing going in and the SoC within one point of the car's charge limit (100 %
  if the car reports none), the Overview reads "Cable connected · 100% (Charge complete)" and the
  Charges page "Fully charged";
• the session's close is kept in a new column, charges.closed_at. The wallbox counter and the Home
  Assistant kWh helper (custom-kWh pricing) are still read up to it, and the wallbox profile switch
  still waits for it;
• the Charges page reloads its history when the car ends its session;
• signal 3736 is no longer read: no car in #414's data sends it as a completion. It stays in the
  diagnostics as charge_completed_raw.

Unchanged: a charge that pauses below the limit still reads as charging while its session is open
(#307); a finished charge appears in the list when the car ends its session; MQTT and the Home
Assistant entities publish the car's own charging flag, as before.

A row that ends on another day says which (#415, @arekm)

A charge or a trip printed its end as a bare time, so a charge from 23:05 to 06:40 the next day read
"23:05 → 06:40". Now it reads "23:05 → 09 Oct 06:40", with the day and month in the reader's
language: in the Charges and Trips drawers, the merge preview, the similar-trips page and the times
of a merged trip's later pieces. A row that starts and ends on one day reads as before, and is still
listed under the day it started.

Upgrade impact

• The charges table gets one new column, closed_at. It stays empty on the charges recorded before
  and on manual and reconstructed ones. Nothing is migrated or deleted, and the charges recorded
  before keep their end.
• The charges CSV export has the new closed_at column; the import ignores it.
• After a charge to the limit with the cable still in, the Overview says "Charge complete" instead of
  "Charging", and a new charge no longer counts the time the car kept its session open afterwards.

Verification

• CI green on the tag: 5,628 passed, 1 skipped, plus 48 passed and 2 skipped on the Windows job;
  the check that the released desktop shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added: 5,628 passed, 1 skipped
  (a local-only reference file the clone does not carry).
• #414 adds five test files and adapts six; #415 adds one and registers its filter in seven that
  render templates. On 4.15.0, 25 of #414's new or adapted tests and the 3 new tests of #415 fail;
  here they pass.
• Nine parts of #414 were put back one at a time, and each time a test failed: the end on the first
  reading after the last sample, the end on the last SoC rise, a reading without an SoC, the wallbox
  ceiling over the session, the kWh helper read up to the close, a full battery still read as
  charging, "complete" with current going in, the wallbox profile guard, the session read before the
  chart.
• Screenshots on demo data in Chromium: a charge to 100 % with its session still open, on the
  Overview and the Charges page, before and after; the Charges and Trips drawers in Italian at 1280
  and 390 px, before and after. On the demo data, a charge to 100 % whose session closed 15 minutes
  after the energy stopped now lasts 155 minutes instead of 170, with the same energy.
• The Docker image, built from this release, ran on the test instance (one car) with a real database
  before the tag: every page answers as on 4.15.0; the closed_at column is added and stays empty on
  the charges already there; the six charges that ran past midnight now show their end day, as
  "→ 11 giu 08:19" in Italian, and the rows within one day show none; the charges CSV has 42
  columns instead of 41; the log has no errors. No trip of that car crosses midnight, and the car
  has not charged since 7 October, so the new end of a charge and "Charge complete" were not seen at
  work on it.
• Not tried: a real charge on 4.15.1 (the new end has not yet dated a real charge), the replay of the
  74 public bundles described in #414, the add-on behind Home Assistant, a real phone.

---

Italiano

Mate 4.15.1 — Una ricarica finisce quando smette di entrare energia

Due modifiche di @arekm: la #414 e la
#415.

Cosa cambia

Una ricarica finisce quando smette di entrare energia, e una batteria piena dice «Carica completa» (#414, @arekm)

Dopo una ricarica, con il cavo ancora inserito, l'auto tiene aperta la sessione di carica ancora per
un po': nei pacchetti di diagnostica riletti nella #414, per minuti sulle B10 e fino a ore sulle T03.
Mate chiudeva la ricarica solo con la sessione, quindi fino ad allora:

• la Panoramica mostrava l'animazione di carica e «In ricarica», e la pagina Ricariche «LIVE» a
  0,00 kW;
• la ricarica veniva registrata come durata fino alla chiusura della sessione: l'ora di fine e la
  durata contavano i minuti, o le ore, dopo che l'energia aveva smesso di entrare.

Ora:

• una ricarica finisce dove ha smesso di aggiungere energia: la più tarda tra la prima lettura dopo
  il suo ultimo campione di carica e la sua ultima salita del SoC. Il SoC finale è quello di quella
  lettura;
• con il cavo inserito, niente che entra e il SoC entro un punto dal limite di carica dell'auto
  (100 % se l'auto non ne indica uno), la Panoramica dice «Cavo connesso · 100% (Carica completa)» e
  la pagina Ricariche «Carica completa»;
• la chiusura della sessione resta in una colonna nuova, charges.closed_at. Il contatore della
  wallbox e l'helper dei kWh di Home Assistant (prezzo kWh personalizzato) si leggono ancora fino a
  lì, e il cambio di profilo della wallbox aspetta ancora quella chiusura;
• la pagina Ricariche ricarica la sua cronologia quando l'auto chiude la sessione;
• il segnale 3736 non si legge più: nessuna auto nei dati della #414 lo manda come fine della carica.
  Resta nella diagnostica come charge_completed_raw.

Non cambia: una ricarica che fa una pausa sotto il limite si legge ancora come in carica finché la
sessione è aperta (#307); una ricarica finita compare nell'elenco quando l'auto chiude la sessione;
MQTT e le entità di Home Assistant pubblicano il segnale di carica dell'auto, come prima.

Una riga che finisce un altro giorno lo dice (#415, @arekm)

Una ricarica o un viaggio scriveva la fine come un'ora sola, quindi una ricarica dalle 23:05 alle
06:40 del giorno dopo si leggeva «23:05 → 06:40». Ora si legge «23:05 → 09 ott 06:40», con giorno e
mese nella lingua di chi legge: nei pannelli del giorno di Ricariche e Viaggi, nell'anteprima
dell'unione, nella pagina dei viaggi simili e negli orari dei pezzi successivi di un viaggio unito.
Una riga che inizia e finisce lo stesso giorno si legge come prima, ed è ancora elencata sotto il
giorno in cui è iniziata.

Impatto dell'aggiornamento

• La tabella delle ricariche riceve una colonna nuova, closed_at. Resta vuota sulle ricariche
  registrate prima e su quelle manuali e ricostruite. Niente viene migrato o cancellato, e le
  ricariche registrate prima tengono la loro fine.
• L'esportazione CSV delle ricariche ha la nuova colonna closed_at; l'importazione la ignora.
• Dopo una ricarica fino al limite con il cavo ancora inserito, la Panoramica dice «Carica completa»
  invece di «In ricarica», e una ricarica nuova non conta più il tempo in cui l'auto ha tenuto aperta
  la sessione dopo.

Verifica

• CI verde sul tag: 5.628 passati, 1 saltato, più 48 passati e 2 saltati sul job Windows; il
  controllo che il guscio desktop pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti: 5.628 passati,
  1 saltato (un file di riferimento solo locale che la copia non porta).
• La #414 aggiunge cinque file di test e ne adatta sei; la #415 ne aggiunge uno e registra il suo
  filtro in sette che disegnano i template. Sulla 4.15.0 falliscono 25 test nuovi o adattati della
  #414 e i 3 test nuovi della #415; qui passano.
• Nove parti della #414 sono state tolte una alla volta, e ogni volta un test è fallito: la fine sulla
  prima lettura dopo l'ultimo campione, la fine sull'ultima salita del SoC, una lettura senza SoC, il
  tetto della wallbox sulla sessione, l'helper dei kWh letto fino alla chiusura, una batteria piena
  letta ancora come in carica, «completa» con corrente che entra, la protezione del profilo della
  wallbox, la sessione letta prima del grafico.
• Schermate con dati dimostrativi in Chromium: una ricarica al 100 % con la sessione ancora aperta,
  nella Panoramica e nella pagina Ricariche, prima e dopo; i pannelli del giorno di Ricariche e Viaggi
  in italiano a 1280 e 390 px, prima e dopo. Sui dati dimostrativi, una ricarica al 100 % la cui
  sessione si è chiusa 15 minuti dopo la fine dell'energia ora dura 155 minuti invece di 170, con la
  stessa energia.
• L'immagine Docker, costruita da questa versio...

Mate 4.15.0 — A charge reads like a trip

Mate 4.15.0 — A charge reads like a trip

The Charges calendar redone by @arekm in
#412, and two fixes: one found in the
report of @arzthilfe on #409, one in the
report of @ViriatusOG on #395.

---

What changes

A charge is a row that opens (#412, @arekm)

The day drawer of the Charges calendar drew a card of some 650 px for each charge. Now:

• each charge is a row, with a thumbnail of its power and SoC curve beside it;
• a click opens it under itself: the energy; a line with the battery's temperature, the outside
  temperature and the average power; the chart; the note on one line; the actions;
• the editors that were on the card (type, 🆓, ✎, 🧭 🔄 ✏️, the place) stay on the row and work
  without opening it;
• Expand all / Collapse all beside the day's date;
• several days at once, as in the Trips calendar: shift-click or drag with a mouse; on a phone, hold
  a day for half a second, then tap another. The heading gives the totals of the range, and each day
  its own.

The chart under a charge reads Home Assistant off the web server's event loop, and when Home
Assistant has just failed to answer, the next charts do not ask it again for a minute.

The charging panel shows the power of a charge under 3 A (#409)

"Charging status" on the Charges page and the charging chip on the Overview computed the power only
from 3 A up. At the 718 V of @arzthilfe's C10, a 1.7 kW home charge carries 2.4 A, so both read
0.00 kW while the chart below drew the power. It was the page's copy of the floor 3.18.3 took out of
the poller (#307). It is gone: zero current still reads zero.

A charge window saved here shows on the Overview at once (#395)

Since 3.10.0 the Overview reads the charge window the poller files under each car, refreshed every
30 minutes. A window saved on the Scheduling page went to a key the Overview reads only when that
one is empty, so after a save the car had confirmed, the Overview kept the old window for up to 30
minutes. The save now files it under the car on screen, as the poller does.

Upgrade impact

• Nothing is migrated or deleted; no table changes.
• The Charges calendar looks different: the same information and the same actions, in rows.
• With two cars, a window saved on the Scheduling page is filed under the car on screen and no
  longer touches the other car's. The poller's next read of the car still wins, as before.

Verification

• CI green on the tag: 5,596 passed, 1 skipped, plus 48 passed and 2 skipped on the Windows job;
  the check that the released desktop shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added: 5,596 passed, 1 skipped
  (a local-only reference file the clone does not carry).
• Eleven new tests for the two fixes. On 4.14.2, 3 of the 6 for #409 fail (a 2.37 A charge reads
  0.00 kW, on the panel and on the page) and 2 of the 5 for #395 fail (the Overview keeps the old
  window after a save, whether switched off or moved). Now all eleven pass. One existing test now reads
  the window the Overview shows instead of the old shared key; what it checks is unchanged.
• #412 brings its own tests. Each of its four fixes from the review was put back one at a time, and
  each time its tests failed: the range that crosses midnight (4), the gap of a paused charge (1),
  the chart read off the event loop (2), the minute without asking Home Assistant (1).
• Screenshots on demo data: the Charges calendar on a computer, with several days open and at phone
  width; the charging panel and the Overview chip at 1.7 kW, before and after; the Overview after a
  save on the Scheduling page, before and after.
• The Docker image, built from this release, ran on the test instance (one car) with a real database
  before the tag: every page answers as on 4.14.2 (the fuel page sends a car without a tank elsewhere,
  as before); each charge of the last five weeks opens in its day as a row with its curve, two merged
  charges as one; September as a range lists the same 5 charges, over 4 days; the log has no errors.
  That car has not charged since 7 October, nor had its window changed there, so neither fix was seen
  at work on it.
• Not tried: a real charge under 3 A or a real schedule save on 4.15.0, the add-on behind Home
  Assistant, a real phone.

---

Italiano

Mate 4.15.0 — Una ricarica si legge come un viaggio

Il calendario delle Ricariche rifatto da @arekm nella
#412, e due correzioni: una trovata nella
segnalazione di @arzthilfe sulla #409,
una in quella di @ViriatusOG sulla #395.

Cosa cambia

Una ricarica è una riga che si apre (#412, @arekm)

Il pannello del giorno nel calendario delle Ricariche disegnava una scheda di circa 650 px per ogni
ricarica. Ora:

• ogni ricarica è una riga, con accanto una miniatura della sua curva di potenza e SoC;
• un clic la apre sotto di sé: l'energia; una riga con la temperatura della batteria, quella esterna e
  la potenza media; il grafico; la nota su una riga; le azioni;
• i comandi che erano sulla scheda (tipo, 🆓, ✎, 🧭 🔄 ✏️, il luogo) restano sulla riga e funzionano
  senza aprirla;
• Espandi tutto / Comprimi tutto accanto alla data del giorno;
• più giorni insieme, come nel calendario dei Viaggi: Maiusc-clic o trascinamento con il mouse; sul
  telefono si tiene premuto un giorno per mezzo secondo e poi si tocca un altro giorno. L'intestazione
  dà i totali dell'intervallo, e ogni giorno i suoi.

Il grafico sotto una ricarica legge Home Assistant fuori dal ciclo principale del server web, e quando
Home Assistant non ha appena risposto, i grafici successivi non lo interrogano di nuovo per un minuto.

Il pannello di carica mostra la potenza di una ricarica sotto i 3 A (#409)

«Stato di carica» nella pagina Ricariche e la ricarica in corso nella Panoramica calcolavano la potenza
solo da 3 A in su. Ai 718 V della C10 di @arzthilfe, le sue ricariche di casa da 1,7 kW portano 2,4 A,
quindi entrambi dicevano 0,00 kW mentre il grafico sotto disegnava la potenza. Era la copia nella
pagina della soglia che la 3.18.3 aveva tolto dal poller (#307). Ora non c'è più: corrente zero dà
ancora zero.

Una finestra di ricarica salvata qui si vede subito nella Panoramica (#395)

Dalla 3.10.0 la Panoramica legge la finestra di ricarica che il poller registra per ogni auto,
aggiornata ogni 30 minuti. Una finestra salvata nella pagina Schedulazione finiva in una chiave che
la Panoramica legge solo quando quella dell'auto è vuota, quindi dopo un salvataggio confermato
dall'auto la Panoramica mostrava la finestra vecchia per un massimo di 30 minuti. Ora il salvataggio la
registra per l'auto sullo schermo, come fa il poller.

Impatto dell'aggiornamento

• Niente viene migrato o cancellato; nessuna tabella cambia.
• Il calendario delle Ricariche ha un aspetto diverso: le stesse informazioni e le stesse azioni, in
  righe.
• Con due auto, una finestra salvata nella pagina Schedulazione viene registrata per l'auto sullo
  schermo e non tocca più quella dell'altra. La lettura successiva dell'auto da parte del poller vince
  ancora, come prima.

Verifica

• CI verde sul tag: 5.596 passati, 1 saltato, più 48 passati e 2 saltati sul job Windows; il
  controllo che il guscio desktop pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti: 5.596 passati,
  1 saltato (un file di riferimento solo locale che la copia non porta).
• Undici test nuovi per le due correzioni. Sulla 4.14.2 falliscono 3 dei 6 per la #409 (una ricarica
  da 2,37 A dà 0,00 kW, nel pannello e nella pagina) e 2 dei 5 per la #395 (la Panoramica tiene la
  finestra vecchia dopo un salvataggio, sia spenta sia spostata). Adesso passano tutti e undici. Un test
  esistente ora legge la finestra che mostra la Panoramica invece della vecchia chiave condivisa; quello
  che controlla non cambia.
• La #412 porta i suoi test. Ognuna delle sue quattro correzioni dopo la revisione è stata tolta una
  alla volta, e ogni volta i suoi test sono falliti: l'intervallo che attraversa la mezzanotte (4), la
  pausa di una ricarica interrotta (1), il grafico letto fuori dal ciclo principale (2), il minuto senza
  interrogare Home Assistant (1).
• Schermate con dati dimostrativi: il calendario delle Ricariche su un computer, con più giorni aperti
  e a larghezza di telefono; il pannello di carica e la ricarica in corso nella Panoramica a 1,7 kW,
  prima e dopo; la Panoramica dopo un salvataggio nella pagina Schedulazione, prima e dopo.
• L'immagine Docker, costruita da questa versione, ha girato sull'istanza di prova (una sola auto) con
  un database vero prima del tag: ogni pagina risponde come sulla 4.14.2 (la pagina del carburante
  manda altrove un'auto senza serbatoio, come prima); ogni ricarica delle ultime cinque settimane si apre
  nel suo giorno come una riga con la sua curva, due ricariche unite come una sola; settembre come
  intervallo elenca le stesse 5 ricariche, su 4 giorni; nel log non ci sono errori. Quell'auto non ricarica
  dal 7 ottobre e lì non le è stata cambiata la finestra, quindi nessuna delle due correzioni si è vista
  all'opera.
• Non provati: una vera ricarica sotto i 3 A o un vero salvataggio della programmazione sulla 4.15.0,
  l'add-on dentro Home Assistant, un telefono vero.

Mate 4.14.2 — A password Leapmotor refuses is named, and Mate waits an hour

Mate 4.14.2 — A password Leapmotor refuses is named, and Mate waits an hour

A fix found in the diagnostics @DJ-Elo-Ostfriesland sent on
#411, with the meaning of the codes
from @arekm.

---

What changes

Since 4.x, when Leapmotor refuses a sign-in, Mate keeps only its number (API=302010108), not the
server's message. Mate tells a refused password from a passing failure by the words in the error, so
this one read as passing:

• the startup login asked again every 5 minutes, where a refused password waits an hour;
• the cloud-history worker asked on its own every 5 minutes as well;
• the Overview said "the Leapmotor cloud refuses the login", without pointing at the password.

On @DJ-Elo-Ostfriesland's install, after an internet outage made Mate sign in again, that came to 257
refused sign-ins on 10/10.

302010108 is "Incorrect account or password": @arekm found that message next to it in the 3.x
diagnostics of 17 issues, kerniger/leapmotor-ha#74 pairs them the same way, and in #338 it went away
the moment the right password was in.

• Mate now names the code: the error reads API=302010108 (incorrect account or password).
• The startup login waits an hour before offering the same password again, and the history worker
  waits the same hour.
• The Overview reads "the password was rejected" and "Check the Leapmotor account in Settings."; the
  log says "check credentials".
• A password changed in Settings restarts the poller and is tried at once, as before.

Upgrade impact

• Nothing is migrated or deleted. Only the wording of a refused sign-in and the wait after it change.
• Other refusals are unchanged, 302010107 included. @arekm reads it as "password error limit
  reached, try again in 2 minutes"; on #411 it came about one answer in ten. Fewer attempts with a
  refused password should make it rarer: not measured.

Verification

• CI green on the tag: 5,510 passed, 1 skipped, plus 48 passed and 2 skipped on the Windows job;
  the check that the released desktop shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added — so that nothing is
  skipped: 5,511 passed, none skipped.
• Five new tests. On 4.14.1 three of them fail: a 302010108 refusal does not read as a password
  problem, the startup login asks again after 5 seconds instead of an hour, and the history worker
  after 5 minutes. The other two check that a refusal of unknown meaning (302010219) still reads as
  passing and is asked again as before. Now all five pass.
• Screenshots of the Overview's link tile, on synthetic data, after seven 302010108 refusals put
  through the real bridge and the poller's own startup loop: 4.14.1 reads "the Leapmotor cloud refuses
  the login", next attempt in 5 min; 4.14.2 reads "the password was rejected", next attempt in 60 min,
  and "Check the Leapmotor account in Settings."
• The Docker image, built from this release, ran on the test instance (one car) with a real database
  before the tag: every page answers as on 4.14.1 (the fuel page sends a car without a tank
  elsewhere, as before), and the log has no errors. Its sign-in was accepted, so the new wording was
  not seen there.
• Not tried: a real account whose password Leapmotor refuses, the add-on behind Home Assistant, a
  phone.

---

Italiano

Mate 4.14.2 — Una password rifiutata da Leapmotor viene chiamata per nome, e Mate aspetta un'ora

Una correzione trovata nella diagnostica che @DJ-Elo-Ostfriesland ha mandato sulla
#411, con il significato dei codici
trovato da @arekm.

Cosa cambia

Dalla 4.x, quando Leapmotor rifiuta un accesso, Mate tiene solo il suo numero (API=302010108), non il
messaggio del server. Mate distingue una password rifiutata da un errore passeggero dalle parole
dell'errore, quindi questo veniva letto come passeggero:

• l'accesso all'avvio riprovava ogni 5 minuti, dove una password rifiutata aspetta un'ora;
• anche la parte che scarica lo storico dal cloud riprovava per conto suo ogni 5 minuti;
• la Panoramica diceva «il cloud Leapmotor rifiuta l'accesso», senza indicare la password.

Sull'installazione di @DJ-Elo-Ostfriesland, dopo che un guasto della connessione internet aveva
costretto Mate ad accedere di nuovo, sono stati 257 accessi rifiutati il 10/10.

302010108 è «Incorrect account or password» (account o password errati): @arekm ha trovato quel
messaggio accanto al codice nella diagnostica 3.x di 17 segnalazioni, kerniger/leapmotor-ha#74 li
abbina allo stesso modo, e nella #338 è sparito appena è stata inserita la password giusta.

• Mate ora dà un nome al codice: l'errore dice API=302010108 (incorrect account or password).
• L'accesso all'avvio aspetta un'ora prima di riprovare la stessa password, e la parte dello storico
  aspetta la stessa ora.
• La Panoramica dice «la password è stata rifiutata» e «Controlla l'account Leapmotor nelle
  Impostazioni.»; il log dice «check credentials».
• Una password cambiata nelle Impostazioni riavvia il poller e viene provata subito, come prima.

Impatto dell'aggiornamento

• Niente viene migrato o cancellato. Cambiano solo le parole di un accesso rifiutato e l'attesa dopo.
• Gli altri rifiuti non cambiano, compreso 302010107. @arekm lo legge come «raggiunto il limite di
  errori della password, riprova fra 2 minuti»; sulla #411 arrivava circa una risposta su dieci. Meno
  tentativi con una password rifiutata dovrebbero renderlo più raro: non misurato.

Verifica

• CI verde sul tag: 5.510 passati, 1 saltato, più 48 passati e 2 saltati sul job Windows; il
  controllo che il guscio desktop pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti — così che non si
  salti niente: 5.511 passati, nessuno saltato.
• Cinque test nuovi. Sulla 4.14.1 tre falliscono: un rifiuto 302010108 non viene letto come un
  problema di password, l'accesso all'avvio riprova dopo 5 secondi invece che dopo un'ora, e lo storico
  dopo 5 minuti. Gli altri due controllano che un rifiuto di significato sconosciuto (302010219) venga
  ancora letto come passeggero e riprovato come prima. Adesso passano tutti e cinque.
• Schermate del riquadro del collegamento nella Panoramica, con dati inventati, dopo sette rifiuti
  302010108 passati dal bridge vero e dal ciclo di avvio del poller: la 4.14.1 dice «il cloud Leapmotor
  rifiuta l'accesso», prossimo tentativo fra 5 min; la 4.14.2 dice «la password è stata rifiutata»,
  prossimo tentativo fra 60 min, e «Controlla l'account Leapmotor nelle Impostazioni.»
• L'immagine Docker, costruita da questa versione, ha girato sull'istanza di prova (una sola auto) con
  un database vero prima del tag: ogni pagina risponde come sulla 4.14.1 (la pagina del carburante
  manda altrove un'auto senza serbatoio, come prima), e nel log non ci sono errori. Lì l'accesso è
  stato accettato, quindi le parole nuove non si sono viste.
• Non provati: un vero account di cui Leapmotor rifiuta la password, l'add-on dentro Home Assistant,
  un telefono.

Mate 4.14.1 — A reading stays with the car it was read from

Mate 4.14.1 — A reading stays with the car it was read from

A fix for accounts with two cars, found in the diagnostics @dommi1966 sent on
#338.

---

What changes

Besides the poller, the web writes a car's reading in two places: the check after a command (lock,
climate, windows…) and the 🔄 Refresh button. Both asked twice which car was meant — once to read it
from the cloud, once to write the reading — and the car chosen in the sidebar can change in between,
while the cloud answers. Then one car's reading was filed under the other.

On @dommi1966's install (an A10 and a shared T03), right after a command to the T03 on 30/09, the
T03's reading — 53 % and 9,275 km — was filed under the A10. The A10's diagnostics then showed that
day as "driven 8,527 km" (the T03's odometer minus the A10's), and a standby bar of 39 % a day
(the T03's 53 % down to the A10's 20.9 %) on a car that lost none.

• The car is now chosen once, when the command is sent or Refresh is pressed, and both the read
  and the write are that car's, wherever the sidebar goes meanwhile.
• A car the account no longer lists is neither read nor written, instead of the other car being read.

Upgrade impact

• Nothing is migrated, recomputed or deleted. A reading already filed under the wrong car stays where
  it is, with what it shows.
• With one car nothing changes: there is only one car to choose.

Verification

• CI green on the tag: 5,505 passed, 1 skipped, plus 48 passed and 2 skipped on the Windows job;
  the check that the released desktop shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added — so that nothing is
  skipped: 5,506 passed, none skipped.
• Four new tests. The two that reproduce #338 — an account with an A10 listed first and a T03, a
  command (and a Refresh) on the T03, the sidebar moved to the A10 while the cloud answers — fail on
  4.14.0 exactly as the diagnostics did: the T03's 53 % and 9,275 km under car 1. The two about a car
  no longer on the account each fail when the check they cover is taken out. Now all pass.
• The Docker image, built from this release, ran on the test instance (one car) with a real database
  before the tag: every page answers as on 4.14.0 (the fuel page sends a car without a tank
  elsewhere, as before), and the log has no errors.
• Not proven: in @dommi1966's diagnostics the command to the T03 is there (right after it the T03
  alone was polled every 10 s, which only a command from the web does with MQTT off); the switch of
  car in the sidebar is not, because the pack keeps no record of the pages opened. The code allowed
  it, and the new tests reproduce it.
• Not tried: a real account with two cars, the add-on behind Home Assistant, a phone.

---

Italiano

Mate 4.14.1 — Una lettura resta all'auto da cui è stata letta

Una correzione per gli account con due auto, trovata nella diagnostica che @dommi1966 ha mandato
sulla #338.

Cosa cambia

Oltre al poller, la parte web scrive la lettura di un'auto in due punti: il controllo dopo un comando
(chiusura, clima, finestrini…) e il pulsante 🔄 Aggiorna. Tutti e due chiedevano due volte di quale
auto si trattasse — una volta per leggerla dal cloud, una volta per scrivere la lettura — e l'auto
scelta nella barra laterale può cambiare in mezzo, mentre il cloud risponde. Allora la lettura di
un'auto finiva sotto l'altra.

Sull'installazione di @dommi1966 (una A10 e una T03 condivisa), subito dopo un comando alla T03 il
30/09, la lettura della T03 — 53 % e 9.275 km — è stata scritta sotto la A10. La diagnostica della
A10 mostrava allora quel giorno come «drove 8527 km» (il contachilometri della T03 meno quello della
A10), e una barra di standby del 39 % al giorno (il 53 % della T03 sceso al 20,9 % della A10) su
un'auto che non aveva perso niente.

• L'auto ora si sceglie una volta sola, quando parte il comando o premi Aggiorna, e sia la
  lettura sia la scrittura sono di quell'auto, dovunque vada nel frattempo la barra laterale.
• Un'auto che l'account non elenca più non viene né letta né scritta, invece di leggere l'altra.

Impatto dell'aggiornamento

• Niente viene migrato, ricalcolato o cancellato. Una lettura già finita sotto l'auto sbagliata resta
  dov'è, con quello che mostra.
• Con una sola auto non cambia niente: c'è una sola auto da scegliere.

Verifica

• CI verde sul tag: 5.505 passati, 1 saltato, più 48 passati e 2 saltati sul job Windows; il
  controllo che il guscio desktop pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti — così che non si
  salti niente: 5.506 passati, nessuno saltato.
• Quattro test nuovi. I due che riproducono la #338 — un account con una A10 elencata per prima e una
  T03, un comando (e un Aggiorna) sulla T03, la barra laterale spostata sulla A10 mentre il cloud
  risponde — falliscono sulla 4.14.0 esattamente come la diagnostica: il 53 % e i 9.275 km della T03
  sotto l'auto 1. I due su un'auto non più sull'account falliscono ciascuno se si toglie il controllo
  che coprono. Adesso passano tutti.
• L'immagine Docker, costruita da questa versione, ha girato sull'istanza di prova (una sola auto) con
  un database vero prima del tag: ogni pagina risponde come sulla 4.14.0 (la pagina del carburante manda altrove
  un'auto senza serbatoio, come prima), e nel log non ci sono errori.
• Non dimostrato: nella diagnostica di @dommi1966 il comando alla T03 c'è (subito dopo, solo la T03 è
  stata letta ogni 10 s, cosa che con MQTT spento fa solo un comando dalla web); il cambio d'auto nella
  barra laterale no, perché il pacchetto non tiene traccia delle pagine aperte. Il codice lo permetteva,
  e i test nuovi lo riproducono.
• Non provati: un vero account con due auto, l'add-on dentro Home Assistant, un telefono.

Mate 4.14.0 — Mate no longer writes a charge's note

Mate 4.14.0 — Mate no longer writes a charge's note

@arekm's #406: the note of a charge is the
user's, and 🧭 beside 📍 looks a missing address up when asked. Plus a fix to the message under 🧭, and
docs for showing Mate inside Home Assistant through hass_ingress
(#407).

---

A charge's note is yours — #406, @arekm

• With the default settings Mate wrote a note on every charge it closed: the station's address, the
  start and end times, the outside and battery temperatures. To find that address it sent the position
  of every charge closed away from home to OpenStreetMap's Overpass, even with ⚡ Charging stations and
  the address lookup switched off. Both stop. The note is left to you, as a trip's is since 4.13.0.
• The same facts are already on the card: the times in its heading, the temperatures on its chart, the
  address on its 📍 line (4.13.1).
• 🧭 on the 📍 line, where the line has no address and no charging place names the charge: it asks
  the provider chosen in Settings ▸ Address lookup at once, even with that card's switch off and
  however old the charge, then draws the line again. When no address comes, a row under the line says
  why: the provider has nothing there, or how asking it failed.
• Settings ▸ Address lookup loses Write the note by itself.
• The 🧭 in a trip's summary also says why no address came; before, without network, it left the
  dashes with no message.
• The refuel's 🧭 is unchanged.

Also in this release

• A network error without words read "Asking Nominatim failed: " with nothing after it under 🧭; it now
  names the error.
• Mate inside Home Assistant from a Docker install
  (#407): the README and .env.example
  name hass_ingress's default ingress mode and the addresses to put in MATE_FRAME_ANCESTORS. The
  README said that with a password, logging in inside a frame does not work and to log in in a regular
  tab first. It now says what was measured: in a frame on the same site as Mate logging in works; in a
  frame on another host the login page comes back even after logging in in a tab.

Upgrade impact

• Nothing is migrated, recomputed or deleted. The notes Mate wrote before stay as they are: nothing tells
  one Mate wrote from one typed in. The Write the note by itself setting stays in the database, unread.
• A charge closed after the update gets no note, and its closing sends nothing to Overpass. The address
  on its 📍 line comes, as in 4.13.1, from the background lookup if its switch is on.
• 🧭 on a charge sends that charge's position to the chosen provider when you press it, also with the
  switch off: you asked.

Verification

• CI green on the tag: 5,501 passed, 1 skipped (a test that needs a local-only file), plus 48
  on the Windows job; the check that the released desktop shell still runs this Mate is green.
• Locally, in the CI's image with Node.js and a MateDesktop checkout added — so that nothing is
  skipped: 5,501 passed, 1 skipped (a test that needs a local-only file).
• The new and changed tests, run on 4.13.1, give 18 failures; now all 83 pass.
• In Chromium, on a database with made-up addresses and no network, at 1280 and 390 px: a charge without
  an address has 🧭 on its 📍 line, one with a station and its address has none; the note has no 🧭;
  🧭 without network says why on a row of its own, read whole beside the card's buttons; Settings ▸
  Address lookup has no Write the note by itself; no script errors.
• The Docker image, built from this release, ran on the test instance with a real database before the
  tag: every page answers; Settings has no note switch; over 24 days of charges, 29 cards, 🧭 shows on the
  2 without an address and no card has the note's 🧭; the charges CSV has the same columns and rows; no
  errors in the log.
• #407: in Chromium, behind a stand-in for hass_ingress's ingress mode (the headers it sends, with
  X-Ingress-Path): without MATE_FRAME_ANCESTORS the frame is refused; with Home Assistant's address in
  it the pages, the links and a setting saved from the panel work, with and without a password.
• Not tried: 🧭 against a real lookup service, a real phone, Safari, Firefox, the add-on behind Home
  Assistant, and a real Home Assistant with hass_ingress.

---

Italiano

Mate 4.14.0 — Mate non scrive più la nota delle ricariche

La #406 di @arekm: la nota di una ricarica
è tua, e 🧭 accanto a 📍 cerca un indirizzo mancante quando lo chiedi. In più una correzione al messaggio
sotto 🧭, e le istruzioni per mostrare Mate dentro Home Assistant con hass_ingress
(#407).

---

La nota di una ricarica è tua — #406, @arekm

• Con le impostazioni predefinite Mate scriveva una nota su ogni ricarica che chiudeva: l'indirizzo
  della colonnina, l'ora di inizio e di fine, la temperatura esterna e quella della batteria. Per trovare
  l'indirizzo mandava a Overpass di OpenStreetMap la posizione di ogni ricarica chiusa fuori casa, anche
  con ⚡ Colonnine di ricarica e la ricerca indirizzi spente. Smette di fare entrambe le cose. La nota la scrivi tu,
  come quella dei viaggi dalla 4.13.0.
• Le stesse informazioni sono già nella scheda: gli orari nell'intestazione, le temperature nel grafico,
  l'indirizzo sulla riga 📍 (4.13.1).
• 🧭 sulla riga 📍, quando la riga non ha un indirizzo e nessun luogo di ricarica dà il nome alla
  ricarica: chiede subito al servizio scelto in Impostazioni ▸ Ricerca indirizzi, anche con
  l'interruttore di quella scheda spento e per una ricarica vecchia quanto vuoi, poi ridisegna la riga. Se
  non arriva nessun indirizzo, una riga sotto dice perché: il servizio lì non ha niente, oppure come è
  fallita la richiesta.
• Impostazioni ▸ Ricerca indirizzi perde Scrivi la nota da sola.
• Anche il 🧭 nel riepilogo di un viaggio dice perché non è arrivato un indirizzo; prima, senza rete,
  lasciava i trattini senza nessun messaggio.
• Il 🧭 dei rifornimenti non cambia.

Anche in questa versione

• Un errore di rete senza testo scriveva sotto 🧭 «La richiesta a Nominatim non è riuscita: » e poi
  niente; ora dice di che errore si tratta.
• Mate dentro Home Assistant da un'installazione Docker
  (#407): il README e .env.example
  indicano la modalità predefinita ingress di hass_ingress e gli indirizzi da mettere in
  MATE_FRAME_ANCESTORS. Il README diceva che con una password l'accesso dentro un frame non funziona, e
  di fare prima login in una scheda normale. Ora dice quello che è stato misurato: in un frame sullo
  stesso sito di Mate l'accesso funziona; in un frame su un altro host la pagina di accesso torna anche
  dopo il login in una scheda.

Impatto dell'aggiornamento

• Niente viene migrato, ricalcolato o cancellato. Le note che Mate ha scritto prima restano come sono:
  niente distingue una nota scritta da Mate da una scritta da te. L'impostazione Scrivi la nota da sola
  resta nel database, ma non viene più letta.
• Una ricarica chiusa dopo l'aggiornamento non riceve nessuna nota, e alla chiusura non viene mandato
  niente a Overpass. L'indirizzo sulla sua riga 📍 arriva, come nella 4.13.1, dalla ricerca in sottofondo
  se il suo interruttore è acceso.
• 🧭 su una ricarica manda la posizione di quella ricarica al servizio scelto quando lo premi, anche con
  l'interruttore spento: l'hai chiesto tu.

Verifica

• CI verde sul tag: 5.501 passati, 1 saltato (un test che ha bisogno di un file solo locale), più
  48 sul job Windows; il controllo che il guscio desktop pubblicato faccia ancora girare questa Mate è verde.
• In locale, nell'immagine della CI con Node.js e una copia di MateDesktop aggiunti — così che non si
  salti niente: 5.501 passati, 1 saltato (un test che ha bisogno di un file solo locale).
• I test nuovi e modificati, fatti girare sulla 4.13.1, danno 18 fallimenti; adesso passano tutti e 83.
• In Chromium, su un database con indirizzi inventati e senza rete, a 1280 e 390 px: una ricarica senza
  indirizzo ha 🧭 sulla riga 📍, una con colonnina e indirizzo no; la nota non ha più 🧭; 🧭 senza rete dice
  perché su una riga sua, leggibile per intero accanto ai pulsanti della scheda; Impostazioni ▸ Ricerca
  indirizzi non ha più Scrivi la nota da sola; nessun errore negli script.
• L'immagine Docker, costruita da questa versione, ha girato sull'istanza di prova con un database vero
  prima del tag: ogni pagina risponde; Impostazioni non ha più l'interruttore della nota; su 24 giorni di
  ricariche, 29 schede, 🧭 compare sulle 2 senza indirizzo e nessuna scheda ha il 🧭 della nota; il CSV
  delle ricariche ha le stesse colonne e righe; nessun errore nel log.
• #407: in Chromium, dietro un sostituto della modalità ingress di hass_ingress (gli stessi header,
  con X-Ingress-Path): senza MATE_FRAME_ANCESTORS il frame viene rifiutato; con l'indirizzo di Home
  Assistant le pagine, i link e un'impostazione salvata dal pannello funzionano, con e senza password.
• Non provati: 🧭 con un servizio di indirizzi vero, un telefono vero, Safari, Firefox, l'add-on dentro
  Home Assistant, e un vero Home Assistant con hass_ingress.