Entratek Power Dot Pro: No reply to getConfiguration request

[Kalli113]

Describe the bug

Manche OCPP-Wallboxen (bspw. die ältere Wifi-Version der Entratek Power Dot Pro) unterstützen nicht den parameterlosen getconfiguration-Aufruf. Meine Entratek-Wallbox liefert in diesem Fall gar keine Antwort, was den Start von EVCC verhindert:

[ocpp ] TRACE 2024/03/15 17:14:59 sent JSON message to xxx: [2,"2179812988","GetConfiguration",{}] [main ] FATAL 2024/03/15 17:15:59 cannot create charger 'EntratekWallbox': cannot create charger type 'ocpp': ocpp message (2179812988): GenericError - Request timed out

Lt. Wallbox-Dokumentation (PDF-Seite 20) wird nur die Abfrage von maximal 4 Keys gleichzeitig unterstützt.

Dies ist laut OCPP-Spezifikation 1.6 zulässig:
The number of configuration keys requested in a single PDU MAY be limited by the Charge Point. This maximum can be retrieved by reading the configuration key GetConfiguratinMaxKeys.

EVCC sollte zuerst den Wert GetConfiguratinMaxKeys von der Wallbox abfragen und ggf. die getconfiguration-Werte Chunk-weise laden, um eine vollständige Konfiguration zu erhalten. Da der Konfig-Parameter "getconfiguration : false" seit Version 0.130.? nicht mehr berücksichtigt wird, startet EVCC mit der o.g. Wallbox nicht mehr.

Steps to reproduce

1. Entsprechende OCPP-Wallbox in EVCC ab V0.130 konfigurieren
2. EVCC starten
3. Start schlägt mit "GenericError - Request timed out" fehl

Configuration details

chargers:
  - name: EntratekWallbox
    type: ocpp
    timeout: 10m
# funktionslos seit V0.130
#    getconfiguration: false
    connecttimeout: 10m

Log details

[ocpp  ] TRACE 2024/03/15 17:14:59 sent JSON message to xxx: [2,"2179812988","GetConfiguration",{}]
[main  ] FATAL 2024/03/15 17:15:59 cannot create charger 'EntratekWallbox': cannot create charger type 'ocpp': ocpp message (2179812988): GenericError - Request timed out

What type of operating system are you running?

Linux

Version

0.130.6

[andig]

Worth noting your box is not spec compliant if it times out. Thats an ugly FW bug 😞.

Instead of something complicated, we could just read them one by one? I do see the risk though that other boxes may fail on keys they don‘t recognize. I‘d rather hard-code that for the specific expection than generalize yet another mechanism that likely wont work.

[andig]

/cc @premultiply another use case for getconfiguration: false.

[premultiply]

@Kalli113 Bitte auch die ganze Spec dazu lesen und nicht nur den Abschnitt über eine Funktionalität (getConfiguration mit gezielter Angabe von einzelnen Konfigurationseinträgen) den wir überhaupt nicht nutzen und der hier gar nicht relevant ist.

[premultiply]

Bitte aktuelles Nightly verwenden und damit bitte die vollständige Ausgabe von evcc charger --log debug,ocpp:trace,db:error --diagnose

Konfig reduzieren auf

chargers:
  - name: EntratekWallbox
    type: ocpp

Das ist so leider sonst überhaupt nicht aussagekräftig.

[premultiply]

Die Box scheint kein grundsätzliches Problem mit getConfiguration([]) zu haben wie in diesem Issue gemutmaßt.
Siehe hier: #15612 Da klappt es.

Es wäre auch äusserst schwierig die Box irgendwo an irgendeinem CS anzumelden wenn auf ein unspezifisches getConfiguration([]) grundsätzlich nicht geantwortet würde.

Die angeführten Limitierungen beziehen sich ausschließlich auf die gezielte Abfrage einzelner Konfigurationseinträge.
Wird nirgends genutzt und daher nicht relevant. Wenn wir dies tun würden würden wir dies selbstverständlich berücksichtigen ;)

[andig]

…und dennoch zeigt das Log einen Timeout.

[premultiply]

Da hier im Log jegliche Referenz fehlt ist meine Glaskugel damit derzeit überfordert.

Bei ABB gab es übrigens schon mal ein ziemlich identisches Problem, was sich im Endeffekt dann durch den Factory Reset der Box einfach beheben ließ: #15533

[Kalli113]

Update 22:09 : Sorry, ich hatte das falsche Log angehangen:

@premultiply hier das Log von der aktuellen Nightly mit der von dir genannten OCPP-Konfiguration:

evcc.log

Leider gibt es von der Entratek-Wallbox unterschiedliche Versionen (siehe auch PDF von Entratek). Die im Thread #15612 #15612 genannte Wallbox ist eine neuere Revision, welche Bluetooth unterstützt und welche darüber auch ein Firmware-Update erhalten kann. Leider kann meine Wifi-Version der Wallbox kein Update erhalten und deswegen kann dieser ärgerliche Fehler in der Firmware wohl auch niemals behoben werden. Vom Hersteller ist leider keine Hilfe zu erwarten - ich habe alles versucht.

Bisher konnte ich mit der Angabe von "getconfiguration : false" in der OCPP-Konfig behelfen und die Wallbox funktionierte grundsätzlich problemlos. Leider ist genau das jetzt mit der neuen Version 0.130 entfallen.

Entschuldige, ich bin kein OCPP-Experte, aber der relevante Abschnitt in der Spec liest sich für mich so, dass eine leere Parameter-Liste OPTIONAL ist, d.h. es ist durchaus zulässig, dass der ChargePoint konkrete Parameter-Keys erwartet:

Welche GetConfiguration-Abfrage verwendet EVCC denn, wenn der o.g. Abschnitt es nicht ist? Ich bin in dem Spec-PDF nicht fündig geworden.

Ein ähnliches Problem gab es auch mit dieser Wallbox:
#10184

[andig]

For reference: hier gings mal los mit den workarounds: #6785

[premultiply]

Entschuldige, ich bin kein OCPP-Experte, aber der relevante Abschnitt in der Spec liest sich für mich so, dass eine leere Parameter-Liste OPTIONAL ist

Genau andersrum: Die gezielte Angabe und damit die Anfrage einzelner, spezifizierter Konfigurationsschlüssel in einer Liste ist optional und fällt - wenn verwendet - unter die in GetConfigurationMaxKeys angegebene Längenbeschränkung (der Anfrage-Liste!).

Der Standardfall ist ein leerer getConfiguration-Request bei dem der Charge Point mit der Liste aller seiner Konfigurationseinstellungen antworten MUSS ("...SHALL return...").

Andernfalls hätte man ja überhaupt keine Chance herauszufinden welche Konfigurationsschlüssel der Charge Point überhaupt kennt. Die wenigsten davon sind standardisiert.

[andig]

Nutzt ja alles nix, wenn das Ding auf den Request nicht antwortet…

[Kalli113]

OK, danke für eure Antworten. Ich dachte die grundsätzlichen Config-Keys wären standardisiert und könnten daher fix von EVCC abgefragt werden.
Ich weiß ja nicht, was die krude deutsche Übersetzung "Get Configuration : Ja. Max. 4 Keys jedes Mal" in dem Entratek-PDF sonst zu bedeuten hat. Evtl. würde die Box auf einen konkreten Request mit maximal 4 Parametern antworten, aber das ist reine Spekulation.

Wie könnte man alternativ die Parameter manuell festlegen? Ich bin es ja gewohnt, dass ich EVCC wegen des OCPP-Websocket-Path-Problems schon manuell anpassen muss, da kommt es auf ein paar mehr Parameter auch nicht an. :)

[premultiply]

Ich dachte die grundsätzlichen Config-Keys wären standardisiert und könnten daher fix von EVCC abgefragt werden.

Ist auch so. Teilweise sind sie standardisiert.
Man darf auch für den Charger möglicherweise unbekannte Custom-Keys anfragen.

Das könnte man prinzipiell auch machen, ist aber mit einem entsprechenden Overhead und zusätzlicher Verzögerung durch die jeweiligen round-trip-Zeiten verbunden. So wirklich schön und performant ist das definitiv nicht.
Und wie immer müsste man dann auch noch hoffen, dass es nicht wieder andere Boxen gibt die keine spezifizierten getConfiguration-Anfragen unterstützen...

[andig]

Guten morgen. Was ist denn hier der Lösungsvorschlag?

[premultiply]

Bin mir noch unschlüssig.
Müssen wir mal durchsprechen und ggf. auch erstmal verschiedene Ansätze testen.
Denn bisher ist es erstmal nur eine Theorie dass es überhaupt mit Einzelabfragen funktioniert.

[andig]

Deshalb würde ich das gerne ausprobieren. Genau das war die Idee oben.

[Kalli113]

Ich stelle mich sehr gerne als Tester zur Verfügung.

[andig]

Ich denke, @premultiply fehlt erstmal und weiterhin ein Log...

[Kalli113]

@andig Welches Log fehlt denn? Ich hatte bereits vorgestern dieses Log bereit gestellt:

evcc.log

[andig]

@premultiply ?

[andig]

Wie wollen wir hier weiter machen?

[premultiply]

Erstmal einen Testballon einbauen um zu sehen ob überhaupt irgendwas funktioniert und die Theorie zu bestätigen.

Sollte damit etwas mehr funktionieren wäre dann ggf. nochmal abzuwägen ob hier der Aufwand/Nutzen in Relation stehen um diese alte Firmware auch noch irgendwie zu unterstützen.

@Kalli113 Hattest du eigentlich schon mal beim tatsächlichen Hersteller der Box (Uchen) angefragt welche Möglichkeiten die noch ggf. für ein FW-Upgrade sehen/haben.
http://www.uchen.com.cn/en/products.php?tid=64&pid=64

[Kalli113]

@premultiply Ich bin mir ziemlich sicher, dass ich es mit einem chinesischen Support-Team zu tun hatte. Die Mails von denen kamen meistens Nachts an. Auch wenn die sich hinter einer Entratek-Email verbargen, kann ich mir gut vorstellen, dass ich in Wirklichkeit mit Uchen-Mitarbeitern Kontakt hatte. Ich kann ja nochmal mein Glück direkt bei Uchen versuchen, aber viel Hoffnung habe ich nicht.

[Kalli113]

Ich bin mit Uchen leider nicht wirklich voran gekommen:
Nachdem sich anfangs recht zügig eine Support-Mitarbeiterin bei mir mit den Worten "We can update the firmware, but need the wallbox online" gemeldet hat, habe ich meine Entratek-Wallbox mit dem backend cpam3.x-cheng.com:443/ocpp verbunden. Anschließed wurde meine Entratek-Wallbox in der DS Charge-App auch für wenige Stunden "online" angezeigt, danach nicht mehr. Und "Mary" hat sich seit dem (auch auf Rückfrage) nie wieder gemeldet.... :(

[andig]

Tentatively closing, since logfile is missing this might be identical to #15991

[Kalli113]

@andig @premultiply leider hat #15991 nicht geholfen.
Es gibt auch mit der 0.130.11 weiterhin einen Timeout nach dem getConfiguration-Request an meiner Entratek Power Dot Pro:

evcc charger --log debug,ocpp:trace,db:error --diagnose
[main  ] INFO 2024/09/16 15:06:37 evcc 0.130.11 (3eb1ae0c)
[main  ] INFO 2024/09/16 15:06:37 using config file: /etc/evcc.yaml
[ocpp-1] DEBUG 2024/09/16 15:06:38 waiting for chargepoint: 5m0s
[ocpp  ] INFO 2024/09/16 15:06:45 charge point connected, registering: 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:45 enqueued CALL [1843403095, ChangeAvailability] for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:45 dispatched request 1843403095 for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:45 sent JSON message to 03xxxxxxxxxxxxxxxxxx: [2,"1843403095","ChangeAvailability",{"connectorId":0,"type":"Operative"}]
[ocpp  ] TRACE 2024/09/16 15:06:45 started timeout timer for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:51 received JSON message from 03xxxxxxxxxxxxxxxxxx: [2, "0c39d5b4-66e8-498d-f4c6-fdcadf5fe334", "StatusNotification", {"connectorId": 1, "errorCode": "NoError", "info": "", "status": "Available", "vendorId": ""}]
[ocpp  ] TRACE 2024/09/16 15:06:51 handling incoming CALL [0c39d5b4-66e8-498d-f4c6-fdcadf5fe334, StatusNotification] from 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:51 sent CALL RESULT [0c39d5b4-66e8-498d-f4c6-fdcadf5fe334] for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:51 sent JSON message to 03xxxxxxxxxxxxxxxxxx: [3,"0c39d5b4-66e8-498d-f4c6-fdcadf5fe334",{}]
[ocpp  ] TRACE 2024/09/16 15:06:53 received JSON message from 03xxxxxxxxxxxxxxxxxx: [3, "1843403095", {"status": "Accepted"}]
[ocpp  ] TRACE 2024/09/16 15:06:53 handling incoming CALL RESULT [1843403095] from 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:53 completed request 1843403095 for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:53 03xxxxxxxxxxxxxxxxxx ready to transmit again
[ocpp  ] TRACE 2024/09/16 15:06:53 timeout canceled for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:53 enqueued CALL [3070159396, GetConfiguration] for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:53 dispatched request 3070159396 for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:53 sent JSON message to 03xxxxxxxxxxxxxxxxxx: [2,"3070159396","GetConfiguration",{}]
[ocpp  ] TRACE 2024/09/16 15:06:53 started timeout timer for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:54 received JSON message from 03xxxxxxxxxxxxxxxxxx: [2, "0c39e1fb-66e8-4990-ff94-7ccf6c4aca2f", "StatusNotification", {"connectorId": 1, "errorCode": "NoError", "info": "", "status": "Available", "vendorId": ""}]
[ocpp  ] TRACE 2024/09/16 15:06:54 handling incoming CALL [0c39e1fb-66e8-4990-ff94-7ccf6c4aca2f, StatusNotification] from 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:54 sent CALL RESULT [0c39e1fb-66e8-4990-ff94-7ccf6c4aca2f] for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:06:54 sent JSON message to 03xxxxxxxxxxxxxxxxxx: [3,"0c39e1fb-66e8-4990-ff94-7ccf6c4aca2f",{}]
[ocpp  ] TRACE 2024/09/16 15:07:01 received JSON message from 03xxxxxxxxxxxxxxxxxx: [2, "0c39fb3d-66e8-4997-0eed-56755432f86a", "Heartbeat", {}]
[ocpp  ] TRACE 2024/09/16 15:07:01 handling incoming CALL [0c39fb3d-66e8-4997-0eed-56755432f86a, Heartbeat] from 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:07:01 sent CALL RESULT [0c39fb3d-66e8-4997-0eed-56755432f86a] for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:07:01 sent JSON message to 03xxxxxxxxxxxxxxxxxx: [3,"0c39fb3d-66e8-4997-0eed-56755432f86a",{"currentTime":"2024-09-16T15:07:01Z"}]
[ocpp  ] TRACE 2024/09/16 15:07:05 received JSON message from 03xxxxxxxxxxxxxxxxxx: [2, "0c3a0a06-66e8-499a-672f-f729043b37b2", "StatusNotification", {"connectorId": 1, "errorCode": "NoError", "info": "", "status": "Available", "vendorId": ""}]
[ocpp  ] TRACE 2024/09/16 15:07:05 handling incoming CALL [0c3a0a06-66e8-499a-672f-f729043b37b2, StatusNotification] from 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:07:05 sent CALL RESULT [0c3a0a06-66e8-499a-672f-f729043b37b2] for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:07:05 sent JSON message to 03xxxxxxxxxxxxxxxxxx: [3,"0c3a0a06-66e8-499a-672f-f729043b37b2",{}]
[ocpp  ] TRACE 2024/09/16 15:07:23 timeout for client 03xxxxxxxxxxxxxxxxxx, canceling message
[ocpp  ] TRACE 2024/09/16 15:07:23 completed request 3070159396 for 03xxxxxxxxxxxxxxxxxx
[ocpp  ] TRACE 2024/09/16 15:07:23 request 3070159396 for 03xxxxxxxxxxxxxxxxxx timed out
[ocpp  ] TRACE 2024/09/16 15:07:23 03xxxxxxxxxxxxxxxxxx ready to transmit again
[main  ] FATAL 2024/09/16 15:07:23 cannot create charger 'EntratekWallbox': cannot create charger type 'ocpp': timeout

Gibt es eine Chance, dass ich die Konfigurationswerte selbst fix im Code vorgeben kann so wie die Werte vor der 0.130 mit "getconfiguration : false" vorbelegt waren? Dann könnte ich wenigstens von neuen EVCC-Versionen profitieren (insb. die Vehicles-Integrationen, die regelmäßige Pflege erfordern) und ihr braucht nicht extra für diese "spezielle" Wallbox einen Workaround implementieren.

[andig]

@premultiply soweit ich das sehe antwortet die Box auch mit 0.130.11 einfach gar nicht auf GetConfiguration. Was machen wir damit? Mein Vorschlag wäre das zu akzeptieren und danach "best effort" als Box ohne Zähler weiter zu machen. Alternativ bräuchten wir die Möglichkeit, GetConfiguration vollständig zu deaktivieren oder key-weise abzuklappern.

[andig]

@Kalli113 wir haben uns intern dazu abgestimmt, dass wir hier keine Anpassung machen wollen. Der WR verhält sich völlig abnormal. Wenn Du selbst einen PR machen willst (Parameterlösung oder auf Timeout warten und ignorieren) schauen wir uns das gerne an. Leider fehlt die Kapazität, jeder letzten Sondernlocke nachzulaufen :(

Closing as wontfix.