Alpha Testing: OCPP Wallbox Adapter

foxriver76

@glasfaser Bekomme das Matching von 1715 auf 4873 noch nicht so ganz hin, villt. kannst du mir nochmal auf die Sprünge helfen, wie du das meinst.

Die beiden Datenpunkte mit null sind nur zum steuern, wobei transactionActive theoretisch ein ack nach dem Steuern bekommen kann. Availability kann man bei mir zwar steuern, bekommt aber keine Rückmeldung.

Also eine Ladepause könntest du mal mindestens manuell ansteuern, indem du transactionActive auf false setzt, das sollte die aktuelle Transaktion (Ladung) stoppen und mit true fortsetzen. ein Ampere Limit scheint nur über SetChargingProfile möglich zu sein. Hier bin ich noch am überlegen, wie man das sinnvoll implementiert. Ich würde vermutlich nur ermöglichen die Ladung zu beschränken und nicht das konfigurieren von Profilen mit schedule etc. da da dann keiner mehr durchsteigt und vermutlich der Use-Case besser über ein Skript abdeckbar ist insofern man die Ampere über den Adapter beschränken kann.

Glasfaser

@foxriver76

Bekomme das Matching von 1715 auf 4873 noch nicht so ganz hin, villt. kannst du mir nochmal auf die Sprünge helfen, wie du das meinst

Der Wert 1715 war von der ersten Ladung ( Moment LOG Aufnahme ) , hat mit dem zweiten Wert nichts zu tun der ist von gestern , Sorry wenn du es so verstanden hast.

Der Wert 4873 Wh ist der Endwert eines Ladevorganges.
" Ladevorgang wird mit 0 Wh gestartet und endet bei mir mit 4873 Wh auch im Datenpunkt meterValue sichtbar "

Ich hatte ja wie ich oben schon geschrieben in der Wallbox einen Pool von 900 s , da ich den Pool der Wallbox dann auf 5 s gestellt hatte und dann in den Modbus-Registern geschaut hatte konnte ich den Wert hinzugefügte Wh ( pro Ladevorgang) zuordnen .

Also eine Ladepause könntest du mal mindestens manuell ansteuern, indem du transactionActive auf false setzt,

Das habe ich gemacht , das komische ist es tut sich nichts ( mehr ),
Datenpunkt transactionActive mit true/false auch bei dem anderen Datenpunkt availability true/false.
Im DEBUG LOG ist auch nichts zu erkennen .

Ich bin mir sicher , wo ich die Version 0.0.5 nach deiner Thread Eröffung aufgespielt hatte , das ich den Datenpunkt transactionActive mit true/false schalten konnte und es änderte sich auch dazu der Datenpunkt status dazu .

Eventuell hat es damit zu tun , das Datenpunkt transactionActive nicht (null) war ,sondern schon auf true .

.....

Screenshot´s von den Änderungen der Datenpunkte auf true/false :

.

2021-10-30 12:15:40.643 - info: ocpp.0 (7202) Received MeterValues from "/Dorn"
2021-10-30 12:16:35.704 - debug: ocpp.0 (7202) {}
2021-10-30 12:16:35.705 - debug: ocpp.0 (7202) Received heartbeat from "/Dorn"
2021-10-30 12:16:40.660 - debug: ocpp.0 (7202) {"connectorId":1,"transactionId":1,"meterValue":[{"sampledValue":[{"value":"4607"}],"timestamp":"2021-10-30T10:16:39Z"}]}
2021-10-30 12:16:40.664 - info: ocpp.0 (7202) Received MeterValues from "/Dorn"
2021-10-30 12:17:36.026 - debug: ocpp.0 (7202) {}
2021-10-30 12:17:36.026 - debug: ocpp.0 (7202) Received heartbeat from "/Dorn"
2021-10-30 12:17:40.636 - debug: ocpp.0 (7202) {"connectorId":1,"transactionId":1,"meterValue":[{"sampledValue":[{"value":"4664"}],"timestamp":"2021-10-30T10:17:40Z"}]}
2021-10-30 12:17:40.637 - info: ocpp.0 (7202) Received MeterValues from "/Dorn"
2021-10-30 12:18:35.725 - debug: ocpp.0 (7202) {}
2021-10-30 12:18:35.726 - debug: ocpp.0 (7202) Received heartbeat from "/Dorn"
2021-10-30 12:18:40.629 - debug: ocpp.0 (7202) {"connectorId":1,"transactionId":1,"meterValue":[{"sampledValue":[{"value":"4721"}],"timestamp":"2021-10-30T10:18:39Z"}]}
2021-10-30 12:18:40.629 - info: ocpp.0 (7202) Received MeterValues from "/Dorn"

Glasfaser

@foxriver76

Habe nochmal alles neu Probiert und folgendes herrausgefunden :

Wenn der Datenpunkt transactionActive mit false gesetzt wird , dann wird der Datenpunkt status auf Finishing gesetzt und di Ladung dadurch unterbrochen .

2021-10-30 15:20:36.394 - debug: ocpp.0 (27124) {"connectorId":1,"transactionId":1,"meterValue":[{"sampledValue":[{"value":"424"}],"timestamp":"2021-10-30T13:20:35Z"}]}
2021-10-30 15:20:36.398 - info: ocpp.0 (27124) Received MeterValues from "/Dorn"
2021-10-30 15:20:37.836 - debug: ocpp.0 (27124) {"meterStop":425,"timestamp":"2021-10-30T13:20:36Z","transactionId":1,"reason":"Remote"}
2021-10-30 15:20:37.837 - info: ocpp.0 (27124) Received stop transaction from "/Dorn"
2021-10-30 15:20:39.673 - debug: ocpp.0 (27124) {"connectorId":1,"errorCode":"NoError","status":"Finishing","timestamp":"2021-10-30T13:20:36Z"}
2021-10-30 15:20:39.674 - info: ocpp.0 (27124) Received Status Notification from "/Dorn": Finishing

Wenn ich Ihn wieder auf true setze passiert nichts und auch keine Log Ausgabe dazu.

Erst wenn ich den Datenpunkt availability true/false. schalte , wird es wieder freigegeben / geladen .

Aber dabei wird ein neuer Ladevorgang gesetzt , so das der Zähler Wh bei 0 beginnt , also keine Pause sondern ein Neustart .

hier ein GIF dazu :

foxriver76

@glasfaser Ich denke es unterscheidet sich teilweise stark, wie die Wallbox Hersteller das Protokoll intern umsetzen. Bei mir ist es z. B. so, dass der availability state alles andere blockiert, sprich wenn Unvailable mittels availability state gesetzt wurde, dann kann ich keine Transaktion mehr starten, muss erst wieder mit dem availability state aktiviert werden. Sowas wie PauseTransaction gibts leider meines Wissens nicht in OCPP, weshalb es immer eine neue Transaktion ist und der Counter neu anfängt. Gedanke von OCPP ja auch eher kommerziell mehrere WBs managen, daher kann ich es etwas nachvollziehen.

Ich habe mal eine 0.0.7 gemacht, bei der gibts nen State zum setzen des Limits in Watt, der wird aber nur angezogen wenn eine neue Transaktion gestartet wird, das direkte setzen geht derzeit meist nicht, da die Library nen Bug hat, scheint auch leider nicht mehr so maintained zu sein. Deshalb kommt jetzt aktuell beim eintragen eines Wertes ein Fehler im Log.

Schimi

wenn man es "über die katze" installieren kann... wäre ich mit einer "cfos Power Brain" Wallbox dabei

Glasfaser

@schimi sagte in Alpha Testing: OCPP Wallbox Adapter:

wenn man es "über die katze" installieren kann.

kannst du doch ... , wenn du dich nicht über den oben genannten Weg traust !?

Glasfaser

@foxriver76 sagte in Alpha Testing: OCPP Wallbox Adapter:

Deshalb kommt jetzt aktuell beim eintragen eines Wertes ein Fehler im Log.

Du meinst das hier :

2021-10-30 21:27:06.199 - debug: ocpp.0 (18684) Sending SetChargingProfile for /Dorn
2021-10-30 21:27:06.211 - error: ocpp.0 (18684) Cannot execute command "chargeLimit" for "/Dorn": Invalid value "[object Object]" for field csChargingProfiles

Schimi

@glasfaser der weg oben hat irgendwie nicjt geklappt.... Und über "die katze" findet er nichts wenn ich mach ocpp suche

Fehler sitzt wohl vor dem Bildschirm

Glasfaser

@schimi sagte in Alpha Testing: OCPP Wallbox Adapter:

der weg oben hat irgendwie nicjt geklappt....

weil ...nicht geklappt ??? sind Fehlermeldungen oder was !?

Ich hoffe du hast im Verzeichniss /opt/iobroker den Befehl ausgeführt.

wenn ich mach ocpp suche

Du mußt über URL installieren .

Schimi

@glasfaser Das wirds gewesen sein.... Bin nicht im iobroker Ordner gewesen....

Ich probier mal heute abend wieder

Schimi

Ok, hat geklappt (Url im iobroker)...
Die ersten daten sind da... Bin noch unterwegs (habe es uber vpn "eingerichtet"...

Ich mache später mal nen screenshot... Oder was "braucht" ihr noch?

Schimi

Wallbox:
cFos PowerBrain Wallbox (PowerBrain Controller)

Ich kann das laden mit dem Datenpunkt "transactionActive" starten und beenden.... das chargeLimit scheint keine auswirkung zu haben.

Wenn ich "aviability" auf false stelle geht das laden auch aus bzw bei true auf an....

Viel mehr konnte ich nicht testen da keine großartige ladung gerade bevorsteht....

Scheint sich auch mit dem automatischen überschussladen der Box zu beissen (die Box habe ich im iobroker über Modbus eingebunden (und ein zwei HTTP befehle (dokumentiert auf der Webseite)...

Das wurde vom Log ausgespuckt während ich "rumprobiert" habe:

ocpp.0
2021-10-31 16:40:21.224	info	Received Status Notification from "/1": SuspendedEVSE

ocpp.0
2021-10-31 16:40:16.392	info	Received MeterValues from "/1"

jarvis.0
2021-10-31 16:40:15.955	info	Client with IP ::ffff:192.168.1.182 connected

ocpp.0
2021-10-31 16:39:17.671	info	Received Status Notification from "/1": Charging

ocpp.0
2021-10-31 16:39:16.382	info	Received Status Notification from "/1": SuspendedEVSE

ocpp.0
2021-10-31 16:39:16.359	info	Received Start transaction from "/1"

ocpp.0
2021-10-31 16:39:16.345	info	Received Authorization Request from "/1"

ocpp.0
2021-10-31 16:39:07.639	info	Received Status Notification from "/1": Preparing

ocpp.0
2021-10-31 16:38:58.020	info	Received stop transaction from "/1"

ocpp.0
2021-10-31 16:38:57.998	info	Received Status Notification from "/1": Unavailable

ocpp.0
2021-10-31 16:38:44.232	error	Cannot execute command "chargeLimit" for "/1": Invalid value "[object Object]" for field csChargingProfiles

ocpp.0
2021-10-31 16:38:35.310	info	Received MeterValues from "/1"

ocpp.0
2021-10-31 16:37:37.301	error	Cannot execute command "chargeLimit" for "/1": Invalid value "[object Object]" for field csChargingProfiles

ocpp.0
2021-10-31 16:37:35.316	info	Received MeterValues from "/1"

ocpp.0
2021-10-31 16:37:03.640	error	Cannot execute command "chargeLimit" for "/1": Invalid value "[object Object]" for field csChargingProfiles

ocpp.0
2021-10-31 16:36:36.598	info	Received Status Notification from "/1": Charging

ocpp.0
2021-10-31 16:36:35.299	info	Received Status Notification from "/1": SuspendedEVSE

ocpp.0
2021-10-31 16:36:35.282	info	Received Start transaction from "/1"

ocpp.0
2021-10-31 16:36:35.259	info	Received Authorization Request from "/1"

ocpp.0
2021-10-31 16:35:51.234	info	Received Status Notification from "/1": Preparing

ocpp.0
2021-10-31 16:35:51.195	info	Received stop transaction from "/1"

ocpp.0
2021-10-31 16:35:40.172	info	Received Status Notification from "/1": SuspendedEVSE

ocpp.0
2021-10-31 16:35:40.139	info	Received Start transaction from "/1"

ocpp.0
2021-10-31 16:35:40.125	info	Received Authorization Request from "/1"

ocpp.0
2021-10-31 16:35:24.183	error	Cannot execute command "chargeLimit" for "/1": Invalid value "[object Object]" for field csChargingProfiles

ocpp.0
2021-10-31 16:34:54.505	info	Received Status Notification from "/1": Preparing

ocpp.0
2021-10-31 16:34:48.702	info	Received Status Notification from "/1": Unavailable

ocpp.0
2021-10-31 16:34:39.182	error	Cannot execute command "chargeLimit" for "/1": Invalid value "[object Object]" for field csChargingProfiles

ocpp.0
2021-10-31 16:34:28.088	error	Cannot execute command "chargeLimit" for "/1": Invalid value "[object Object]" for field csChargingProfiles

manuBT

Schönen guten Abend!

Also nach dem ich lange den „/„ am Ende der OCPP Server Adresse vergessen habe kann ich nun Erfolg melden.
Der Adapter spricht mit einer EVBox Elvi.
Es kommt nicht viel an aber wenigstens etwas!

Sollte eigentlich mehr kommen oder ist das der aktuelle Stand ?!

Beste Grüße !

E3032512-8FBB-452C-9696-D740DA0692A9.jpeg

foxriver76

@manubt Ne das ist alles zur Zeit.. ihr könnt euch gerne mal das Protokoll anschauen. Ich weiß aktuell nicht was ich da noch sinnvolles rausziehen soll/kann. Sehe gerade, dass er dir wegen der IP-Adresse ein Haufen "Ordner" anzeigt.

Edit: Habe eine 0.0.8 gemacht, da sollten solche Strukturen nun vermieden werden.

manuBT

@foxriver76 Ich schaue mir das bei Gelegenheit mal an. Kämpfe gerade noch an einer anderen Stelle mit der Wallbox das sie den originalen Nachgerüsteten ModBus Zähler erkennen will !

Danke trotzdem!

manuBT

@foxriver76

So, Zähler ist auch in seine Schranken gewiesen!

Jetzt ist mir aber doch noch etwas in den Sinn gekommen wozu meine technischen Fähigkeiten sicher nicht ausreichend sind…
Es ist ja schon ziemlich cool die Daten jetzt lokal zu haben und damit irgendwelche Auswertungen zu machen etc.
Jedoch wäre es ja auch schon gut zusätzlich noch mit dem Backend des Herstellers verbunden zu sein.
Wegen Firmware Update etc…
So wie ich das OCPP verstehe gibt es da ja keine große Sicherheit etc.
Könnte der Adapter die Daten nicht Prinzipiell 1:1 an die Adresse des Anbieters durchschieben.
Der hat keine API oder ähnliches, zumindest öffentlich.
Damit hätte man das beste aus beiden Welten!

@foxriver76 Nicht als Forderung verstehen, aber falls es dir im Winter langweilig werden sollte

Danke so oder so!!!

foxriver76

@manubt sagte in Alpha Testing: OCPP Wallbox Adapter:

Könnte der Adapter die Daten nicht Prinzipiell 1:1 an die Adresse des Anbieters durchschieben.

Verstehe nicht ganz wie du das meinst..

Schimi

@foxriver76 sagte in Alpha Testing: OCPP Wallbox Adapter:

@manubt Ne das ist alles zur Zeit.. ihr könnt euch gerne mal das Protokoll anschauen. Ich weiß aktuell nicht was ich da noch sinnvolles rausziehen soll/kann. Sehe gerade, dass er dir wegen der IP-Adresse ein Haufen "Ordner" anzeigt.

Edit: Habe eine 0.0.8 gemacht, da sollten solche Strukturen nun vermieden werden.

Hi,

hast du vielleicht eine URL zum protokol.... habe mal gesucht aber irgendwie finde ich nichts "übersichtliches"... Wahrscheinlich suche ich falsch

foxriver76

@schimi Ich habe mich an diesem Dokument orientiert: https://www.oasis-open.org/committees/download.php/58944/ocpp-1.6.pdf

Schimi

@foxriver76

ich könnt mir vorstellen das sowas wie:

Bei aktiver/letzter session geladene kWh
insgesammt geladene kWh
der soc (wobei ich nicht glaube das die Boxen den auslesen können.... ist bei Typ2 glaube ich gar nicht vorgesehen)

Interessant wären falls mal eine Vis damit erzeugen möchte...

Ich meine das müsste der Punkt "7.31. Measurand" in deinem PDF sein.....

Ich persönlich brauche OCPP nicht für meine Box.... aber bin da zum testen bereit.... was ich jetzt nicht brauche kann ja in zukunft noch kommen

NEWS

Alpha Testing: OCPP Wallbox Adapter

Support us

321
Online

31.7k
Users

79.8k
Topics

1.3m
Posts

NEWS

Alpha Testing: OCPP Wallbox Adapter

Support us

321Online

31.7kUsers

79.8kTopics

1.3mPosts

321
Online

31.7k
Users

79.8k
Topics

1.3m
Posts