Und kannst du den link da drin auch testen, dann sollte er eine Datei runterladen. Zeile 6.
Guten Morgen, habe den Fehler gefunden.
Es lag am Pihole 
Danke für die Hilfe 
Gruß Thomas
Wie kann ich möglichst einfach und kostenlos Zugriff auf eine private Docker Registry bekommen? Also Zugriff nur mit Logindaten. Nichts selber hosten, sondern Cloud.
Google Cloud?
Der reboot des PI hat die Probleme gelöst! Jetzt läufts auch bei mir sauber. Danke @Mane123 kleines Dankeschön geht auch gleich noch per Paypal raus.
Nachdem letzte Woche Montag die PV angeschlossen worden ist, wollte ich natürlich zeitnah eine PV-Überschuss Lösung eingerichtet haben.
Für mich war allerdings nur eine lokale Lösung ohne Cloud Anbieter / Abo o.ä. die richtige Wahl.
Mit dem Tesla Solar Charger ist dies die bekannte Lösung für mich, ohne dass ich mich z.B. intensiv mit Node Red o.ä. auseinandersetzten musste, da mir dies so gar nicht liegt.
Meine Settings möchte ich Euch gerne hier posten, damit es die Mitglieder mit ähnlicher Hardware einfacher haben.
Peak: 11,86 kWp
WR: Fronius symo Gen 24 10 plus + SmartMeter 65A
Storage: BYD 10kW
Synology NAS - Docker
Bitte entsprechend Eure IP stattdessen eintragen. Im Fronius WR muss noch API aktiviert werden. Dazu als Customer anmelden und unter Kommunikation / Solar API aktivieren. Ja, ModBus ist sicherlich besser, aber dazu wird das Techniker PW benötigt, was ich mir erst holen muss bzw. gar nicht weiß, ob ich das überhaupt bekomme.
Eingebundene Funktionen/Stati:
SmartMeter Daten:
BYD Homestorage Werte:
Inverter Leistung:
Bei Fragen könnt Ihr Euch gerne melden.
@Mane123 Patrick, ich danke Dir vielmals für Deine Mühe und Zeit dafür. Die Spende ging soeben raus!
Nachtrag für die Tippfaulen: 
Grid:
http://192.168.178.61/solar_api/v1/GetMeterRealtimeData.cgi?Scope=Device&DeviceId=0&DataCollection=MeterRealtimeData
$.Body.Data.PowerReal_P_Sum
Battery:
http://192.168.178.61/solar_api/v1/GetPowerFlowRealtimeData.fcgi
$.Body.Data.Inverters.1.SOC
http://192.168.178.61/solar_api/v1/GetPowerFlowRealtimeData.fcgi
$.Body.Data.Site.P_Akku
Inverter:
http://192.168.178.61/solar_api/v1/GetPowerFlowRealtimeData.fcgi
$.Body.Data.Site.P_PV
Tipp, schreib das nochmal auf GitHub in Englisch und du hilfst auch dem internationalen Publikum
Schiebs durch deepL, geht schneller…
Hab ich mir gerade so ähnlich auch auf meinem neuen Symo Gen24 8 Plus eingerichtet.
Frage: Woher weiß TSC dass geladen werden kann? Bleibt ja eigentlich nur die Grid Power Info wenn intern nicht gemessen wird…?!
Eine Frage habe ich noch: Wie kann es sein, dass nach 1 Tag bereits die Meldung kommt, dass das Tesla Token expired ist und aktualisiert werden muss?
Ja, die Info kommt vom Gridpower bzw. Smart Meter, weil da der Hausverbrauch und PV Ertrag erfasst wird. Beim Token bin ich mir nicht sicher. Ich habe über die Webseite in der Basic Konfiguration den Token angefragt und zugelassen. Damit ist eigentlich der Zugang zum Auto gesichert.
@FFF Jupp, hatte ich direkt mit Deepl gemacht und hoch geladen. 
Ich habe den Token genau so erstellt. Standard TSC yml. Als ich vorhin nach Hause kam war der Token expired. Mal schauen was die Kiste morgen sagt. Heute kam in Berlin ohnehin nicht genug vom Dach. Wird Zeit das der Wattpilot kommt.
Mehrere Möglichkeiten:
- Zu alte Version, Tesla hat da Mitte Februar was geändert, das habe ich erst in 2.24.7 korrigiert
- Backup zurückgespielt
- Mehrere Instanzen mit gleichem Token am Laufen. (wenn du bei jeder Instanz separat dein Passwort eingegeben hast - kein Problem, wenn du aber den Token aus der Datenbank direkt rüber kopierst → Problem)
Hintergrund des Fehlers: Alle 8 Stunden läuft der Token ab und wird neu geholt, bis Mitte Februar war das unendlich oft möglich. Mittlerweile wird aber der Token invalide, sobald er einmal erneuert wurde => Du machst ein Backup und lässt aber die bestehende Instanz weiterlaufen => Es wird refresht => der Token im Backup ist expired => Du spielst ein Backup zurück => Der invalide Token ist im TSC. Das Problem fällt aber erst auf, wenn das Auto das erste Mal gesteuert werden soll und die 8 Stunden rum sind.
Wenn alles funktioniert, expired der Token nie.
Nabend, danke für die Erklärung. Eigentlich kann da nur Variante 3 in Frage kommen.
- gestern Erstinstallation auf PC 1 bei mir (schließe ich daher aus)
- siehe 1. (daher auch auszuschließen)
- gestern Erstinstallation von TSC auf PC 1 lief nicht gleich alles. Token wurde per App (s. Github) angefragt und dann in TSC über das Tesla Konto bestätigt (aber nicht mit allen nötigen Rechten glaube ich)
Da 3. gestern wegen der nicht kompletten Token Rechte nicht ordentlich lief habe ich heute eine 2. TSC Instanz auf meinem Windows Server (Windows 11 Pro) installiert. Token neu beantragt per App und in TSC per Tesla Konto bestätigt. Da kommen die 2 Instanzen ins Spiel. Die Instanz von gestern lief seitdem nicht mehr bewusst, wohl aber der PC (kann sein, dass Docker im Hintergrund lief ohne das ich Docker for Windows Desktop aktiv hatte). Ich habe nun aber den Zugriff für TSC im Tesla Konto entzogen und einmal komplett neu auf der Server Instanz beantragt (morgens). Dennoch bekam ich heute Nachmittag die Expire Fehlermeldung und ich musste erneut per Tesla Konto bestätigen. Der PC von gestern war bei der Expire Fehlermeldung heute Nachmittag nicht mehr an. Wenn ich morgen wieder die Fehlermeldung erhalte, würde ich nochmal Bescheid geben. Stand jetzt zeigt TSC aber keine Fehler an.
Nach einigem Kampf (lag an mir und meinem Unvermögen mit Docker und Postgres) habe ich geschafft, die Daten (Datums) von meinem PI, auf dem eine alte Instanz lief und den ich zwischenzeitlich produktiv nutzte, wieder auf das NAS zu spielen. Es läuft nun wieder, allerdings hat es beim Ladeprotokoll die Daten weggehauen. Ist nicht schlimm, aber gibt es irgend einen Weg, das wieder zu beheben? Zugriff auf beide DBs hätte ich. Oder hätte ich für TSC auch Backup und Restore durchführen müssen? Es funktionierte einfach mit der neuen alten DB.
Das Datum und Uhrzeit aus der Tabelle zieht der TSC beim Anzeigen der Seite live aus der Tesla Mate Datenbank. Und ich kann dir jetzt schon die traurige Nachricht übermitteln, dass die Daten, die er aus TeslaMate nicht holen kann, in der nächsten Version weg sein werden.
Edit: Falls du noch weiter kämpfen willst. Im TSC wenn du ein Backup machst, hast du eine SQLite Datenbank, in der gibt es „handled Charges“ als Tabelle, da drin eine Spalte ChargingProcessId. Das ist die ChargingProcessId aus der TeslaMate Datenbank.
Heute Abend von meiner Seite eine Erfolgsmeldung. Ganz kurz war heute früh beim Seite aufrufen der Tokenfehler zu sehen, der sich dann aber in Luft auflöste. Heute tagsüber wurden die ersten jungfräulichen 25kwh ins Auto per Überschuss geladen. Vielen Dank für die tolle Lösung!
Es scheint vor 5 Std der Command Proxy bei mir abgeschmiert zu sein, also alle Autos, die den bereits fordern, konnten die letzten 5 Std. nicht gesteuert werden… Warum er abgestürzt ist - keine Ahnung, gab keine Fehlermeldung und auch sonst nichts. Aber waren die ersten 5 Std seit Einführung, also noch >99% uptime
Ja hier gab es einen Fehler.
Trotz 0W PV Erzeugung hat der Tesla 4kW gezogen.
Ah, hatte mich gerade gewundert, warum er so lange geladen hat obwohl kein PV Strom mehr da war.
Ich wusste gar nicht, dass man mit dem TSC noch „von einem externen Drittsystem abhängig“ ist, ich dachte, das läuft alles zwischen dem Tesla und dem TSC (der wiederum mit Teslamate spricht).