OCPP: Mennekes Smart Ladestation seit 0.130.8 Fehlerhaft

[benesolar]

Describe the bug

Hallo,

seit dem Update 0.130.0 startet die Ladung nicht mehr. Habe auch schon 0.130.3 getestet.

• charge power: not available
• charger out of sync: expected enabled, got disabled

evcc-20240825-152707-ocpp trace.log

Steps to reproduce

1. Funktionierende Config mit 0.129.0
2. Update auf 0.130.3 ...

Configuration details

network:
  schema: http
  host: evcc.local
  port: 7070

interval: 5s # control cycle interval

# database configuration for persisting charge sessions and settings
# database:
#   type: sqlite
#   dsn: <path-to-db-file>

# telemetry: true

# log settings
log: error
levels:
  core: error
  lp-1: error
  lp-2: error
  lp-3: error
  cache: error
  db: error
  ocpp: error

# meter definitions
meters:
  - name: grid
    type: template
    template: fronius-gen24
    usage: grid
    host: 192.168.1.248
    port: 502
  - name: pv1
    type: template
    template: fronius-gen24
    usage: pv
    host: 192.168.1.248
    port: 502
  - name: pv2
    type: template
    template: fronius-solarapi-v1
    usage: pv
    host: 192.168.1.249
    port: 502
  - name: pv3
    type: custom
    power:
      source: sunspec
      id: 240
      uri: 192.168.1.249:502
      value:
        - 201:W
        - 211:W
  - name: battery
    type: template
    template: fronius-solarapi-v1
    usage: battery
    host: 192.168.1.248
    user: customer
    password: xxx
  - name: EVSE-DIN
    type: template
    template: eastron
    # RS485 via adapter (Modbus RTU)
    modbus: rs485serial
    id: 2
    device: /dev/ttyUSB0 # USB-RS485 Adapter Adresse
    baudrate: 9600
    comset: "8N1" # Kommunikationsparameter für den Adapter

# charger definitions
chargers:
  - name: EVSE-DIN
    type: template
    template: evse-din
    # RS485 via adapter (Modbus RTU)
    modbus: rs485serial
    id: 1
    device: /dev/ttyUSB0 # USB-RS485 Adapter Adresse
    baudrate: 9600 
    comset: "8N1" # Kommunikationsparameter für den Adapter
  - name: SmartTRechts
    stationid: Webergasse
    connector: 1
    type: template
    template: ocpp
    connecttimeout: 5m
    timeout: 10m
    autostart: true
    bootnotification: false
    meterInterval: 60s
    metervalues: Energy.Active.Import.Register
  - name: SmartTLinks
    stationid: Webergasse
    connector: 2
    type: template
    template: ocpp
    connecttimeout: 5m
    timeout: 10m
    autostart: true
    bootnotification: false
    meterInterval: 60s
    metervalues: Energy.Active.Import.Register
#- name: fritzdect
#  type: template
#  template: fritzdect
#  uri: https://192.168.1.254 # FRITZ!Box ip address (local)
#  user: fritz3914 # FRITZ!Box username (Has to have Smart Home privileges!)
#  password: xxx # FRITZ!Box password
#  ain: 'xxx' # switch actor identification number without blanks (see AIN number on switch sticker)
#  standbypower: 10 # treat as charging above this power

# vehicle definitions
vehicles:
  - name: polestar
    type: template
    template: polestar
    title: Polestar 2
    identifiers:
      - 043768e29a7xxx # RFID token ID
    mode: pv
    user: xxx
    password: xxx
    vin: YSMVSxxx
    capacity: 75
  - name: BMW
    type: custom
    title: BMW IX1
    capacity: 64.7
    identifiers:
      - 041f64eacd1xxx
    onIdentify:
      mode: pv
#  - name: scooter
#    type: template
#    template: niu-e-scooter
#    title: scooter # Wird in der Benutzeroberfläche angezeigt # Optional
#    user: xxx # Benutzerkonto (bspw. E-Mail Adresse, User Id, etc.)
#    password: xxx # Passwort des Benutzerkontos (bei führenden Nullen bitte in einfache Hochkommata setzen)
#    serial: Nxxx
#    capacity: 4 # Akku-Kapazität in kWh # Optional 

# site describes the EVU connection, PV and home battery
site:
  title: Zuhause # display name for UI
  meters:
    grid: grid # grid meter
    pv: # list of pv inverters/ meters
    - pv1
    - pv2
    - pv3
    battery: battery # battery meter
  prioritySoC: # give home battery priority up to this soc (empty to disable)
  bufferSoC: # ignore home battery discharge above soc (empty to disable)
  residualPower: 100
  circuit: main

circuits:
  - name: main
    maxCurrent: 35
    meter: grid

# loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
  - title: Garage # display name for UI
    charger: EVSE-DIN # charger
    meter: EVSE-DIN # charge meter
    phases: 0 # ev phases (default 3)
    enable: # pv mode enable behavior
      delay: 1m # threshold must be exceeded for this long
      threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
    disable: # pv mode disable behavior
      delay: 3m # threshold must be exceeded for this long
      threshold: 0 # maximum import power (W)
    guardDuration: 5m # switch charger contactor not more often than this (default 5m)
  - title: LadesäuleRechts
    charger: SmartTRechts
    mode: off
    phases: 0
    enable: # pv mode enable behavior
      delay: 1m # threshold must be exceeded for this long
      threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
    disable: # pv mode disable behavior
      delay: 4m # threshold must be exceeded for this long
      threshold: 0 # maximum import power (W)
    guardDuration: 5m # switch charger contactor not more often than this (default 5m)
  - title: LadesäuleLinks
    charger: SmartTLinks
    mode: off
    phases: 0
    enable: # pv mode enable behavior
      delay: 1m # threshold must be exceeded for this long
      threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
    disable: # pv mode disable behavior
      delay: 4m # threshold must be exceeded for this long
      threshold: 0 # maximum import power (W)
    guardDuration: 5m # switch charger contactor not more often than this (default 5m)
#  - title: Schuko
#    charger: fritzdect
#    meter:
#    vehicle:
#    mode: pv
#    soc:
#    # polling defines usage of the vehicle APIs
#    # Modifying the default settings it NOT recommended. It MAY deplete your vehicle's battery
#    # or lead to vehicle manufacturer banning you from API use. USE AT YOUR OWN RISK.
#    poll:
      # poll mode defines under which condition the vehicle API is called:
      #   charging: update vehicle ONLY when charging (this is the recommended default)
      #   connected: update vehicle when connected (not only charging), interval defines how often
      #   always: always update vehicle regardless of connection state, interval defines how often (only supported for single vehicle)
#    mode: charging
      # poll interval defines how often the vehicle API may be polled if NOT charging
#      interval: 60m
#      min: 0 # immediately charge to 0% regardless of mode unless "off" (disabled)
#      target: 100 # always charge to 100%
#      estimate: false # set true to interpolate between api updates
#      phases: 1 # ev phases (default 3)
#    enable: # pv mode enable behavior
#      delay: 1m # threshold must be exceeded for this long
#      threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
#    disable: # pv mode disable behavior
#      delay: 5m # threshold must be exceeded for this long
#      threshold: 200 # maximum import power (W)
#    guardDuration: 5m # switch charger contactor not more often than this (default 10m)
#    minCurrent: 6 # minimum charge current (default 6A)
#    maxCurrent: 16 # maximum charge current (default 16A)

# tariffs are the fixed or variable tariffs
tariffs:
  currency: EUR
  grid:
    # either static grid price (or price zones)
    type: fixed
    price: 0.2073 # EUR/kWh
  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.07 # EUR/kWh
# push messages
messaging:
  events:
    start: # charge start event
      title: Ladung von {{.vehicleTitle}} gestarted
      msg: |
        {{.title}} Begann Ladung von {{.vehicleTitle}} im {{ toString .mode | upper }} Modus.
    stop: # charge stop event
      title: Ladung von {{.vehicleTitle}} pausiert
      msg: |
        Ladung von {{.vehicleTitle}} pausiert
    connect: # vehicle connect event
      title: "{{.vehicleTitle}} verbunden mit {{.title}}"
      msg: |
        {{.vehicleTitle}} verbunden mit {{.title}} an {{round (divf .pvPower 1000) 2 }} kW PV.
    disconnect: # vehicle connected event
      title: "{{.vehicleTitle}} disconnected of {{.title}}"
      msg: |
        {{.vehicleTitle}} disconnected of {{.title}} nach {{.connectedDuration}}.
        Geladen {{round (divf .chargedEnergy 1000) 2 }} kWh in {{.chargeDuration}}.
  services:
    - type: telegram
      token: xxx # bot id
      chats:
      - -xxx # list of chat ids

Log details

Siehe Anhang

What type of operating system are you running?

Linux

Version

0.130.3

[andig]

Bitte 0.130.3 probieren. Sollte behoben sein.

[benesolar]

ich habe bereits 0.130.3 laufen - Fehler tritt auch da auf.

Komplettes Log: evcc-20240825-155251-trace.log

[andig]

Dann brauchts bitte ein Log mit site, loadpoint, ocpp auf trace. Sonst nix. Danke.

[benesolar]

Log mit beiden Anschlüssen der Ladestation: evcc-20240825-171151-trace.log

Hier nochmal der OCPP Log vom Start der Ladestation mit der Antwort auf GetConfiguration: evcc-20240825-152707-ocpp trace.log

[andig]

Bevor ich da versuche weiter einzusteigen: Du zwingst der Wallbox die Messwerte auf:

metervalues: Energy.Active.Import.Register

wunderst Dich dann aber, dass Leistung nicht dabei ist... Warum auch immer das bei den anderen Box geht, aber die Config ist ja einfach falsch. Tatsächlich scheint Connector 1 auch keine Leistung zu liefern, 2 aber sehr wohl. Warum auch immer.

@premultiply warum wir hier bei Connector 1 überhaupt Leistung dekoriert?

[benesolar]

Stand nach dem Update auf 0.130.4 und geänderter Config:

  - name: SmartTRechts
    stationid: Webergasse
    connector: 1
    type: template
    template: ocpp
    connecttimeout: 5m
    timeout: 2m
    bootnotification: false
  - name: SmartTLinks
    stationid: Webergasse
    connector: 2
    type: template
    template: ocpp
    connecttimeout: 5m
    timeout: 2m
    bootnotification: false

werden keine Fehlermeldungen mehr angezeigt, Ladung funktioniert.

evcc-20240825-204406-trace.log

Bei dem einen Ladepunkt werden im Aus und PV Modus 12 W Ladeleistung angezeigt. Hier misst der Zähler den Eigenverbrauch vom Controller der Ladestation.

[premultiply]

@andig Irgendwas stimmt hier noch nicht mit der Initialisierung bei mehreren Connectoren. Lass uns da nochmal gemeinsam nach schauen.

@benesolar

  - name: SmartTRechts
    stationid: Webergasse
    connector: 1
    type: template
    template: ocpp
  - name: SmartTLinks
    stationid: Webergasse
    connector: 2
    type: template
    template: ocpp

ist mehr als ausreichend.

[benesolar]

zu früh gefreut, ich habe die Einstellungen oben übernommen und auf 0.130.4+1724669427 aktualisiert:

[lp-2 ] ERROR 2024/08/27 12:39:52 charge power: not available
[lp-3 ] ERROR 2024/08/27 12:39:52 charge power: not available 

evcc-20240827-124057-trace.log

Logfile von der Ladestation selbst:

OCPP16.log

[andig]

Ja, sind wir dran...

[andig]

Test des angehängten PR wäre Klasse. Der ist ein bisschen zu groß, um ihn mal eben so zu mergen.

[benesolar]

Erst jetzt wieder möglich, Ladestation war defekt.

0.130.7: weiterhin charge power: not available bei den Anschlüssen wo kein Ladevorgang läuft.

0.130.7+1725675906: cannot create charger 'SmartTLinks': cannot create charger type 'template': cannot create charger type 'ocpp': timeout evcc-20240907-170440-trace.log

[andig]

@benesolar der timeout sollte jetzt auch behoben sein. Charge power bin ich unsicher, ggf. bräuchte es da nochmal ein Logfile.

[benesolar]

evcc 0.130.11 (81a31592) cannot create charger type 'ocpp': timeout

evcc-20240915-204603-trace.log

[andig]

Deine WB trennt die Verbindung:

charge point disconnected: Webergasse

Wäre eine Frage an den Herstellersupport möglich?

/cc @premultiply

[benesolar]

Ich starte immer die Ladestation und EVCC gleichzeitig neu, hängt eventuell damit zusammen? Hier ein neuer Log ohne disconnect.

evcc-20240915-213704-trace.log

Mit 0.130.7 funktioniert es.

Was genau soll ich den Hersteller fragen?

[premultiply]

Ich starte immer die Ladestation und EVCC gleichzeitig neu, hängt eventuell damit zusammen?

Mach mal bitte erst die Ladestation aus, starte dann evcc (neu) und dann die Ladestation wieder an.

[benesolar]

So kann ich es erst am Wochenende machen wenn ich wieder vorort bin.

Inzwischen ein log mit 0.130.7 falls es hilft: evcc-20240917-173511-trace.log

[andig]

[Webergasse-1] DEBUG 2024/09/15 21:31:29 waiting for chargepoint: 5m0s
[ocpp  ] TRACE 2024/09/15 21:31:29 error dispatching request [341681420, TriggerMessage] to Webergasse: cannot send request 341681420, no client Webergasse exists
[Webergasse-2] DEBUG 2024/09/15 21:31:29 failed triggering StatusNotification: cannot send request 341681420, no client Webergasse exists

Das ist maximal merkwürdig. -2 kommt völlig aus dem Nichts, ohne dass auch nur ein Ladepunkt verbunden wäre (@premultiply wo kommt das her?)

Dann fällt auf, dass die Box lower-case Config Keys benutzt, aber auf ChangeConfiguration in richtiger Schreibweise reagiert (@premultiply sollten wir das Einlesen case insensitive machen?).

Leider ergibt das Log (zumindest der Start) nicht viel Sinn für mich. Vielleicht liegts tatsächlich am gleichzeitigen Restart.

[benesolar]

Habe den Bereich in der .py gefunden der für ChangeConfiguration zuständig ist. .lower steht dort überall dabei

Ich denke ein Zitat daraus ist erlaubt: elif ConfigKey.lower() == 'HeartbeatInterval'.lower():

[andig]

Das heisst ja nicht, dass das irgendwie ein Standard wäre. Aber ja...

[premultiply]

In der Spec steht es eigentlich ganz klar als fester String mit Groß- und kleinbuchstaben drin. Aber warum einfach kopieren wenn man wieder irgendeine Sonderlocke in die Firmware bauen kann...

[andig]

@benesolar könntest Du dem Nightly nochmal eine Chance geben? Bitte erst evcc, dann WB starten damit wir ein sauberes Log bekommen.

[benesolar]

Hier die Logs mit dem gewünschten Prozedere:

0.130.7.log 0.130.11+1726846520.log

Weiterhin gleicher Fehler.

[mfuchs1984]

Kann es sein, dass evcc die verfügbaren MeterValuesSampledData nicht verarbeitet, da die wallbox diese in Hochkommata packt?

Aus der "configurationKey" Message: {"readonly": false, "key": "metervaluessampleddata", "value": "'Power.Active.Import', 'Energy.Active.Import.Register'"}

[andig]

Ähhhh…. Was soll denn der Mist jetzt wieder?! Es ist wirklich unglaublich, welchen Sch*** die sich da zusammen braten. Das lässt sich aber lösen 👍🏻

[premultiply]

🤦🏻‍♂️🙄

[andig]

@benesolar @premultiply ich verstehe das Log nicht. Der Anfang fehlt. Ich sehe

[Ladestation-1] DEBUG 2024/09/20 18:57:53 waiting for chargepoint: 5m0s
[ocpp  ] TRACE 2024/09/20 18:57:53 error dispatching request [3589246882, TriggerMessage] to Ladestation: cannot send request 3589246882, no client Ladestation exists
[Ladestation-2] DEBUG 2024/09/20 18:57:53 failed triggering StatusNotification: cannot send request 3589246882, no client Ladestation exists

Hier spricht evcc schon fröhlich mit der WB. Wo kommt das her wenn noch gar keine verbunden ist??? Das kann nicht sein.

[andig]

@benesolar ansonsten zeigt das Log keinen Fehler mehr. Was klappt denn jetzt noch nicht?

[benesolar]

das ist nur im main Log drinnen: cannot create charger type 'ocpp': timeout

Und dann ist zumindest in der funktionierenden 0.130.7 der Fehler charge power: not available auf den Ladepunkten wo kein Ladevorgang läuft.

[andig]

das ist nur im main Log drinnen: cannot create charger type 'ocpp': timeout

Ich seh da nix. Was ist das main log?

Und dann ist zumindest in der funktionierenden 0.130.7 der Fehler

...aber um das gehts ja nun schon seit 5 Releases nicht mehr.

Ich mache mal vorsichtig zu. Gerne nochmal komplettes Log fürs Nightly ab Start falls es noch einen Fehler gibt. https://github.com/evcc-io/evcc/issues/15677#issuecomment-2365099832 erweckt bei mir den Eindruck, als würden da Teile vom Log fehlen, warum auch immer.

[benesolar]

evcc 0.130.11 (4f51534b)

[main ] FATAL 2024/09/21 13:12:57 cannot create charger 'SmartTLinks': cannot create charger type 'template': cannot create charger type 'ocpp': timeout
[main ] FATAL 2024/09/21 13:12:57 will attempt restart in: 15m0s 

neue Log mit der gewohnten Vorgangsweise (Ladestation stromlos, EVCC neustart, Stromversorgung Ladestation ein): evcc-20240921-131707-trace.log deaktiviert sind nur db, modbus und sunspec

[andig]

Es bleibt leider dabei:

[main  ] INFO 2024/09/21 13:09:24 evcc 0.130.11 (4f51534b)
[main  ] INFO 2024/09/21 13:09:24 using config file: /etc/evcc.yaml
[main  ] INFO 2024/09/21 13:09:24 listening at :7070
[Ladestation-2] DEBUG 2024/09/21 13:09:32 waiting for chargepoint: 5m0s
[ocpp  ] TRACE 2024/09/21 13:09:32 error dispatching request [3813203135, TriggerMessage] to Ladestation: cannot send request 3813203135, no client Ladestation exists
[Ladestation-1] DEBUG 2024/09/21 13:09:32 failed triggering StatusNotification: cannot send request 3813203135, no client Ladestation exists

In deiner ganzen Config taucht die Vokabel Ladestation nicht auf. Woher kommt das also??? Wie kann evcc versuchen an ein Device zu schicken das nirgendwo konfiguriert ist?

[benesolar]

Sorry hab es in der EVCC Config auf Ladestation umbenannt.

 - name: SmartTLinks
    stationid: Ladestation
    connector: 1
    type: template
    template: ocpp
  - name: SmartTRechts
    stationid: Ladestation
    connector: 2
    type: template
    template: ocpp

Die Ladestation braucht offenbar eine gute Minute bis sie nach dem Start erreichbar ist. Und ich auch ca. bis ich beim Verteiler bin und den Leitungsschutzschalter wieder eingeschalten habe.

[andig]

Die Ladestation braucht offenbar eine gute Minute bis sie nach dem Start erreichbar ist.

Ok. Ich verstehe trotzdem nicht, wie es sein kann dass evcc da hin schickt bevor sich überhaupt etwas verbunden hat. Entweder fehlt uns ein Teil des Logs oder ich weiss es auch nicht :(

[andig]

In 30min gibts nochmal neues nightly. Mir ist weiterhin unklar, warum vor Setup kommuniziert werden kann. Es scheint ein Teil vom Log zu fehlen.

[benesolar]

evcc-20240922-202447-trace.log [main ] FATAL 2024/09/22 20:22:42 cannot create charger 'SmartTLinks': cannot create charger type 'template': cannot create charger type 'ocpp': timeout

[andig]

Also das Log zeigt den Fehler nicht?

[benesolar]

dafür das:

[ocpp  ] TRACE 2024/09/22 20:22:06 received JSON message from Ladestation: [2, "947e0a64-790f-11ef-8f09-000a1484c32e", "BootNotification", {"chargePointSerialNumber": "000a1484c32e", "chargePointVendor": "Mennekes", "meterType": "IEC61107", "meterSerialNumber": "", "chargePointModel": "ACUV4", "firmwareVersion": "3633"}]
[ocpp  ] TRACE 2024/09/22 20:22:06 handling incoming CALL [947e0a64-790f-11ef-8f09-000a1484c32e, BootNotification] from Ladestation

[Ladestation-1] DEBUG 2024/09/22 20:22:25 BootNotification timeout

[mfuchs1984]

@andig der Fehler ist im log aus Betrag https://github.com/evcc-io/evcc/issues/15677#issuecomment-2366908347

[main ] FATAL 2024/09/22 20:22:42 cannot create charger 'SmartTLinks': cannot create charger type 'template': cannot create charger type 'ocpp': timeout [main ] FATAL 2024/09/22 20:22:42 will attempt restart in: 15m0s

Allerdings sieht es aus, als ginge es danach einfach weiter.

[andig]

@benesolar erstmal tausend Dank für Deine Geduld! Es scheint als hätte die WB ein Zeitverhalten bei dem sie sich dann mit evcc beharkt. Ich denke ich habe den Fehler möglicherweise gefunden.

@premultiply schau mal bitte:

func (cs *CS) OnBootNotification(id string, request *core.BootNotificationRequest) (*core.BootNotificationConfirmation, error) {
    cp, err := cs.ChargepointByID(id)
    if err != nil {
        return nil, err
    }

    return cp.OnBootNotification(request)
}

Ich vermute, dass wir dem Chargepoint hier gar nicht antworten solange er noch nicht registriert ist. M.E. sollten auch alle CS Handler- so der CP nicht gefunden wird- immer eine Antwort zurück geben so wie wir das an anderer Stelle mit den Connections auch machen? PR to follow: https://github.com/evcc-io/evcc/pull/16279.

[andig]

Nightly ist aktualisiert.

[benesolar]

Danke auch für die Geduld mit meiner Ladestation 😀

Leider weiterhin: cannot create charger 'SmartTLinks': cannot create charger type 'template': cannot create charger type 'ocpp': timeout

evcc-20240923-111623-trace.log.txt

[andig]

Nightly in 20min. Neue Problem (danke Mennekes) ist, dass die WB den Status Request für den Connector zwar akzeptiert, aber nie antwortet...

[benesolar]

[main ] FATAL 2024/09/25 22:44:01 cannot create charger 'SmartTRechts': cannot create charger type 'template': cannot create charger type 'ocpp': timeout

evcc-20240925-224845-trace.log

[premultiply]

@andig:

Ursache: Innerhalb von Timeout bzw. Timeout/2 bekommen die Konnektoren keine StatusNotification nach der Initialiserung des CP. Weder indirekt über CP noch über die Konnektoren.

Einfache Dinge die noch zu probieren wären, in der Hoffnung dass Mennekes die angetriggerte Nachricht nur erst viel später schickt:

• Init-Timeout der Konnectoren (auch) auf ConnectTimeout statt fest auf 30s legen. -
• Bei der Initialisierung der Konnektoren immer gleich eine StatusNotification antriggern (statt nur als Rettungsanker nach Timeout/2).

Erweiterter möglicher Lösungsweg:

• Letzte eingegangene StatusNotification pro Konnektor immer am CP cachen. Egal ob Charger verbunden oder nicht und beim Konnektor-Verbinden nur passiv prüfen ob Connector-ID plausibel ist (<= Gesamtzahl der vom CP gemeldeten Konnektoren) und schon mal für den gewünschten Konnektor jemals ein valider Status eingangen ist.

[andig]

Letzteres. Ich mache Vorschlag.

[benesolar]

Über eine Lösung wäre ich dankbar. Kann ich hier irgendwie unterstützen?

[andig]

Ich hab nochmal einen Versuch gemacht. Könntest Du den lokal bauen (oder in Docker ausprobieren)?

[benesolar]

Damit kenne ich mich nicht aus. Mit einem nightly könnte ich es testen.

[andig]

@benesolar könntest Du heute testen? Dann würde ich es jetzt mal probehalber ins nightly schubsen.