ABL eMH3: OCPP setup issues #15559
Comments
|
Anbei noch die volle Logdatei |
Die Box wartet auf die lokale Freigabe via RFID oder Free Charge-Mode. |
Das ist ein Fehler in der OCPP-Implementierung der Box. Verletzung des Standards. Bitte damit an den Hersteller wenden. |
|
Hallo, vielen Dank für die Info. Da wird seitens ABL wohl nichts mehr kommen, da die eMH3 aus dem Programm genommen wurde. Also heißt das, dauerhaft die Version 0.129.0 nutzen? Vielen Dank. |
|
Erstmal Problem 1 bei dir lösen, der Error ist zweitrangig und nur ein Hinweis. |
|
Die ID für freies Laden wird doch in der Konfiguration (idtag: 10101010101010) mit übergeben, |
|
RFID-Karte vorhalten oder |
|
Nochmal kurz getestet, Konfiguration auf Freies Laden funktioniert, allerdings sind die Funktionen nicht gewünscht. Was auch nicht geht, ist die Regelung. EVCC bekommt die Ladeleistung nicht mit, |
Prima. Wie erwartet. Dann genau so lassen.
Die Alternative lautet RFID-Authentifizierung.
Das idTag heisst per default "evcc" und wird grundsätzlich nur bei RemoteStartTransaction benötigt.
Das ist richtig. Der Default-Modus "off" in evcc sperrt den Ladepunkt für fremde Nutzer, die Fahrzeugerkennung ermöglicht es nur berechtigte Fahrzeuge automatisch zu laden (Default-Lademodus des jeweiligen Fahrzeugs).
Das ist nicht richtig. Das verhindert evcc über das gesendete ChargingProfile mit Stromvorgabe 0.
Das wäre ein anderes Problem was sich hoffentlich im Log erkennen lässt. |
|
Bitte die Konfig der beiden OCPP-Ladepunkte mal auf - type: template
template: ocpp
stationid: ABL_3W226305065
connector: 1
name: wb_re_1
- type: template
template: ocpp
stationid: ABL_3W226305065
connector: 2
name: wb_re_2reduzieren und den FreeCharge Mode aktivieren. Schau auch mal bitte ob du in der Konfiguration der Box irgendwo das Meter Sample Interval Box auf 10s reduzieren kannst. Dann mal bitte den Output von |
|
Also, ich habe jetzt dein Log mal durchgesehen.
Ab hier funktioniert es wie es soll. Bitte auch noch beachten, da du insgesamt 4 Ladepunkte hast, dass pro Intervall immer nur ein LP bearbeitet wird und es daher zu längeren Verzögerungen zwischen Aktion in der UI und tatsächlicher Änderung am Charger kommen kann. Das einzige was etwas irritierend ist, ist dass die Meteringdaten von evcc in dem Log nicht erkannt wurden und daher vermutlich keine sinnvolle Anzeige in der UI kam. Das kann aber mit der Neuverbindung durch die Änderung auf FreeChargeMode zusammenhängen. Das würde ich gerne mit einem aktuellen Log nochmal genauer ansehen. Hier also bitte nochmal mit dem aktuellen Nightly Build testen. Dazu bitte FreeChargeMode anschalten bzw. angeschaltet lassen, dann die Box vollständig neustarten und dann erst evcc (neu)starten. |
|
Werde ich morgen nochmal testen. Etwas schwierig mit 1-4 Fahrzeugen und Sonne die mal da ist und mal nicht 😁 Ich habe die Box schon mal umgestellt und auf nightly geswitcht. Lokale Vorauthorisierung habe ich auch mal ausgeschaltet. Nachfolgend noch ein Log, nach dem EVCC start, ohne Fahrzeuge. |
|
Fahrzeug wurde angesteckt, erst mit 6A geladen, dann mit 16A und dann gestoppt, obwohl kein Überschuss verfügbar war, idTag ist in der Config nicht mehr drin. Trace:
|
|
Eine manuelle Ansteuerung über Min+PV funktioniert, Zählerwerte werden gesendet, allerdings wird die Ladeleistung in EVCC nicht erkannt, |
|
Die Anzeige der Leistung des Ladepunkts hat nicht mit der Überschussregelung zu tun. Diese basiert ausschließlich auf den Daten des Netzanschlusses (grid). |
|
Abgesehen von den diversen Fehlermeldungen auf Grund von Fehlern in der Firmware funktioniert es nach dem erstem Blick in das Log aber nun eigentlich wie es soll. Bei der Ausgabe der nicht kritischen Fehler werden wir sicherlich noch nachjustieren. Die Sache mit den Meteringdaten stellt mich aber gerade noch vor ein Rätsel. /cc @andig Ich stehe auf dem Schlauch. Weshalb werden hier die Ladeleistungen und Energie mit NotAvailable abgelehnt? Hast du eine Idee? Und wir haben mit Blick auf den Screenshot offensichtlich das Problem, dass wir die interne Constraint-Fehlerausgabe via OCPP an den Charger zurückwerfen, was dieser sicherlich nicht verstehen wird. |
|
Ich glaube du hast recht, er merkt also das die Box Strom zieht (Leistung fehlt), zeigt es glaube ich nur nicht an. [lp-3 ] ERROR 2024/08/23 10:59:22 charge power: not available Was ich aber als Fehler sehe, dass die Box beim Einstecken sofort mit 6A, dann mit 16A läd und dann abgeschaltet wird. Zudem scheint es noch ein Problem mit dem Timer zu geben, dieser resettet sich immer bei neuladen der Seite auf 2:59. |
|
@premultiply die MeterValues messages ist auf den ersten Blick anders als bswp. bei meinem Bender Charger, es handelt sich hier um ein Array mit 2 Objekten, das erste enthält die erfolgreich geparsten Currents, das zweite den Rest und nochmals die Currents. Evtl. ist das die Ursache? Die Fehlermeldungen korrespondieren mit den sampledValues, die im ersten Objekt nicht drin sind. Ist das die Stelle, wo das verarbeitet wird? Ohne jetzt der go Experte zu sein würde ich sagen, die for-Schleife nimmt das erste Objekt, schaut sich den Timestamp (2024-08-23T06:02:45.311+00:00) an und wenn er neuer ist als conn.meterUpdated, werden die Werte verarbeitet -> die currents werden gespeichert und conn.meterUpdated auf die aktuelle Zeit conn.clock.Now() gesetzt. Nun wird das zweite Objekt mit dem Timestamp 2024-08-23T06:02:45.337+00:00 verarbeitet. Da aber conn.clock.Now() bei Verarbeitung des ersten Objekts schon später als der Timestamp des zweiten Objekts ist, wird der Inhalt ignoriert. |
|
Autsch, ja!! Super! Da muss ich erstmal überlegen wie wir damit sinnvoll umgehen. /cc @andig |
Dann sollten wir das einfach nach Timestamps sortieren (anstatt mit location rumzufrickeln)? Vorschlag kommt. |
|
Die Location ist hier schon auch relevant, da das hier eine Box mit zwei LPs ist und der Ladestrom beider LPs auf den Body-Werten auftaucht, wir uns hier aber nur für die Outlets (Connector) interessieren. Die Body-Werte verwirren hier nur - kann aber bei anderen Boxen wieder anders sein. |
|
Je nach Verhalten der Wallboxen ggf. over engineered, aber wäre es nicht am robustesten, mit dem neuesten timestamp anzufangen und dann bis zum ältesten Objekt weiterzumachen und measurands, die noch nicht gefunden wurden, daraus zu ergänzen? Dabei Outlet vor Body priorisieren? |
Sind die irgendwo definiert?
Umgekehrt und dann wird einfach überschrieben. |
|
Das würde hier vielleicht funktionieren aber in anderen Fällen (andere Boxen) ist die Reihenfolge ggf. eine andere? Aktuell sehe ich noch keine elegante Möglichkeit das möglichst universell zu lösen. |
|
Ocpp 1.6 Specs chapter 7.30 Body Cable EV Inlet Outlet |
|
Ich sehe hier gar kein Problem. Oder wollen wir Spannungsabfall über das Kabel messen??? |
|
Startet wieder und verbindet. Werde es ggf. heute Nachmittag nochmal mit einem Ladevorgang testen. |
|
Nachfolgend ein Log von einem kurzen Ladevorgang: |
|
Wenn ein Fahrzeug eingesteckt ist, kein Überschuss verfügbar ist, laufen die charge abfragen alle auf timeout und werden in der UI als Fehler angezeigt. |
|
Sieht aus, als würde die Wallbox in dem Fall aufhören, die MeterValues im konfigurierten 10 Sekunden Intervall zu senden. |
|
Genau, ggf. da keine Ladung aktiv ist, bzw keine Ladeleistung freigegeben ist. |
|
Eine Transaction sollte aber aktiv sein. Und dann gilt
|
|
Nachfolgend ein Trace nach dem Update auf aktuellen Docker Nightly ohne Fahrzeug, da werden die Werte gesendet: |
|
In diesem Fall fragt evcc aktiv nach den Werten, vermutlich weil keine Transaktion läuft, während man im anderen trace mit angestecktem Fahrzeug die requests nicht sieht, vermutlich weil erwartet wird, dass die Wallbox sich an die Spec halt und die Werte dann selbst sendet. Ich denke der Experte ist hier @premultiply. |
|
Aktuellen Nightly installiert... es dauert 300 Sekunden (timeout), bis vom start von evcc, bis zum erreichen der Weboberfläche. |
|
@premultiply das scheint das beschriebene Problem mit mehreren Connectoren zu sein: es wird 2x die Availability geändert, gibt zunächst aber nur 1x BootNotification zurück. Später- nach TriggerMessage kommt sie dann. Warum es am Ende dennoch in Timeout läuft ist mir auf die Schnelle nicht klar. Ich mache nochmal auf, auch wenn es jetzt ein anderes Fehlerbild ist. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
@etecprojekt das ist ein eigenständiges Problem das wir uns anschauen sollten wenn das Setup erstmal vernünftig mit Deiner Box funktioniert. Eins nach dem Anderen! |
|
Angehängter PR soll jetzt auch das Verhalten mit mehreren Connectoren fixen und Timingissues beim Start auflösen. Test des PRs wäre Klasse. Der ist ein bisschen zu groß, um ihn mal eben so zu mergen. |
|
@andig kannst du den PR in die Docker Nightly mit reinnehmen? |
|
Der PR kommt- wie jeder andere auch- ins nightly wenn er gemerged wird. Damit da nix kaputt geht wäre ein Test vorab schön. |
|
Mit aktueller nightly, kein starten möglich: |
|
Ist schon gelöst, siehe #15852 |
|
Nightly baut |
|
Startet wieder, Fehlermeldung am Anfang ist geblieben: |
Das ist nur eine Debugmeldung. Wenns sonst funktioniert wunderbar! |
|
Aktuell an der OCPP-Box leider nur ein Fahrzeug, sieht aber momentan sehr gut aus 👍
|
|
Es scheint so, dass die Regelung einen Tag funktioniert und sobald ein Fahrzeug nochmal angesteckt wird, nicht mehr. Ggf. könnte ich das ganze am Wochenende einmal genau testen. |
|
@etecprojekt du bitte Dir uns uns einen Gefallen und mach vollständige Logfiles. Wenn der Fehler in Zeile 13 auftaucht ist es UNMÖGLICH rauszufinden, warum er auftaucht. Da das konkrete Problem hier erstmal gelöst war würde ich das Issue jetzt schließen. Für Folgeprobleme sehr gerne neues Issue mit aussagekräftigem Logfile. Vielen Dank! |
Describe the bug
Hallo zusammen,
nach dem Update von Version 0.129.0 auf 0.130.2 funktioniert die Ansteuerung der ABL eMH3 (3W2263) nicht mehr.
Nachfolgende Fehlermeldungen aus dem Log:
[ocpp ] ERROR 2024/08/21 07:04:20 ocpp message (2383823729): OccurrenceConstraintViolation - Field CallResult.Payload.ChargingSchedule.ChargingRateUnit required but not found for feature GetCompositeSchedule ([3, "2383823729" ,{"status":"Accepted","connectorId":1,"scheduleStart":"2024-08-21T05:04:19.385+00:00","chargingSchedule":{"duration":60,"startSchedule":"2024-08-21T05:04:19.385+00:00","chargingSchedulePeriod":[{"startPeriod":0,"limit":-1.0}]}}])Die Ladung wird laut Log wohl freigegeben aber es erfolgt keine Ladung.
Haben jetzt erstmal wieder auf Version 0.129.0 zurück.
Steps to reproduce
PV-Überschussladen, Min+PV ohne Funktion.
Configuration details
Log details
What type of operating system are you running?
Linux
Version
0.130.2
The text was updated successfully, but these errors were encountered: