photron

Im Rahmen der Integration des Victron GX als Zählerwertquelle, sind wir auch daran vorbeigekommen, dass man einen WARP Charger in die andere Richtung als Wallbox an Victron GX anbinden könnte. Dazu müsste man den Registersatz einer Victron Wallbox im WARP Charger implementieren. Ich habe das mal als Ticket hinterlegt, damit der Gedanke nicht verloren geht: https://github.com/Tinkerforge/esp32-firmware/issues/353

Issue zu 1.) https://github.com/Tinkerforge/esp32-firmware/issues/340

Füg mal bitte nach dem lcd_128x64_create Aufruf dies ein lcd_128x64_set_response_expected_all(&lcd, true); und lass das lcd_128x64_destroy weg, oder ruf es nach dem lcd_128x64_write_line auf.

Mich wundert eher, dass das nicht crashed mit lcd_128x64_destroy vor lcd_128x64_write_line. Das das so herum funktioniert ist eher Zufall. Dreh das mal bitte wieder um. lcd_128x64_write_line gibt einen int zurück. Gibt dir denn Wert mal bitte aus.

Es scheint das Unraid Server Docker Container ausführen kann. Getestet habe ich das aber nicht. Brick Daemon kann in einem Docker Container gebaut werden: https://github.com/Tinkerforge/brickd/tree/master/src/build_data/docker Das müsstest du dir aktuell selber bauen, das ist nicht auf Docker Hub verfügbar.

When you run brickd as user then it cannot access the GPIO pins with an EACCESS error. That is somewhat expected. There was a bug in the cleanup code for that case that resulted in a crash. This is fixed on Github now. You need to run brickd as root, but then it still cannot access the GPIO pins this time with an EBUSY error. This is unexpected. I can repoduce this problem with Ubuntu on an Raspberry Pi 5. But this is working fine with Raspberry Pi OS. So this must be an Ubuntu specific problem. I don't have the time right now to look into this Ubuntu specific problem. Maybe we could look at this next week. Sorry!

I cannot reproduce the "sudo apt --fix-broken install" here. Where did you find that you should install the dependencies (sudo apt-get install libusb-1.0-0 libudev1 procps) by hand? This is not neccessary. Also libudev1 is not required anymore. There where a few places left that still mentioned libudev1, I updated them now. Please try this brickd version, this should fix the GPIO problem. Edit: Attachment deleted. Brick Daemon 2.4.6 has been released. Please install the official release instead.

Nicht alle Autos können das. Zum Beispiel der Renault Zoe nicht.

Sehr gut! Das steht auf der TODO Liste.

Das "x5" soll dir sagen, dass du fünf uint32 (also 10 Register) von Adresse 4000 bis 4009 auslesen musst, um an die maximal 20 Byte zu kommen, die eine Tag ID lang sein kann. Die Dokumentation ist da verwirrend. Ich verbessere das gleich.

Ich hatte einen Dreher in den Device Type Konstanten. Jetzt sollte es funktionieren. warp3_firmware_2_3_0_6644692d_4934adb8f67548a_merged.bin

Die Art des Speichers wird jetzt am Device Type automatisch erkannt. Es ist nicht mehr notwendig das von Hand auszuwählen. Zusammenhängende Registerbereiche werden jetzt in einem Stück gelesen. Dadurch werden weniger Leseoperartion benötigt und die Timeouts sollten weniger werden, oder villeicht auch ganz verschwinden. warp3_firmware_2_3_0_66439481_59eb0ce0c4f72d0_merged.bin

Es wird nur eine Verbindung aufgebaut die sich dann alle vier Zähler teilen. Es werden aber dennoch mehr Daten ausgelesen. Ich habe da noch Ideen das zu verbessern. Zum Beispiel, werden aktuell alle Werte einzeln gelesen, auch wenn sie in den Registern hintereinander weg stehen und eigentlich meherer Werte in einem Rutsch gelesen werden könnten.

Danke, danach hatte ich gesucht. Die alte Version der Spezifikation kannte die Hochvolt-Varinante noch nicht. Wir haben hier eine neue Version gefunden. Dort steht auch der 10x Faktor für Spannung und Leistung der Hochvolt-Batterie drin: https://github.com/evcc-io/evcc/discussions/13460#discussioncomment-9138426

Vielleicht ist das den Timeout geschuldet, dass die Spannungen und Ströme etwas zeitlich versetzt gemessen sind und dadurch nicht exakt zusammenpassen.

Einmal zum Verständnis: Die Leistungsspalte ist die Leistung die in das jeweilige "Ding" rein (positiv) oder raus (negativ) geht. Nach diesen Zahlen müsste da gerade folgendes passieren: Die Wallbox tut nichts. In den Wechselrichter gehen gerade 161 W rein. Das ist eher komisch. Dieser Werte sollte das sein was gerade am AC Anschluss deines Wechselrichters passiert. Wenn der Speicher voll ist und der Wechselrichter gerade bei voller Sonne 10 kW produziert und ans Haus/Netz abgibt, dann sollte da -10.000 W stehen. Wenn der Speicher mit 1 kW lädt, bei 10 kW Sonne, dann gehen aus dem Wechselrichter noch 9 kW ans Haus/Netz, dann sollte da -9.000 W stehen. So ist dieser Wert gedacht. Der Energie­ein­speisung-Wert sollte das sein, was dein Wechselrichter gesamt an Energie abgegeben hat. Da lese ich aktuell Register 504 "Total Active Power Generation" für aus. Das hat aber wohl keinen sinnvollen Wert. Am Netzanschluss werden gerade 796 W an das Stromnetz abgegeben/verkauft. Es wurden 2.064,8 kWh aus dem Netz bezogen/gekauft und 2.826,7 kWh ans Netz abgegeben/verkauft. Der Speicher entlädt mit 15 W. Es wurden 2.070,8 kWh in den Speicher geladen und 2.047,4 kWh aus dem Speicher entladen. Die Last/das Haus verbraucht gerade 756 W und hat bisher 6.668,4 kWh verbraucht. So richtig passt das alles nicht zusammen. Ich könnte jetzt behaupten es ist in Wirklichkeit folgendes passiert: Der Wechselrichter nimmt nicht 161 W auf, sondern gibt 1.610 W ab. Dort müsste also -1.610 W stehen. Davon verbraucht das Haus 756 W und die restlichen 796 W werden ans Netz verkauft. Das würde dann auch besser zu diesen Zahlen passen. Kannst du mir deine Grafik erklären? Ich lese das so: PV produziert 1.820 W (14% der möglichen Gesamtleistung von 13 kW) Der Speicher ist 99% voll und entlädt mit 7 W. Das Haus verbraucht 796 W. 900 W werden an das Stromnetz verkauft. Für die Leistung des Wechselrichters lese ich Register 636 "Output Total Active Power" in W. Welchen Wert nimmt du dafür? Am Netzanschluss passen die Ströme nicht zu den Leistungen. Da muss ich auch noch mal schauen.

Danke für's Testen! Die Skaliserung ist nach Registertabelle und scheint bei @Jojo ja auch so zu passen. Ich kann keine andere Dokumention dazu finden. Also folge ich erstmal deiner Vermutung und füge eine zweite Variante des virtuellen Zählers für den Hochspannungs-Speicher hinzu. Ich kann in den Modbus-Registern keins finden, dass mir erlauben würde, automatisch zwischen Niederspannungs- und Hochspannungs-Speicher zu unterscheiden. Die Phasenspannungen habe ich erstmal rausgeworfen. Auch hier kann ich aus den Modbus-Registern nicht erkennen, ob das System mit oder ohne Neutralleiter angeschlossen ist und somit die Spannungen zu Neutral oder zwischen den Phasen misst. Ich gehe erstmal davon aus, dass der Neutralleiter angeschlossen ist. Das betrachten verschiedene Hersteller verscheiden. Wir haben uns darauf festgelegt, dass Export/Einspeisung/Entladen als negativer Wert und Import/Bezug/Laden als positiver Wert dargestellt werden. Ich habe das Vorzeichen für Strom und Leistung des Speichers gedreht. Die Dokumention von Deye schweigt sich darüber leider aus. Mir ist noch aufgefallen, dass bei euch beiden Spannung * Strom != Leistung ist. Deye liefert mehere Stromwerte und Leistungswerte für den Netzanschluss und aus der Dokumention ist nicht ganz klar was was ist. Ich denke ich hatte da die falschen Werte genommen. Ich nehme dafür jetzt die externen Werte. Könnt ihr beide bitte mit der angehängten Firmware testen. Dort habe ich jetzt die konfigurierbaren Zähler auf fünf erhöht, damit ihr alles gleichzeitg testen könnt. Schaut mal bitte, ob am Netzanschluss die Ströme und die Leistung passen. Für unsere Regelung müssen wir wissen wieviel Leitung insgesamt und wie viel Strom pro Phase am Netzanschluss bezogen (positiver Wert) oder eingespeist (negativ) wird. warp3_firmware_2_3_0_66422b7c_e4d0223eb453a78_merged.bin

Das Problem mit dem Einrichten des Zählers ist behoben und die Ausgabe auf dem Log explodiert auch nicht mehr. warp3_firmware_2_3_0_663b7a12_76d49de195228d9_merged.bin

Danke für's Testen. Das funktioniert besser als erwartet, dafür das ich das hier nicht getestet habe. Den Bug können wir nachstellen. Wir gehen dem nach. Stimmt, die -1000 fehlen. Das habe ich verbessert. Die große Menge an Meldung kommt daher das ich alles auslese und ausgebe. Das wird in der fertigen Version nicht so sein. Das werden wir in Zukuft erhöhen.

Support für Victron und generische Modbus/TCP Anbindiung für beliebige Zähler ist aktuell in Arbeit. Im Git Repo schon verfügbar und dann Teil der nächsten Firmware-Version.

Hier eine erste WARP3 Firmware mit Deye Hybrid-Wechselrichter Support. Absolut ungetestet, nur basierend auf der Dokumentation. Danke Jojo. @Jojo Wenn du das testen möchtest, dann richte bitte vier Modbus/TCP Zähler auf der Zähler-Unterseite der Wallbox ein. Jeweils einen für jeden der möglichen vier virtuellen Zähler. Du solltest dann dort auch schon Daten sehen, wenn es funktioniert. Ich lese im Moment noch mehr Register aus, als ich in der Meters API abbilden kann. Mir ist nicht ganz klar wie die ganzen Spannungen, Ströme und Leistungen zuzuordnen sind. Daher werden im Ereignislog alle ausgelesenen Werte ausgegeben. Am besten wäre, wenn du die Ereignis-Log Unterseite öffnest, sich die Daten kurz (villeicht 30-40 Sekunden) sammeln lässt und dann das Ereignis-Log speicherst und mir schicken könntest. warp3_firmware_2_3_0_66351a8e_92bf0d855c4a347_merged.bin

Die Lösung ist wie pip schon selbst schreibt: pip install Ich habe gerade alle Varianten durchprobiert die wir dokumentieren, um die Python Bindings zu installieren. Wir liefern das egg-info nicht direkt aus. Das veraltete egg Format wird durch "python setup.py install" erzeugt. Ich vermute du hast die Python Bindings darüber installiert. Laut Dokumentation, die ich dazu finden konnte, ist es deprecated setup.py direkt aufzurufen. Man soll stattdessen "pip install ." im Verzeichnis ausführen, in dem die setup.py Datei liegt. Das installiert die Bindings dann im aktuellen dist-info Format. Danke für den Hinweis.

Laut dem Dokument werden die 100er Modelle unterstüzt. Diese beziehen sich auf den Wechselrichter, aber nicht auf den Netzanschluss oder den Speicher. Danke. Welche Register liest du den aus? Für PV Überschlussladen brauchen wir aktuell die Leistung am Netzanschluss und zukünftig werden wir auch noch die Leistung und den SoC des Speichers mit einbeziehen. Anzeigen tun wir auch noch die importierte und exportierte Energie.

Wir brauchen die Information darüber welche Werte in welchem Modbus-Register zu finden sind. Für Deye konnte ich da auf Anhieb gerade keine Dokumentation finden. An diesem Thema arbeiten wir gerade aktiv. Da wird sich intern wahrscheinlich noch was an der Struktur ändern. So sieht das aktuelle für einen Solarmax Max.Storage Wechelrichter aus: https://github.com/Tinkerforge/esp32-firmware/blob/3290eb60f6d56d078d148f07096fa17484654661/software/src/modules/meters_modbus_tcp/prepare.py#L629 Es wir auch in Kürze die Möglichkeit geben, dass du einen benutzerdefinierten Modbus/TCP-Zähler anlegst und dort von Hand angibst in welchen Modbus-Registern welche Werte zu finden sind. Sprich, wenn du uns Dokumentation bereitstellen kannst und uns am besten noch beim Testen helfen kannst, dann schauen wir uns an, ob wir das einbauen können. Oder du kannst dir das esp32-firmware git clonen, und den Support selbst einbauen und einen Pull Request auf GitHub machen. Oder du kannst dir in Kürze einen benutzerdefinierten Zähler einrichten und die Modbus-Register von Hand angeben. Oder Deye unterstüzt SunSpec und du verwendest unsere vorhandene SunSpec Unterstützung. Leider ist SunSpec nicht bei allen Herstellern gleich gut umgesetzt. Daher haben wir jetzt für Sungrow nicht SunSpec sondern gehen über den Sungrow eigenen Registersatz.

Hier jetzt der aktuelle Stand. In dieser Version ist die Konfiguration etwas anders. Nach einem Update von einer der vorherigen Testversionen auf diese, muss einmal der Zähler neu konfiguriert werden. Neu in dieser Version: Support für Sungrow SG Wechselrichter. warp3_firmware_2_3_0_6630b9e7_3290eb60f6d56d0_merged.bin