OCPP-Backend für den eigenen kWh-Nachweis: Erfahrungen mit Chargebox-ID und Zählerständen?

[jenssgb]

Hallo zusammen,

laut Wiki schickt die openWB software2 per OCPP ID-Tag, Heartbeat und Zählerstände an ein externes Backend: beim Anstecken, beim Abstecken und alle 5 Minuten. Steuern kann das Backend nicht. Genau das würde ich gern mit einem Backend testen, das nur mitliest.

Offen gesagt: Ich bin Jens, Gründer von bluepolicy, und entwickle MeruX. Das ist eine kostenlose App für Ladeberichte an der Wallbox zu Hause. Sie nimmt Ladevorgänge per OCPP 1.6 an (ohne OCPP per Zählerfoto) und macht am 1. jedes Monats einen digital signierten PDF-Bericht, z. B. für die Erstattung beim Arbeitgeber. Die openWB soll dabei ganz normal weiterregeln, PV-Überschuss inklusive.

Meine Fragen:

1. Welche Chargebox-ID setzt ihr pro Ladepunkt-Profil? Gibt es bei mehreren Ladepunkten Stolperfallen?
2. Hängt jemand ein Backend an, das Basic Auth verlangt? Hat das geklappt?
3. Sind die Zählerstände bei Anstecken/Abstecken zuverlässig genug für eine Monatsabrechnung pro Fahrzeug? Oder habt ihr Lücken gesehen, z. B. nach einem Neustart?

Die Antworten fasse ich hier zusammen, damit auch andere was davon haben. Einen Link zur App gibt's auf Nachfrage.

Viele Grüße
Jens

[Gerolein]

Mir ist nicht so ganz klar, was dein Ansinnen ist. Die Fragen klingen so, als ob du Erfahrungswerte mit der OCPP-Anbindung der openWB suchst. Dein Projekt klingt so, als ob du einen OCPP-Server betreibst und Ladeberichte verschickst.

Wenn du jemanden zum testen suchst: ich trag" gerne mal deine Serverdaten in meine openWB ein. Ich hab' auch zwei Ladepunkte.

[jenssgb]

Danke fürs Ausprobieren und die genaue Beschreibung! Da passt bei der Verbindung etwas nicht, das schauen wir uns an. Hättest du Lust, kurz mit meinem Team zu sprechen? Dann gehen wir das zusammen durch. Wenn ja, sag kurz Bescheid, wie wir dich am besten erreichen.

Viele Grüße
Jens

[charan-sat]

We checked our server logs and no connection request reached the server with URL wss://ws.merux.app/ocpp/T923****. Either the OCPP URL entered in the charge point is incorrect or the charge point handles the URL differently meaning it could concatenate something to the URL after it's entered.
Kindly let us know if we can get on a call to investigate this issue further?

[Gerolein]

Strange. I cannot enter anything else than just the URL. And the URL is exactly what the App showed. But when I let curl do the request I get a "curl: (22) Refused WebSockets upgrade: 403". Maybe the second parameter "Id" is needed for authentication rather than chargepoint identification? And thus is needed to be put somehow into the URL?

[charan-sat]

Thank you for checking and sharing the details.
MeruX generates a new OCPP URL for each wallbox onboarding attempt. If the previous attempt has timed out, the URL from that attempt may no longer be valid.
To establish the connection, please start a new onboarding attempt in MeruX and configure openWB using the newly displayed details:
OCPP URL: Use the exact URL displayed in the app.
Authorization key: Configure the authorization key provided by MeruX in the appropriate openWB authentication field.
Security profile: Select OCPP Security Profile 2, if supported by your openWB configuration.

Please also ensure that the correct charger serial number is entered during onboarding.
If the connection still fails, we would be happy to arrange a short call to investigate the openWB configuration and connection logs together.

[Gerolein]

MeruX generates a new OCPP URL for each wallbox onboarding attempt.

That's clear. No one will configure this manually.

Authorization key: Configure the authorization key provided by MeruX in the appropriate openWB authentication field.

There is no explicit field in openWB configuration. Authorization needs to be encoded somehow in the URL.

Please also ensure that the correct charger serial number is entered during onboarding.

You can enter whatever you like in openWB's charging-point's setup. That's why I assumed the second Id needs to go there. My general assumption was: The URL identifies the account which might compromise multiple charging points which might charge different cars. openWB has configuration items for each of these three entities. Checked / tested for validity needs to be done on account and charging point level. Since openWB does not do a proper authentication of the presented charging-cards via OCPP, the card Id (=the charging EV) is only something that's used to separate charging-sessions.