Deutsch
v1.19.57 (Stable)
Frontend- und Backend-Änderungen, keine Firmware-Änderungen.
3D-Karte: komplette Touren-Historie per „Weitere Touren laden" (Issue #86). Die Touren-Liste zeigte bisher fest nur die 50 neuesten Fahrten, ohne Hinweis, dass ältere existieren. Bei regelmäßigem Fahren wirkte das wie eine harte 3-Monats-Grenze, obwohl die komplette Historie längst geladen war. Ein „Weitere Touren laden"-Eintrag am Listenende blendet jeweils die nächsten 50 ein.
3D-Karte: Account und Bike im Editor per Dropdown wählbar. account_id und bike_id mussten bisher als rohe Text-Werte eingetippt werden. Der Editor zeigt jetzt zwei verknüpfte Auswahllisten wie die übrigen Karten, ein Kontowechsel setzt die Bike-Auswahl zurück.
Dashboard-Card: Ziel-SoC-Regler zeigt keine unsinnigen Prozentwerte mehr (Issue #87). Hatte die verknüpfte Entity einen Min/Max-Bereich außerhalb von 0-100 (z. B. die Akkukapazität in Wh), zeigte der Regler den Rohwert mit angehängtem „%" (etwa „800 %"). Jetzt prüft die Karte den Bereich und zeigt stattdessen einen Hinweis. Der Editor-Hinweistext nennt die erwartete 0-100-Skala.
Reichweiten-Schätzung: bereits gespeicherte unplausible Verbrauchswerte werden herausgefiltert (Issue #78, Folgefund). Der Fix aus v1.19.50 verhinderte nur, dass neue unplausible Werte gespeichert werden. Ein noch aus der Zeit davor gespeicherter Eintrag konnte die Schätzung dauerhaft verfälschen (z. B. über 1.000 km). Dieselbe Plausibilitätsschwelle gilt jetzt auch bei der Berechnung selbst, ein manuelles Löschen von Daten ist nicht nötig.
Doku: esphome/MOBILE.md erklärt jetzt, warum die native API bei der mobilen Bridge unterwegs eine manuelle IP-Umstellung braucht und warum die MQTT-Variante das vermeidet.
English
v1.19.57 (Stable)
Frontend and backend changes, no firmware changes.
3D map: load the full tour history on demand (issue #86). The tour list used to hard-cap at the 50 most recent rides with no hint that older ones existed. For a regular rider that can look like a fixed 3-month cutoff, even though the full history was already loaded and just never shown. A "Load more tours" row at the bottom now reveals the next 50 each time.
3D map: pick account and bike from a dropdown in the editor. account_id and bike_id used to be raw text fields. The editor now shows two linked dropdowns like the other cards, and switching accounts resets the bike selection.
Dashboard card: the target-SoC slider no longer shows nonsensical percentages (issue #87). If the linked entity's min/max fell outside 0-100 (for example a battery capacity in Wh), the slider showed the raw value with a "%" appended, such as "800%". The card now checks the range and shows a hint instead. The editor hint text names the expected 0-100 scale.
Range estimate: already-stored implausible consumption values are filtered out (issue #78 follow-up). The v1.19.50 fix only stopped new implausible values from being written. An entry stored before that could keep distorting the estimate indefinitely (for example over 1,000 km). The same plausibility floor now also applies where the range is calculated, no manual data cleanup needed.
Docs: esphome/MOBILE.md now explains why the native API needs a manual IP change on the road with the mobile bridge and why the MQTT variant avoids it.
Nederlands
v1.19.57 (Stable)
Frontend- en backend-wijzigingen, geen firmware-wijzigingen.
3D-kaart: volledige tourgeschiedenis op aanvraag laden (issue #86). De tourlijst was vast begrensd op de 50 meest recente ritten, zonder aanwijzing dat er oudere bestonden. Voor een regelmatige rijder kan dat als een harde grens van 3 maanden overkomen, terwijl de volledige geschiedenis allang geladen was en alleen niet werd getoond. Een regel "Meer tours laden" onderaan de lijst toont voortaan telkens de volgende 50.
3D-kaart: account en fiets kiezen via een keuzelijst in de editor. account_id en bike_id moesten tot nu toe als ruwe tekstwaarden worden ingetypt. De editor toont nu twee gekoppelde keuzelijsten zoals de andere kaarten, en bij het wisselen van account wordt de fietskeuze teruggezet.
Dashboardkaart: de doel-SoC-schuifregelaar toont geen onzinnige percentages meer (issue #87). Had de gekoppelde entiteit een min/max buiten 0-100 (bijvoorbeeld de accucapaciteit in Wh), dan toonde de regelaar de ruwe waarde met een "%" erachter, zoals "800%". De kaart controleert nu het bereik en toont in plaats daarvan een melding. De hinttekst in de editor noemt de verwachte schaal van 0-100.
Bereikschatting: reeds opgeslagen onwaarschijnlijke verbruikswaarden worden eruit gefilterd (issue #78, vervolgbevinding). De fix in v1.19.50 voorkwam alleen dat nieuwe onwaarschijnlijke waarden werden opgeslagen. Een item dat daarvoor al was opgeslagen, kon de schatting blijvend verstoren (bijvoorbeeld meer dan 1.000 km). Dezelfde plausibiliteitsgrens geldt nu ook waar het bereik wordt berekend, handmatig opschonen van gegevens is niet nodig.
Documentatie: esphome/MOBILE.md legt nu uit waarom de native API bij de mobiele bridge onderweg een handmatige IP-wijziging nodig heeft en waarom de MQTT-variant dat voorkomt.