openWB Forum

Diskussion, Fragen, Anregung zur ModbusTCP Implementierung der openWB bitte hierhin.

Register Doku ist hier zu finden:

https://openwb.de/main/wp-content/uploa ... openWB.pdf

Der aktuelle Code unterscheidet nicht zwischen Coils, Input und Holding Registern. Zur Abgrenzung der Datentype habe ich das hier bei Wikipedia gefunden:

• Einzelner Ein-/Ausgang „Coil“: Lesen & Schreiben, 1-bit, Function Codes 01, 05, 15
• Einzelner Eingang „Discrete Input“: nur Lesen, 1-bit, Function Codes 02
• (analoge) Eingänge „Input Register“: nur Lesen, 16-bits, Function Codes 04
• (analoge) Ein-/Ausgänge „Holding Register“: Lesen & Schreiben, 16-bits, Function Codes 03, 06, 16

Da fast alle Daten der openWB nur lesbar sind, sollten diese vielleicht nur über Input Register zugänglich sein.
Schaltfunktionen wie der RSE oder (de-)aktivieren einzelner Ladepunkte würden von meinem Empfinden besser als Coils (1 bit) abgebildet.

Grund für die Implementierung ist doch die Anforderung der neuen Förderung. Macht es da nicht Sinn, den RSE über Modbus auch schreibbar auszuführen? Ich denke, da keine Vorgabe für die einzelnen Register besteht, möchte im Falle eines Falles der Netzbetreiber "einfach nur abschalten" können. Ansonsten müsste für jede Wallbox genau hinterlegt werden, welche Register ggf. in welcher Reihenfolge mit welchen Werten zu beschreiben sind. Den Aufwand würde ich mir als Netzbetreiber nicht antun wollen.

LutzB hat geschrieben: ↑Mo Okt 19, 2020 7:07 am Grund für die Implementierung ist doch die Anforderung der neuen Förderung. Macht es da nicht Sinn, den RSE über Modbus auch schreibbar auszuführen? Ich denke, da keine Vorgabe für die einzelnen Register besteht, möchte im Falle eines Falles der Netzbetreiber "einfach nur abschalten" können. Ansonsten müsste für jede Wallbox genau hinterlegt werden, welche Register ggf. in welcher Reihenfolge mit welchen Werten zu beschreiben sind. Den Aufwand würde ich mir als Netzbetreiber nicht antun wollen.

Als Netzbetreiber würde ich doch ehr das auf höherer Ebene angesiedelte OCPP nutzen wollen, und nicht irgendwelche Bitmanipulationen in den Wallboxen machen...

bye
TT

Das hatte ich eigentlich auch erwartet...

Es geht schlicht um bidirektionalfähige Kommunikation, neben MQTT nun eben auch ModbusTCP

Ein RSE äquivalent folgt noch @LutzB

Also, in der Testinstallation klappte das lesen sehr gut, das Schreiben ist allerdings immer 3-10 Sekunden verzögert.
Gibt es hier einen Trick ?

Das kommt drauf an was geschrieben wurde bzw. wann es verarbeitet wird.

Ladepunkt sperren und freigeben ca. 3-10 Sekunden
A bei Sofortladen 10-30 Sekunden
Lademodus wechseln noch länger.
Gibt es einen Statusregister für den Lademodus, der ausgelesen werden kann ?
die Beobachtungen beziehen sich ausschließlich auf die Anzeige im Browser

Ja das ist normal.
Die Verarbeitung erfolgt immer alle 10 Sekunden.
Über Modbus kann der "neue" Lademodus auch schon direkt ausgelesen werden.
Intern wird er nach spätestens 10 sec verarbeitet und dann auch visualisiert.

Thomas aus W hat geschrieben: ↑Mo Okt 19, 2020 1:50 pm Als Netzbetreiber würde ich doch ehr das auf höherer Ebene angesiedelte OCPP nutzen wollen, und nicht irgendwelche Bitmanipulationen in den Wallboxen machen...

OCPP ist im Kontext Belieferung und Abrechnung relevant. Für die Steuerung auf VNB Sicht wird es meines Wissens nicht eingesetzt (die ladefreigabe an einer öffentlichen WB macht nicht der VNB).
Das Theme via RSE ist Sache des VNB und nur äusserlich mit dem Thema Freigabe/OCPP verwandt.
Eine Standard-ladesäule, die alle beteiligten integriert gibt es da noch nicht.
Solange bleibt es wohl beim RSE bzw. der Steurbox fürs zukünftige iMSys (beide mit 4 analogen, potentialfreien Kontakten)