heppth Posted June 29, 2023 at 09:33 AM Share Posted June 29, 2023 at 09:33 AM (edited) 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 "Ladefreigabe" 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 Edited June 29, 2023 at 09:36 AM by heppth Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 29, 2023 at 01:52 PM Share Posted June 29, 2023 at 01:52 PM 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 "Ladefreigabe" 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? 1 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 29, 2023 at 02:42 PM Share Posted June 29, 2023 at 02:42 PM 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 1 Quote Link to comment Share on other sites More sharing options...
heppth Posted July 5, 2023 at 05:53 AM Author Share Posted July 5, 2023 at 05:53 AM 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? Quote Link to comment Share on other sites More sharing options...
rtrbt Posted July 5, 2023 at 12:51 PM Share Posted July 5, 2023 at 12:51 PM 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 1 Quote Link to comment Share on other sites More sharing options...
heppth Posted July 5, 2023 at 03:08 PM Author Share Posted July 5, 2023 at 03:08 PM 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 AlignedData 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. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted July 6, 2023 at 08:29 AM Share Posted July 6, 2023 at 08:29 AM 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 1 Quote Link to comment Share on other sites More sharing options...
heppth Posted July 6, 2023 at 12:52 PM Author Share Posted July 6, 2023 at 12:52 PM 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! 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.