Teslas unter Berücksichtigung der erzeugten PV Leistung laden
Berücksichtigung der Börsenstrompreise, zum günstigen Laden mit Netzstrom (z.B. mit Tibber oder aWATTar)
Keine besondere Wallbox erforderlich, funktioniert sogar mit dem mitgelieferten UMC oder dem Tesla WallConnector, weil das Auto direkt gesteuert wird (wie in der Tesla App).
Regelung bis runter auf 1A statt der üblichen 6A bei der Regelung über die Wallbox. Damit ist keine Phasenumschaltung erforderlich.
Was brauche ich?
Tesla mit Internet am Ladeplatz (egal ob über das Tesla eigene LTE oder WLAN)
Falls Nutzung in Verbindung mit PV Anlage eine Schnittstelle zum Auslesen der PV Daten (Überschuss/Netzbezug), das kann sein REST, Modbus TCP oder MQTT
Ein ständig laufendes Gerät mit Docker Unterstützung und permanenten Internetzugriff, das kann sein:
ein alter PC/Laptop (Windows oder Linux)
bestimmte Versionen von Synology NAS,…
ein Raspberry Pi
Raspberry Pi benötigtes Material
Den Raspberry Pi 4 selbst (zum Normalpreis oder auf Amazon in teuer)
Alternativ kann man auch den Raspberry Pi 5, nach eigenem Ermessen die 4GB oder 8GB RAM Variante nehmen, der Raspberry Pi 4 ist aber vollkommen ausreichend Raspi 5 4GB RAM. ACHTUNG: Der Raspberry Pi 5 braucht ein anderes Netzteil und ein anderes Gehäuse!
Stromversorgung für den RaspberryPi 4 (keine Handynetzteile verwenden, die haben oft keine konstante Spannung und der Raspberry stürzt immer wieder ab)
Jop, hier ein Beispiel von einem Tag mit wechselnder Bewölkung im Mai. Gelb die PV, rot der Netzbezug, rosa der gesteuerte Tesla und grau der Rest vom Haus:
Entpricht 96% PV Strom, 4% Netzstrom. Besser wird es nicht, da das Auto recht träge regelbar ist und schnelle Schwankungen (Herdplatte an/aus, wechselnde Bewölkung,…) daher nicht zu 100% ausgeglichen werden können. An Tagen mit konstanter Sonne und konstantem Hausverbrauch sind es praktisch 100% Sonnenstrom.
Habe ich auch erst überlegt, ob ich das mache, aber in C# war ich einfach schneller und ursprünglich war’s nur für mich gedacht. War dann allerdings kaum Aufwand nochmal umzubauen und ich dachte mir vll hilft’s ja jemandem und sei es nur als Codevorlage
SMA Plugin ist fertig und Konfigurationsanleitung in der README ergänzt. Bei Fragen und Problemen, gerne auf mich zukommen. Und: Einen PayPal Donate Button gibt’s jetzt auch
Wenn man schonmal dabei ist Feedback zu geben, Dockerhub schlägt ja wie immer vor MultiArch zu bauen. Du hast in den GitHub Actions die du bisher nutzt nur ARM64 und AMD64 drin. So unwahrscheinlich wie es auch ist, da wäre ne Idee noch normales ARM (also 32Bit) reinzupacken welches alte Raspberries noch hatten. Eventuell sogar alles was Teslamate bietet. Dürfte nix weiter sein als die Actions anzupassen, C# compiled ja auf alles.
Ein weiterer Punkt wäre REST-API. So weit ich das laut Doku sehe kann man den bisher nur per Enviroment Variablen, sowie über die eigene Seite ansprechen. Eine HomeAssitant Integration (oder ähnliches) müsste das am Besten aber über REST machen. Evt. geht das ja schon, fehlt nur in der Doku.
Das mit der Architektur stelle ich noch um, ich hatte nur Probleme mit der Github Pipeline bzw Actions, irgendwas hat es da zerlegt und ich hab mich dann vorerst nicht weiter drum gekümmert.
Bezueglich Rest Endpunkte: Gibts aktuell noch nicht, gerne Vorschläge, was es geben soll, dann kann ich die einbauen.
Wäre es möglich MinAmp und MaxAmp während der Container läuft zu verändern? Wenn ja wären das so zwei Dinge die richtig cool wären. Will man das Auto etwas schneller vollbekommen kann man das so automatisiert auf z.B. 5A min setzen lassen. Und natürlich das switchen zwischen Maximum Power Charge Mode und PV Charge. Mehr fällt mir spontan nicht ein was Sinn machen könnte.
Da wäre die Umsetzung interessant. Passiv versuchen, also die ganze Zeit nur im PV Modus laden bis man die volle Leistung braucht und dann 16A ziehen, Aktiv die MinAmp höher setzen, oder intelligent anhand der Zeit von Sonnenauf- bzw. Untergang das planen (Beispielsweise wenn man 11Uhr los muss und das am Vortag 14Uhr dransteckt zieht er alles von Solar, stoppt die Ladung über Nacht und fängt frühs wieder an, aber mit höherer MinAmp, sodass er das Ziel erreicht).
Das sehe ich als falsche Option, weil Annahme: Ich habe 80% als Ziel um 11 Uhr, ich habe 65% im Akku (mal angenommen ich brauche eine Stunde für 15%). Warum soll ich dann zum Sonnenaufgang um 6 Uhr die min Ampere erhöhen wenn es vll bis um 10 schüttet und von 10 bis 11 hab ich dann Sonne und kann die vollen 11kW aus der PV ziehen? Aus meiner Sicht macht alles zwischen MaxPower und nur PV keinen Sinn. Immer wenn ich schon vorher mit Netzbezug lade schmeisse ich die Chance weg, dass später ggf. doch noch mehr Sonne scheint als erwartet.
Okay, da hast du natürlich Recht, an Regen hab ich nicht gedacht.
Berechnen tust du das anhand der kW die der Anschluss bringt? Weil du musst ja unterscheiden ob die 16A 3Phasig oder 1Phasig anliegen.
Im Prinzip sehr einfach. Aus aktuellem Ladestand und Abfahrtszeit weisst Du wann der letzte Moment ist um auf volle Netzladung umzustellen. Wenn die PV also vor dieser last time schon weiter ist wird er nie umschalten.
Genau so mache ich das. Nur dass ich auch noch morgens den Rest im Akku mit laden lasse. Da weiß ich dass ich über Nacht 25% brauche. Und kann so morgens den Rest bis hinunter auf 10% Akku ins Auto laden.
Ist dann ja nur ein Summand auf der Ladeleistung der solange ansteht bis der Akku leer ist.
So ähnlich wie in der ooen WB der Auto Vorrang. Nur eben zeitlich begrenzt auf die Zeit ohne PV Ertrag.
Das ist aktuell noch nicht implementiert, momentan gehe ich immer von dreiphasig aus. Nachdem Tesla aber beim Anstecken immer zu laden beginnt sehe ich ja da, ob 3 oder einphasig => Kann ich mir merken, bis ausgesteckt wird.
Bin ganz zufrieden 99% Sonnenstrom, das 1% kommt halt daher, dass nur alle 30 Sekunden geregelt wird und bei wechselnder Bewölkung/schaltenden Geräten wie Waschmaschine und Herd, hat man halt immer etwas Netzbezug und etwas Einspeisung… Insegesamt 38kWh nachgeladen, dann war der Akku auf 90%.
Falls die Software hier schon jemand nutzt, in der docker-compose.yml ist eine neue Option hinzugekommen unter volumes, mit config Files. Damit überlebt die aktuelle Einstellung, ob PV, oder Maximale Leistung einen Container-Neustart und eine Container-Neuerstellung. Zum Thema MindestSoC zum Zeitpunkt x: Dauert noch ein wenig, ich hab wie man unschwer erkennen kann noch nie Frontend programmiert, also kann noch ein wenig dauern. Zudem bin ich am Überlegen, ob ich das ganze Frontend nochmal umbaue, sodass normale REST Endpoints genutzt werden => Jede Funktionalität in der UI könnte auch direkt von außen angesprochen werden.
Nochmals eine kleine Korrektur: Das Abwarten der x Minuten zum Ladestand hat nicht korrekt funktioniert. Der Timer wurde nicht zurückgesetzt, wenn innerhalb der x Minuten wieder zu wenig Überschuss da ist. Ich werde mich die nächsten Tage mit den Github Releases mal genauer auseinander setzen, sodass korrekt Releases erzeugt werden und im Git Repo ein Changelog ersichtlich ist. Dann kann man sich auch automatisch benachrichtigen lassen, wenn ein neuer Release da ist.
So, da ich es selber brauche, habe ich mir eine quick and dirty Version zum Laden auf Zeitpunkt x gemacht (Verbesserung folgt): Man muss einen SOC + Datum + Stunden + Minuten eingeben (Werte werden beim Verlassen der Eingabefelder gespeichert). Aktuell ist aber eine feste Laderate von 15% pro Stunde hinterlegt (entspricht in etwa einem LR bei 11kW). Wichtig: Neue Environment Variable für die Zeitzone hinzufügen (Siehe README).
Zudem ist noch eine Korrektur mit drin, unter bestimmten Umständen wurde die gespeicherte Konfig nicht richtig ausgelesen.
Beim Aktuellen Stand wird das Ganze jetzt mal eine Zeit bleiben, weil ich einiges umstellen muss, sodass ich erweitern kann.
99% Sonnenstrom, das 1% kommt halt daher, dass nur alle 30 Sekunden geregelt wird und bei wechselnder Bewölkung/schaltenden Geräten wie Waschmaschine und Herd, hat man halt immer etwas Netzbezug und etwas Einspeisung… Insegesamt 38kWh nachgeladen, dann war der Akku auf 90%.