photron

Die neuen Firmwares im ersten Post haben diesen Fehler behoben. Sorry!

SMA wird kommen, wir sitzen da auch nicht auf der 6-Register-Methode fest. Das funktioniert ja offensitlich nicht 100%. @CptHildi Bitte dokumentiere hier weiter deine Erfahrungen, davon können wir lernen, wie es richtig zu machen ist. Danke!

Hier geht es weiter

Als nächstes großes Feature kommt die Batteriespeicher-Steuerung. Im Webinterface unter Energiemanagement > Speichersteuerung zu finden. Unter anderem kann dem Batteriespeicher das Entladen verboten werden, während im Schnelllademodus geladen wird. Vorher hätte sich der Batteriespeicher für die Ladung des Autos entladen. Dies kann jetzt unterbunden werden. Intern wird dies über das Lastmanagement realisiert. Daher muss der Lastmanager aktiviert sein. Dies ist aber vermutlich eh schon der Fall, da die Speichersteuerung hauptsächlich zusammen mit dem PV-Überschussladen verwendet werden wird, für das der Lastmanager auch aktiviert sein muss. Aktuell steht zur Kommunikation mit dem Batteriespeicher Modbus/TCP zur Verfügung. Es gibt aktuell sechs Aktionen, die wir für sinnvoll halten: Laden vom Netz erlauben Erlaubnis zum Laden vom Netz zurücknehmen Entladen verbieten Verbot zum Entladen zurücknehmen Laden verbieten Verbot zum Laden zu­rück­neh­men Neu in Phase 3: Wiederholungs-Interval einstellbar gemacht Presets für Alpha ESS, Deye, Hailei, Sungrow und Victron Energy hinzugefügt Zeitraum als Bedingung hinzugefügt Speichersteuerung global abschaltbar gemacht Einzelnen Regeln abschaltbar gemacht MaskWriteRegister für bit-weises Schreiben hinzugefügt Das Ganze funktioniert ähnlich wie die Anbindung von Modbus/TCP-Stromzählern. Weiterführende Dokumentation ist hier zu finden: https://docs.warp-charger.com/docs/compatible_devices/batteries Das Preset für SMA fehlt absichtlich, da das letzte Preset nicht richtig funktioniert hat und noch nachgebessert werden muss. Achtung: Die Konfiguration ist zwischen diesen und den vorherigen Firmwares nicht kompatible und muss nach dem Update neu angelegt werden. Wir freuen uns über jegliche Rückmeldung. Gerne auch mit Modbus-Registersätzen die für eure Speicher funktionieren. Nachtrag: Firmwares aktualisiert. Die Geräteadresse für eine benutzerdefinierte Register kann wieder umgestellt werden. warp_firmware_2_8_9_68fb9d1f_b017ccfee85d188_feature-batteries-30_merged.bin warp2_firmware_2_8_10_68fb9e5c_b017ccfee85d188_feature-batteries-30_merged.bin warp3_firmware_2_8_10_68fb9fb6_b017ccfee85d188_feature-batteries-30_merged.bin energy_manager_firmware_2_4_9_68fba100_b017ccfee85d188_feature-batteries-30_merged.bin energy_manager_v2_firmware_1_3_9_68fba20a_b017ccfee85d188_feature-batteries-30_merged.bin

Für PV-Überschussladen muss die Wallbox nur wissen wie gross die saldierte PV-Überschussleistung in W ist. Typsicherweise sitzt am Hausanschluss schon ein Zähler der genau diesen Wert erfasst. Denn lesen wir dann einfach vom Wechselrichter und steuern damit das PV-Überschussladen der Wallbox. Bei Victron Energy GX lesen wir dazu die phasengetrennte Netzanschlussleistung aus den System Unit Registern 820, 821 und 822 und summieren die drei Werte auf. Kommen da bei dir die richtigen Werte raus, auch wenn deine Topologie eine andere ist? Wenn ja, dann musst du da nichts basteln und es wird einfach funktionieren. Falls die Werte in den Registern 820, 821 und 822 nicht passen, dann kannst du einen API Zähler mit der Vorlage "PV-Überschussladen" in der Wallbox anlegen. Dieser Zähler hat genau einen Messwert: die saldierte Leistung am "Netzanschluss" in W. Der Wert muss positiv bei Bezug aus der Stromnetz und negativ bei Einspeisung ins Stromnetz sein. Den Messwert kannst du extern berechnen du dann einmal pro Sekunde über MQTT oder HTTP an die Wallbox schicken: https://docs.warp-charger.com/docs/interfaces/mqtt_http/api_reference/meters/?hardwareType=warp3&apiType=mqtt

Sigenergy steht auf der TODO Liste. Ich kann dir aber gerade keine genauere Angabe dazu machen wann das fertig sein wird. Lass uns mal mit "bald" verbleiben. 😅

Fixed brickd 2.4.8 is released. Please try "sudo apt update" and "sudo apt install brickd" again.

Die Wallbox hat einen Modbus/TCP Server (im Log modbus_tcp_srvr). Über diesen können anderen Modbus/TCP Clients Daten von der Wallbox auslesen und diese auch steuern. Im Log ist zu sehen, dass alle paar Sekunden sich von IP-Adresse 192.168.121.168 jemand zum Modbus/TCP Server der Wallbox verbindet und die Verbindung dann sofort wieder trennt. Wie und wo versuchst du denn die Daten über Modbus/TCP auszulesen? Der Debug-Client hat mit dem Modbus/TCP Server nichts zu tun. Dies ist ein Werkzeug für fortgeschrittene Nutzer (und vorallem für uns in der Entwicklung), um mit anderen Modbus/TCP Geräten (z.B. Stromzählern, Wechselrichtern oder Batteriespeichern) testweise zu kommunizieren. Für den normalen Betrieb der Wallbox spielt der Debug-Client keine Rolle.

Bindings: Go 2.0.17 Fix bool arrays in setters Download: Go

Bindings: Go 2.0.17 Bool-Arrays in Settern repariert Download: Go

New brickd version to work with libgpiod2 and libgpiod3 coming this week.

Ich habe gerade in die Shelly Dokumentation geschaut und ich stimme dem zu. Das sollte einfach funktionieren. Alle drei Shelly Pro 3EM Varianten (Shelly Pro 3EM, Shelly Pro 3EM-400 und Shelly Pro 3EM-3CT63) verweisen auf die gleiche API-Dokumentation.

Die Unterstützung für Growatt steht auf der TODO Liste, die wird in kürze kommen.

Bindings: Python 2.1.32 Add support NFC forum tag type 5 to NFC Bricklet API Add cardemu_set/get_tag_id function to NFC Bricklet API Add write_line_2 function to OLED 128x64 Bricklet 2.0 API Add set/get_motor_stalled_callback_configuration functions and MOTOR_STALLED callback to Silent Stepper Bricklet 2.0 API Add set/get_capture_input_callback_configuration functions and CAPTURE_INPUT callback to IO-4 Bricklet 2.0 API Download: Python

Bindings: Python 2.1.32 Unterstützung für NFC Forum Tag Type 5 zur NFC Bricklet API hinzugefügt cardemu_set/get_tag_id Funktion zur NFC Bricklet API hinzugefügt write_line_2 Funktion zur OLED 128x64 Bricklet 2.0 API hinzugefügt set/get_motor_stalled_callback_configuration Funktionen und MOTOR_STALLED Callback zur Silent Stepper Bricklet 2.0 API hinzugefügt set/get_capture_input_callback_configuration Funktionen und CAPTURE_INPUT Callback zur IO-4 Bricklet 2.0 API hinzugefügt Download: Python

Kannst du über den Fernzugriff auf der Wallbox unter System -> Ereignis-Log einen Debug-Report speichern und hier anhängen?

Momentan fehlt der Wallbox die Möglichkeit überhaupt Modbus/UDP zu verwenden. Wir haben nur Modbus/TCP, weil das weit verbreitet ist. Ganz kurzfristig wird sich da leider nichts tun. Hinderlich ist weiterhin, dass wir keinen VM-3P75CT hier haben. Hast du schon eine WARP3 und den VM-3P75CT verbaut und könntest uns über den Fernzugriff zugänglich machen?

Nein, das hängt nicht zusammen. Wie genau kommst du den nicht mehr auf die Webversion? Lädt die Seite einfach nicht, bekommst du eine Fehlermedlung, oder irgendetwas anderes?

Bindings: Go 2.0.16 Add support NFC forum tag type 5 to NFC Bricklet API Add CardemuSet/GetTagID function to NFC Bricklet API Add WriteLine2 function to OLED 128x64 Bricklet 2.0 API Add Set/GetMotorStalledCallbackConfiguration functions and MotorStalled callback to Silent Stepper Bricklet 2.0 API Add Set/GetCaptureInputCallbackConfiguration functions and CaptureInput callback to IO-4 Bricklet 2.0 API Fix device identifier check Download: Go

Bindings: Go 2.0.16 Unterstützung für NFC Forum Tag Type 5 zur NFC Bricklet API hinzugefügt CardemuSet/GetTagID Funktion zur NFC Bricklet API hinzugefügt WriteLine2 Funktion zur OLED 128x64 Bricklet 2.0 API hinzugefügt Set/GetMotorStalledCallbackConfiguration Funktionen und MotorStalled Callback zur Silent Stepper Bricklet 2.0 API hinzugefügt Set/GetCaptureInputCallbackConfiguration Funktionen und CaptureInput Callback zur IO-4 Bricklet 2.0 API hinzugefügt Device Identifier Check repariert Download: Go

Wir haben mittlerweile eine SDM630 Modbus/TCP Registertabelle im WARP Charger. Du könntest also hier direkt mit dem WARP Charger den Modbus-RTU-nach-TCP-Wandler ansprechen. Ohne Umweg über Node-RED und API-Zähler. Was möchtest genau erreichen? Ein WARP Charger kann über seine Modbus/TCP API die Werte seines Zähler 0 wieder über Modbus/TCP rausgeben, wenn auch in einer anderen Registertabelle. Der WARP Energy Manager 2.0 hat noch keine Modbus/TCP API, steht aber auf der Todo Liste: https://github.com/Tinkerforge/esp32-firmware/issues/215

Modbus/UDP gibt es wohl, aber ich habes noch nie verwendet gesehen. Ich würde mich wundern, wenn dieser Zähler wirklich nur Modbus/UDP unterstützt. Hast du da mehr Dokumentation dazu? Ich kann auf die Schnelle keine detalierte Dokumentation oder Registertabelle finden. Ohne die Registertabelle kommen wir da eh nicht weiter.

Das sieht richtig aus.

Der Unterschied zwischen Smart und Pro ist exakt das Vorhandensein des Zählers. Daher kann die Smart ohne Zähler nichts messen und schätzen ist nicht möglich. Du kannst in der Wallbox den Shelly Pro 3EM als Zähler für die Ladevorgänge einrichten. Dazu unter Energiemanagement -> Stromzähler den "WARP Charger" Zähler löschen und einen neuen Stromzähler hinzufügen. Dabei unbedingt die Nummer des Stromzählers auf 0 umstellen, denn Zähler 0 ist der Zähler der für die Ladevorgänge verwendet wird. Als Klasse wählst du "Modbus/TCP" und als Hostname den Hostnamen oder die IP-Addresse des Shelly Pro 3EM. Als Registertabelle wählst du "Shelly Pro 3EM" und als Messort "Anderer". Dann "Hinzufügen", "Speichern", "Neustart" klicken. Jetzt solltest du die Werte des Shelly Pro 3EM sehen und diese werden dann auch für das Ladelog benutzt.

Firmware: WARP1 2.8.8, WARP2 2.8.8, WARP3 2.8.8, WARP Energy Manager 2.4.8, WARP Energy Manager 2.0 1.3.8 SunSpec: Falsche Leistungs- und Phase-zu-Phase-Spannungswerte für WattNode-Stromzähler korrigiert Fernzugriff: Hinzufügen eines neuen Benutzer repariert Absturz in der allgemeinen Konfigurationsbehandlung behoben Download: WARP1 2.8.8 bzw. WARP2 2.8.8 bzw. WARP3 2.8.8 bzw. WARP Energy Manager 2.4.8 bzw. WARP Energy Manager 2.0 1.3.8