MatzeTF

Wir können nur das nutzen, was das SunSpec-Gerät anbietet. Aktuell bietet der Wechselrichter nur die 100er-Modelle und keine 700er-Modelle an. Dementsprechend haben wir da gar keine Wahl. Das Model 160 kann mehrere Module enthalten und enthält dafür auch eine Angabe, wie viele Module es enthält. Das Problem ist nun, dass die Angabe für die Module auf 2 steht, anschließend aber die Daten für 6 Module folgen. Die Blocklänge von 48 passt auch zu zwei Modulen. 8 für den Header plus 2 x 20 für die Module. Korrekt wäre jedoch eine Blocklänge von 128. Alternativ sollte halt nach den zwei Modulen Schluss sein und nicht noch Daten für vier weitere Module folgen. Das ist aktuell einfach kaputt.

Da nur zwei Signal Kabel bei den Netzwerkkabel angeschlossen sind, gehe ich davon aus, dass der Servodrive über Half-Duplex kommuniziert? Korrekt. Der Parameter "Word Lenght" wird nicht spezifisch im Datenblatt des Servodrives erwähnt. Ist da "8" ein gängiger Wert oder wie findet man da raus was für ein Wert verwendet werden soll? 8 ist der Standardwert und is gibt kaum eine Anwendung, die etwas anderes verwendet. Falls doch, ist das eigentlich immer angegeben. In diesem Fall sollte "First Input Number" 302833 bzw. 302832 oder 302834 betragen? Wenn ich mir das Datasheet so ansehe, bezweifele ich eher, dass es sich tatsächlich um Input Register handelt. In der Doku ist bei 9.2.1 Code 0x06 angegeben, aber das ist ein Schreibzugriff, der korrekt bei 9.2.2 angegeben ist. Ich vermute daher, dass es Holding Register sind. Dementsprechend muss First Register Number 402833 bzw. 402832 oder 402834 sein. Wie find ich raus was für einen Wert bei "Number of Inputs" eingetragen werden soll? Register sind immer zwei Bytes groß. Bei Number of Inputs muss also eine 1 eingetragen werden. Leider ist das bei dem Gerät von Register zu Register unterschiedlich. P05-35 hat einen Wertebereich von 0~65535 und ist somit ein uint16, der in ein Register passt. P05-04 hat einen Wertebereich von 0~6553.5 und ist somit eine uint16 Festkommazahl, die in ein Register passt. P05-05 hat einen Wertebereich von -9999~9999 und ist wahrscheinlich ein int16, der in ein Register passt. P05-07 hat einen Wertebereich von 1~1073741824, was nicht in ein Register passt und wahrscheinlich ein uint32 ist, der zwei Register belegt, nämlich P05-07 und P05-08, was nicht in der Tabelle steht. Da musst du also 2 als Number of Inputs angeben. Muss ich mich um CRC check Werte kümmern? Oder ist das etwas was das Bricklet automatisch macht? Musst du nicht, das macht das Bricklet automatisch.

Einige Wechselrichter, insbesondere die von SMA, machen das leider so, dass sie bei Dunkelheit im Standby keine Werte anzeigen. Anfangs hatten wir SunSpec so implementiert, dass nach vorhandenen Werten gesucht wurde. Wenn man den Scan dann nachts laufen lassen hat, wurde immer ein Wechselrichter ohne Werte gefunden, und man musste den Scan tagsüber laufen lassen. Das ist jetzt kein Problem mehr und verschwindende und wieder auftauchende Werte werten unterstützt. Bei manchen SMA-Wechselrichtern werden werden aufgrund falscher Daten nicht alle Werte erkannt, das stimmt. Ansonsten kennen wir als SMA-Quirk bisher nur, dass die Phasenströme von Wechselrichtern immer mit Vorzeichen angegeben werden, obwohl sie laut SunSpec-Standard vorzeichenlos sein sollten. Dafür haben wir aber einen Workaround implementiert.

Leider liefert der Wechselrichter auch im Kompatibilitätsmodus die gleichen kaputten Daten. Er behauptet, Daten für zwei MPP-Tracker zu haben, liefert dann aber Daten für sechs. Ich vermute mal, dass du nur zwei Strings an deinem WR angeschlossen hast. Danke, du kannst die Portweiterleitung jetzt wieder deaktivieren.

Zu deinem Wechselrichter: Die Geräteerkennung bricht ab, weil der Wechselrichter an einer Stelle falsche Daten liefert. SunSpec-Daten sind eine Kette von Blöcken und jeden Block gibt an, wie lang er ist. Bei einem Block wird nun eine zu kurze Länge gemeldet, sodass wir den Anfang des nächsten Blockes mitten in den Daten des vorigen Blockes suchen, was natürlich nicht funktioniert. Da es keine Möglichkeit gibt, die tatsächliche Länge des Blockes herauszufinden, ist das an der Stelle auch nicht zu retten. Für dich macht das allerdings keinen Unterschied, da ich händisch an den Mustern in den Daten erkennen kann, dass nach dem kaputten Block keine weiteren Blöcke mehr kommen. Das bedeutet allerdings auch, dass du den tatsächlichen Netzbezug nicht über SunSpec auslesen kannst. 😒 Gibt es im Webinterface deines Wechselrichters irgendwelche Einstellmöglichkeiten hinsichtlich SunSpec? Falls nicht, kannst du die Portweiterleitung wieder deaktivieren, da wir dann sowieso nichts anderes aus dem Gerät herausbekommen.

Aktuell kann man mit dem zweiten Zähler noch nichts machen, außer die Werte ansehen, da PV-Überschussladen für die Wallboxen noch nicht fertig ist. Es motiviert aber Nutzer, es auszuprobieren, und wir bekommen Feedback zu SunSpec, was sich bei der vor einiger Zeit veröffentlichten SunSpec Beta Firmware doch sehr in Grenzen hielt. SunSpec ist eigentlich ein Standard, allerdings hält sich praktisch kein Hersteller komplett an den Standard, sodass wir auf Nutzerfeedback angewiesen sind, um herauszufinden, welcher Hersteller an welcher Stelle eine Extrawurst braucht.

Laut Log bricht die Erkennung wegen einer unerwarteten Antwort vom Wechselrichter ab. Es ist möglich, dass es noch weitere Modelle gibt, die dir den Netzbezug liefern könnten. Kannst du uns eine Portweiterleitung einrichten, damit wir uns die SunSpec-Antwort von deinem Wechselrichter genauer ansehen können? Falls ja, leite einfach irgendeinen TCP-Port über 10000 auf Port 502 deines Wechselrichters weiter. Wenn du DynDNS hast, wäre das super, ansonsten kannst du deine IP des Tages per PM an mich schicken oder ich schaue nach, von welcher IP dein letzter Post gesendet wurde. 😉

Wir arbeiten gerade daran, PV-Überschussladen als Feature in die Wallboxen zu integrieren. Um das nutzen zu können, brauchst du einen zweiten Zähler, der den Netzbezug am Hausanschluss misst. Viele Wechselrichter stellen diese Information über SunSpec zur Verfügung, weshalb wir die Wallboxen bereits SunSpec-kompatibel gemacht haben. Wer den Netzbezug auf andere Art misst, kann sich als zweiten Zähler einen API-Zähler einrichten und die Werte über eine eigene Anwendung in die Wallbox schieben. Die Werte deines Wechselrichters sind negativ, weil es sich dabei um PV-Produktion bzw. Energieabgabe aus dem Speicher handelt. Der Wert ist offensichtlich nicht der Netzbezug bzw. -einspeisung am Hausanschluss. Ich interpretiere die Grafik so, dass du ab 8 Uhr morgens etwas Sonne hattest und bis kurz nach dem Mittag ein paar Mal viel Strom gebraucht hast und sonst der Speicher geladen wurde, der gegen 13 Uhr voll war und den Stromverbrauch deines Hauses bis ca. 23 Uhr gedeckt hat. Wechselrichter, die den Netzbezug messen können, stellen dafür üblicherweise ein zweites Gerät per SunSpec zur Verfügung. Kannst du die SunSpec-Gerätesuche nochmal laufen lassen und das Log hier posten?

Es gibt leider keine Möglichkeit, die Batteriespannung aus der Ferne auszulesen. Wenn man nur den Stromverbrauch vom RTC Bricklet beachtet, liegt die theoretische maximal Batterielebensdauer bei ca. 2 Jahren. Dabei ist es unerheblich, ob der RPi läuft oder nicht. Das Problem ist, dass die Batterie auch ohne Verbraucher altert und die zwei Jahre nicht erreichen wird. Dazu kommt, dass die Batterie wahrscheinlich vor dem Versand schon ein paar Monate im Regal lag. Wenn da einiges unglücklich zusammenkommt, kann es passieren, dass sie schon nach einem halben Jahr leer ist. Ich habe gerade mal ein RTC Bricklet mit eingesetzter Batterie aus der Schublade gekramt und da war nach ca. einem Jahr auch die Batterie leer. Die Batteriespannung beträgt da aktuell noch 0,3 V. Wahrscheinlich hatte das Bricklet die Uhrzeit also schon vor längerer Zeit vergessen. Die gute Nachricht ist, dass du mit etwas Bastelei eine fast beliebige andere Batterie oder auch einen Akku oder Supercap anschließen kannst. Letztere müsstest du allerdings selbst nachladen. Der verwendete IC akzeptiert laut Datenblatt alles von 0.9 bis 5 V. Du könntest dir z.B. einen Adapter für AA Batterien basteln und dann für besonders lange Haltbarkeit eine AA Batterie auf Lithium-Basis nehmen. Ich nehme für sowas die Energizer Ultimate Lithium (#notsponsored). Bei dem geringen Verbrauch des RTC Bricklet dürfte die Batterie somit nur durch ihre Lager-Lebensdauer von 20 Jahren begrenzt sein. Ansonsten tut’s natürlich auch jede andere „dickere“ Knopfzelle, wobei ich wahrscheinlich bei ca. 1,55 V Zellenspannung bleiben und keine CR2032 nehmen würde.

Ja, das Beispiel geht davon aus, dass du die Bricklets über einen Master Brick an den PC anschließt, auf dem tinkerforge_mqtt läuft. Die Verwendung eines ESP32 Bricks wird da in der Tat nicht berücksichtigt.

Da dein erster Post schon von letztem Jahr ist, bin ich mir gerade nicht ganz sicher, in welchem Zustand sich dein Setup gerade befindet. Wenn du diese Fehlermeldungen im Ereignis-Log des ESP32 Brick hast, dann hast du das MQTT-Modul mit in die Firmware kompiliert? Das korrekte Setup sollte so aussehen: Auf dem ESP32 Brick läuft die Standardfirmware. Auf der VM mit dem MQTT-Broker läuft kein Brick Daemon. Dem tinkerforge_mqtt Script musst du außer den Zugangsdaten für den MQTT-Server noch mittels --ipcon-host die Adresse des Gerätes mit den Bricklets angeben. In deinem Fall ist das die Adresse vom ESP32 Brick. Aktuell verbindet sich das tinkerforge_mqtt Script mit dem Brick Daemon der VM, aber an der VM sind gar keine Bricks oder Bricklets angeschlossen. Dementsprechend wird da nichts gefunden. Wenn du versuchst, MQTT-Nachrichten direkt an den ESP32 Brick zu schicken, versteht der die nicht, weil er keine automatische Übersetzung für die angeschlossen Bricklets durchführen kann.

Ja, mach mal bitte einen neuen Thread auf. Poste da dann nicht nur das Log vom Scan, sondern auch ein Debug-Log, das du am besten direkt nach dem Schließen den Scan-Fensters runterlädst. Es würde uns auch sehr helfen, wenn du uns eine Portweiterleitung auf dein Smart Meter einrichtest und wir damit testen können. Falls das okay für dich ist, nimm einfach irgeindenen TCP Port über 10000 und leite ihn auf Port 502 deines Smart Meter weiter. Wenn du DynDNS hast, wäre das super, ansonsten kannst du deine IP des Tages per PM an mich schicken oder ich schaue nach, von welcher IP dein letzter Post gesendet wurde. 😉

Bekommst du da mit der WARP sinnvolle Werte raus? Viele Hersteller haben eine sehr eigene Interpretation von Sunspec und wir hatten noch kein elgris-Gerät zum Testen. Falls zumindest der Leistungswert für den Netzbezug richtig ausgelesen wird, kannst du damit voraussichtlich ohne evcc direkt PV-Überschussladen nutzen, wenn wir die Integration für WARP 1, 2 und 3 fertig haben.

„Connection reset by peer“ bedeutet, dass die Wallbox versucht, eine Verbindung aufzubauen, die dann von der Gegenstelle abgelehnt wird. Entweder ist in der Wallbox nicht die richtige Adresse vom MQTT-Server eingetragen, oder der Server lehnt die Verbindung ab weil der MQTT-Daemon entweder auf dem falschen Interface läuft oder eine Firewall die Verbindung blockiert. Da du vermutlich mit Home Assistant und evcc zum MQTT-Server verbinden kannst, vermute ich, dass du einfach einen Tippfehler in der Adresse vom MQTT-Server in der Wallbox hast. Wir hatten auch schon mal das Problem, dass jemand die Adresse der Wallbox als MQTT-Server eingetragen hatte. Falls es das beiden nicht ist, lade doch mal hier ein Debug-Log von der Wallbox hoch.

Wenn der Hilfskontakt richtig eingerastet ist, bekommt man ihn meiner Erfahrung nach eigentlich nur mit Werkzeug oder roher Gewalt wieder los. Seltsam. Wir behalten das mal im Hinterkopf für den Fall, das sich noch jemand anderes mit mysteriösen Schützfehlern bei uns meldet. Ansonsten freuen wir uns einfach darüber, dass bei dir jetzt wieder alles zu funktionieren scheint. 😀

Zwischen Schütz und Hilfskontakt sollte gar kein Luftspalt sein, im Sinne von < 0,5 mm. Bei korrekter Installation hängen die eigentlich auch sehr fest aneinander und wir hören jetzt zum ersten Mal davon, dass sie sich von alleine voneinander gelöst haben.

Dann hattest du vorher wahrscheinlich die Beta-Firmware installiert. Danach ist das zu erwarten. Da niemand in dem Beta-Thread geantwortet hat, hatten wir den Eindruck, dass niemand die Beta ausprobiert hat. 😉

Nein. Das Einzige, was du auf den Bricklets permanent schreiben kannst, ist die UID. Du könntest also dem immer vorhandenen IO-4 Bricklet eine UID nach einem festen Muster geben, z.B. Seriennummer + Typ * 1000. Die UIDs von Master Bricks kann man leider nicht ändern.

„Manuelle Ladefreigabe“ bedeutet, dass jemand im Webinterface auf „Start“ oder den Taster an der Wallbox drücken muss (sofern der so eingestellt ist, dass eine Ladung damit gestartet werden kann). Das ist also eine zusätzliche Freigabe, unabhängig von EVCC. Üblicherweise ist das nicht das, was du in Kombination mit EVCC haben willst, und du solltest es wieder ausschalten. Was du brauchst, ist die Externe Steuerung. Ist die aktiviert?

Mit der Option „Externen Steuerung“ funktioniert das nicht, da die nur den Ladestrom begrenzen kann. Schau dir mal die inject_tag API an. Damit kann man eine NFC-Karte vortäuschen, um einen Ladevorgang zu starten oder zu stoppen.

Es gab leider ein Speicherleck in der Firmware, das wir erst vor kurzen gefunden haben. Bei der WARP 1 wurde es dadurch wahrscheinlicher, dass sie wegen zu wenig Speicher abstürzt, und gerade MQTT ist ziemlich speicherhungrig. @mattsches müsste bei Gelegenheit auf den aktuellen Entwicklerstand aktualisieren.

Kurz zur Info: rtrbt ist aktuell krank. Dementsprechend dauert es leider noch etwas, bis er sich dein Log ansehen kann. Jetzt sollte aber alles notwendige drinstehen.

In dem Protokoll steht wieder nichts von dem drin, was wir brauchen. Nur nochmal zur Sicherheit: Start klicken Browser und Tab offen und sichtbar lassen Das Problem möglichst reproduzieren Stop klicken Du darfst zwischen Start und Stop auf keinen Fall Tab oder Browser schließen. Du solltest in der Zeit auch nicht zu einem anderen Tab oder einer anderen App wechseln oder das Display ausschalten bzw. zuklappen. Die Datei sollte anschließend deutlich größer als 60 kB sein.

V2L ist nicht netzsynchronisiert. Das sollte man besser nicht mit einer Steckdose im Haus verbinden. 😉

Bidirektionales Laden behalten wir im Auge, allerdings ist da im Moment außer viel heißer Luft nichts zu holen. Einige Fahrzeuge unterstützen bereits bidirektionales Laden per DC, allerdings braucht man dafür eine sehr teure DC-Wallbox. Ich bin mir gerade gar nicht sicher, ob es überhaupt schon bidirektionale DC-Wallboxen für Privatnutzer gibt. Es gibt AC-Wallboxen anderer Hersteller, die damit werben, bidirektionales Laden zu unterstützen, allerdings gibt es noch gar kein Fahrzeug, das bidirektionales Laden per AC unterstützt. Das Problem bei bidirektionalem Laden ist, dass es aus technischer Sicht Unsinn ist, da die Cobalt-basierten Lithium-Ionen-Akkus in Autos nicht für häufige Ladezyklen im stationären Einsatz geeignet sind. Wenn du ein Einfamilienhaus an ein Auto hängst, ist dein Akku schon nach wenigen Jahren auf unter 70 % SOH gesunken, was üblicherweise als Grenze angesehen wird, ab wann ein Tausch fällig wird. Die Fahrzeughersteller garantieren meist >100.000 km bis der Akku so weit verschlissen ist, aber wenn dein Auto nur zu Hause steht, machst du keinen einzigen Kilometer und könntest dann theoretisch alle paar Jahre einen neuen Akku vom Hersteller fordern. Da die Hersteller das verständlicherweise nicht wollen, ist die maximale Energieentnahme im V2G/V2H-Betrieb so weit begrenzt, dass sich das Fahrzeug bei regelmäßigem V2G/V2H-Einsatz z. B. schon nach zwei Jahren weigert, weiter Energie abzugeben, und das Ganze somit nur bedingt praktisch nutzbar ist. Im stationären Einsatz werden übrigens Lithium-Eisenphosphat-Akkus eingesetzt, die eine viel größere Anzahl Ladezyklen vertragen. Die haben allerdings nur die halbe Energiedichte, was egal ist, wenn du irgendwo im Keller einen großen Klotz hinstellen kannst, aber bei Autos bedeuten würde, dass sich die Reichweite halbieren würde.