Tesla Wall Connector v2 mit TWCManager – Dynamische PV-Überschussladung realisieren
Anfangs hegte ich starke Zweifel daran, ob das frisch installierte Solarcarport (Blogpost) bzw. Loxone jemals vernünftig mit der installierten Tesla-Ladesäule kommunizieren kann, um eine automatische Überschussladung je nach verfügbarer PV-Leistung zu realisieren. Aber zum Glück lag ich völlig falsch und hab nun sogar eine zweite Ladesäule nachgerüstet. Der erste Schritt zum Ziel lag dabei am Anzapfen der integrierten RS485-Schnittstelle des Tesla Wall Connector, dessen Leistung per TWCManager durch simple HTTP-Aufrufe gesteuert werden kann.
Wie gering der Aufwand schlussendlich war, um das System hardwareseitig zum Laufen zu bekommen und wie man damit sogar mehr als einen Tesla Wall Connector einbinden kann, um den PV-Überschuss perfekt zu nutzen, ist Inhalt des nachfolgenden Blogpost.
Warum eigentlich der Stress mit dem TWC (Tesla Wall Connector)?
Einige werden sich vielleicht vorab die Frage gestellt haben, warum ich mir nicht einfach eine “smarte” Ladesäule mit integriertem Netzwerkanschluss zulege, wie bspw. die Keba P30 (Affiliate-Link), um eine automatische Überschussladung je nach verfügbarer Sonnenenergie zu realisieren.
Ganz einfach: Ich hatte bereits einen Telsa Wall Connector v2 und war bisher immer sehr zufrieden damit. Ausserdem ist die Taste am Ladestecker einfach zu sexy, um mit einem einfachen Klick die Ladeklappe am Tesla zu öffnen.
Mit relativ geringem Aufwand lässt sich zudem sogar ein zweiter Wall Connector nachrüsten (bei eBay für 420 Euro besorgt), dessen Einbindung dann vollkommen automatisch funktioniert. Aber später dazu mehr…
BTW: Da der Tesla Wall Connector einen stink normalen Typ 2-Anschluss hat, lassen sich damit auch Elektroautos anderer Hersteller laden. Und das bis zu 22kW, sofern das beim lokalen Netzbetreiber (Stadtwerke) angemeldet und genehmigt wurde. Sofern die Ladeleistung dauerhaft auf 11kW begrenzt wird, genügt übrigens eine einfache Anmeldung, die jedoch vom eingetragenen Elektriker unterschrieben sein muss.
Tesla Wall Connector pimpen per TWCManager
Das Open-Source-Projekt TWCManager (GitHub-Link) hat sich zum Ziel gesetzt die RS485-Schnittstelle des Tesla Wall Connector zu nutzen, um dessen Ladeleistung dynamisch zu steuern.
Dabei ist die Schnittstelle eigentlich dazu gedacht, die vorhandene Leistung an einem Standort unter mehreren TWC aufzuteilen. Ein TWC wird dabei als Master definiert mit der Info, welche Gesamtleistung (z.B. 16A, bei 3dreiphasigem Anschluss dann 11kW) zur Verfügung steht. Bis zu drei weitere TWC können dann als Slave an den RS485-Bus des Masters in Reihe angeschlossen werden und der Master verteilt dann die voreingestellte verfügbare Ladeleistung dynamisch unter den Ladesäulen.
Findige Menschen haben dann das verwendete Protokoll reverse-engineered und in den TWCManager übertragen, welcher schlicht und einfach die beschriebene Master-Funktion softwareseitig emuliert.
Eins vorab: Ich übernehme keinerlei Haftung für die Modifikation eurer Anlage. Jeder führt die Schritte auf eigene Verantwortung hin durch und sollte zudem unbedingt einen Fachmann in Form eines Elektrikers hinzuziehen!
Hardware für den Betrieb des TWCManager in Betrieb nehmen
Grundsätzlich gibt es mehrere Möglichkeiten den TWC einzubinden. Eine gängige Möglichkeit ist vermutlich die im TWCManager Installation-Guide (Direktlink) beschriebene Möglichkeit, welche vorsieht, einen Raspberry Pi Zero W (Affiliate-Link) in den TWC einzubauen und dessen interne 5V-Stromversorgung anzuzapfen. Oha… Das war mir aber ehrlich gesagt doch ein Stück zu gruselig und zudem wollte ich das Ganze am Ende nicht per WLan sondern kabelgebunden und damit ausfallsicherer realisieren.
Da ich neben der Stromleitung sowieso ein Netzwerkkabel vom Technikraum bis hin zur Ladesäule verlegt hatte, konnte ich es aber sogar noch kostengünstiger lösen.
Bevor jemand selbst Hand anlegt hier der übliche Disclaimer: Arbeiten an und mit Strom dürfen nur von autorisiertem Personal vorgenommen werden. Bevor am TWC oder anderen stromführenden Geräten gearbeitet wird, muss immer vorher die Sicherung ausgeschaltet werden, sodass das Gerät stromlos ist. Es besteht sonst die Gefahr eines Stromschlags und damit Lebensgefahr!
Genug der belehrenden Worte. Erstmal ein verdrilltes Adernpaar des Netzwerkkabels an den linken “RS-485” “In”-Anschluss führen. Blaue Ader ganz links (RS485 +) und weiße Ader direkt rechts daneben (RS485 -).
Damit die Steuerung des Wall Connector über RS485 möglich ist, muss noch der Wahlschalter links daneben auf “F” gestellt werden (merkt euch direkt, auf welcher Stellung der Wahlschalter bisher war – später relevant).
Das andere Ende des Netzwerkkabels wird dann mit dem selben Adernpaar an einen wenigen Euro teuren USB zu RS485 Konverter (Affiliate-Link) angeschlossen. Blaue Ader ebenfalls an + (mit D+ und A gekennzeichnet) und die weiße Ader an – (mit D- und B gekennzeichnet).
Wichtig dabei ist die korrekte Adernbelegung, da die RS485-Kommunikation sonst nicht funktioniert. Ist die Belegung vertauscht, kann aber auch nichts kaputt gehen. Für den Betrieb notwendig ist ein geschirmte und verdrilltes Adernpaar, da das Signal sonst gerade bei längeren Kabelstrecken abreißt. Hier sind es in Summe bestimmt 40-50 Meter zwischen USB-Adapter im Netzwerkschrank und WTC im Carport, welche dennoch ohne Probleme überwunden werden können.
Den USB-Adapter kann man dann entweder an einem RaspberryPi 4 (Affiliate-Link) mit Raspberry OS (externer Link) betreiben oder an einem beliebigen Debian-System, in diesem Fall ein bereits vorhandener Intel NUC8i3BEH (Affiliate-Link) mit Proxmox-Virtualisierungsumgebung und dem “Raspberry Pi Desktop” (externer Link) als x86-Version, der noch genug Power und mit dem Crucial CT16G4SFD824A 16GB (Affiliate-Link) genügend RAM für weitere VMs besitzt.
UPDATE VOM 02.12.2021:
In der Zwischenzeit hat es bei mir bereits einige “billige” RS485-USB-Adapter zerlegt, sodass die Kommunikation mit dem Tesla Wallconnector nicht mehr zuverlässig funktioniert hat. Deshalb bin ich mittlerweile auf den etwas teureren Waveshare Industrial USB to RS485 Converter (Affiliate-Link) umgestiegen, der bisher schon knapp ein Jahr seinen Dienst verrichtet – auf Holz klopf.
Ausserdem habe ich mittlerweile an beiden Enden der RS485-Verbindung (also am RS485-USB-Adapter und an den RS485-Ports des Tesla Wallconnector) jeweils einen 120 Ohm Abschlusswiderstand angeschlossen. Also jeweils ein Beinchen des Widerstands an “A” und ein Beinchen an “B”. So sagt es die Spezifikation – und dann hält man sich eben doch lieber daran, um weiteren Verbindungsproblemen aus dem Weg zu gehen.
UPDATE ENDE
Software für den Betrieb des TWCManager in Betrieb nehmen
Erstmal per SSH auf dem System einloggen. In diesem Fall mit dem Benutzer “pi” und der IP “192.168.3.33”:
ssh pi@192.168.3.33
Das Standardpasswort beim Raspberry OS, welches im Anschluss abgefragt wird, lautet “raspberry”.
Jetzt muss erstmal ein Webserver installiert werden, welcher später das Webinterface vom TWCManager anzeigt und HTTP-Requests entgegennimmt :
sudo apt-get update && sudo apt-get install -y lighttpd && sudo apt-get install -y php7.3-cgi && sudo lighty-enable-mod fastcgi-php && sudo service lighttpd force-reload && sudo chown -R www-data:www-data /var/www/html && sudo chmod -R 775 /var/www/html && sudo usermod -a -G www-data pi
Die Befehle habe ich im Grunde 1:1 aus der offiziellen TWCManager-Anleitung übernommen, nur hat sich der dort angegebene Befehl “sudo apt-get install -y php7.0-cgi” in der Zwischenzeit geändert in “sudo apt-get install -y php7.3-cgi”.
Nun noch ein paar Pakete und den TWCManager selbst:
sudo apt-get install -y screen git python3-pip && sudo python3 -m pip install pyserial sysv_ipc && git clone https://github.com/cdragon/TWCManager.git ~/TWC && sudo cp TWC/HTML/* /var/www/html
Im Anschluss werden die Settings gecheckt:
sudo nano ~/TWC/TWCManager.py
Hier ein gutes Stück herunterscrollen bis zum Eintrag “rs485Adapter = ‘/dev/ttyUSB0’“. Sofern der RS485-USB-Adapter das einzige USB-Device am Rechner ist, sollte der Eintrag bereits passen. Wer mehr als ein USB-Device verwendet, erhält im Blogpost Mehrere USB-Geräte unter Linux mit fixem Namen ansprechen weitere Hilfestellung.
Je nachdem, wie der bzw. die Tesla Wall Connector abgesichert sind, wird der Eintrag “wiringMaxAmpsAllTWCs = 40” angepasst. In der voreingestellten Ami-Variante sind fette 40A angegeben, da diese nur einphasig betrieben werden. Da der Tesla Wall Connector in Europa jedoch dreiphasig betrieben werden kann, ist der Wert entsprechend geringer. Wer – wie ich – lediglich einen 11kW-Lader bei den Stadtwerken angemeldet hat, ändert den Wert auf 16. Bei “230V x 16A x 3 Phasen” ergibt das dann in Summe knapp 11.000W, also 11kW, welche später für alle angeschlossenen TWC zur Verfügung stehen. Funfact: Die allermeisten E-Autos können eh nur mit 11kW maximal per AC (Wechselspannung) laden. Man hat also lediglich dann Geschwindigkeitseinbußen, sofern zwei Ladesäulen gleichzeitig in Betrieb sind.
Der Eintrag “wiringMaxAmpsPerTWC = 40” wird dann ebenfalls auf “wiringMaxAmpsPerTWC = 16” geändert, sofern die Auslegung der Verkabelung inkl. Sicherung dafür geeignet ist. Unbedingt mit dem Elektriker absprechen, da es sonst im schlimmsten Fall bei einer Überlastung zu Kabelbrand führen kann! Bevor man den oben angesprochenen Wahlschalter am TWC auf “F” umstellt, merkt man sich am besten, welche Stellung er vorher hatte. Rechts oben am TWC ist eine Legende, sodass man direkt nachvollziehen kann, welche Maximalleistung am TWC derzeitig freigegeben ist. Dieser Wert sollte sich dann eben bei “wiringMaxAmpsAllTWCs” und “wiringMaxAmpsPerTWC” widerspiegeln.
Abschließend kann der Eintrag “minAmpsPerTWC = 12” auf “minAmpsPerTWC = 6” geändert werden. Damit wird die Minimalleistung auf 6A herabgesetzt, was bei einphasigem Betrieb (dazu komme ich später nochmal) lediglich knapp 1,4kW entspricht. Passend also für PV-Überschussladung bei maximal bewölktem Himmel ohne Netzbezug. Noch niedrigere Werte funktionieren übrigens nicht.
Die restlichen Werte der Config habe ich unverändert gelassen. Jetzt die Datei mit “STRG + o” speichern und mit “STRG + x” schließen.
Nach der Installationsorgie am besten noch schnell ein
sudo reboot
und nach dem erneuten SSH-Login dann direkt testen, ob der TWCManager läuft:
/usr/bin/python3 /home/pi/TWC/TWCManager.py
Jetzt sollte sowas in der Art ausgegeben werden:
TWC Manager starting as fake Master with id 7777 and sign 77
09:41:03: Send master linkready1
...
09:41:03: Send master linkready2
...
09:41:04: 32.00 amp slave TWC 7835 is ready to link. Sign: 95
09:41:04: Set slave TWC 7835 protocolVersion to 2, minAmpsTWCSupports to 6.
09:41:04: Send master linkready2
09:41:04: 32.00 amp slave TWC 8906 is ready to link. Sign: 60
09:41:04: Set slave TWC 8906 protocolVersion to 2, minAmpsTWCSupports to 6.
Wie der Ausgabe zu entnehmen ist, werden hier direkt beide angeschlossene TWC mit der ID 7835 und 8906 gefunden. Der TWCManager vergibt sich selbst automatisch die Fake ID 7777.
Jetzt sollte sich auch das minimalistische Webinterface über die IP des Rechners aufrufen lassen. In diesem Beispiel also: http://192.168.3.33
Im Anschluss wird ein Service eingerichtet, welcher den TWCManager nach zehn Sekunden automatisch neustartet, sofern sich der Dienst einmal aufhängt (Logik hier gefunden):
Aber erstmal den vorhin manuell gestarteten und noch laufenden TWCManager mit “STRG + c” killen.
Und nun zur Neustart-Logik, welchen in die Datei TWCManager.service wandert. Erstmal den Editor öffnen mit:
sudo nano /etc/systemd/system/TWCManager.service
Und folgenden Text reinkopieren:
[Unit]
Description=Autostart TWCManager, logs to be found in journalctl -U TWCManager.system
[Service]
User=pi
Type=idle
ExecStart=/usr/bin/python3 /home/pi/TWC/TWCManager.py
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
Die Datei dann wie vorhin mit “STRG + o” speichern und mit “STRG + x” schließen.
Abschließend dann noch die entsprechenden Berechtigungen hinzufügen, den Dienst aktivieren und das System neustarten.
sudo chmod 644 /etc/systemd/system/TWCManager.service && sudo systemctl daemon-reload && sudo systemctl enable TWCManager.service && sudo reboot
Das automatische Neustarten des Dienstes ist in der Praxis übrigens mega relevant, da die Ladesäule bei einem Ausfall des TWCManager (vermutlich aus Sicherheitsgründen) gar keine Leistung mehr abgibt. Das Fahrzeug zeigt dann schlicht einen Ladefehler am Display und im Fall des Model 3 eine rot leuchtende Lade-LED – statt einer brav grün pulsierenden.
Nach dem Neustart des Systems sollte direkt wieder das Webinterface über die IP des Rechners erreichbar sein.
Dort kann man direkt einmal ausprobieren, ob die Steuerung so funktioniert, wie sie soll:
Über “Non-scheduled power” lässt sich bspw. “10A” auswählen und mit “Save” bestätigen. Nach wenigen Sekunden sollten die Änderungen durchgeführt werden. Manchmal dauert es auch einige Momente länger, also nur Geduld. Achso, die Seite ist nicht dynamisch und muss deshalb manuell mit dem “blauen runden Button” refresht werden.
Das Coole am Webinterface ist jetzt aber eigentlich, dass man easy per URL-Aufruf den gewünschten Leistungswert anpassen kann, hier z.B. auf 7 Ampere. Die IP muss natürlich jeder entsprechend anpassen…
http://192.168.3.33/index.php?nonScheduledAmpsMax=7&submit=Save
Diese URL wird dann später im Kontext des virtuellen Ausgangsbefehls in Loxone relevant, über welchen die automatische PV-Überschussladung getriggert wird. Wie das im Detail funktioiniert, ist Inhalt eines weiteren Blogpost. Schon alleine deshalb, weil meine hinterlegte Logik mittlerweile sehr umfangsreich und an meine Bedürfnisse hin angepasst ist. So lässt sich bspw. im Automatik-Modus definieren, ob bzw. wieviel “PV-Leistungspuffer” während des Ladens in 0,1kW-Schritten vorgehalten werden soll. Außerdem werden sich ändernde Leistungswerte maximal alle 30 Sekunden an den TWCManager weitergeleitet, um die Ladeelektronik nicht kirre zu machen.
Erweiterte Konfiguration per Tesla-API
In der oben gezeigten Konfiguration lässt sich die Leistung zwischen 6 und 16 Ampere frei setzen. Ein Ladestopp – z.B. bei gänzlich fehlendem PV-Überschuss – lässt sich lediglich dann realisieren, wenn der Tesla-Login rechts unten im Webinterface des TWCManagers eingetragen wird. Dann sendet der TWCManager per Telsa-API einen Ladestopp-Befehl per Internet an das Fahrzeug, sofern der Wert “nonScheduledAmpsMax” auf 0 gesetzt wird. Ich habe das bisher auch benutzt und es hat immer ordentlich funktioniert, wenn auch manchmal erst mehrere Sekunden verzögert.
Künftig werde ich aber auch eine andere Logik setzen, wofür ein MDT KNX-Aktor AZI-0616.01 (Hesteller-Link) installiert wurde.
Dieser ermöglicht es jede der drei Phasen der beiden TWC separat anzusteuern und zusätzlich sogar die tatsächliche Wirkleistung der einzelnen Phasen in Echtzeit auszulesen. Da die Relais nur bis 16A ausgelegt sind, darf ein TWC pro Phase nicht mehr als 3,7kW abgeben, was aber sowieso entsprechend durch den TWCManager geregelt wird. Außerdem ist die verbaute Ladetechnik von E-Fahrzeugen ohnehin in den allermeisten Fällen – wie beim Model 3 – auf 11kW begrenzt, was für den Heimgebrauch ja auch mehr als ausreicht.
Aus meinem täglichen Leben
Achso und apropos dreiphasiger Anschluss. Vor dem Anschließen des Fahrzeugs an die Ladesäule kann jetzt per Loxone-App gewählt werden, ob ein- oder dreiphasig geladen werden soll. Bei einphasiger Konfiguration sind dann Leistungen zwischen 1,4 und 3,7kW möglich. Bei dreiphasiger Konfiguration entsprechend das Dreifache und damit Werte zwischen 4,1 und 11kW.
So sieht die Statusanzeige dann in der Loxone App aus, ergänzt um einige zentrale Infos:
Während des Ladevorgangs lässt sich in der Praxis dann leider keine dynamische Anpassung vornehmen, da das Fahrzeug immer einen Fehler auf dem Display anzeigt und den Ladevorgang komplett beendet. Erst nach einem physischen Ab- und erneuten Anschließen des Ladekabels am Fahrzeug fährt der Ladevorgang fort. Bei manchen Fahrzeugen scheint das zwar zu funktionieren, auf Dauer ist das aber vermutlich weniger gut für die Leistungselektronik des eigenbauten Ladecontrollers. Habe sogar in diesem interessenten TFF-Thread zum Thema TWCManager gelesen, dass manche Ladecontroller kaputt gehen können, wenn ihnen während der mehrphasigen Ladung eine einzelne Phase gekappt wird. Klingt dämlich (vorallem vor dem Hintergrund eines temporären Phasenausfalls), ausschließen möchte ich es aber nicht.
In meinem Fall nutze ich das Abschalten aller Phasen über den KNX-Relais-Aktor dann, wenn das Fahrzeug gar nicht vor Ort ist (Auslesen der Geokoordinaten per Tesla-API, wie im Blogpost Tesla Model 3 in FHEM einbinden – Praktische Szenarien für den Alltag erklärt). Auch lässt sich ein aktiver Ladevorgang so im Notfall abbrechen, wobei ich da lieber ebenfalls die Tesla-API nutze, indem ich die Ladegrenze auf 50% (niedrigster Wert) stelle. Sofern das Fahrzeug dann weniger als 50% “state-of-charge” hat, lädt es eben mit lockeren 6A weiter bis 50%, anderenfalls bricht das Fahrzeug den Ladevorgang von sich aus ab. Sobald die tatsächliche Ladeleistung dann auf unter 5W fällt (durch den KNX-Aktor per Wirkleistungsmessung ermittelt), wird die Ladesäule zeitverzögert komplett vom Strom getrennt. So werden dann auch die knapp 3-4W Standbyleistung des TWC eingespart. Nicht viel, aber jedes Watt zählt. Netter Nebeneffekt ist dabei, dass kein anderes E-Auto ungefragt Strom zapfen kann.
Und noch ein Wort zur Installation von zwei Ladesäulen: Der TWCManager begnügt sich mit der Info, wieviel Power insgesamt zur Verfügung steht und regelt die Leistung dann selbstständig unter bis zu drei angeschlossenen TWC.
Insgesamt bin ich mit der Lösung super zufrieden, da die PV-Anlage jetzt perfekt genutzt werden kann, um die überschüssige Leistung direkt ins Auto zu laden, welche sonst für nur wenige Cent pro kWh eingespeist werden würde.
Hier erkennt man, wie gut die Logik funktioniert, um den Eigenverbrauch bzw. die Leistung des TWC automatisch nachzuregeln. Kurz nach 7:30 Uhr startet die Ladung automatisch und regelt dynamisch hoch, bis das Fahrzeug um ca 12:30 Uhr vollgeladen ist. Dabei wird etwas Reserve (grüne Spitzen) gelassen, glaube da hatte ich den “Überschusspuffer” auf 0,2kW gestellt. Der Netzbezug (rote Spitzen) lässt sich damit aber nicht immer verhindern, wenn bspw. doch mal ein Verbraucher mit höherer Leistung (E-Herd, Hauswasserwerk, etc.) anspringt. Hier würde dann nur ein zusätzlicher Haus-Akku helfen – vielleicht ja eines der überüberübernächsten Technik-Projekte…
Wenn du dir einen Tesla zulegen möchtest, kannst du gerne über meinen Affiliate-Link https://ts.la/jrg61387 ordern. Aktuell erhalten wir dann beide 1.500 km freies Supercharging (Tesla-Aktionen können sich ändern).
26 Kommentare
Schön, dass zur Zeit wieder mehr Blogs kommen! Wir planen grade unser neues Haus, da passt es grade recht!
Hi Marco,
nach zeitaufwändigen Projekten, wie das Solarcarport, habe ich nun endlich wieder mehr Zeit zum Bloggen. Du kannst dich also auf weitere Inhalte in kürzeren Abständen freuen.
Viele Grüße
Jörg
Nicht alle Autos kommen mit 6A zurecht. Insbesondere eine Zoë zickt damit gerne mal rum. Außerdem ist die Ladeeffizienz verbesserungswürdig. Besser mindestens 8 oder 10 einstellen.
Hi Matthias,
danke für deinen Hinweis!
Hab bislang meist eine Minimalleistung von 8A -> 1,8kW eingestellt. Sonst dauert der Ladevorgang einfach zu lange und währenddessen verbrädt die Karre auch gut 0,1kW für die eingebaute Elektronik, die “wach” ist. Aber unter Tag stehen durch die knapp 9kWp PV-Anlage eh meist mehr als 2kW für den Ladevorgang zur Vefügung.
Bei 10A soll die Ladeelektronik ja anscheinend den besten Wirkungsgrad haben. Werde ich demnächst auch mal die verschiedenen Settings zwischen 6 und 16A durchtesten. Die Leistungswerte vom TWC bekomme ich direkt vom KNX-Aktor, welche Leistung schlussendlich im Akku landet, zeigt die ScanMyTesla-App an, welche die Werte vom installierten OBD-Bluetooth-Adapter erhält. Bin schon gespannt…
Viele Grüße
Jörg
Hallo zusammen,
kann mir jemand hierbei helfen? Habe alle Schritte wie hier/ in der Anleitung des TWCManagers beschrieben installiert (über su – und nicht per sudo. Das sollte ja aber keinen Unterschied machen).
(Grundsystem: Distribution Raspbian – 10 (buster) Kernel 4.19.69-v7+, Ein Loxberry)
root@loxberry:~# python3 -m pip install sysv_ipc
Collecting sysv_ipc
Using cached sysv_ipc-1.0.1.tar.gz (102 kB)
ERROR: Command errored out with exit status 1:
command: /usr/bin/python3 -c ‘import sys, setuptools, tokenize; sys.argv[0] = ‘”‘”‘/tmp/pip-install-86ytf62h/sysv-ipc/setup.py'”‘”‘; __file__='”‘”‘/tmp/pip-install-86ytf62h/sysv-ipc/setup.py'”‘”‘;f=getattr(tokenize, ‘”‘”‘open'”‘”‘, open)(__file__);code=f.read().replace(‘”‘”‘\r\n'”‘”‘, ‘”‘”‘\n'”‘”‘);f.close();exec(compile(code, __file__, ‘”‘”‘exec'”‘”‘))’ egg_info –egg-base /tmp/pip-pip-egg-info-kcgtgw2h
cwd: /tmp/pip-install-86ytf62h/sysv-ipc/
Complete output (3 lines):
Traceback (most recent call last):
File “”, line 1, in
ModuleNotFoundError: No module named ‘setuptools’
—————————————-
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.
Hi Niko,
bin mir nicht ganz sicher, denke aber, dass bei Loxberry schon einiges “verbogen” ist im Hintergrund, was man als Anwender gar nicht mitbekommt. Habe auch schon einige Male versucht außerhalb der Loxberry-Plugins Dinge nachzuinstallieren, ebenfalls ohne Erfolg…
Grüße
Jörg
Hallo Jörg,
Danke für deinen Input. Ich habe es am Wochenende auf einem separaten Pi Zero installiert. Das hat nach meiner ersten Ansicht auch funktioniert (Rückmeldung um 12:30:27 im log), jedoch klappt die RS485 Kommunikation glaube ich nicht korrekt. Der TWC wird gefunden aber nach knapp 30 sek. killt es die Verbindung wieder – time out oder was anderes, so dass ich ein grünes dauerleuchten oben und ein viermal rot in der Mitte habe.
Parallel per SSH sehe ich folgendes:
12:30:09: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:13: Web query: ‘b’getStatus”, id 44674, time 1601814613, type 2
12:30:17: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:17: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:17: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:18: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:23: Web query: ‘b’getStatus”, id 2932, time 1601814623, type 2
12:30:26: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:27: SHB 1896: 09 00.00/06.00A 0000 0000 M: 00 00.00/00.00A 0000 0000
12:30:33: Web query: ‘b’getStatus”, id 4362, time 1601814633, type 2
12:30:35: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:43: Web query: ‘b’getStatus”, id 11246, time 1601814643, type 2
12:30:43: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:51: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:53: Web query: ‘b’getStatus”, id 49730, time 1601814653, type 2
12:30:59: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:30:59: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:31:00: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:31:00: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
12:31:02: Web query: ‘b’getStatus”, id 18413, time 1601814662, type 2
12:31:08: 32.00 amp slave TWC 1896 is ready to link. Sign: 55
Habt ihr eine Idee woran das liegen könnte? Ich habe wie hier installiert/ den gleichen USB Adapter verwendet. Nutze ein CAT6 Netzwerkkabel. Um hier ein Thema auszuschließen habe ich es auch mit einem 20cm CAT6 ausprobiert. Ich nutze keine Abschlusswiderstände oder ähnliches (direkt angeschlossen).
Grüße und Danke
Niko
Hey cool, sehr interessant das mal alles zu sehen.
Danke für den Einblick!
Super Anleitung ! Vielen Dank.
Ein Hinweis:
Bitte den Befehl
sudo apt-get updat && sudo apt-get install -y lighttpd && sudo apt-get install -y php7.3-cgi && sudo lighty-enable-mod fastcgi-php && sudo service lighttpd force-reload && sudo chown -R www-data:www-data /var/www/html && sudo chmod -R 775 /var/www/html && sudo usermod -a -G www-data pi
in
sudo apt-get update && sudo apt-get install -y lighttpd && sudo apt-get install -y php7.3-cgi && sudo lighty-enable-mod fastcgi-php && sudo service lighttpd force-reload && sudo chown -R www-data:www-data /var/www/html && sudo chmod -R 775 /var/www/html && sudo usermod -a -G www-data pi
korrigieren 😉
Du hast versehentlich anstatt update, updat geschrieben.
Viele Grüße
Marco
Hi Marco,
vielen Dank für den Hinweis! Ist erledigt.
Grüße
Jörg
Super Sache
Ich habe zwei Tesla Wallboxen der Gen3. Wäre das auch mit diesen möglich. Meine Idee wäre einen Shelly 3EM zu verwenden der einen Schütz steuert der die Wallbox an und ausschaltet. Eine Dynamische Steuerung wäre damit nicht möglich. Ideen für für Überschussladen mit der Gen3 Wallbox sind willkommen.
LG
Peter
Hi Peter,
TWCManager läuft nur in Kombination mit dem Tesla Wallconnector Gen2. Die neue Gen3 besitzt keine ansteuerbare RS485 mehr. Vermutlich wird es aber bald möglich sein diese per WLan anzusprechen – da muss man einfach mal die nächsten Softwareupdates durch Tesla abwarten.
Viele Grüße
Jörg
Hi Peter,
hast du damit schon Erfolg?
Also die Gen3 mit einem Schütz zu steuern?
lg,
Stefan
Laut TWC Release Notes funktioniert mit der aktuellen Version auch die Gen 3 Wallboxen
Wär ja mega… Aber welches Repo meinst du genau? Hier finde ich z.B. nichts davon: https://github.com/dracoventions/TWCManager
“We don’t expect to add support for gen 3 TWCs unless their wireless protocol is reverse engineered by a third party.”
Bei “ngardiner” (mein aktueller Favorit) leider auch nichts… -> https://github.com/ngardiner/TWCManager
Viele Grüße
Jörg
Hallo,
gibts schon Erkenntnisse zur Verwendung mit dem TWC gen 3?
Ich würde das auch gerne nutzen.
lg
Jürgen
Nope…
Hi Jörg,
super Blog. danke dir für deine Arbeit 🙂
Bin auch sehr an dem Thema interessiert.
Da ich neu im “Tesla-Wallbox-Game” bin: Kann man aus der Erfahrung aus der Vergangenheit sagen, ob Tesla generell “feature-update-freudig” ist und wir ein Softwareupdate für die Überschussladungsmöglichkeiten erwarten können?
beste Grüße,
Stefan
Für den Wallconnector v3 ziemlich sicher ja. Insgesamt ist es eben so, dass Tesla als Hauptmarkt die USA bedient – da sind solche Themen glaub noch nicht so breit in der Masse angekommen… Aber das wird sich auch Stück für Stück ändern.
Viele Grüße
Jörg
Loxone spricht ja auch RS485.
Kann man nicht eine direktere Kommunikation hinbekommen, ohne den Raspberry PI aber mit dem RS485 Adapter von Loxone? Ich versuche zusätzliche Komponenten (wie Raspberry PI) zu minimieren, weil die ja auch alle einen Ruhestromverbrauch haben…
Hi Stefan,
nope, das klappt nicht.
Nen alter RPI2/3 braucht vielleicht 2-3W. Ne extra Loxone-Extension dafür bräuchte vermutlich auch mind. 1W… aber wie gesagt – klappt so nicht.
Viele Grüße
Jörg
Hi Jörg,
Kann man bei der Version von “ngardiner” auch mit Loxone die Ladeleistung regeln ?
lg
Stefan
Hi Stefan!
Logo, ist einfach ein HTTP-Request, bei dem du einen Parameter (nonScheduledAmpsMax) mitgibst, der eben die gewünschte Ladestromstärke in Ampere festlegt. Genau so, wie im Blogpost beschrieben. Also z.B. für 7 Ampere: http://192.168.3.33/index.php?nonScheduledAmpsMax=7&submit=Save
Viele Grüße
Jörg
Ich würde den TWCManager gerne zweckentfremden. Es ist bereits 2x vorgekommen, dass sich jemand in meiner Anwesenheit meines TWC gen2 bedient und sein eAuto lädt. Mit TWCManager möchte ich erreichen, dass der TWC die Ladung nur bei meinem Auto startet. Ist dies über RS-485 irgendwie realisierbar ? Eine Hardwarelösung via RFID wüsste wüßte ich nicht anzuschließen.
Hi Rouven,
sollte mit TWCManager und einem per RS485 angeschlossenen Tesla Wallconnector funktionieren, jup.
Einfach die Einstellungen anpassen, dass beim Einstecken nicht sofort losgeladen wird und die vom Wallconnector erkannte Tesla-Seriennummer des gewünschten Fahrzeugs als bekannt hinterlegen.
Einzige Voraussetzung ist eben, dass der TWC die Fahrzeugerkennung unterstützt – das können manche TWC, manche nicht. So richtig herausgefunden habe ich auch noch nicht, wie man das ohne “Ausprobieren” herausfinden kann…
Viele Grüße
Jörg
Moin Jörg,
eine Frage, brauchtest du den RS485 (Modbus) nicht mit einem Widerstand terminieren?