MatzeTF

Und dann? Hinter dem kaputten Modell kommt nichts sinnvolles mehr; du verpasst also nichts. Der einzige „Power“-Wert, den dein Wechselrichter über SunSpec liefert, ist leider nicht der Netzbezug, sondern die AC-Leistung deines Hybrid-WR.

Das steht auf unserer ToDo-Liste, aber nicht weit oben weil es aufgrund der Komplexität der möglichen Einstellungen recht umfangreich ist und deswegen nichts für den Durchschnittsnutzer ist. Pro Wert hast du Registertyp, Registeradresse, Datentyp, Endianness, Skalierungsfaktor und Wert für „Wert nicht verfügbar“. Der Skalierungsfaktor kann dabei entweder fix sein oder in einem anderen Register stehen. In letzterem Fall hast du nochmal Registertyp, Registeradresse, Datentyp und Endianness. 🤢 Wer bereit ist, sich da durchzukämpfen, kann sich hoffentlich auch ein Konvertierungstool in Python oder so hacken, um die Werte damit auszulesen und unsere zu API füttern.

Da spricht nichts gegen, das sollte funktionieren.

Modbus darf nie ein Stern sein sondern nur ein Bus. Es heißt ja auch Modbus und nicht Modstern. 😜 Der Master muss aber nicht an einem Ende sitzen sondern darf auch in der Mitte sitzen. Beide Enden müssen Terminiert werden, aber nie in der Mitte. Die 32 Geräte kommen daher, dass jedes Gerät einen gewissen Unit Load verursacht. Schau dir mal dieses Dokument dazu an. Ein Driver muss 32 Unit Loads und 2x Terminierung unterstützen. Ein Receiver ist standardmäßig 1 Unit Load. Moderne RS485-Transceiver haben aber einen Unit Load von 0.5 oder 0.25, sodass du 64 oder sogar 128 Geräte an einen Bus hängen kannst. Wahrscheinlich ist der Unit Load aber nicht im Datasheet deiner Servos angegeben. Probier es einfach aus. In gewissem Rahmen ist die Anzahl der Slaves abhängig von Kabellänge oder Kabelqualität. Ist das Kabel zu lang oder der Querschnitt zu gering, ist der Widerstand zu hoch und es kommt am Ende kein ausreichend starkes Signal mehr an. Ich glaube, dazu gibt es auch Tabellen mit Richtwerten, aber dazu habe ich gerade nichts. Such mal nach RS485 statt Modbus, dann solltest du da mehr finden. CAT6 ist overkill. Für Modbus brauchst du keine Schirmung. Der Widerstand pro Meter ist da wahrscheinlich interessanter. CAT5 geschirmt oder ungeschirmt ist genauso gut. Ich würde das mit dem größeren Aderquerschnitt bzw. der kleineren AWG-Angabe nehmen.

Wir haben zum Testen ein KOSTAL KSEM G2 benutzt. Das ist nicht gerade günstig und ob es besonders gut ist, weiß ich auch nicht, aber es funktioniert einfach.

photron hat schon ausführlich geantwortet, aber da ich auch schon angefangen hatte, etwas zu schreiben, hier noch ein paar direkte Antworten auf deine Fragen. Ich glaube, das ist das Gleiche. Die englischen SunSpec-Dokumente nennen die Blöcke in den Modellen „Module“. Ich vermute, dass dein Wechselrichter zwei DC-Eingänge hat und deswegen zwei Module dafür vorgesehen sind. Die anderen vier sollten dann nicht da sein, sind es aber trotzdem. Nein, Model 122 ist nicht das Problem. Das wird korrekt erkannt, enthält aber keine Informationen, die wir aktuell auswerten. Deswegen wird das als nicht unterstützt angezeigt. Über 64000 liegen herstellerspezifische Modelle. 64870-64879 ist für SMA reserviert. Das ist okay und wird auch korrekt erkannt und übersprungen, weil wir nichts damit anfangen können.

Leider gibt es noch keinen Termin. Mit zwei unabhängigen Wallboxen mit zwei Energy Managern könnte das für dich aber schwierig werden, da du für dynamisches Lastmanagement ein zentrales Managementgerät brauchst. Wenn du auf beiden Energy Managern unabhängig voneinander dynamisches Lastmanagement laufen lässt, werden sie gegeneinander arbeiten. Würde es bei deinem Anschluss ausreichen, eine Wallbox dynamisch zu managen, die dann ggf. die Ladung ganz unterbrechen würde?

Aktuell lässt sich die SunSpec Block-Chain einfach nicht bis zum End Model parsen, da man vor erreichen des Endes einen „Illegal Address“ Fehler bekommt. Praktisch jeder SunSpec-Parser sollte darüber stolpern. Das ist ein so grundlegender Fehler, dass da bei den SMA-Entwicklern jemand gepennt haben muss. Wie man das am besten am First Level Support vorbei bekommt, kann ich dir leider nicht sagen. Ich hatte schon überlegt, ob du einfach darauf verweist, dass die Information aus der Entwicklungsabteilung deines Wallboxherstellers stammt und die Aussage ist, dass das nur von dem SMA-Entwicklern repariert werden kann. Es kann dann natürlich auch sein, dass sie dir nicht mehr helfen wollen, weil du eine Wallbox benutzt, die nicht von SMA ist. 😉

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. 😉