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.130.7
2. Update auf 0.130.8
   ...

Configuration details

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

interval: 10s # 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: sunspec-inverter
    usage: pv
    modbus: tcpip
    id: 1
    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-gen24
    usage: battery
    host: 192.168.1.248
    port: 502
  - 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: SmartTLinks
    stationid: Ladestation
    connector: 1
    type: template
    template: ocpp
    connecttimeout: 10m
    timeout: 5m
    meterinterval: 60s
  - name: SmartTRechts
    stationid: Ladestation
    connector: 2
    type: template
    template: ocpp
    connecttimeout: 10m
    timeout: 5m
    meterinterval: 60s
#- name: fritzdect
#  type: template
#  template: fritzdect
#  uri: https://192.168.1.254 # FRITZ!Box ip address (local)
#  user: xxx # 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: 250
  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.8

[andig]

Bitte 0.130.3 probieren. Sollte behoben sein.

[andig]

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

[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?

[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.

[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.

[andig]

Deine WB trennt die Verbindung:

charge point disconnected: Webergasse

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

/cc @premultiply

[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.

[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...

[mfuchs1984]

Ok, ich sehe in den logs auch jeweils nur eine StatusNotification, für einen der beiden Connectors. Kannst du mal Ladestation + evcc neu starten?

[benesolar]

• Station neugestartet
• nach 90 Sekunden EVCC neugestartet

evcc-20250208-102523-trace.log

[benesolar]

es verbindet auch immer die letzte Ladestation im Log:

[Ladestation-2] DEBUG 2025/02/08 09:48:02 !! registering Ladestation:2
[Ladestation-1] DEBUG 2025/02/08 09:48:02 !! registering Ladestation:**1**
...
[Ladestation-1] DEBUG 2025/02/08 09:53:02 !! connected Ladestation:**1**

[Ladestation-1] DEBUG 2025/02/08 09:56:06 !! registering Ladestation:1
[Ladestation-2] DEBUG 2025/02/08 09:56:06 !! registering Ladestation:**2**
...
[Ladestation-2] DEBUG 2025/02/08 10:01:06 !! connected Ladestation:**2**

[Ladestation-2] DEBUG 2025/02/08 10:19:17 !! registering Ladestation:2
[Ladestation-1] DEBUG 2025/02/08 10:19:17 !! registering Ladestation:**1**
...
[Ladestation-1] DEBUG 2025/02/08 10:24:17 !! connected Ladestation:**1**

[Ladestation-2] DEBUG 2025/02/08 10:33:36 !! registering Ladestation:2
[Ladestation-1] DEBUG 2025/02/08 10:33:36 !! registering Ladestation:**1**
..
[Ladestation-1] DEBUG 2025/02/08 10:38:36 !! connected Ladestation:**1**

[mfuchs1984]

Danke, ich denke das ist ein Schritt nach vorne. Ich schau mir mal die Connection Handler an, es sieht so aus, also würde der für den jeweils anderen Chargepoint nicht aufgerufen.

[mfuchs1984]

Wir haben hier einen Chargepoint mit zwei Connectors. Ich glaube für diese Konstellation ist noch was nicht ganz richtig.

[mfuchs1984]

Ich glaube, evcc wartet hier auf zwei Connections, während es nur eine für beide Connectors gibt. Ich untersuche das nochmal genauer.

[mfuchs1984]

Ich denke ich hab was gefunden. Ist erstmal unabhängig vom caching des status, betrifft aber OCPP Ladestationen mit mehreren Connectors. Melde mich wenn ich mehr weiß.

[andig]

@mfuchs im master failed jetzt auch ab und an der Ocpp Test. Irgendwas ist flakey.

[mfuchs1984]

#18705

[mfuchs1984]

Ich habe selbst leider keinen dual Charger, kann also nicht abschließend testen, ob der neue Code komplett damit kompatibel ist. Habe aber dennoch einmal zwei Ladepunkte konfiguriert und so den Deadlock gefunden.

Unabhängig davon wissen wir aber schon, dass die Änderung bei Chargern ohne RemoteTrigger funktioniert, die vorher nicht initialisiert werden konnten.

[benesolar]

[main ] FATAL 2025/02/10 03:56:49 charger [SmartTLinks] cannot create charger 'SmartTLinks': cannot create charger type 'template': cannot create charger type 'ocpp': timeout

evcc-20250210-035920-trace.log

[premultiply]

Es fehlt irgendwie jegliche StatusNotification.

@benesolar Könntest du das mal bitte mit angesteckten Fahrzeugen wiederholen?

[benesolar]

Kann ich morgen abend machen.

Habe es nochmal probiert und EVCC hat erfolgreich gestartet!
Das hab ich auch wieder eingestellt: interval: 10s

evcc-20250210-065358-trace.log

[mfuchs1984]

Ja, wenn man sich die logs oben anschaut, sieht man nicht immer alle notwendigen StatusNotification Nachrichten. Es ist also ein wenig Glücksache und du brauchst ggf. mehrere Versuche bzw. musst auch die Wallbox neu starten.

[mfuchs1984]

Bin gespannt, ob die Steuerung funktioniert. (Aktuell meldet deine Ladestation "otherError", das sollte aber nix mit evcc zu tun haben.)

[benesolar]

Im Log der Ladestation selbst gibts laufend folgende Fehlermeldung:

10.02.2025 19:22:19 [INFO    ] Got message: [2,"3265300922","GetCompositeSchedule",{"connectorId":2,"duration":60}]
10.02.2025 19:22:19 [ERROR   ] (OCPP) Invalid Remote Command
10.02.2025 19:22:19 [ERROR   ] Sending callError: [4, "3265300922", "NotImplemented", "Action not known.", {}]

laut Programmierung der Ladestation fehlt hier
chargingRateUnit = "A"

[mfuchs1984]

Was man da sieht, ist, dass die Ladestation das GetCompositeSchedule Kommando nicht implementiert hat, das macht aber normalerweise nichts aus. Wo fehlt die chargingRateUnit? Bei GetCompositeSchedule ist sie optional laut OCPP specs
Optional. Can be used to force a power or current profile

[benesolar]

so steht es drinnen:

elif TheAction == "GetCompositeSchedule":
            if not ('connectorId' in TheParams and 'duration' in TheParams):
                self.error('(OCPP) Missing value in GetCompositeSchedule')
                return {'status': 'Rejected'}
            if "chargingRateUnit" in TheParams:
                if TheParams["chargingRateUnit"] != "A":
                    return {'status': 'Rejected'}
                else:
                    chargingRateUnit = "A"
            else:
                chargingRateUnit = "A"
            return self.OcppGetCompositeSchedule(TheParams['connectorId'], TheParams['duration'], chargingRateUnit)

[mfuchs1984]

Da sollte man doch im letzten else landen, connectorId ist drin, chargingRateUnit ist nicht in TheParams, also Ampere.

[mfuchs1984]

Sollte aber wie gesagt eh egal sein, evcc braucht das nicht zwingend.

[andig]

Laut https://github.com/lorenzodonini/ocpp-go/blob/master/ocpp1.6/smartcharging/get_composite_schedule.go#L36 Wäre das eine weitere an den Haaren herbei gezogene Erfindung. Bleibt die Frage, wo das reject dann her kommt?

[andig]

Die Fehlermeldung ist ja auch eine Andere: woher kommt das „action not known“?

[mfuchs1984]

@benesolar wo hast du denn den Codeausschnitt her?

[benesolar]

Sind ein paar .py Dateien auf der MikroSD Karte von der Station.

Der konkrete Abschnitt ist aus der TRM Datei.
In der Communicator Datei ist dann dieser Abschnitt Auskommentiert: # elif action_name == "GetCompositeScheduleRequest":

Aber hauptsache es funktioniert - morgen Abend hänge ich zwei Prüfboxen an die Ladesäule.

[mfuchs1984]

Spannend 😃

[premultiply]

Ist doch praktisch, dann kannst du alle Softwarefehler der Station selbst fixen. 👍🏼

[benesolar]

Funktioniert.

Fehlermeldung sind ab dem ersten Ladevorgang je Connector weg.
Auch nach dem abstecken der Autos.

evcc-20250211-174520-trace.log.txt

Herzlichen Dank @andig und @mfuchs1984 !

[mfuchs1984]

Mega!

[andig]

Die Blumen gebühren @mfuchs. HAMMER! 🥂

[mfuchs1984]

Naja, die Grundlage für den pull request kam von dir, ich hatte halt die Muße, das zu debuggen ;)