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.

Mate 4.13.1 — a charge shows where it happened

Mate 4.13.1 — a charge shows where it happened

@arekm's #405: every charge says where it
happened, from the same address table and lookup as the trips in 4.13.0.

---

Where a charge happened — #405, @arekm

• Beside 📍 a charge card shows the station with its address after it, e.g. "Station ·
  address". Without a station it shows the place assigned to the charge, else the charging place
  whose radius holds its point, marked "(charging place)", else the address — a charge at home
  included, which before had no such line.
• The addresses come from 4.13.0's table and background pass, which now also looks up the charges
  that ended in the last three days (a merged charge at its first piece's point). A trip and a charge
  in the same spot cost one request, so a charge where a trip already ended usually costs none.
• The switch in Settings ▸ Address lookup is renamed Look up the addresses of trips and
  charges and stops both.
• The search on Charges and on Events finds a charge by its address, town or postcode; a charge's
  rows in Events are named as its card.
• The charges CSV export gains two columns, place and address.
• Also fixed: the start of a merged trip was not looked up when its first piece had ended before the
  three days and its last inside them.

Upgrade impact

• Nothing is migrated, recomputed or deleted; no new table.
• The address switch now covers charges too, home charges included. The automatic charge note
  ("Write the note by itself") still skips home charges and is unchanged. In practice a home charge
  rarely adds a request, since the home address is usually known from the trips already.
• Charges older than three days at the update get no lookup of their own: they show the station or the
  charging place as before, or an address once a newer trip or charge passes through the same spot.
• In browsers without CSS :has() (e.g. Firefox before 121) the OpenStreetMap credit stays visible
  even where no address from it is shown.

Verification

• CI green on the tag: 5,498 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,499 passed.
• The new and changed tests, run on 4.13.0, give 21 failures; now all 100 pass.
• In Chromium, on a copy of a real database with its addresses replaced by fake ones and no network, and
  on the demo, at 1280 and 390 px: charge cards show 📍 with the address; a station typed with ✏️ gives
  "Station · address"; the search finds charges by a place; the demo's station reads "Rubicone Est HPC ·
  Autostrada Adriatica, Gatteo" and home charges "Casa (charging place)"; Events rows of charges name the
  place; the charges CSV has the two new columns and the same number of rows; on a phone the line wraps
  and its buttons stay on the card; no new script errors, same load times. With no network, one request
  fails and waits 15 minutes.
• The Docker image, built from this commit, ran on the test instance with a real database before the
  tag: every page answers, the switch is on after the update, the latest charges' cards show 📍 with an
  OpenStreetMap address and its credit, and the charges CSV has the two new columns.
• Not tried: the real lookup service for charges, a real phone, Safari, Firefox, and the add-on behind
  Home Assistant.

---

Italiano

Mate 4.13.1 — una ricarica mostra dove è avvenuta

La #405 di @arekm: ogni ricarica dice
dove è avvenuta, con la stessa tabella degli indirizzi e la stessa ricerca dei viaggi della 4.13.0.

---

Dove è avvenuta una ricarica — #405, @arekm

• Accanto a 📍 la scheda di una ricarica mostra la colonnina con il suo indirizzo dopo, per
  esempio «Colonnina · indirizzo». Senza colonnina mostra il luogo assegnato alla ricarica, altrimenti
  il luogo di ricarica nel cui raggio cade il punto, con «(luogo di ricarica)», altrimenti
  l'indirizzo — anche per una ricarica a casa, che prima non aveva questa riga.
• Gli indirizzi vengono dalla tabella e dal giro in sottofondo della 4.13.0, che ora cerca anche le
  ricariche finite negli ultimi tre giorni (una ricarica unita al punto del suo primo pezzo). Un viaggio
  e una ricarica nello stesso punto costano una richiesta sola, quindi una ricarica dove è già finito un
  viaggio di solito non ne costa nessuna.
• L'interruttore in Impostazioni ▸ Ricerca indirizzi si chiama ora Cerca gli indirizzi di viaggi
  e ricariche e li ferma entrambi.
• La ricerca in Ricariche e in Eventi trova una ricarica dal suo indirizzo, dalla città o dal CAP;
  le righe di una ricarica in Eventi hanno lo stesso nome della sua scheda.
• L'esportazione CSV delle ricariche ha due colonne in più, place e address.
• Corretto anche: la partenza di un viaggio unito non veniva cercata quando il suo primo pezzo era
  finito prima dei tre giorni e l'ultimo dentro.

Impatto dell'aggiornamento

• Niente viene migrato, ricalcolato o cancellato; nessuna tabella nuova.
• L'interruttore degli indirizzi ora vale anche per le ricariche, comprese quelle di casa. La nota
  automatica delle ricariche («Scrivi la nota da sola») continua a saltare quelle di casa e non cambia.
  In pratica una ricarica a casa raramente aggiunge una richiesta, perché l'indirizzo di casa di solito
  è già noto dai viaggi.
• Le ricariche più vecchie di tre giorni al momento dell'aggiornamento non hanno una ricerca propria:
  mostrano la colonnina o il luogo di ricarica come prima, oppure un indirizzo appena un viaggio o una
  ricarica più nuovi passano dallo stesso punto.
• Nei browser senza :has() del CSS (per esempio Firefox prima della 121) la citazione di
  OpenStreetMap resta visibile anche dove non compare un suo indirizzo.

Verifica

• CI verde sul tag: 5.498 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.499 passati.
• I test nuovi e modificati, fatti girare sulla 4.13.0, danno 21 fallimenti; adesso passano tutti e 100.
• In Chromium, su una copia di un database vero con gli indirizzi sostituiti da indirizzi finti e senza
  rete, e sulla demo, a 1280 e 390 px: le schede delle ricariche mostrano 📍 con l'indirizzo; una
  colonnina scritta con ✏️ dà «Colonnina · indirizzo»; la ricerca trova le ricariche da un luogo; la
  colonnina della demo dice «Rubicone Est HPC · Autostrada Adriatica, Gatteo» e le ricariche a casa «Casa
  (luogo di ricarica)»; le righe delle ricariche in Eventi nominano il luogo; il CSV delle ricariche ha le
  due colonne nuove e lo stesso numero di righe; sul telefono la riga va a capo e i suoi pulsanti restano
  nella scheda; nessun errore nuovo negli script, tempi di caricamento uguali. Senza rete una richiesta
  fallisce e aspetta 15 minuti.
• L'immagine Docker, costruita da questo commit, ha girato sull'istanza di prova con un database vero
  prima del tag: ogni pagina risponde, l'interruttore è acceso dopo l'aggiornamento, le schede delle
  ultime ricariche mostrano 📍 con un indirizzo di OpenStreetMap e la sua citazione, e il CSV delle
  ricariche ha le due colonne nuove.
• Non provati: il servizio di indirizzi vero per le ricariche, un telefono vero, Safari, Firefox, e
  l'add-on dentro Home Assistant.

Mate 4.13.0 — trips show where they started and ended

Mate 4.13.0 — trips show where they started and ended

@arekm's #404: every trip says where it
started and ended, kept as an address of its own instead of text in the trip's note.

---

Where a trip started and ended — #404, @arekm

• A trip's row reads "A → B": in the middle of the row on a computer, on a line of its own on a
  phone. The Trip summary on the trip's page names both ends in full, and the trip's start and end
  rows in Events name theirs.
• An end inside one of your charging places shows the place's name, marked "(charging place)", so
  renaming the place renames those trips. Elsewhere it is the address: a shop or a station by its name,
  else the street and number, then the town.
• Mate looks the addresses up shortly after a trip ends, with the provider set in Settings ▸
  Address lookup (OpenStreetMap's Nominatim unless a provider with its key is set there). Each spot,
  19 m by at most 38 m, is asked about once and shared by every trip and car that starts or ends there. At most
  4 requests a minute, 1.1 s apart; a failure is asked again from 15 minutes up to 6 hours; an address
  found is asked again after 90 days.
• A new switch in that card, Look up where trips start and end, turns the lookups off: nothing is
  then sent by itself, and the addresses already found stay shown.
• 🧭 beside a missing address in the Trip summary looks that trip's ends up at once, on any trip,
  whatever the switch says.
• Only the trips that ended in the last three days are looked up by themselves. An older trip that
  started or ended where a newer one did shows that address too.
• The search on Trips and on Events finds a trip by either end, its name or its full address.
• The trips CSV export gains two columns at the end, start_place and end_place.
• Where an address from OpenStreetMap is shown, the view credits it once.

Upgrade impact

• A new table, addresses, is created when Mate starts. Nothing already stored is migrated,
  recomputed or deleted.
• The new switch starts as "Write the note by itself" was, since on 4.12.1 that automatic note is
  what sent a trip's ends to the lookup service: an install that had it off sends nothing by itself, the
  others keep sending the start and end of each new trip, as before. From then on the two switches are
  separate.
• Mate no longer writes a trip's note by itself. The automatic trip note (address, time and
  temperature) and the 🧭 beside the note are gone; Write the note by itself now covers charges only.
  The notes written before stay as they are.
• Trips older than three days at the update get no lookup of their own: their ends show "—" until
  🧭 is pressed or a newer trip starts or ends at the same spot.
• The demo seeds its own addresses and asks no one.

Verification

• CI green on the tag: 5,472 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,473 passed.
• The new and changed tests, run on 4.12.1, give 7 failures and 10 errors (the lookup and its table do
  not exist there); now all 138 pass. Four deliberate breaks of the new code — no check of the switch,
  the switch always on after the update, the Settings card not saving it, 🧭 obeying the switch — each
  turn one of them red.
• In Chromium, on a copy of a real database with no network and the provider replaced by a stub, and on
  the demo, at 1280 and 390 px: trip rows, the Trip summary and Events name both ends; the search finds
  trips by a place; the CSV has the two new columns; no new script errors. A database where "Write the
  note by itself" was never changed starts with the new switch on; one where it was off starts with the
  switch off and sends nothing when Trips opens. With the switch off, 🧭 on a September trip made 2
  requests and drew both addresses. The Settings card turns the switch off and on again without touching
  the note's. With no network, the first lookup fails and waits 15 minutes; 🧭 then leaves the dashes,
  with no message.
• The Docker image, built from this commit, ran on the test instance with a real database before the
  tag: every page answers, the new switch is on after the update, the trip page shows the ends' lines
  and 🧭, the CSV has the two new columns, and the first pass asked Nominatim about 4 spots and found all
  4.
• Not tried: a real phone, Safari, Firefox, and the add-on behind Home Assistant.

---

Italiano

Mate 4.13.0 — i viaggi mostrano da dove sono partiti e dove sono arrivati

La #404 di @arekm: ogni viaggio dice da
dove è partito e dove è arrivato, tenuto come un indirizzo a sé invece che come testo nella nota del
viaggio.

---

Da dove a dove — #404, @arekm

• La riga di un viaggio dice «A → B»: al centro della riga sul computer, su una riga a sé sul
  telefono. Il Riepilogo del viaggio nella sua pagina nomina per intero i due estremi, e le righe di
  inizio e di fine del viaggio in Eventi nominano il loro.
• Un estremo dentro uno dei tuoi luoghi di ricarica mostra il nome del luogo, con «(luogo di
  ricarica)», quindi rinominare il luogo rinomina quei viaggi. Altrove è l'indirizzo: un negozio o un
  distributore per nome, altrimenti la via e il civico, poi la località.
• Mate cerca gli indirizzi poco dopo la fine del viaggio, con il servizio scelto in Impostazioni ▸
  Ricerca indirizzi (Nominatim di OpenStreetMap, se lì non c'è un servizio con la sua chiave). Ogni
  punto, 19 m per al massimo 38 m, viene chiesto una volta sola e vale per tutti i viaggi e le auto che partono o
  arrivano lì. Al massimo 4 richieste al minuto, a 1,1 s l'una dall'altra; un errore viene richiesto da
  15 minuti fino a 6 ore; un indirizzo trovato viene richiesto di nuovo dopo 90 giorni.
• Un interruttore nuovo in quella scheda, Cerca partenza e arrivo dei viaggi, spegne le ricerche:
  allora non viene inviato nulla da solo, e gli indirizzi già trovati restano visibili.
• Il 🧭 accanto a un indirizzo mancante nel Riepilogo del viaggio cerca subito i due estremi di quel
  viaggio, su qualsiasi viaggio, comunque sia l'interruttore.
• Vengono cercati da soli solo i viaggi finiti negli ultimi tre giorni. Un viaggio più vecchio partito o
  arrivato dove è passato uno più nuovo mostra anche lui quell'indirizzo.
• La ricerca in Viaggi e in Eventi trova un viaggio da uno qualsiasi dei due estremi, dal nome o
  dall'indirizzo completo.
• L'esportazione CSV dei viaggi ha due colonne in più in fondo, start_place e end_place.
• Dove compare un indirizzo di OpenStreetMap, la vista lo cita una volta.

Impatto dell'aggiornamento

• All'avvio Mate crea una tabella nuova, addresses. Niente di quello già salvato viene migrato,
  ricalcolato o cancellato.
• L'interruttore nuovo parte com'era «Scrivi la nota da sola», perché nella 4.12.1 è quella nota
  automatica che mandava gli estremi di un viaggio al servizio di ricerca: un'installazione che l'aveva
  spenta non manda nulla da sola, le altre continuano a mandare la partenza e l'arrivo di ogni viaggio
  nuovo, come prima. Da lì in poi i due interruttori sono separati.
• Mate non scrive più da solo la nota di un viaggio. La nota automatica dei viaggi (indirizzo, orario
  e temperatura) e il 🧭 accanto alla nota non ci sono più; Scrivi la nota da sola ora vale solo per
  le ricariche. Le note scritte prima restano come sono.
• I viaggi più vecchi di tre giorni al momento dell'aggiornamento non hanno una ricerca propria: i loro
  estremi mostrano «—» finché non si preme il 🧭 o un viaggio più nuovo parte o arriva nello stesso punto.
• La demo porta con sé i suoi indirizzi e non chiede niente a nessuno.

Verifica

• CI verde sul tag: 5.472 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.473 passati.
• I test nuovi e modificati, fatti girare sulla 4.12.1, danno 7 fallimenti e 10 errori (la ricerca e la
  sua tabella lì non esistono); adesso passano tutti e 138. Quattro rotture fatte apposta del codice
  nuovo — nessun controllo dell'interruttore, l'interruttore sempre acceso dopo l'aggiornamento, la scheda
  delle Impostazioni che non lo salva, il 🧭 che obbedisce all'interruttore — fanno diventare rosso ognuna
  uno di loro.
• In Chromium, su una copia di un database vero senza rete e con il servizio sostituito da uno finto, e
  sulla demo, a 1280 e 390 px: le righe dei viaggi, il Riepilogo del viaggio ed Eventi nominano i due
  estremi; la ricerca trova i viaggi da un luogo; il CSV ha le due colonne nuove; nessun errore nuovo
  negli script. Un database dove «Scrivi la nota da sola» non era mai stato toccato parte con
  l'interruttore nuovo acceso; uno dove era spento parte con l'interruttore spento e non manda nulla
  aprendo Viaggi. Con l'interruttore spento, il 🧭 su un viaggio di settembre ha fatto 2 richieste e ha
  disegnato i due indirizzi. La scheda delle Impostazioni spegne e riaccende l'interruttore senza toccare
  quello della nota. Senza rete la prima ricerca fallisce e aspetta 15 minuti; il 🧭 lascia allora i
  trattini, senza messaggi.
• L'immagine Docker, costruita da questo commit, ha girato sull'istanza di prova con un database vero
  prima del tag: ogni pagina risponde, l'interruttore nuovo è acceso dopo l'aggiornamento, la pagina del
  viaggio mostra le righe degli estremi e il 🧭,...

Mate 4.12.1 — a reload stays on the month being looked at

Mate 4.12.1 — a reload stays on the month being looked at

@arekm's #403: after a reload, the Trips,
Charges, Wallbox and Refuels calendars come back to the month on screen, with the day or range that
was open.

---

A reload stays on the month — #403, @arekm

The month being looked at lived only on screen, so every reload went back to the current month: a
reload by hand, the Wallbox page's own every 30 seconds when idle, the Charges page's at the end of a
charge, and the browser's Back from a trip. Now the month on screen goes into the page's address —
/trips?month=2026-09 — without adding a step to the browser's history.

• A reload comes back to that month, with the day or the range that was open there.
• The browser's Back from a trip comes back to it too.
• Jump to today takes the month out of the address, so a reload then follows the date into the
  next month.
• A day or a month picked replaces the ?highlight= link the page was opened by (from a map popup,
  for example), so a reload opens what was picked, not the linked trip or charge.
• A charging-station filter stays in the address beside the month.
• On Refuels, a refuel added or deleted redraws the month on screen; it used to redraw the current one.
• An address whose month is not one, such as ?month=2026-13, opens the current month.

One change to know: when a charge ends, the Charges page reloads itself and now stays on the month on
screen. The new charge is in the current month, one click on Jump to today away.

Upgrade impact

• Normal update. Nothing in the stored data is migrated, recomputed or deleted, and there is no new
  setting.
• A bookmark or a link with ?month= opens on that month; the menu opens each page on the current
  month, as before.

Verification

• CI green on the tag: 5,423 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,424 passed.
• 24 of the 26 new tests fail on 4.12.0 and pass now. The other two check what must not change — a
  month that failed to load, and Jump to today, leave no month in the address — and pass on both.
• In Chromium, on a copy of a real database with no network, 4.12.0 and 4.12.1 side by side at 1280
  and 390 px: after opening 9 September, or 9–13 September, a reload stays there, where 4.12.0 went
  back to October; Back from a trip comes back to 9 September; Charges keeps September, with a station
  filter too; a day picked after a ?highlight= link is the one a reload opens; the other pages keep
  their address; the browser console shows the same messages on both.
• Not tried: Wallbox on a real database (it needs Home Assistant; covered by its page render) and
  Refuels on a real database (the test car has no fuel tank; covered by the browser tests), a real
  phone, Safari, Firefox, and the add-on behind Home Assistant.
• The Docker image, built from this commit, ran on the test instance with a real database before the
  tag: every page answers; /trips?month=2026-09 and /charges?month=2026-09 open on September,
  Charges with a station filter too; a month that is not one opens the current month; and a
  ?highlight= link opens on its own trip's month.

---

Italiano

Mate 4.12.1 — ricaricando la pagina resti sul mese che stai guardando

La #403 di @arekm: dopo un ricaricamento,
i calendari di Viaggi, Ricariche, Wallbox e Rifornimenti tornano sul mese che era sullo schermo, con il
giorno o l'intervallo che era aperto.

---

Ricaricando resti sul mese — #403, @arekm

Il mese che stavi guardando esisteva solo sullo schermo, quindi ogni ricaricamento tornava al mese
corrente: quello fatto a mano, quello della pagina Wallbox ogni 30 secondi quando è ferma, quello della
pagina Ricariche alla fine di una ricarica, e il tasto Indietro del browser da un viaggio. Adesso il
mese sullo schermo va nell'indirizzo della pagina — /trips?month=2026-09 — senza aggiungere un passo
alla cronologia del browser.

• Un ricaricamento torna su quel mese, con il giorno o l'intervallo che era aperto.
• Anche il tasto Indietro del browser da un viaggio ci torna.
• Torna a oggi toglie il mese dall'indirizzo, così un ricaricamento poi segue la data nel mese
  successivo.
• Un giorno o un mese scelto sostituisce il link ?highlight= con cui si era aperta la pagina (da un
  popup della mappa, per esempio), così un ricaricamento apre quello che hai scelto, non il viaggio o la
  ricarica del link.
• Il filtro per colonnina resta nell'indirizzo accanto al mese.
• In Rifornimenti, un rifornimento aggiunto o cancellato ridisegna il mese sullo schermo; prima
  ridisegnava quello corrente.
• Un indirizzo con un mese che non esiste, come ?month=2026-13, apre il mese corrente.

Un cambiamento da sapere: quando una ricarica finisce, la pagina Ricariche si ricarica da sola e adesso
resta sul mese sullo schermo. La ricarica nuova è nel mese corrente, a un clic su Torna a oggi.

Impatto dell'aggiornamento

• Aggiornamento normale. Niente dei dati salvati viene migrato, ricalcolato o cancellato, e non c'è
  nessuna impostazione nuova.
• Un segnalibro o un link con ?month= apre su quel mese; il menu apre ogni pagina sul mese corrente,
  come prima.

Verifica

• CI verde sul tag: 5.423 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.424 passati.
• 24 dei 26 test nuovi cadono sulla 4.12.0 e passano adesso. Gli altri due controllano quello che non
  deve cambiare — un mese che non si è caricato, e Torna a oggi, non lasciano un mese nell'indirizzo — e
  passano su tutte e due.
• In Chromium, su una copia di un database vero senza rete, 4.12.0 e 4.12.1 affiancate a 1280 e 390 px:
  dopo aver aperto il 9 settembre, o dal 9 al 13 settembre, un ricaricamento resta lì, dove la 4.12.0
  tornava a ottobre; Indietro da un viaggio torna al 9 settembre; Ricariche tiene settembre, anche col
  filtro per colonnina; un giorno scelto dopo un link ?highlight= è quello che apre un ricaricamento;
  le altre pagine tengono il loro indirizzo; la console del browser mostra gli stessi messaggi su tutte
  e due.
• Non provati: Wallbox su un database vero (serve Home Assistant; coperta dal test della sua pagina) e
  Rifornimenti su un database vero (l'auto di prova non ha serbatoio; coperti dai test nel browser), un
  telefono vero, Safari, Firefox, e l'add-on dentro Home Assistant.
• L'immagine Docker, costruita da questo commit, ha girato sull'istanza di prova con un database vero
  prima del tag: ogni pagina risponde; /trips?month=2026-09 e /charges?month=2026-09 aprono su
  settembre, Ricariche anche col filtro per colonnina; un mese che non esiste apre il mese corrente; e un
  link ?highlight= apre sul mese del suo viaggio.

Mate 4.12.0 — the Trips calendar opens a range of days

Mate 4.12.0 — the Trips calendar opens a range of days

@arekm's #402: a week, a weekend or a
holiday opens in the Trips calendar in one gesture, and a calendar's drawer always shows the day
picked last.

---

A range of days in the Trips calendar — #402, @arekm

Three ways to pick it:

• on a computer, Shift-click a second day, forwards or backwards;
• or drag the mouse across the days: they are ringed as you go, and open when you let go;
• on a phone, hold a day for half a second — a dashed ring marks it — and tap the last one. A
  tap on the held day, a scroll, or a day chosen another way lets it go.

The drawer opens with one heading for the whole range — the trips, the kilometres, the battery, the
driving time and the rest of a day's figures — and then each day with trips, newest first, under its
own heading, with its own figures and trips.

• A range stays inside the month on screen, as the calendar shows one month.
• A day's date under the range opens that day alone, with its 🔗 button for merging trips, which a
  range does not have.
• A reload brings the range back, as it brings a day back, and so does the way back from one of its
  trips.
• Charges, Wallbox and Refuels keep one day per click.
• A line under the Trips calendar names the three gestures.

When the car charged between the first trip and the last — over a few days it almost always has —
the range's battery reads as a day's already does with a charge in it: what the trips used, added up,
and what the charges added. In a day with a charge, the two figures now say what each one counts. A
day with no charge goes from its first reading to its last, so the range's figure need not equal its
days' figures added up: a day also counts what the car lost while parked between its trips.

The drawer shows the day picked last — #402, @arekm

Two days picked in quick succession sent two requests side by side, and a slow answer for the first
day could fill the drawer under the second day's ring — on all four calendars, and with the 🔗 merge
view on Trips. A new pick now replaces the request its drawer is still waiting for. A failed day's
"Try again" strip goes once another day is asked for, since its retry would replace the newer day;
the blocks that refresh themselves, such as the Overview's status card, keep theirs until their next
answer, as before.

Upgrade impact

• Normal update. Nothing in the stored data is migrated, recomputed or deleted, and there is no new
  setting.

Verification

• CI green on the tag: 5,397 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,398 passed.
• 28 of the new tests fail on 4.11.2 and pass now. The browser tests ran in Chromium, with the mouse
  and with touch emulated, at 390 and 1280 px: each gesture sends one request, for the range only.
• A test added during review: a block that refreshes itself keeps its "Try again" strip while the
  refresh is on its way. It fails on the version of #402 that took the strip away from every block,
  and passes now. On the Overview, with the refresh's answer held back 3 s, the strip stays, as on
  4.11.2; on that earlier version it was gone for those 3 s.
• Not tried: a real phone, Safari and Firefox.
• The Docker image, built from this commit, ran on the test instance with a real database before the
  tag. There, over four ranges — all of August, all of September, 20–27 September and 1–8 October —
  the drawer listed exactly the days with trips (29, 27, 6 and 8), and the range's trips and
  kilometres are its days' added up, to within 0.1 km, the rounding of each day's figure.

---

Italiano

Mate 4.12.0 — il calendario dei Viaggi apre più giorni insieme

La #402 di @arekm: una settimana, un fine
settimana o una vacanza si aprono nel calendario dei Viaggi con un gesto solo, e il cassetto di un
calendario mostra sempre l'ultimo giorno scelto.

---

Più giorni nel calendario dei Viaggi — #402, @arekm

Tre modi per sceglierli:

• sul computer, Maiusc-clic su un secondo giorno, in avanti o all'indietro;
• oppure trascini il mouse sui giorni: si cerchiano mentre passi, e si aprono quando lasci;
• sul telefono tieni premuto un giorno per mezzo secondo — lo segna un bordo tratteggiato — e
  tocchi l'ultimo. Un tocco sul giorno tenuto, uno scorrimento o un giorno scelto in un altro modo
  lo lasciano andare.

Il cassetto si apre con un'intestazione per tutto l'intervallo — i viaggi, i chilometri, la batteria,
il tempo di guida e le altre cifre di un giorno — e poi ogni giorno con viaggi, dal più recente, sotto
la sua intestazione, con le sue cifre e i suoi viaggi.

• L'intervallo resta dentro il mese che vedi, perché il calendario mostra un mese.
• La data di un giorno sotto l'intervallo apre quel giorno da solo, con il suo pulsante 🔗 per unire i
  viaggi, che l'intervallo non ha.
• Ricaricando la pagina l'intervallo torna, come torna un giorno, e così tornando indietro da uno dei
  suoi viaggi.
• Ricariche, Wallbox e Rifornimenti aprono sempre un giorno per clic.
• Una riga sotto il calendario dei Viaggi ricorda i tre gesti.

Se tra il primo e l'ultimo viaggio l'auto ha caricato — in qualche giorno succede quasi sempre — la
batteria dell'intervallo si legge come già quella di un giorno con una ricarica: quanto hanno usato i
viaggi, sommato, e quanto hanno aggiunto le ricariche. In un giorno con una ricarica, adesso le due
cifre dicono cosa conta ciascuna. Un giorno senza ricariche va dalla prima all'ultima lettura, quindi la
cifra dell'intervallo può non essere la somma di quelle dei suoi giorni: un giorno conta anche quello
che l'auto ha perso da ferma tra i suoi viaggi.

Il cassetto mostra l'ultimo giorno scelto — #402, @arekm

Due giorni scelti in fretta mandavano due richieste insieme, e una risposta lenta per il primo giorno
poteva riempire il cassetto sotto il bordo del secondo — in tutti e quattro i calendari, e con la vista
🔗 di unione nei Viaggi. Adesso una nuova scelta sostituisce la richiesta che il suo cassetto sta ancora
aspettando. La striscia «Riprova» di un giorno non caricato sparisce quando se ne chiede un altro,
perché il suo nuovo tentativo sostituirebbe il giorno più recente; i blocchi che si aggiornano da soli,
come il riquadro di stato della Panoramica, tengono la loro fino alla risposta successiva, come prima.

Impatto dell'aggiornamento

• Aggiornamento normale. Niente dei dati salvati viene migrato, ricalcolato o cancellato, e non c'è
  nessuna impostazione nuova.

Verifica

• CI verde sul tag: 5.397 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.398 passati.
• 28 dei test nuovi cadono sulla 4.11.2 e passano adesso. I test nel browser hanno girato in Chromium,
  col mouse e col tocco simulato, a 390 e 1280 px: ogni gesto manda una sola richiesta, solo per
  l'intervallo.
• Un test aggiunto durante la revisione: un blocco che si aggiorna da solo tiene la sua striscia
  «Riprova» mentre l'aggiornamento è in viaggio. Cade sulla versione della #402 che toglieva la striscia
  da ogni blocco, e passa adesso. Sulla Panoramica, con la risposta dell'aggiornamento trattenuta 3 s, la
  striscia resta, come nella 4.11.2; con quella versione spariva per quei 3 s.
• Non provati: un telefono vero, Safari e Firefox.
• L'immagine Docker, costruita da questo commit, ha girato sull'istanza di prova con un database vero
  prima del tag. Lì, su quattro intervalli — tutto agosto, tutto settembre, dal 20 al 27 settembre e
  dall'1 all'8 ottobre — il cassetto ha elencato esattamente i giorni con viaggi (29, 27, 6 e 8), e i
  viaggi e i chilometri dell'intervallo sono la somma di quelli dei suoi giorni, a meno di 0,1 km,
  l'arrotondamento della cifra di ogni giorno.