OCPP: Keine MeterValues-Messages / kein automatischer Start / ChargePointMaxProfile

[heppth]

Hallo,

ich teste gerade die OCPP-Implementierung der WARP 2 (FW 2.1.3). Dabei sind mir folgende Dinge aufgefallen.

Keine MeterValues-Messages:
Von anderen Wallboxen bin ich es gewohnt, dass während des Ladevorgangs MeterValues-Messages eintreffen. Allerdings erscheinen keine MeterValues-Messages. (Zähler ist nachträglich verbaut, alle Werte werden in der WebUI angezeigt)

Kein automatischer Start:
In den Ladeeinstellungen ist "Manuelle Ladefreigabe" deaktiviert. Weiterhin ist in der Benutzerverwaltung "Lade­freigabe" deaktiviert. Daher ging ich davon aus, dass die Wallbox nach dem Einstecken/Bootvorgang sofort mit dem Laden anfängt. Dies ist aber nicht der Fall. Ich benötige noch eine RemoteStartTransaction-Message

ChargePointMaxProfile:
Der OCPP-Server soll der Wallbox vorgeben, wie schnell sie lädt. Wenn eine SetChargingProfile-Message mit TxDefaultProfile geschickt wird, reagiert die Wallbox sofort und passt den Ladestrom an. Eine Message mit ChargePointMaxProfile scheint die Wallbox allerdings zu ignorieren. Wie ist hier der Stand?

Gruß
Thomas

bearbeitet June 29, 2023 at 09:36 von heppth

[rtrbt]

On 6/29/2023 at 11:33 AM, heppth said:

Keine MeterValues-Messages:
Von anderen Wallboxen bin ich es gewohnt, dass während des Ladevorgangs MeterValues-Messages eintreffen. Allerdings erscheinen keine MeterValues-Messages. (Zähler ist nachträglich verbaut, alle Werte werden in der WebUI angezeigt)

Das ist in der Tat seltsam. Ich kann das hier auch nachstellen. Die Default-Einstellung ist, dass Meter.Active.Import.Register (lies: der Stromzählerwert) alle 60 Sekunden geschickt werden soll. Das funktioniert bei mir aber erst, wenn ich einmal ein ChangeConfiguration schicke, dass MeterValuesAlignedData auf den Wert konfiguriert (und dann neustarte weil ChangeConfiguration mit RebootRequired antwortet). Ich debugge das und melde mich nochmal.

On 6/29/2023 at 11:33 AM, heppth said:

Kein automatischer Start:
In den Ladeeinstellungen ist "Manuelle Ladefreigabe" deaktiviert. Weiterhin ist in der Benutzerverwaltung "Lade­freigabe" deaktiviert. Daher ging ich davon aus, dass die Wallbox nach dem Einstecken/Bootvorgang sofort mit dem Laden anfängt. Dies ist aber nicht der Fall. Ich benötige noch eine RemoteStartTransaction-Message

Das ist im Moment korrekt. Statt einer RemoteStartTransaction-Message kannst du auch ein NFC-Tag an die Wallbox halten. Dann schickt sie ein Authorize.req an den Server und wenn der das Tag autorisiert, beginnt der Ladevorgang.

Nach der OCPP-Spezifikation gibt es keine Möglichkeit einen komplett unautorisierten Vorgang zu starten, solange eine Verbindung zum Server besteht (also einen der weder vom Server durch eine Authorize.conf bestätigt, oder durch ein RemoteStartTransaction angefordert wurde). Das ist aber ein Modus, den wir gegebenfalls noch nachlegen wollen, gerade mit dem Gedanken, dass später ja auch Netzbetreiber Wallboxen per OCPP steuern wollen, ich da aber im Moment nicht davon ausgehe, das man denen eine Liste von NFC-Tags geben kann/muss.

On 6/29/2023 at 11:33 AM, heppth said:

ChargePointMaxProfile:
Der OCPP-Server soll der Wallbox vorgeben, wie schnell sie lädt. Wenn eine SetChargingProfile-Message mit TxDefaultProfile geschickt wird, reagiert die Wallbox sofort und passt den Ladestrom an. Eine Message mit ChargePointMaxProfile scheint die Wallbox allerdings zu ignorieren. Wie ist hier der Stand?

Das funktioniert in meinem Test. Bekommst du im Ereignis-Log Ausgaben, wenn du das Profile schickst? Bzw. spätestens alle 5 Minuten wertet die Wallbox alle konfigurierten Profile neu aus. Der Output ist dann z.B.:

2023-06-29 14:42:55,042  Evaluating charging profiles
2023-06-29 14:42:55,043      ChargePointMaxProfiles[1] applied.
2023-06-29 14:42:55,043      Connector 1
2023-06-29 14:42:55,053      Profile evaluation done. Distributing limit
2023-06-29 14:42:55,054      Currents distributed:
2023-06-29 14:42:55,064         ConnID  Allowed Phases  MinRate
2023-06-29 14:42:55,064         0       12.000  3       0.000
2023-06-29 14:42:55,075         1       12.000  3       0.000
2023-06-29 14:42:55,075      Next check: 2023-06-29T20:00:00Z
2023-06-29 14:42:55,085  
2023-06-29 14:42:55,086  Setting connector 1 limit to 12000

(Ich habe testweise ein ChargePointMaxProfile installiert, dass den Strom von 8 bis 20 Uhr UTC auf 12 Ampere limitiert)

Bekommst du ähnliche Ausgaben?

[rtrbt]

Update: Den Bug mit der Defaulteinstellung der Zählerwerte habe ich gefunden und gefixt. Firmware mit dem Fix ist im Anhang.

warp2_firmware_2_1_3_649d9785_e8d76a17697a077_merged.bin

[heppth]

Wow das ging ja schnell. Super Service!

Zwei Fragen noch:

• Ist es möglich/angedacht, dass nur eine WARP-Wallbox eine OCPP-Verbindung aufbaut und andere WARP-Wallboxen als zusätzlicher Connector auftauchen? Oder muss jede Wallbox seine eigene OCPP-Verbindung aufbauen?
• Werden nun in der MeterValues-Message auch Ströme, Spannung, etc. geschickt?

[rtrbt]

On 7/5/2023 at 7:53 AM, heppth said:

Wow das ging ja schnell. Super Service!

Immer gerne :)

 

On 7/5/2023 at 7:53 AM, heppth said:

Ist es möglich/angedacht, dass nur eine WARP-Wallbox eine OCPP-Verbindung aufbaut und andere WARP-Wallboxen als zusätzlicher Connector auftauchen? Oder muss jede Wallbox seine eigene OCPP-Verbindung aufbauen?

Ist im Moment nicht geplant. Was wäre dein Use-Case dafür? (Wenn der gut ist, kann man die Planung ja ändern ;) )

 

On 7/5/2023 at 7:53 AM, heppth said:

Werden nun in der MeterValues-Message auch Ströme, Spannung, etc. geschickt?

In der Standardeinstellung nicht. Du kannst aber per ChangeConfiguration den MeterValuesAlignedData-Wert ändern um mehr Zählermesswerte zu bekommen. Alle Zählerwerte, die OCPP ansich kennt findest du hier: https://github.com/Tinkerforge/tfocpp/blob/master/spec/ocpp-1.6 edition 2.pdf auf Seite 86 und 87 (der Abschnitt 7.31. Measurand)

Im Moment unterstützen wir folgende, wenn du einen SDM72V2 verbaut hast:

Energy.Active.Export.Register,Energy.Active.Import.Register,Energy.Reactive.Export.Register,Energy.Reactive.Import.Register,Power.Active.Export,Power.Active.Import,Power.Offered,Power.Reactive.Export,Power.Reactive.Import,Power.Factor,Current.Import,Current.Export,Current.Offered,Voltage,Frequency

bzw. folgende wenn du einen SDM630 verbaut hast:

Energy.Active.Export.Register,Energy.Active.Import.Register,Energy.Reactive.Export.Register,Energy.Reactive.Import.Register,Power.Active.Export,Power.Active.Import,Power.Reactive.Export,Power.Reactive.Import,Power.Factor,Current.Offered,Voltage,Frequency

(das ist direkt die kommaseparierte Liste, die du per ChangeConfiguration schicken kannst)

Beim SDM630 fehlen Current.Import, Current.Export und Power.Offered. Die sollten eigentlich verfügbar sein, sehe ich nochmal nach: https://github.com/Tinkerforge/esp32-firmware/issues/259

 

[heppth]

Am 5.7.2023 um 14:51 schrieb rtrbt:

Ist im Moment nicht geplant. Was wäre dein Use-Case dafür? (Wenn der gut ist, kann man die Planung ja ändern ;) )

Es wäre deutlich einfacher, wenn man 10 Wallboxen hat und nur ein Mal den maximalen Strom via OCPP vorgeben müsste und die 10 Wallboxen den Strom unter sich aufteilen.

Die MeterValues (sowohl Aligned­Data als auch SampleData) werden nun einwandfrei übertragen. Perfekt!

Das einzige was mich noch etwas wundert ist, dass ChargingLimit ignoriert wird. Hier ein Auszug aus meinem Log:

16:50:08.112  INFO  OCPP: Sent following message to warp2-22p6: SetChargingProfile: {
  "connectorId": 0,
  "csChargingProfiles": {
    "chargingProfileId": 1,
    "stackLevel": 0,
    "chargingProfilePurpose": "ChargePointMaxProfile",
    "chargingProfileKind": "Absolute",
    "chargingSchedule": {
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        {
          "startPeriod": 0,
          "limit": 9
        }
      ]
    }
  }
}
16:50:08.293  INFO  OCPP: warp2-22p6 sent Result: {
  "status": "Accepted"
}

Hier ein Log-Auszug aus der Wallbox:

2023-07-05 17:00:08,008  Evaluating charging profiles
2023-07-05 17:00:08,010      Connector 1
2023-07-05 17:00:08,010      TxDefaultProfiles[0] applied
2023-07-05 17:00:08,020      Profile evaluation done. Distributing limit
2023-07-05 17:00:08,021      Currents distributed:
2023-07-05 17:00:08,031          ConnID    Allowed    Phases    MinRate
2023-07-05 17:00:08,031          0    32.000    3    0.000
2023-07-05 17:00:08,042          1    11.000    3    0.000
2023-07-05 17:00:08,042      Next check: never
2023-07-05 17:00:08,042  
2023-07-05 17:00:08,053  Setting connector 1 limit to 11000

Basierend auf der Spezifikation dachte ich, dass das niedrigste Limit zählt, wenn sowohl TxDefaultProfile als auch ChargePointMaxProfile gesetzt ist.

[rtrbt]

tl;dr: Nach meiner Interpretation der Spec wirkt ein ChargePointMaxProfile, dass als Kind "Absolute", aber keinen scheduleStart-Wert gesetzt hat, nie. Das ist aber streitbar. Wenn du scheduleStart auf einen Zeitpunkt in der Vergangenheit setzt funktionierts.

Hm das ist ein sehr spezifischer Fall, den du da erzeugst.

Das ChargingProfile hat als Kind "Absolute". Laut Spec

Quote

Absolute
 Schedule periods are relative to a fixed point in time defined in the schedule.

(Hervorhebung von mir)

Der ChargingSchedule hat aber keinen startSchedule gesetzt. Wieder laut Spec

Quote

startSchedule
 dateTime
 0..1
 Optional. Starting point of an absolute schedule. If absent the schedule will be relative to start of charging.

Nach meiner Interpretation heißt das, dass du bei einem Absolute-Profile im Schedule den startSchedule weglassen darfst, und wenn du das tust, dann fängt das ganze Profile in dem Moment zu wirken an, wenn ein Ladevorgang (also eine Transaktion) beginnt.

Ich habe mir dann den Code, der ein Profile evaluiert nochmal angesehen (findest du hier: https://github.com/Tinkerforge/tfocpp/blob/fdf69d6389e803c4b2d06ac3b9ec20c8b816404a/src/ocpp/ChargingProfile.cpp#L47 im Code sind alle /* */-Kommentare Zitate aus der Spec) und mit den Debug-Ausgaben nachvollzogen, warum das Profile nicht wirkt. Sowohl wenn das Profile gesetzt wird, als auch wenn die Transaktion beginnt, bekomme ich folgende Ausgabe:

2023-07-06 09:25:56,730  Received SetChargingProfile.req stacklevel 0
2023-07-06 09:25:56,741  Charging profile accepted as ChargePointMaxProfile level 0
2023-07-06 09:25:56,785  Sending SetChargingProfile.conf.
2023-07-06 09:25:56,809  Evaluating charging profiles
2023-07-06 09:25:56,810      ChargePointMaxProfiles[3] not set
2023-07-06 09:25:56,810      ChargePointMaxProfiles[2] not set
2023-07-06 09:25:56,820      ChargePointMaxProfiles[1] not set
2023-07-06 09:25:56,821  Evaluating charging profile 5
2023-07-06 09:25:56,831      startSchedule not set or kind is relative. Assuming schedule is relative to the start of a transaction.
2023-07-06 09:25:56,841      No transaction running. Schedule does not apply.
2023-07-06 09:25:56,852      TODO HIT.
2023-07-06 09:25:56,852      ChargePointMaxProfiles[0] did not apply

----------------------------------

2023-07-06 09:26:26,869  Sending StartTransaction.req at connector 1 for tag 0460FC929E3380 at 32.758 kWh.
2023-07-06 09:26:26,874  Sending StatusNotification.req: Status SuspendedEVSE for connector 1
2023-07-06 09:26:26,889  Evaluating charging profiles
2023-07-06 09:26:26,889      ChargePointMaxProfiles[3] not set
2023-07-06 09:26:26,889      ChargePointMaxProfiles[2] not set
2023-07-06 09:26:26,899      ChargePointMaxProfiles[1] not set
2023-07-06 09:26:26,900  Evaluating charging profile 5
2023-07-06 09:26:26,910      startSchedule not set or kind is relative. Assuming schedule is relative to the start of a transaction.
2023-07-06 09:26:26,920      No transaction running. Schedule does not apply.
2023-07-06 09:26:26,931      TODO HIT.
2023-07-06 09:26:26,931      ChargePointMaxProfiles[0] did not apply

Im Code sind wir dann hier: https://github.com/Tinkerforge/tfocpp/blob/fdf69d6389e803c4b2d06ac3b9ec20c8b816404a/src/ocpp/ChargingProfile.cpp#L91-L97

In beiden Fällen wirkt das Profile also nicht, weil (angeblich) keine Transaktion läuft. Das liegt daran, dass die Transaktion, die in der zweiten Ausgabe gestartet wurde, auf dem Connector 1 läuft (also dem einzigen, den die Wallbox hat). Auf Connector 0 (also dem ganzen Charge Point) läuft nie eine Transaktion, die sind immer den spezifischen Connectoren zugeordnet. Deshalb ist im Evaluierungs-Code die startTxnTime nie gesetzt und damit wird der Schedule nicht angewandt.

Die Interpretation, dass eine Transaktion nicht in die Evaluierung eines Profiles auf Connector 0 eingeht, ist leider etwas wage. Ich finde aber, dass die Spec zumindest Hinweise darauf gibt, dass das so gedacht ist:

1. Transaktionsspezifische Profiles sind nicht auf Connector 0 erlaubt:

Quote

If a transaction-specific profile with purpose TxProfile is present, it SHALL overrule the default charging profile
with purpose TxDefaultProfile for the duration of the current transaction only. [...] TxProfile SHALL only be set at Charge Point ConnectorId >0.

und für das transactionId-Feld des ChargingProfiles:

Quote

transactionId
 integer
 0..1
 Optional. Only valid if ChargingProfilePurpose is set to TxProfile, the transactionId MAY be used to match the profile to a specific transaction.

2. ChargePointMaxProfiles sind explizit zur Lastverteilung gedacht. Dabei sollte egal sein, ob gerade eine Transaktion läuft oder nicht:

Quote

In load balancing scenarios, the Charge Point has one or more local charging profiles that limit the power or
current to be shared by all connectors of the Charge Point.

 

Wenn ich das Profile so ändere, dass es nicht mehr vom Transaktionsstart abhängt, indem ich startSchedule auf z.B. den 6.7.2023 00:00 setze, dann funktionierts wie erwartet:

2023-07-06 10:23:43,204  Received SetChargingProfile.req stacklevel 0
2023-07-06 10:23:43,216  Charging profile accepted as ChargePointMaxProfile level 0
2023-07-06 10:23:43,258  Sending SetChargingProfile.conf.
2023-07-06 10:23:43,344  Evaluating charging profiles
[...]
2023-07-06 10:23:43,355  Evaluating charging profile 5
2023-07-06 10:23:43,366      startSchedule set and kind is absolute or recurring. Using startSchedule.
2023-07-06 10:23:43,376      Checking schedule periods.
2023-07-06 10:23:43,376      Schedule applied.
2023-07-06 10:23:43,387      Setting number of phases to 3.
2023-07-06 10:23:43,387      Setting current limit to 9.000.
2023-07-06 10:23:43,398      ChargePointMaxProfiles[0] applied.
2023-07-06 10:23:43,398         ConnID  Allowed Phases  MinRate
2023-07-06 10:23:43,408         0       9.000   3       0.000
2023-07-06 10:23:43,409         1       32.000  3       0.000
[...]
2023-07-06 10:23:43,452      Profile evaluation done. Distributing limit
2023-07-06 10:23:43,462      Currents distributed:
2023-07-06 10:23:43,462         ConnID  Allowed Phases  MinRate
2023-07-06 10:23:43,473         0       9.000   3       0.000
2023-07-06 10:23:43,473         1       9.000   3       0.000
2023-07-06 10:23:43,483      Next check: never
2023-07-06 10:23:43,484  
2023-07-06 10:23:43,484  Setting connector 1 limit to 9000

 

[heppth]

Puh, da habe ich die OCPP-Spezifikation wohl falsch interpretiert. Fortan schicke ich nun immer ein startSchedule in SetChargingProfile.

Diese zwei Messages...

14:39:18.729  INFO  OCPP: Sent following message to warp2-22p6: SetChargingProfile: {
  "connectorId": 0,
  "csChargingProfiles": {
    "chargingProfileId": 256,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxDefaultProfile",
    "chargingProfileKind": "Absolute",
    "chargingSchedule": {
      "startSchedule": "2023-07-06T00:00:00Z",
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        {
          "startPeriod": 0,
          "limit": 6
        }
      ]
    }
  }
}
14:39:18.733  INFO  OCPP: Sent following message to warp2-22p6: SetChargingProfile: {
  "connectorId": 0,
  "csChargingProfiles": {
    "chargingProfileId": 1,
    "stackLevel": 0,
    "chargingProfilePurpose": "ChargePointMaxProfile",
    "chargingProfileKind": "Absolute",
    "chargingSchedule": {
      "startSchedule": "2023-07-06T00:00:00Z",
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        {
          "startPeriod": 0,
          "limit": 8
        }
      ]
    }
  }
}

... führen nun wie erwartet zu:

2023-07-06 14:44:18,034  Evaluating charging profiles
2023-07-06 14:44:18,034      ChargePointMaxProfiles[0] applied.
2023-07-06 14:44:18,034      Connector 1
2023-07-06 14:44:18,045      TxDefaultProfiles[0] applied
2023-07-06 14:44:18,045      Profile evaluation done. Distributing limit
2023-07-06 14:44:18,055      Currents distributed:
2023-07-06 14:44:18,056          ConnID    Allowed    Phases    MinRate
2023-07-06 14:44:18,066          0    8.000    3    0.000
2023-07-06 14:44:18,067          1    6.000    3    0.000

Vielen Dank!