v1.19.59 (Stable)
Backend-, Frontend- und Firmware-Änderungen. Fasst die Betas 1 bis 3 zusammen. Nach dem Update Home Assistant neu starten.
Firmware: Die Restzeit-Schätzung beim Laden stimmt jetzt von Anfang an (Issue #94, Analyse und Patch von PEPITO82). Die Bridge schätzt die Ladezeit bis 80 und 100 % aus der Geschwindigkeit, mit der der Ladestand steigt. Als Bezugspunkt diente der erste Ladestandswert nach dem Anstecken des Ladegeräts, der irgendwo innerhalb eines 1-%-Schritts liegt. Der erste gemessene Schritt deckte deshalb nur einen Bruchteil ab, zählte aber als ganzer, und die Glättung baute den Fehler nur langsam ab. Die Schätzung war dadurch immer zu kurz (in der Simulation nach 5 Minuten im Median nur 59 % der echten Zeit). Jetzt dient der erste volle Schritt nur dazu, den Bezugspunkt auf eine Schrittkante zu legen, gemessen wird ab dem zweiten Schritt. Die Schätzung erscheint dadurch nach etwa 3 bis 5 Minuten, dafür mit einem brauchbaren Wert. Ein fallender Ladestand verankert den Bezugspunkt neu. Die Änderung steckt in allen Bridge-Firmwares (Single, C3, Dual je Bike) und in den Beispiel-YAMLs. Die Firmware muss neu geflasht werden, um das zu bekommen (Web-Installer oder OTA).
Neuer Sensor „Range Band“: die Bosch-Reichweite als ein Wert, wie in der Flow App (Issue #78). Die Flow App zeigt die Reichweite als Spanne, zum Beispiel „39 bis 83 km (Turbo bis Eco)“. Die Integration kannte diese Zahlen schon, aber nur als einzelne Sensoren je Fahrmodus. Der neue Sensor Range Band fasst sie zusammen: niedrigster bis höchster Modus, zum Beispiel „37–80 km“. In den Attributen stehen min_km, max_km, die Modi an beiden Enden und die Werte je Modus. Wie die Einzelsensoren folgt er dem letzten Sync des Bikes und kann deshalb ein paar Kilometer hinter der Flow App liegen. Er wird für Smart-System-Bikes angelegt, die Reichweiten je Modus melden, nicht für eBike System 2. Der Wert ist Text, daher gibt es keine Einheit und kein Diagramm.
Reichweiten-Schätzung: Touren unter 5 km werden nicht mehr verwendet (Issue #78). Eine kurze Fahrt sagt wenig über die Reichweite einer langen aus, weil sie meist langsam und flach ist. Außerdem lässt sie sich am ungenauesten messen: Ein einzelner Akkustand-Schritt oder eine Zähleraktualisierung macht schon einen großen Teil ihrer Energie aus. Wer fast nur kurze Fahrten macht, bekommt deshalb keinen Schätzwert mehr statt eines, der nur Besorgungsfahrten beschreibt. Für die Planung längerer Touren sind die Bosch-Reichweiten gedacht (Einzelsensoren und Range Band). Neues Attribut an beiden Schätz-Sensoren: tours_too_short zählt die ausgelassenen Kurzfahrten, auch wenn der Sensor keinen Wert hat. Die README ist in allen sechs Sprachen ergänzt.
Reichweiten-Schätzung: Touren mit unrealistisch niedrigem Verbrauch werden ignoriert, neue Diagnose-Attribute (Issue #78). Die Schätzung nutzt die Energie jeder Tour. Die kommt aus einem Energiezähler, den die Bosch Cloud verspätet und manchmal nur teilweise aktualisiert, oder aus dem Live-Akkustand der Bridge. Eine Tour kann dadurch mit viel zu wenig Energie gespeichert sein, ohne dass die bisherige Grenze (unter 1,0 Wh/km) das bemerkt. Eine einzelne solche Tour (über 30 km mit etlichen Höhenmetern, gespeichert mit nur 41 Wh) hat bei einem echten Bike die Reichweite bei vollem Akku um rund 14 Prozent hochgezogen. Jetzt zählen auch Touren unter 2,5 Wh/km nicht mehr zur Schätzung, selbst wenn sie schon gespeichert sind (Touren mit 0 Wh waren schon bisher draußen). Was gespeichert wird, bleibt unverändert, damit das Nachtragen der Energie einer Tour (Issue #67) weiter funktioniert. Wer fast nur mit sehr wenig Unterstützung fährt, sieht dadurch unter Umständen keinen Wert, bis genügend Touren über der Grenze liegen.
Neue Attribute an beiden Schätz-Sensoren: tours_ignored (wie viele Touren ignoriert wurden, jetzt auch die mit 0 Wh), tours_ignored_sample (die fünf neuesten mit Datum, Kilometern, Wh und Quelle der Energie: cloud oder ble_live), tours_used_by_source (verwendete Touren je Quelle), wh_per_km_min und wh_per_km_max (Spanne der verwendeten Touren). Sie sind auch da, wenn der Sensor gerade keinen Wert hat. Außerdem schreibt die Integration eine INFO-Logzeile „Range estimate for bike …“, sobald sich die Zahlen ändern (Log-Level von custom_components.ha_bosch_ebike auf info stellen). Ist die Schätzung bei dir weiterhin zu hoch, helfen diese Attribute, bitte poste sie in Issue #78. Die README ist in allen sechs Sprachen ergänzt.
Trick Check: Die Dauer von Wheelies wird jetzt richtig angezeigt (Issue #92, Beitrag von JulianHock). Der Parser hat die Dauer bei allen Trick-Typen als Millisekunden gelesen. Bosch liefert aber nur bei Sprüngen Millisekunden (Ganzzahl, z. B. 320). Wheelies kommen in Sekunden (Dezimalzahl, z. B. 2.0), ein Wheelie von 2 Sekunden erschien deshalb als 0,0 s. Jetzt wird nur bei Sprüngen durch 1000 geteilt. Bei Manuals und Stoppies ist die Einheit noch nicht bestätigt, weil bisher keine Fahrt mit Werten ungleich null vorlag. Sie werden wie Wheelies als Sekunden gelesen. Wenn du einen Manual oder Stoppie fährst, vergleiche die Dauer bitte mit der Flow App und melde dich, falls sie nicht passt.
Dashboard-Karte: klarere Felder und ein Hinweis bei falscher Belegung (Issue #91). Das Feld „Akku-SoC-Entity (0..100)“ heißt jetzt „Akkustand-Sensor (aktueller Ladestand in %)“ und trägt einen Hinweis, dass die Ladegrenze ein eigenes Feld hat. Das Feld für den Zielwert heißt jetzt „Ladegrenze: Ziel-SoC input_number-Entity“. Steht im Akkustand-Feld ein input_number oder number oder dieselbe Entität wie beim Ziel-SoC, zeigt die Karte jetzt einen Hinweis. Vorher gab sie den Wert des Helfers still als Akkustand aus, sobald der Live-Sensor nicht verfügbar war. Was angezeigt wird, bleibt wie konfiguriert. Alle sieben Sprachen sind angepasst. Die neue Kartenversion wird erst nach einem Neustart von Home Assistant und einem Neuladen des Browsers geladen.
v1.19.59 (Stable)
Backend, frontend and firmware changes. Combines betas 1 to 3. Restart Home Assistant after updating.
Firmware: the remaining charge time estimate is now right from the start (issue #94, analysis and patch by PEPITO82). The bridge estimates the time to 80 and 100 % from the rate at which the charge level rises. The reference point was the first charge level after the charger connects, which sits somewhere inside a 1 % step. The first measured step therefore covered only a fraction of a step but counted as a whole one, and the smoothing faded that error only slowly. The estimate was always too short (in simulation a median of just 59 % of the real time after 5 minutes). Now the first full step only aligns the reference point to a step edge, and the rate is measured from the second step on. The estimate shows up after about 3 to 5 minutes, but with a usable value. A falling charge level anchors the reference point again. The change is in every bridge firmware (single, C3, dual per bike) and in the example YAMLs. You need to flash the firmware again to get it (web installer or OTA).
New sensor "Range Band": the Bosch reachable range as one value, like the Flow app (issue #78). The Flow app shows the range as a span, for example "39 to 83 km (Turbo to Eco)". The integration already had these figures, but only as separate sensors per assist mode. The new Range Band sensor combines them: lowest to highest mode, for example "37–80 km". The attributes hold min_km, max_km, the modes at both ends and the figure per mode. Like the individual sensors it follows the bike's last sync, so it can trail the Flow app by a few kilometres. It is created for Smart System bikes that report a range per mode, not for eBike System 2. The value is text, so there is no unit and no graph.
Range estimate: tours under 5 km are no longer used (issue #78). A short ride says little about the range of a long one, because it is mostly slow and flat. It is also the hardest to measure precisely: a single battery level step or one counter update is already a large part of its energy. Someone who rides almost only short rides therefore gets no estimate instead of one that only describes errands. For planning longer tours, use the Bosch reachable range (the individual sensors and Range Band). New attribute on both estimate sensors: tours_too_short counts the short rides that were left out, also while the sensor has no value. The README is updated in all six languages.
Range estimate: tours with unrealistically low consumption are ignored, new diagnostic attributes (issue #78). The estimate uses the energy of each tour. That comes from an energy counter the Bosch cloud updates late and sometimes only partly, or from the live battery level of the bridge. A tour can therefore be stored with far too little energy without the previous check (below 1.0 Wh/km) noticing. One such tour (over 30 km with plenty of climbing, stored with just 41 Wh) pushed the full battery range of a real bike up by about 14 percent. Tours below 2.5 Wh/km are now left out of the estimate too, including ones that are already stored (tours with 0 Wh were already left out). What gets stored is unchanged, so the later completion of a tour's energy (issue #67) keeps working. If you mostly ride with very little assistance, you may see no value until enough tours lie above the limit.
New attributes on both estimate sensors: tours_ignored (how many tours were left out, now including the ones with 0 Wh), tours_ignored_sample (the five newest, with date, kilometres, Wh and the source of the energy: cloud or ble_live), tours_used_by_source (tours used per source), wh_per_km_min and wh_per_km_max (spread of the tours used). They are also there while the sensor has no value. The integration also writes an INFO log line "Range estimate for bike …" whenever the numbers change (set the log level of custom_components.ha_bosch_ebike to info). If the estimate is still too high for you, these attributes help, please post them in issue #78. The README is updated in all six languages.
Trick Check: the duration of wheelies is now shown correctly (issue #92, contributed by JulianHock). The parser read the duration of every trick type as milliseconds. Bosch only reports milliseconds for jumps (an integer, for example 320). Wheelies come in seconds (a decimal, for example 2.0), so a 2 second wheelie showed up as 0.0 s. Only jumps are divided by 1000 now. For manuals and stoppies the unit is not confirmed yet, because no ride with non zero values has been seen. They are read as seconds like wheelies. If you ride a manual or a stoppie, please compare the duration with the Flow app and get in touch if it does not match.
Dashboard card: clearer fields and a notice for a wrong assignment (issue #91). The field "Battery SoC entity (0..100)" is now called "Battery level sensor (current charge, %)" and carries a hint that the charge limit has its own field. The field for the target value is now called "Charge limit: target SoC input_number entity". If the battery level field holds an input_number or number, or the same entity as the target SoC, the card now shows a notice. Before, it silently reported the helper's value as the battery level whenever the live sensor was not available. What is shown stays as configured. All seven languages are updated. The new card version is only loaded after a Home Assistant restart and a browser reload.
v1.19.59 (Stable)
Backend-, frontend- en firmware-wijzigingen. Combineert bèta 1 tot 3. Herstart Home Assistant na de update.
Firmware: de schatting van de resterende laadtijd klopt nu vanaf het begin (issue #94, analyse en patch door PEPITO82). De bridge schat de tijd tot 80 en 100 % uit de snelheid waarmee het laadniveau stijgt. Als referentiepunt diende het eerste laadniveau nadat de lader is aangesloten, dat ergens binnen een stap van 1 % ligt. De eerste gemeten stap besloeg daardoor maar een fractie van een stap, maar telde als een hele, en de afvlakking verkleinde die fout maar langzaam. De schatting was daardoor altijd te kort (in simulatie na 5 minuten gemiddeld maar 59 % van de echte tijd). Nu dient de eerste volledige stap alleen om het referentiepunt op een stapgrens te leggen, en wordt de snelheid vanaf de tweede stap gemeten. De schatting verschijnt na ongeveer 3 tot 5 minuten, maar met een bruikbare waarde. Een dalend laadniveau verankert het referentiepunt opnieuw. De wijziging zit in alle bridge-firmwares (single, C3, dual per fiets) en in de voorbeeld-YAML's. Je moet de firmware opnieuw flashen om dit te krijgen (web-installer of OTA).
Nieuwe sensor "Range Band": de Bosch-actieradius als één waarde, zoals in de Flow-app (issue #78). De Flow-app toont de actieradius als bereik, bijvoorbeeld "39 tot 83 km (Turbo tot Eco)". De integratie had deze waarden al, maar alleen als aparte sensoren per ondersteuningsmodus. De nieuwe sensor Range Band voegt ze samen: van de laagste tot de hoogste modus, bijvoorbeeld "37–80 km". In de attributen staan min_km, max_km, de modi aan beide uiteinden en de waarde per modus. Net als de losse sensoren volgt hij de laatste synchronisatie van de fiets en kan hij dus een paar kilometer achterlopen op de Flow-app. Hij wordt aangemaakt voor Smart System-fietsen die een actieradius per modus melden, niet voor eBike System 2. De waarde is tekst, dus er is geen eenheid en geen grafiek.
Actieradius-schatting: tours korter dan 5 km worden niet meer gebruikt (issue #78). Een korte rit zegt weinig over de actieradius van een lange, omdat hij meestal traag en vlak is. Bovendien is hij het minst nauwkeurig te meten: één stap in het accuniveau of één tellerupdate is al een groot deel van de energie. Wie bijna alleen korte ritten rijdt, krijgt daarom geen schatting meer in plaats van een schatting die alleen boodschappenritten beschrijft. Voor het plannen van langere tours is de Bosch-actieradius bedoeld (de losse sensoren en Range Band). Nieuw attribuut op beide schattingssensoren: tours_too_short telt de weggelaten korte ritten, ook als de sensor geen waarde heeft. De README is in alle zes talen aangevuld.
Actieradius-schatting: tours met onrealistisch laag verbruik worden genegeerd, nieuwe diagnose-attributen (issue #78). De schatting gebruikt de energie van elke tour. Die komt uit een energieteller die de Bosch-cloud laat en soms maar gedeeltelijk bijwerkt, of uit het live-accuniveau van de bridge. Een tour kan daardoor met veel te weinig energie zijn opgeslagen zonder dat de tot nu toe geldende grens (onder 1,0 Wh/km) dat opmerkt. Eén zo'n tour (meer dan 30 km met flink wat hoogtemeters, opgeslagen met slechts 41 Wh) trok bij een echte fiets de actieradius met volle accu zo'n 14 procent omhoog. Tours onder 2,5 Wh/km tellen nu ook niet meer mee voor de schatting, zelfs als ze al zijn opgeslagen (tours met 0 Wh waren al uitgesloten). Wat wordt opgeslagen blijft ongewijzigd, zodat het later aanvullen van de energie van een tour (issue #67) blijft werken. Wie vooral met heel weinig ondersteuning rijdt, ziet mogelijk geen waarde totdat genoeg tours boven de grens liggen.
Nieuwe attributen op beide schattingssensoren: tours_ignored (hoeveel tours zijn genegeerd, nu ook die met 0 Wh), tours_ignored_sample (de vijf nieuwste, met datum, kilometers, Wh en de bron van de energie: cloud of ble_live), tours_used_by_source (gebruikte tours per bron), wh_per_km_min en wh_per_km_max (spreiding van de gebruikte tours). Ze zijn er ook als de sensor nog geen waarde heeft. Daarnaast schrijft de integratie een INFO-logregel "Range estimate for bike …" zodra de cijfers veranderen (zet het logniveau van custom_components.ha_bosch_ebike op info). Is de schatting bij jou nog steeds te hoog, dan helpen deze attributen, plaats ze dan in issue #78. De README is in alle zes talen aangevuld.
Trick Check: de duur van wheelies wordt nu goed getoond (issue #92, bijdrage van JulianHock). De parser las de duur van alle triktypen als milliseconden. Bosch levert alleen bij sprongen milliseconden (een geheel getal, bijvoorbeeld 320). Wheelies komen in seconden (een decimaal getal, bijvoorbeeld 2.0), daardoor verscheen een wheelie van 2 seconden als 0,0 s. Nu wordt alleen bij sprongen door 1000 gedeeld. Bij manuals en stoppies is de eenheid nog niet bevestigd, omdat er nog geen rit met waarden ongelijk aan nul is gezien. Ze worden net als wheelies als seconden gelezen. Als je een manual of stoppie rijdt, vergelijk dan de duur met de Flow-app en laat het weten als die niet klopt.
Dashboardkaart: duidelijkere velden en een melding bij een verkeerde invulling (issue #91). Het veld "Accu-SoC-entity (0..100)" heet nu "Accustand-sensor (huidige lading in %)" en heeft een hint dat de laadgrens een eigen veld heeft. Het veld voor de doelwaarde heet nu "Laadgrens: doel-SoC input_number-entity". Staat er in het accustandveld een input_number of number, of dezelfde entiteit als bij de doel-SoC, dan toont de kaart nu een melding. Eerder gaf ze de waarde van de helper stilzwijgend weer als accustand zodra de live-sensor niet beschikbaar was. Wat wordt getoond, blijft zoals ingesteld. Alle zeven talen zijn aangepast. De nieuwe kaartversie wordt pas geladen na een herstart van Home Assistant en het opnieuw laden van de browser.
What's Changed
- Trick Check: read wheelie/manual/stoppie duration as seconds by @JulianHock in #93
New Contributors
- @JulianHock made their first contribution in #93
Full Changelog: v1.19.58...v1.19.59