Tesla Auto anbinden ans Smarthome

Einklappen
X
 
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
  • MiDie
    Dumb Home'r
    • 02.11.2025
    • 14

    #1

    Tesla Auto anbinden ans Smarthome

    Wir haben 2 Teslas und eine Tesla Powerwall 2 plus PV. Tesla managet das Zusammenspiel zwischen PV, Überschussladen und Speicherladung ja schon out of the box sehr praktisch. Nun haben wir ein smarthome von Loxone und eine Wallbox von smarthome. Das Loxone hat nun das Energiemanagement übernommen. Das wirkt auf mich extrem komplexer. Ein Tesla ist per API angebunden, um die Funktionalität von Tesla im Loxone nachzubilden (z.B. Auto immer mindestens bis 30% laden, danach PV-Überschuss bis 80%), die Powerwall zieht über Tibber bei günstigen Strompreis Netzstrom.
    Da der Aufwand sehr hoch war um den ersten Tesla einzubinden, fragen wir uns, ob das überhaupt der richtige Weg ist. Es ist komplexer geworden und war sehr aufwändig (=teuer). Wie ist Eure Erfahrung und Meinung dazu?
  • Jan W.
    Lox Guru
    • 30.08.2015
    • 1529

    #2
    Da der Aufwand sehr hoch war um den ersten Tesla einzubinden, fragen wir uns, ob das überhaupt der richtige Weg ist. Es ist komplexer geworden und war sehr aufwändig (=teuer).
    Die Frage ist, warum Du die Einbindung gemacht hast? Ein E-Auto funktioniert auch ohne Einbindung in Loxone mit einer einfachen Wallbox "out of the box", wie Du selbst gesagt hast. Jede PV-Anlage bringt eine App zur Visualisierung mit, allerdings funktioniert Überschussladen dann meines Wissens nur innerhalb eines Hersteller-Ökosystems gut.

    Die Kosten bzw. der Aufwand der Integration in Loxone stehen sicherlich nicht im Verhältnis zu dem Nutzen. Die gesamte Logik in Loxone nachzubauen und eine evtl. vorhandene Logik der Hersteller abzuschalten - nur weil man es kann - macht wenig Sinn. Du hattest ja oben bereits Wünsche an die Funktionalität angegeben und solche Wünsche lassen sich häufig herstellerübergreifend nur mit eigener Logik d.h. einem flexibel programmierbaren System wie Loxone realisieren.

    Leider sieht es für mich so aus, dass die Hersteller nur bis zu ihrem eigenen Tellerrand schauen und das Marketing jeweils happy ist, wenn eine eigene App vorhanden ist, so dass man die Lösung als "Smart" verkaufen kann. Übergreifende Integration, API's etc. interessieren nur wenige und dann vielfach erst nach einer Kaufentscheidung. Zum Thema Energiewende gibt es hier mehrere Beiträge, u.a. HAN-Schnittstelle bei neuem Stromzähler und Loxone als EMS (Paragraph 14a EnWG in D) und EEBus mit MS Gen. 2.

    Das Thema "API" wurde offiziell von Tesla eine lange Zeit nicht beachtet, so dass die Dokumentation der Owner's API über Reverse-Engineering aus der App von versierten Anwendern erfolgte. Erst seit einiger Zeit bietet Tesla eine offizielle API an, die aus meiner Sicht schon durchdacht ist und im Bereich Sicherheit deutlich mehr bietet als die inoffizielle Owner's API. Diese Fleet API ist dafür aber deutlich komplexer, denn sie ist an einen größeren Kreis von Nutzern gerichtet und hat dadurch auch einen stärkeren kommerziellen Aspekt. Immerhin hat Tesla auch an die Besitzer gedacht und mit der Option Bluetooth die Möglichkeit geschaffen, lokal eine ganze Menge zu steuern.

    Für mich betrachtet stellt sich das so dar: Wallbox von easee, Auto von Tesla, PV-Anlage mit Speicher von Huawei. Ich habe ein Loxberry Plugin programmiert, um lokal via BLE das Laden beim Tesla zu steuern. In Loxone habe ich die Logik für PV-Überschussladen, als auch Öko-Laden zu Zeiten mit Stromüberschuss realisiert.

    Die Bausteine in Loxone kosten nichts extra und die HW war vorhanden, aber die Einarbeitung in das Thema hat schon etwas Zeit gebraucht, insbesondere weil die Logik recht komplex ist, die Bausteine etc. im Laufe der letzten Jahre weiterentwickelt wurden und die Doku nur jeweils kleinen Auschnitte beschreibt. Das ist jetzt auch nicht als Vorwurf an Loxone gemeint, denn die können nichts dafür, wenn sich Gesetze ändern und Strompreise "plötzlich" nicht mehr im Stundentakt, sondern pro Viertelstundentakt berechnet werden.

    Ein Raspberry PI kam hinzu, aber die Kosten sind sehr überschaubar. Ein Loxberry Plugin für die easee Home gab es bereits, aber ob es weiterentwickelt wird ist fraglich (siehe hier). Auch hier habe ich etwas Zeit für die Nutzung und Optimierung der Cloud-basierten API von easee aufgewändet. Über den Aufwand der Erstellung des Loxberry Tesla Command Plugins brauchen wir gar nicht reden - das ist am Ende ein Hobbyprojekt.

    Die Einbindung der PV-Anlage von Huawei in Loxone ist ein weiteres Thema, welches anfangs sehr holperig verlief. Es gab zwar von Huawei eine dokumentierte API für Modbus/TCP, aber es gab viele Fehler bei häufiger Abfrage mit Intervallen unter einer Minute. Um eine halbwegs gute PV-Steuerung über Loxone zu ermöglichen, ist es aber notwendig die Werte in einem Intervall von wenigen Sekunden auszulesen. Erst nach etlichen Monaten entspannte sich das Thema nach einem Update bei Huawei deutlich (Verbesserung um Faktor 100) siehe hier.

    Zu den steuerbaren Geräten kommt bei mir noch eine Wärmepumpe von Stiebel-Eltron hinzu. Die hat ebenfalls eine dokumentierte API und eine Modbus/TCP Anbindung, wenn man die dafür notwendige zusätzliche Komponente "isgWeb" gekauft hat. Auch bei diesem Gerät habe ich viel Forschungsarbeit aufgewändet, da es anfangs keine Dokumentation zur Einbindung in Loxone gab und leider "out of the box" nicht alle Parameter per Modbus/TCP zugänglich waren. Am Ende sind mehrere Artikel in der Loxwiki entstanden. Zur Optimierung in Verbindung mit PV-Anlagen bietet die API sehr wenig. Immerhin gibt es einen virtuellen "SG-ready" Eingang, der bei PV-Überschuss die Warmwassertemperatur erhöht.

    Mein Fazit: die Integration von E-Auto, PV-Anlage, steuerbare Verbraucher etc. in Loxone war und ist sehr aufwändig. Loxone hatte z.B. mehrere Jahre das Abfrageintervall bei Modbus/TCP auf 5sek beschränkt, was für optimale PV-Integration sehr träge ist. Mittlerweile gibt es diese Beschränkung nicht mehr, aber man ist am Ende auf die Unterstützung aller beteiligten Hersteller angewiesen. API's, Cloud-Dienste und Apps ändern sich in wenigen Jahren deutlich und erfordern daher eine ständige Anpassung von eigenen Plugins oder Anbindungen - man ist nie fertig!

    Auch das Forum bzw. die Nutzer haben sich aus meiner Sicht in den letzten Jahren verändert. Früher waren mehr Bastler/Pioniere/Nerds unterwegs, während heute vielfach nicht mal mehr nach einer bereits vorhandenen Lösung im Forum oder der Loxwiki gesucht wird, sondern einfach gepostet wird "ich habe ein Problem mit xyz, kann jemand helfen" ohne irgendwelche Details mitzuliefern. Vielleicht hat sich die Welt tatsächlich in den letzten Jahren geändert bzw. weiterentwickelt, so dass heute mehr Anwender ohne Fachwissen dabei sind?

    Im Gegensatz zu Google und Apple, die nach der Entwicklung von Smartphones einen eigenen Shop mit kostenlosen als auch kostenpflichtigen Apps eingerichtet haben und auf diese Weise den Nutzen für ihre Gerät deutlich erhöht haben, hat Loxone sich für die Abschottung entschieden. Es gibt zwar eine Loxone Library, aber die Unterstützung durch Hersteller ist aus meiner Sicht eher mau. Viele der dort vorhandenen Integrationen stammen von Loxone. Neben den In- und Outputs fehlen häufig Beispiele und funktionierende Integrationen, die einfach übernommen werden können. Professionelle Loxone Partner haben natürlich primär ein kommerzielles Interesse, ihre Dienstleistung zu verkaufen, als eine Community mit Anleitungen zu unterstützen oder ihre aufwändig erarbeiteten Integrationen in der Loxone Library bereitzustellen. Die Pionierzeit ist aus meiner Sicht vorbei und der Markt ist deutlich komplexer und größer geworden.

    Der Loxberry ist als nicht-kommerzielles Projekt entstanden und wird von Loxone wohl eher als Konkurrenz gesehen, weil er die Verkäufe des MS Gen. 2 wahrscheinlich (Upgrade wg. TLS-Anbindungen an andere Geräte) verringert. Der Aufwand für die Weiterentwicklung der Core-Services beim Loxberry ist sicherlich erheblich und die Plugins können nur mit einer ausreichen großen Community und engagierten Usern mit Programmierkenntnissen aktuell gehalten werden. Ich bin sehr gespannt, wie sich der gesamte Bereich E-Mobilität, Energiewende, Smart Home Integration in den nächsten Jahren weiterentwickeln wird.
    Zuletzt geändert von Jan W.; vor einer Woche.
    Miniserver v14.5.12.7, 2x Ext., 2x Relay Ext., 2x Dimmer Ext., DMX Ext., 1-Wire Ext., Gira KNX Tastsensor 3 Komfort, Gira KNX Präsenzmelder, Fenster- und Türkontakte, Loxone Regen- und Windsensor, Gira Dual Q Rauchmelder vernetzt, 1x Relais-Modul
    Loxberry: SmartMeter, MS Backup, CamConnect, Weather4Lox
    Lüftung: Helios KWL EC 370W ET mit Modbus TCP - via Pico-C
    Heizung: Stiebel Eltron WPF 5 cool (Sole-Wasser WP) mit ISG, FB-Heizung mit 18 Kreisen, Erdsonde - via modbus/TCP
    Node-RED: IKEA Tradfri

    Kommentar

    Lädt...