openWB Forum

Hallo Zusammen,

für meinen Firmenwagen benötige ich eine Wallbox, da wir mit der Tankkarte von DKV zusammenarbeiten benötige ich eine DKV-Wallbox:

https://www.dkv-mobility.com/de/elektro ... d-wartung/

und das ist eine Innogy eBox professional:

https://www.mobilityhouse.com/media/pro ... sional.pdf

Für meinen privaten E-Golf habe ich bereits eine OpenWB-Box:

gibt es eine sinnvolle Lösung diese beiden Boxen miteinander zu verbinden?
z.B. als Externer Verbraucher in Smarthome2.0 oder sogar als Ladepunkt?

Ich habe auch das Modbus-TCP Register gefunden:

https://www.innogy-emobility.com/conten ... stcpde.pdf

Mir und einigen Kollegen von mir wäre damit sehr geholfen.
Die Integration muss auch nicht kostenlos sein

Danke & LG Philipp

Hallo nochmal,

ich habe mittlerweile eine eBox Professional und der Modbus sollte auch aktiviert werden.

Die Firma Innogy nutzt fürs Management-System cFos, welches auf auf Raspberry PI 3 oder 4 arbeitet:

https://www.cfos-emobility.de/de/cfos-c ... anager.htm

Kann man davon nicht den Source-Code nutzen?:
https://www.cfos-emobility.de/de/cfos-c ... ctions.htm

habe auch noch was in Github gefunden:
https://github.com/axeluhl/eBox

LG Philipp

P.S.: Ich bin bereit für diese Lösung zu zahlen, also wenn einer Zeit und Lust hat.......

Ich denke mal, dass Du in die Richtung "eigenen Solarstrom in den Firmenwagen laden" gehen möchtest:

Poellph hat geschrieben: ↑Do Aug 26, 2021 10:35 am z.B. als Externer Verbraucher in Smarthome2.0 oder sogar als Ladepunkt?

Da bräuchtest Du ja eigentlich nur einen dreiphasigen Schütz vor der Firmen-Wallbox, den Du mit einem Shelly aus smarthome 2.0 ansteuerst. So hast Du zwar keine Regelung des Ladestroms nach dem PV-Überschuss, kannst aber im Sommer schon mal wenigstens die Wallbox Überschussgesteuert ein- und ausschalten.

Aber so, wie sich das Handbuch liest, müsste man der Box in den Registern 1000-1004 den maximalen Ladestrom vorgeben können. Ein Weg ohne eigene Implementaition eines Innogy-Ladepunkts in der openWB wäre z.B. die Nutzung der generischen Ladepunkte per http oder mqtt die dann über iobroker oder nodeRED nach modbus der Box übersetzt werden. Aber das wird nur jemand zusammenbasteln können, der auch eine solche Box hat. modbus kann da je nach Implementierung ziemlich zickig sein.

Ach so, eine Frage noch: Du autorisierst die Ladung per DKV-Karte an der innogy-Box?

Gero hat geschrieben: ↑Mi Dez 08, 2021 11:28 am Ach so, eine Frage noch: Du autorisierst die Ladung per DKV-Karte an der innogy-Box?

Jo, die Daten der RFID-Karte + KWh usw. gehen per SIM direkt an DKV und die überweisen am Monatsende auf mein Konto.

------------------------------------------------------------------

Gero hat geschrieben: ↑Mi Dez 08, 2021 11:28 am Da bräuchtest Du ja eigentlich nur einen dreiphasigen Schütz vor der Firmen-Wallbox, den Du mit einem Shelly aus smarthome 2.0 ansteuerst. So hast Du zwar keine Regelung des Ladestroms nach dem PV-Überschuss, kannst aber im Sommer schon mal wenigstens die Wallbox Überschussgesteuert ein- und ausschalten.

Kann ja schlecht die Wallbox stromlos machen, dass ist jetzt auch nicht im Sinne von DKV.
Ich glaube auch nicht, dass die Wallbox nach einem power cycle ohne RFID-Registrierung wieder startet.

------------------------------------------------------------------

Gero hat geschrieben: ↑Mi Dez 08, 2021 11:28 am Aber das wird nur jemand zusammenbasteln können, der auch eine solche Box hat. modbus kann da je nach Implementierung ziemlich zickig sein.

Ich würde meine Infrastruktur zur Verfügung stellen.
Hab ne PI3 (noch leer) + openWB series2 standard+ + Innogy ebox Professional.

Hilft diese Grundlage nicht:
https://github.com/axeluhl/eBox
??
------------------------------------------------------------------

Oder wird die Firmware 2.0 mein Problem automatisch lösen??

------------------------------------------------------------------

Oder wird die Firmware 2.0 mein Problem automatisch lösen??

Das glaube ich ehrlich gesagt nicht. Für V2.0 sehe ich gerade massive Programmierung von Bestandsmodulen, die alle angepasst werden müssen, da kann ich mir nicht vorstellen, dass da jemand vom Core Tram die Zeit aufbringt, um eine Fremdhardware zu integrieren.

VG
Det

Poellph hat geschrieben: ↑Mi Dez 08, 2021 3:01 pm ...einem power cycle ohne RFID-Registrierung wieder startet...

Das wäre auch erst einmal herauszufinden, wie oft autorisiert werden muss. Denn wenn Du das Auto einsteckst und es ist keine Sonne da, würde der Ladevorgang starten, wenn man die Max. Ladeleistung per modbus auf irgendwas größer Null setzen würde? Oder muss dann erst noch einmal autorisiert werden? Bzw. erst nach der zweiten Wolke?

Poellph hat geschrieben: ↑Mi Dez 08, 2021 3:01 pm Ich würde meine Infrastruktur zur Verfügung stellen.

Nun, Deine Ladeinfrastruktur steht in Deinem LAN. Auch mit VPN kommt man da nicht unbedingt weiter, da wie im obigen Beispiel beschrieben, man mal aus- und einstecken muss und die reale Ladeleistung per App oder am Auto kontrollieren, ob sie auch so ist, wie per modbus eingestellt.

Langer Rede kurzer Sinn: Wenn jemand eine Fremdwallbox ansteuern soll, muss er eine solche bei sich haben. Am besten machst Du Dir die Arbeit und versuchst Dich an der Ansteuerung per modbus. Es gibt da clients, mit denen kann man die Register beschrieben kann. qmodmaster ist z.B. einer. Der nächste Schritt wäre dann, das mal mit einem modbus-client aus einer middleware (nodeRED, iobroker) zu machen. Denn da bekommt man die geregelte Leistung von der openWB bereitgestellt.

Alternativ fängt man sofort an, ein natives Ladepunkt-Modul zu entwickeln und stellt das dann der Allgemeinheit im Lieferumfang zur Verfügung. Dafür muss der Entwickler aber eine "offene" openWB-Installation haben um dort den Quelltext verändern zu können. Diese Entwickler sind wie Det schreibt, wohl aktuell mit der 2.0-Migration der aktuell implementierten Module beschäftigt. Und brauchen natürlich auch direkten Zugriff auf die Wallbox-Hardware.

Poellph hat geschrieben: ↑Mi Dez 08, 2021 3:01 pm Hilft diese Grundlage nicht:
https://github.com/axeluhl/eBox

So wie ich das sehe, ist das eine komplette Ladesteuerung in die PV-Überschuss reingeht und Laderegelung raus. Im Sinne der openWB hilft das nicht viel, weil die das ja von Haus aus alles mitbringt. Allenfalls in der modbus-Ansteuerung könnte man was abkucken. Das selbstständig parallel zur openWB laufen zu lassen, ist ein bissl doof, weil dann zwei versuchen, den Überschuss wegzuregeln.

Ich selbst könnte einen schnellen nodeRED-Flow zusammenklicken, für eine Implementierung eines Lademoduls fehlt mir die Ahnung und womöglich auch die Zeit. Den modbus-part in nodeRED muss dann jemand übernehmen, der die Wallbox greifbar hat. Vor allem macht man den im Hinblick auf 2.0 wohl am besten in Python und da fehlt's glaube ich noch an Vorlagen.

Fremd-LP sind im Gegensatz zu allen anderen Bauteilen (WR, PV, EV, Zähler, Speicher usw.) problematisch, da es einer Interaktion zwischen Regler und WB(en) für Lastmanagment bedarf. Dies bedingt eine Zusammenarbeit mit dem jeweiligen WB-Hersteller. Bis dato ist das nur bei smartWB gegeben. Nicht einmal go-e, die m.E. massiv von oWB profitieren, erachten dies für nötig. Dahingehend sehe ich da wenig Chancen, dass weitere Fremd-LP in den Master einfließen, sofern sich deren Hersteller nicht beteiligen.

Ich wollte es nur gesagt haben, nicht dass sich hier Leute Arbeit machen und dann enttäuscht sind.
Wer unterstützen will, kauft openWB/smartWB und entwickelt openWB hier weiter mit. Im Gegenzug gibt es ein fachlich fundiertes Forum und Support, um das Beste aus dem System herauszuholen.
VG

Nun ja, aber mit openWB-Hardware oder auch smartWB kommt man halt nicht mit der „Tankkarte“ klar. Und dass der AG für den Frimenwagen so eine Abrechnung des heimischen Strombezugs ermöglicht, ist ja auch erst mal sehr begrüßenswert.

Und genau weil das mit den Fremdladepunkten seine Problematiken mit sich bringt, war mein Ansatz halt das per generischem Ladepunkt zu realisieren. Der wird ja hoffentlich auch in der 2.0 noch mit an Bord sein und da hat dann jeder für sich selbst sein „Imtegrationsprojekt“.

Ist halt leider wie immer in der Software und Schnittstellen. Da gehören halt zwei dazu und wenn die nicht beide koordiniert werden können, kracht‘s halt bei Updates. Ich denke mal, gerade die Web-Entwickler können ein Lied davon singen, dass immer mal wieder APIs unangekündigt verändert werden und dann „agile“ nachgekartet werden muss.

Keine Ahnung, was da "generisch" in v2.x kommt.

Das mit den "Tankkarten" ist - Stand heute - sicher noch nicht der Weisheit letzter Schluss. Ich vermute, dass irgendwann OCPP in oWB implementiert wird, womit dann das Thema gelöst wäre.

Poellph hat geschrieben: ↑Do Aug 26, 2021 10:35 amIch habe auch das Modbus-TCP Register gefunden:

https://www.innogy-emobility.com/conten ... stcpde.pdf

Ist ja mega... Da ist ja alles dokumentiert. Richtig übersichtlich. Mit Datentypen, mit ordentlicher Beschreibung.... Wenn das doch alle so machen würden.

In diesem Thread wurde ja schon mächtig spekuliert. So mit Lastmangement und PV-Laden und so... Vielleicht wäre es besser, wenn du sagst, was dein Ziel ist. Willst du PV-Laden? Willst du Lastmanagement? Willst du einfach nur den Verbraucher angezeigt bekommen?