Priorität der Schnittstellen bei der Ladefreigabe bzw. evcc und ecarup parallel betreiben

[wolkenschaufler]

Hallo Zusammen, 

 

ich möchte gerne meine WARP2 als öffentlichen Ladepunkt über ecarup freigeben. Dabei soll aber dennoch die Steuerung über evcc erhalten bleiben sobald ich mein privates Fahrzeug anstecke. 

 

Die Einrichtung klappt problemlos, jedoch wird dann auch nicht mehr geladen, wenn die heimische Zoe angeschlossen wird. 

Das Verhalten ist nur logisch - die Wallbox wartet dann auf eine Freigabe über OCPP von ecarup. 

Was es eigentlich bräuchte, wäre ein OCPP-Proxy in evcc, welchen es aber aktuell noch nicht gibt. 

 

Hat jemand eine solche Konfiguration im Einsatz (Steuerung der Wallbox über MQTT und OCPP)?

Viele Grüße

bearbeitet July 7, 2025 at 10:17 von wolkenschaufler

[photron]

On 7/7/2025 at 12:16 PM, wolkenschaufler said:

Das Verhalten ist nur logisch - die Wallbox wartet dann auf eine Freigabe über OCPP von ecarup. 

Was es eigentlich bräuchte, wäre ein OCPP-Proxy in evcc, welchen es aber aktuell noch nicht gibt. 

Das Verhalten ist genau so erwartet. Du hast verstanden wo das Problem liegt und wie es zu lösen wäre.

[wolkenschaufler]

Demzufolge gibt es derzeit dann keine Lösung dafür? 

Möglich wäre ja auch, dass die MQTT Freigabe immer höher priorisiert wie OCPP. 

Gruß

[rtrbt]

On 7/7/2025 at 1:13 PM, wolkenschaufler said:

Demzufolge gibt es derzeit dann keine Lösung dafür? 

Leider nicht.

On 7/7/2025 at 1:13 PM, wolkenschaufler said:

Möglich wäre ja auch, dass die MQTT Freigabe immer höher priorisiert wie OCPP. 

Die Ladefreigaben (von denen OCPP und die "externe Steuerung" also meistens MQTT) sind alle parallel, es müssen also alle Freigaben, die aktiv sind, freigeben.

Kurze Bestandsaufnahme: Die Freigabe über EVCC läuft über die Fahrzeugerkennung? Oder benutzt du da ein NFC-Tag, dass EVCC kennt? Wie gehst du im Moment mit dem anderen Fall um, dass EVCC blockiert, wenn OCPP freigibt?

[wolkenschaufler]

Am 7.7.2025 um 14:30 schrieb rtrbt:

Die Ladefreigaben (von denen OCPP und die "externe Steuerung" also meistens MQTT) sind alle parallel, es müssen also alle Freigaben, die aktiv sind, freigeben.

Danke für die Info, das hatte ich schon vermutet

Am 7.7.2025 um 14:30 schrieb rtrbt:

Kurze Bestandsaufnahme: Die Freigabe über EVCC läuft über die Fahrzeugerkennung? Oder benutzt du da ein NFC-Tag, dass EVCC kennt? Wie gehst du im Moment mit dem anderen Fall um, dass EVCC blockiert, wenn OCPP freigibt?

Ja, das wäre der grundsätzliche Plan. Ich war allerdings noch nicht so weit, da nach Anbindung des ecarups Backends eine Steuerung durch EVCC gar nicht mehr möglich war. Insofern habe ich mir auch noch keine Gedanken dazu gemacht, was passiert, wenn EVCC die Ladung freigibt aber das OCPP Backend nicht.

NFC-Tags verwende ich nicht. 

[Jkw]

Hi liebe Leute, ich habe vermutlich die exakt gleiche Frage. Ich nutze aktuell NFC tags zur Ladefreigabe, da die wallbox Recht einfach von der Straße erreichbar ist.

Grundsätzlich würde ich sie gern auch bei Diensten wie charge@friends anbieten, aber wenn ich das tue müsste der ocpp Server auch mein Tag kennen. Angeblich bietet charge at friends das an, aber auf meine E-Mail bekomme ich keine Antwort.

Mir gefällt auch die Idee von deren Sever abhängig zu sein nicht besonders gut. 

Ich frage mich daher ob es möglich wäre (natürlich ist es das ;]) ein "oder" switch einzubauen. Aktuell versuche ich die Firmware zu verstehen um bei NFC Tag Freigabe direkt den Ladevorgang zu starten und selbiges bei ocpp. Alternativ könnte die ocpp Freigabe auch ein virtuelles NFC Tag vortäuschen. Dann brauche ich die Blockade durch ocpp gar nicht mehr. 

Noch bin ich auf der Suche. Vielleicht kann mich ja jemand mit der Nase darauf stoßen. Oder mache ich hier Quatsch?

Gruß jkw

[MatzeTF]

Ein OCPP-Server erwartet immer, die volle Kontrolle über eine Wallbox zu haben. Mit einer Oder-Verknüpfung ist es da nicht getan.

Es ist bestimmt möglich, da irgendwas zu hacken, aber das ist voraussichtlich viel mehr Aufwand, als wir aktuell in einen derartigen Hack investieren können.

Die vorgesehene Variante ist genau das, was du schon genannt hast: Der OCPP-Server muss deine Tags kennen. Es würde mich wundern, wenn du der einzige bist, der genau das mit charge@friends machen möchte, und es dazu noch keine öffentlichen Informationen in irgendwelchen Foren gibt.

Für den Fall, dass der charge@friends-Server ausfällt und du nicht laden kannst, kannst du natürlich mit wenigen Klicks OCPP aus- und NFC einschalten, damit du dich lokal authentifizieren kannst. Deine NFC-Tags können dauerhaft in der Wallbox registriert bleiben, selbst wenn du die lokale NFC-Authentifizierung ausschaltest.

[Jkw]

Dank dir für die Antwort. Ist es vorgeschrieben das der ocpp server exklusiv die Kontrolle hat, oder "nur normal"? 

Falls es nur der normale Zustand ist:

Ich schätze gerade den open source Gedanken an der Warp um funktionen zu haben die andere boxen nicht ermöglichen. 

Grundsätzlich bin ich nicht der erste/einzige mit dem Anliegen. In anderen Fällen schrieb der Support von Charge@friends bereits das eine Mail reicht. Ich habe in 6 Wochen 2x geschrieben und bisher noch nichts erreicht. Tatsächlich schwindet gerade dadurch mein Vertrauen in den Service so sehr das ich eine exklusive Steuerung mein WARP ausschließe. 

Einen parallelen Betrieb (NFC || OCPP) halte ich hingegen für eine gute Sache für die e-mobilität. 

 

Wenn es tatsächlich verboten ist lokale NFC tags zur nutzen dann ist C@F leider raus. 

 

Gruß jkw

[MatzeTF]

On 7/25/2025 at 4:20 PM, Jkw said:

Ist es vorgeschrieben das der ocpp server exklusiv die Kontrolle hat, oder "nur normal"?

Soweit ich weiß, ist das im OCPP-Standard vorgeschrieben.

Vielleicht ist es möglich, den OCPP-Server über eine lokale Freigabe zu informieren, aber das hilft nicht in den Fällen, wenn der Server trotzdem „nein“ sagt oder nicht erreichbar ist.

[Jkw]

Die Idee gefällt mir ... Und wenn man ehrlich ist, dann stellt ja bei "informieren" auch keiner eine Frage. Damit ist dann ja auch die Antwort gar nicht soooo wichtig ;) 

Mir ist klar das ihr das nicht offiziell anbieten werdet, aber wenn du es persönlich einbauen würdest, welche Schritte würdest du dann so grob machen ;) ?

[Jkw]

Im Endeffekt müsste es doch sogar vollständig legal und mit Bordmitteln gehen oder? 

Kann ich nicht beim erkennen der NFC Karte ein Event auslösen (z.b. eine mqtt Nachricht) auf die ich wiederum extern (e.g. durch Homeassistant) reagiere und per evse/ocpp_enabled die ocpp Schnittstelle deaktivieren? 

Geht das schnell genug das dann noch der Ladevorgang getriggert wird? (Kann ich auch selbst testen). Nach dem ausstrecken des Kabels kann ich ocpp gern reaktiveren.

Oder blockiert dann das lauschende NFC Modul den potentiellen Ocpp Vorgang? 

Das wäre doch komplett legitim oder? Kein umgehen des ocpp, sobald ich den service offen deaktiviere. 

Gruss JKW

[MatzeTF]

Keine Ahnung. Das musst du vielleicht einfach ausprobieren.

[Jkw]

Sind so Gedanken aus dem Urlaub .. mach ich aber danach und werde berichten

[Jkw]

Ich habe mir doch noch die Firmware durchgelesen. Vermutlich würde es reichen 

Zitat

#define CHARGING_SLOT_OCPP 11

Auf 6 zu ändern oder? Dann würde sowohl NFC wie auch OCPP jeweils den gleichen slot freischalten. Ist schon sehr hacky vermutlich tut's aber, meinste du nicht auch?

 

Alternativ bei der NFC Freigabe 

Zitat

#if MODULE_OCPP_AVAILABLE()

  bool ocpp_active = ocpp_enabled.get("enabled")->asBool()

  If(ocpp_active){

    backend->set_charging_slot(CHARGING_SLOT_OCPP, 32000, true, true);

  }

#endif

Und bei der OCPP Freigabe entsprechend den USER slot freigeben? 

Natürlich muss auch das weiterreichen des NFC tags an den OCPP server deaktiviert werden, sonst klappt's nicht 

Ich bin schon ganz gespannt das mal zu probieren

bearbeitet July 27, 2025 at 15:50 von Jkw

[rtrbt]

On 7/27/2025 at 5:44 PM, Jkw said:

Ich habe mir doch noch die Firmware durchgelesen. Vermutlich würde es reichen 

Quote

#define CHARGING_SLOT_OCPP 11

Auf 6 zu ändern oder? Dann würde sowohl NFC wie auch OCPP jeweils den gleichen slot freischalten. Ist schon sehr hacky vermutlich tut's aber, meinste du nicht auch?

Ganz so einfach ist das leider nicht: Wenn OCPP nicht freigibt, wird der maximale Ladestrom mehrfach pro Sekunde auf 0 mA geschrieben:https://github.com/Tinkerforge/tfocpp/blob/8f315f5ea976e00a3f177a983b62871ad4f8e200/src/ocpp/Connector.cpp#L66

Ohne dass ich das jetzt genau durchdacht habe müsstest du zusätzlich zumindest noch hier: https://github.com/Tinkerforge/esp32-firmware/blob/19ec67bc6b041a01d6a573fb1f3bb8c5bdb968e0/software/src/modules/ocpp/ESP32Platform.cpp#L672 mittracken, ob der letzte Übergang von 0 mA nach >= 6000mA durch OCPP verursacht wurde (wenn nicht, dann war es wohl NFC) und nur wenn das der Fall ist, erlaubst du OCPP wieder 0 mA zu schreiben um den Ladevorgang zu stoppen, sonst ignorierst du das. Ggfalls musst du noch mehr Hacks einbauen, damit das immer funktioniert.

[Jkw]

Hmm danke für den Hinweis.

Ich frag mich bald ob es einfacher wäre in der platform.cpp das grundsätzlich Schreiben des Slot zu verhindern und falls ein wert > 0 übergeben würde einfach ein RFID Tag zu emulieren. 

Das sollte gerade aus Sicht der Logik vieles vereinfachen oder übersehe ich etwas? 

Danke für eure mitdenken, ich bin echt ultra fan des open source Ansatzes 

Jkw

 

Edit: ne dann kann man nicht mehr per ocpp stoppen. Ja ok .. also doch eher so

 

Zitat

void platform_set_charging_current(int32_t connectorId, uint32_t milliAmps)

{

    uint16_t current = (uint16_t)std::min(32000ul, (uint32_t)milliAmps);

    if (current)

      unlocked_by_ocpp = true;

    if (unlocked_by_ocpp && evse_common.get_ocpp_current() != current)

        evse_common.set_ocpp_current(current);

    if (!current)

      unlocked_by_ocpp = false;

}

 

bearbeitet July 29, 2025 at 09:50 von Jkw