Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[GombersIOB]

Ich habe einen Akku für mein Bosch EBike mit 650 Wh. Es gibt die Empfehlung Akkus immer zwischen 20% und 80% Ladezustand zu halten um die Lebensdauer maximal zu halten. Den unteren Wert zu beachten ist relativ einfach, das wird am Kiox ständig angezeigt.
Aber dann steckt man den Akku ans Ladegerät und müsste ständig vorbeischauen um nicht zuviel zu laden.

Ich habe mir das jetzt automatisiert über eine Shelly SmartPlug M Gen3 smarte Steckdose. Ich habe das auch mal für die MEROSS smarte Steckdose gemacht. Aber der Adapter macht nur alle halbe Stunde einen Update auf den Status, das war mir zu lang

Die Shelly Steckdose akkumuliert die abgegebene Energie offenbar über ihre Lebensdauer.
Ich habe zwei Ansätze über die ich das Laden steuere. Zum Einen gebe ich den Ladezustand am Anfang an und den gewünschten Ladezustand am Ende. Im Script vorgegeben ist ein Anfangsladestand von 20% und eine gewünschter Endladestand von 70%. Über VIS kann ich diese Werte via Schieberegler ändern. Wenn ich aber einfach nur den Stecker einschalte, wird mit diesen Settings gearbeitet.

Der zweite Ansatz ist die Verwendung der Ladekennlinie. Der Ladestrom wird gegen Ende des Ladens geringer. Das Script tracked den Peak des Ladestroms. Fällt der unter einen vorgegebenen Faktor (LOW_POWER_FACTOR, derzeit bei mir 0.5) dann wird das Laden beendet. Das Ganze ist sehr schön bei Olafs Pedal&Perspektive beschrieben. Olaf hat eine Script bereitgestellt, das direkt auf dem Shelly SmartPlug läuft.

Meine VIS-Seite dafpr sieht so aus:

Ich kann, zwischen zwei Akkugrößen wählen und die Ladezustände einstellen. Die Anpassung der Werte kann jederzeit gemacht werden, das Script nimmt immer die eingestellten Werte.
Ich habe zwei Scripte am Laufen.
Das Eine handelt das Ein- und Ausschalten.
Das Zweite triggert einen Timer, Dabei ist mir wichtig, dass der Timer jederzeit eine gewise zeitlang gestoppt und wieder gestartet werden kann, ohne dass die Werte verloren gehen. Ich habe das derzeit auf MAX_MINUTES_STOPPED = 20 (Minuten) festgelegt.

Ich lasse mir Meldungen über Pushover ausgeben. Zur besseren Übersicht über meine Meldungen habe ich mehrere Pushover-Instanzen laufen. Ich lasse mir das "richtige" Pushover über ein globales Script geben. Das passiert am Anfange der Scripte über:

// ==== Pushover ==================================
const pushmessage:string = iobGlbl_getPushoverInstance("ebikebattery");

Hier kann man auch einfach direkt den Namen der Pushover-Instanz eingeben.

SwitchOnOff.ts Handelt das Ein/Ausschalten
BatteryMonitor.ts Steuert den Timer

[GombersIOB]

Ich habe die Scripts ein wenig angepasst.

Das Script reagierte auf jede Änderung des Switch-Objekts. Der Adapter ändert aber nachts immer mal wieder den Zeitstempel. Das führte zur Meldung "Ladesteckdose wurde ausgeschaltet", ohne dass sie eingeschaltet gewesen war. Reagiere jetzt nur noch auf Änderung des Wertes (Schaltzstandes)
von

on({ id: SMARTPLUG_SWITCH_STATE, change: "any" }, (obj) => {

auf

on({ id: SMARTPLUG_SWITCH_STATE, change: "ne" }, (obj) => {

Ich habe das Script geändert, dass das Einschalten des Steckers nur noch über IOBroker/VIS möglich ist Dazu gibt es eine neue User-Variable "Switch" den ich auch mit VIS schalte. Wenn die nich auf "true" steht wird der Stecker direkt wieder ausgeschaltet.

Die geänderten Scripte füge ich bei. Außerdem noch das Setup-Script für die Kontrollvariablen.

SwitchOnOff.ts Kobtrolle dss Ein/Ausschalt-Vorgangs
BatteryMonitor.ts Handelt das Ein/Ausschalten
EBikeAkkuSetup.ts Erstellen der Umgebungsvariablen

[gto]

Hallo GombersIOB
Ich habe Verständnisfragen:
Steuert ein Script den Timer und das andere über die Kennlinie? Müssen beide gleichzeitig laufen? Schaltet das Timerscript das andere aus und umgekehrt?
Danke Thomas

[GombersIOB]

@gto Ich habe aus ästhetischen Gründen zwei Scripts gemacht. Ich mag große Monolithen nicht. Und da hier zwei einigermaßen deutlich unterscheidbare Zwecke zu sehen waren, habe ich auch zwei Scripte daraus
gemacht. Technisch könnte man das auch in eins nehmen.
Da nichts zu überwachen ist, wenn der Shelly nicht eingeschaltet wurde, braucht man auch beide Scripte aktiv.

Der SwitchOnOff.ts behandelt die Anfangswerte, mit denen gestartet wird. Speichert den Zustand des Shelly und setzt die Annahmen an den Ist-Ladezustand und Soll-Ladezustand. Außerdem überwacht es, ob per IOBroker oder auf anderem Wege eingeschaltet wurde. Nach dem Einschalten könnte man dieses Script beenden. Aber warum sollte man das tun?

Der Timer "BatteryMonitor.ts" schaltet aus, mit was immer zuerst erreicht wird: Der gewünschte Ladezustand oder das Absinken der Ladekennlinie. Man kann also derzeit auch keine 100% Füllzustand einstellen, fällt mir bei der Frage auf, da die Kennlinie das Laden ja vorher stoppt.
Diese Möglichkeit muss ich wohl auch noch einbauen. Denn ab und zu soll ja eine LIB/LFP-Batterie zu hundert Prozent geladen werden, um dem BMS zu ermöglichen, den Füllstand sauber zu bestimmen.

Ich habe aber das Einschalten des Ladevorgangs am Steckdosenschalter wieder ermöglicht. Man kann die Kontrolle darüber jetzt in den Uservariablen unter dem Namen ".AppControlledSwitchOn" ein bzw ausschalten.
"True" bedeutet hier, Einschalten nur über IOBroker, "False" lässt das Schalten auch über den Stecker zu.

BatteryMonitor.ts
SwitchOnOff.ts
EBikeAkkuSetup.ts

[gto]

@GombersIOB
Danke für deine ausführliche Erläuterung, jetzt ist "fast" alles klar.
Nur zur Sicherheit: Der Ladestart erfolgt durch Schalten der Dose in der Shelly-App, an der Dose selbst oder über den Datenpunkt ".relay.0.switch"?
Danke
Thomas

[GombersIOB]

@gto "SwitchOnOff" startet nicht das Laden sondern kontrolliert den Startwunsch. Es erkennt das Einschalten über den Steckerschalter oder die ShellyApp oder über VIS und geht damit um. Und es setzt die Anfangswerte zurück.

Auf das Erkennen kann es dann unterschiedlich reagieren.
Derzeit, zum Beispiel, kann ich erzwingen, dass ein Ladestart über den Schalter an der Steckdose unterbunden wird. (Das habe ich gemacht, weil mir schien, dass der Stecker sich "selbstätig" wieder einschaltete. Es kamen Meldungen vom Adapter, die mich irritierten. Aber es ist nur der Adapter gewesen, der den Status völlig unvermittelt nachts updatete. Die Funktion ist jetzt drin, aber eigentlich derzeit sinnfrei. Deshalb habe ich sie über Parameter ein- bzw ausschaltbar gemacht).

Es gibt Wünsche, wie ich im Blog von Olafs Pedal&Perspektive lesen konnte, dass das Laden nicht sofort beginnt sondern mit Verzögerung, damit, wenn der Akku nach einer Fahrt angeschlossen wird, er erst abkühlen kann. Das habe ich (noch) nicht berücksichtigt, wäre da aber leicht möglich zu machen.

"BatteryMonitor" fragt im Loop, mit einminütiger Pause, immer wieder die Gesamt-Lademenge ab und vergleicht sie mit dem Bedarf an Energie um den Akku von Anfangs-Ladezustand auf End-Ladezustand aufzuladen. Außerdem prüft es die Ladeleistung. Wenn die unter einen Prozentwert (hier 50%) der maximalen gemessenen Leistung abfällt, dann stoppt das Laden auch.

Um es nochmal im Detail zu erklären:
Der Shelly-Adapter setzt in den Shelly-Daten (...Relay0.Switch) den Schaltzustand auf "true", wenn die Steckdose eingeschaltet ist. Wenn "SwitchOnOff" das erkennt dann setzt des die Anfangswerte zum Laden.
Und "BatteryMonitor" beginnt mit der Überwachung.

Aber insgesamt möchte ich bitten, nochmal ein paar Tage, bis Mitte nächster Woche, zu warten. Ich bin dabei das Programm nochmal generell zu überarbeiten, um es besser testen zu können und auch mit der Ladekennlinie flexibler umzugehen. Außerdem habe ich die Namen der User-Objekte jetzt systematischer benannt.
Das Testen machte ich bisher über ausprobieren, das möchte ich jetzt systematischer angehen. Ich habe noch Fehler gefunden, die man beim bloßen probieren derzeit nur schwer nachvollziehen kann.