rtrbt

Dafür kannst du den Brick Viewer benutzen: Unter Updates/Flashing das Bricklet auswählen, dann sollte es auf den Bricklet-Tab wechseln. Da die neue UID eintragen und auf Save UID klicken.

Die Änderungen um das Schützschalten weg zu bekommen haben leicht das Messprinzip geändert. Vermutlich müssen wir jetzt nochmal die Wallbox kalibrieren, weil die alte Kalibrierung bei kleinem erlaubten Ladestrom sehr stark ist. Mach das mal wie hier beschrieben:

Zusätzlich kannst du das selbe nochmal machen, wenn dein Auto voll (bzw. auf 80% SoC wenn du das Ladeende darauf konfiguriert hast) ist. Dann wird die Kalibrierung besser. Das muss nicht im selben Ladeprotokoll sein, darf es aber.

Wir hatten dazu auch im Blog was geschrieben: https://www.tinkerforge.com/de/blog/new-functions-for-warp-charger-and-warp-energy-manager/

Ups, da hast du recht. Gefixt: https://github.com/Tinkerforge/esp32-firmware/commit/435cb63c309dcc00f37616bb73d2d4a4344d67f2
(Kommt mit der nächsten Firmware-Version)

Oh sorry, ich habe seit Ewigkeiten auf der TODO-Liste stehen, die Dokumentation dafür zu aktualisieren. Mache ich heute noch.

On 7/11/2023 at 6:28 PM, Frankstar said:

das Ziel wär das aktuelle "Lade-Log" zu unterbrechen damit ich im Ladelog keine Ladungen von über n-Stunden habe und quasi eine neue Ladung beginnt ohne das ich zum Auto gehen muss aus/einstecken.

Das wird mit der CP-Unterbrechung nicht funktionieren (siehe hier ;) )

Im Moment kannst du einen Ladevorgang nur beenden, in dem du entweder das Auto abziehst, oder (falls du die Benutzerfreigabe per NFC-Tag benutzt) das Tag an die Box hältst. Das Tag kannst du aber per API injecten: https://www.warp-charger.com/api.html?v=2#nfc_inject_tag

On 7/8/2023 at 8:25 PM, Little_Company said:

gibt es schon eine ungefähre Vorstellung, wann die Funktion ein Root Zertifikat hochgeladen werden kann eingeplant ist.

Ich habe das gerade Proof-of-Concept-artig zusammengeschrieben und es scheint soweit zu funktionieren. Es fehlt noch GUI im Webinterface usw., aber ich würde sagen, das schaffen wir bis zum nächsten Firmware-Release. Also auf jeden Fall deutlich vor den sechs Monaten.

On 7/7/2023 at 12:34 PM, poohnet said:

Dann sollte doch auch das "Industrial Quad Relay"-Bricklet funktionieren, oder?

Da musst du aufpassen: Beim Industrial Quad Relay 2.1 muss man auf die Polung achten. Das heißt, dass das CP-Signal nicht sauber durchkommt, weil das +/- 12V sind. Musste ich bei einer unserer internen Testboxen debuggen ;)

Sehr gut. Der Fix kommt dann "offiziell" in Firmware 2.1.4.

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

Teste bitte mal diese Firmware-Version:

On 7/4/2023 at 6:17 PM, gustavpaula said:

Mit welcher Methode kann ich eine Ladung nicht mehr starten/stoppen, wenn "Ladeeinstellungen-Manuelle Ladefreigabe = ON"?

Mit der Methode "Auto anstecken". Was die manuelle Ladefreigabe im Endeffekt tut ist, dass sie die Ladestromgrenze "Manuelle Lade­freigabe" auf blockiert (bzw. 0 Ampere) setzt und zwar in dem Moment, in dem du ein Auto abziehst. Das heißt im Umkehrschluss, dass wenn du ein Auto ansteckst, immer in der Grenze 0 Ampere steht. Du musst dann also jedes Mal diese Ladestromgrenze wieder freigeben indem du eins der folgenden Dinge tust:

• im Webinterface auf Start klickst
• Bei passender Tasterkonfiguration (Ladestart oder Ladestart/Ladestop) den Taster drückst
• die API evse/start_charging aufrufst

On 7/4/2023 at 6:17 PM, gustavpaula said:

Das sind einerseits tatsächlich Grenzen für die Höhe des Ladestroms, die nach dem Farbschema in der Anleitung unterschiedliche Zustände haben können. Andererseits gibt es aber noch Bedingungen, die zu einer Ladefreigabe führen oder diese verhindern können.

Jein. Alle Ladestromgrenzen sind im Endeffekt jeweils eine Zahl, nämlich entweder 0, oder 6000 bis 32000 Milliampere. Das Webinterface zeigt dir statt 0 aber "blockiert" und statt 32000 "freigegeben" an. Außer den Ladestromgrenzen gibt es keine "normalen" (lies: nicht Fehler-) Umstände, die einen Ladevorgang verhindern können.

On 7/4/2023 at 6:17 PM, gustavpaula said:

"freigegeben" rechts im Slot bedeutet nicht "die Grenze ist freigegeben" sondern bedeutet "die Ladefreigabe ist durch die Grenze nicht verhindert". Andererseits bedeutet "freigeben" rechts in der Schaltfläche des Slots, dass diese Einschränkung mit Klick darauf deaktiviert wird.

Genau. Wobei "die Ladefreigabe ist durch die Grenze nicht verhindert" trotzdem bedeuten kann, dass der Ladestrom limitiert wird. Eben dann, wenn nicht "freigegeben" sondern z.B. 10,123 Ampere im Slot steht. Der "Freigeben"-Button tut nichts anderes, als in den Slot wieder 32 Ampere zu schreiben.

On 7/4/2023 at 6:17 PM, gustavpaula said:

Z.B. eine 6A Grenze kann manuell auf der Seite Status - erlaubter Ladestrom gesetzt werden, dann kann ich dies aber per "freigeben" bei den Ladestromgrenzen auf 16A ändern. Wer braucht das?

Da hast du eine interessante Frage aufgeworfen. Zuerst die einfache Antwort: den Freigeben-Button am "Externe Steuerung"-Slot braucht man, wenn die externe Steuerung sich aufgehangen hat, man aber wieder laden möchte. Da das eher ein Spezialfall ist, verstecken wir jetzt den Button, wenn die externe Steuerung deaktiviert ist oder bereits freigibt.

Den Button am "Konfiguration"-Slot brauchte man früher, wenn man die Schiebeschalter in der Wallbox umgestellt hat. Wir haben aber vor ein paar Monaten geändert, dass wenn du auf der Statusseite zum Beispiel maximal 16 Ampere einstellen kannst (weil das das Minimum aus Lade- und Zuleitungskabel-Slot ist), in Wirklichkeit 32 Ampere (also "Freigegeben") geschickt werden, wenn du 16 Ampere eingibst, bzw. den Button dafür benutzt.

Das heißt "Wer braucht das?" -> niemand -> Ich habe den Button entfernt. Danke für den Hinweis :D

On 7/4/2023 at 6:17 PM, gustavpaula said:

Diese Vorgehensweise sollte als Erklärung in die Anleitung.

Steht sie in gewisser Weise:

"Auf dieser Unterseite werden außerdem die aktuellen Ladestromgrenzen angezeigt. Alle Grenzen, die derzeit aktiv sind, werden zur Entscheidung, ob ein Ladevorgang erlaubt ist und zur Berechnung des maximalen Ladestroms einbezogen: Nur wenn alle aktiven Ladestromgrenzen nicht blockieren, wird eine Ladung erlaubt. Der erlaubte Ladestrom ist dann das Minimum aller aktiven Grenzen."

Fairerweise ist das sehr kompakt beschrieben.

On 7/4/2023 at 6:17 PM, gustavpaula said:

Diese Farbtabelle sollte irgendwie auf der Seite mit den Ladestromgrenzen super einfach parallel einsehbar sein:

Wir haben prinzipiell vor, mehr erklärende Texte ins Webinterface zu bringen. Die Idee ist, dass es bei komplizierteren Einstellungen einen ?-Button gibt, der eine Erklärung aufklappt. Das hat einerseits den Vorteil, dass die Seite übersichtlicher ist, wenn die Erklärungen nicht aufgeklappt sind, andererseits hat man da dann auch mal die Gelegenheit mehr als einen Halbsatz über eine Konfiguration zu verlieren. Das würde ungefähr so aussehen: (Am Layout usw. wird noch gefeilt)

Wie üblich danke für's Feedback. Wenn man jeden Tag auf das Webinterface bzw. in die Firmware starrt, sieht man die Komplexität manchmal nicht mehr.

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

Hm, das hatte ich befürchtet. Im Anhang die Variante, bei der wir den Widerstandspeak beim Übergang von "Auto will Strom" nach "Auto will keinen Strom" ignorieren.

Da ich optimistisch bin, dass das jetzt funktioniert, habe ich dir die Firmware in zwei Varianten angehangen: Teste erstmal mit der warp_firmware_2_1_2... Das ist wie gehabt eine WARP1 2.1.2-Firmware mit den Bugfixes zusätzlich drin. Falls das funktioniert, kannst du dann auf die warp_firmware_2_1_3... wechseln. Dann hast du die ganzen Neuerungen aus 2.1.3 und die Bugfixes oben drauf. Sonst müsstest du auf der 2.1.2+ bleiben, bis wir irgendwann 2.1.4 veröffentlichen.

warp_firmware_2_1_2_64a2be5b_57432b34a765d3f__merged.bin warp_firmware_2_1_3_64a2bae8_49abde32bf9c00e_merged.bin

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

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?

On 6/29/2023 at 1:44 PM, gustavpaula said:

Was genau ein "Ladestromslot" ist, weiß ich nicht. Habe ICH den Ladestromslot so gesetzt?

Sorry, zwei Wörter für's gleiche. Ein Slot ist eine Ladestromgrenze, so wie du sie im Ladestatus siehst. Den Slot hast nicht du so gesetzt.

On 6/29/2023 at 1:44 PM, gustavpaula said:

Wer/wie/was hat den Ladeslot fälschlicherweise falsch markiert?

Das war die große Frage. Inzwischen habe ich es rausgefunden: Der Slot ist ursprünglich bei WARP1 und WARP2 falsch konfiguriert gewesen. Bei WARP2 haben wir das mit Firmware 2.1.2 schon gefixt gehabt, aber bei WARP1 hatten wir übersehen, dass das selbe Problem existiert.

Ich habe das jetzt für WARP1 auch gefixt, neue Firmware ist im Anhang.

warp_firmware_2_1_2_649d74a0_4e2c6ba61f00eb4__merged.bin

Okay, ich glaube ich habe jetzt verstanden, was da passiert. Da das kompliziert ist habe ich das ganze mal geplottet (mein Excel-Foo ist nicht gut deshalb einfach drei Graphen untereinander) und annotiert.

Du hast folgende Reihenfolge erzeugt:

• 10 Ampere erlaubt, Auto ist voll (das ist der Anfang des Graphen)
• Strom auf 6 Ampere reduziert. Das beeinflusst bei WARP1 die CP-PE-Widerstandsmessung, was man im 3. Graph sieht (Rote 1)
• Auf Stop geklickt (Blaue 1, Rote 2) -> Wir melden dem Auto über das PWM auf CP, dass kein Strom verfügbar ist -> Das PWM geht auf 100% -> Der Widerstand geht wieder etwas hoch.
• Auf Start geklickt. (Blaue 2) Es scheint so zu sein, dass der VW immer wieder anfängt zu laden, wenn das PWM zwischenzeitlich aus war, selbst wenn er voll ist.
• Das Auto will laden und setzt deshalb den Widerstand runter (Rote 3)
• Wir schalten das Schütz (Blaue 3)
• Nach 45 Sekunden bemerkt der VW, dass er voll ist. (Blaue/Rote 4) Er will deshalb den Widerstand wieder auf die 2,7kOhm setzen, macht das aber in der VW-Weise, die bei WARP1 Sprünge in der Messung erzeugt.
• Der gemessene Widerstand springt auf einen so hohen Wert, dass wir glauben, das Auto ist abgezogen (Blaue 5, Rote 5)
• Jetzt der interessante Teil: Einer der Ladestromslots, nämlich der für das Energie/Zeitlimit wird von 32A auf 0A (also blockieren) gesetzt. Das passiert vermutlich direkt durch den Ladecontroller, weil dieser Ladeslot fälschlicherweise bei dir so markiert ist, dass der Ladecontroller ihn auf 0 A setzen soll, wenn ein Auto abgezogen wird. (Gelbe 1)
• ~ 250ms später setzt der ESP den Slot wieder zurück auf 32 A (Gelbe 2)
• Der gemessene Widerstand hat sich wieder gefangen, wir messen ~2.7kOhm -> Das Auto ist angesteckt aber will nicht laden (Rote 6, Blauer Übergang von 6 zu 7.)
• Den Übergang habe ich nochmal beim nächsten Block orange eingekreist, weil man da gut sieht wie es erst kurz auf 2.7kOhm springt, dann etwas abfällt (weil wir wieder das PWM starten) und dann auf ~800 Ohm fällt (weil das Auto Strom anfordert)
• Jetzt geht es im Endeffekt von vorne los, das Auto "lädt" wieder 45 Sekunden (Blaue 8 bis 9)

Das heißt es kommen folgende Probleme zusammen:

• Der VW schaltet die Widerstände so um, dass wir diesen Peak in der Messung sehen.
• Das Zeit/Energielimit geht davon aus, dass der entsprechende Ladeslot nicht beim Abziehen eines Autos geleert wird, setzt das aber nicht explizit. Aus irgendeinem Grund ist bei dir dieser Slot aber so konfiguriert, dass geleert wird. Hattest du eventuell mal eine andere Beta-Firmware, Test-Firmware oder einen der Forks laufen?
• Durch das Nullen des Ladeslots ist die Zeit, die der VW sehen kann, dass wir keinen Strom zur Verfügung stellen so lang, dass er dann glaubt er müsste wieder anfangen zu laden, wenn Strom verfügbar ist.

Ich baue dir heute Nachmittag noch eine Testfirmware, bei der ich den Bug fixe, dass der Ladeslot zurückgesetzt wird. Im Idealfall reicht das schon, weil dann der VW nach den 45 Sekunden und der Abschaltung nicht wieder anfängt zu laden. Falls das weiterhin passiert, müssen wir (lies @borg ) in der Ladecontroller-Firmware das Timing etwas anpassen um mit dem Peak in der Messung umgehen zu können.

Sorry, das ist bei mir untergegangen. Habe gerade einen Blick reingeworfen, die Implementierung des Energie/Zeitlimits blockiert alle 45 Sekunden für 250ms. Jetzt muss ich nur rausfinden, warum.

Damit es erstmal wieder bei dir funktioniert, zwei Optionen:

1. Entweder aktualisiere den Energy Manager auf 1.0.6 (und bleib bei der Wallbox auf 2.1.3)
2. Oder (mit Wallbox-Firmware 2.1.3): Deaktiviere in den Ladeeinstellungen die Zählerüberwachung und gehe dann wieder auf 2.1.2. Das müsste funktionieren.

Zur Erklärung: Wir haben mit der Wallbox-Firmware 2.1.0 das Lastmanagement-Kommunikationsprotokoll so umgestellt, dass es vorwärts kompatibel ist. D.h. wenn wir neue Daten hinzufügen sollte eigentlich sowohl das Setup "alter Lastmanager (egal ob Energy Manager oder Wallbox); neue gesteuerte Wallbox", als auch das Setup "neuer Lastmanager; alte gesteuerte Wallbox" funktionieren. Das scheint bei dir nicht der Fall zu sein. Werden wir uns in Ruhe ansehen.

Das Downgrade der Wallbox-Firmware funktioniert bei dir nicht, weil du eine Wallbox mit Zähler hast. In 2.1.3 haben wir die Zählerüberwachung hinzugefügt, die automatisch aktiviert wird, wenn ein Stromzähler gefunden wird. Das funktioniert wie viele andere Module über eine eigene Ladestromgrenze. Wenn du jetzt auf 2.1.2 downgradest, dann bleibt diese Ladestromgrenze aktiv, die Firmware kennt sie aber nicht mehr, deshalb wird der Ladevorgang nie freigegeben. Das ist der Grund, warum wir bei 2.1.3 im Changelog "Sichergestellt, dass Downgrades (auf diese Firmware oder neuer) funktionieren, selbst wenn künftig neue Ladestromgrenzen hinzugefügt werden" haben. Ab 2.1.3 werden alle unbekannten Ladestromgrenzen (also solche, die Überbleibsel eines Up- und dann Downgrades sind) deaktiviert, damit das Laden wieder funktioniert.

On 6/22/2023 at 11:39 PM, bm-3 said:

Found unknown meter type 0x0. Assuming this is a SDM72DM.

Wenn du so weit kommst, ist das ein gutes Zeichen: Die Modbus-Kommunikation läuft schon mal.

Die SDM-Zähler haben alle ein Register, dass den Zählertyp angibt. Damit detektiert die Wallbox automatisch, was für einen Zähler du angeschlossen hast.

Das Problem ist jetzt, dass es diese ältere Version des SDM630 gibt, die nicht den "erwarteten" Zählertyp in dem Register stehen hat, sondern einfach 0. Bei der WARP2 gehen wir davon aus, dass das dann ein alter SDM630 sein muss. Bei der WARP1 können wir das nicht so machen, weil es möglicherweise auch alte Versionen des SDM72DM (V1) gibt, die auch 0 zurückgeben. Deshalb muss eine WARP1 bei einem unbekannten Zähler annehmen, dass das ein SDM72DM (V1) ist.

Du kannst das jetzt reparieren, indem du den Zählertypen von Hand auf SDM630 überschreibst. (Das ist eine persistente Konfiguration -> Musst du nur einmal machen) Dafür gibt es leider keinen Knopf im Webinterface (Habe mal ein Issue angelegt, dass wir den hinzufügen: https://github.com/Tinkerforge/esp32-firmware/issues/255).

Um das von Hand zu machen, musst du auf die recovery-Seite der Wallbox gehen, je nachdem ob du per Hostname oder IP auf das Webinterface gehst unter http://warp-xyz/recovery  oder http://10.0.0.1/recovery (Hostname oder IP musst du durch deine ersetzen). Dann unter API in die Textbox folgendes einfügen:

{"method":"PUT", "url":"/meter/type_override_update", "payload":2}

und auf Call API klicken. In der Textbox darunter sollte dann eine 200 erscheinen.

Danach auf dem normalen Webinterface unter System->Firmware-Aktualisierung einmal auf neu starten klicken. Dann sollte der SDM630 korrekt erkannt werden.

Edit: API angepasst für WARP(2) >= 2.1.3

Der vollständige Debug-Report wäre sehr hilfreich. Entweder hier oder per PM.

On 6/20/2023 at 5:36 PM, roquestrongo said:

Konntest du die ESP Resets (Softreset) in meinem Ladelog nachvollziehen ? Ist das normal das der WARP2 / der ESP Beim Laden neustartet?

Das fehlte in @borgs Antwort. Der ESP startet nicht neu. Das Ladelog funktioniert wie folgt: Wenn du Start klickst, wird sofort ein Debug-Report gezogen, also die Konfiguration und das Ereignis-Log hintereinander. Danach werden die ganzen Daten gesammelt, bis du Stop klickst, dann wird nochmal ein Debug-Report gezogen. Die Idee ist, dass wir dann sehen können, welche Konfigurations-/Zustandsänderungen und welche Ereignislog-Nachrichten aufgetaucht sind, während die Daten gesammelt wurden.

Der Neustart, den du da siehst, ist vor dem Start des Ladelogs passiert. und zwar ~ 3 Minuten. Wenn "Software reset via esp_restart" als  "reset reason" angegeben wird, dann ist das typischerweise ein Neustart, den man aktiv ausgelöst hat, z.B. durch eine Konfigurationsänderung im Webinterface.

Interessant ist, dass der Ladecontroller auch neugestartet ist, und zwar ~ 15 Minuten vor dem Start des Ladelogs. Hattest du die Wallbox vom Strom getrennt, oder die Firmware aktualisiert?

Die GPIOs sind in Ordnung. Prinzipiell hast du da den Effekt, dass für's Webinterface die GPIOs nur alle 250 ms abgefragt werden, da aber teilweise deutlich hochfrequentere Prozesse ablaufen, z.B. PWMs. Dann ist praktisch zufällig, ob du High oder Low siehst.

Quote

1. erste Zeile/erste und zweite Reihe: "current configuration 0" und "motor fault"
2. zweite Zeile/vierte Reihe: "CP-PWM"
3. dritte Zeile/vierte Reihe: "CP Separation" 
4. vierte Zeile/dritte und vierte Reihe: "contactor check before" und "contactor check behind"
5. fünfte Zeile/vierte Reihe: "LED"

1. Motor fault ist okay, der Ladecontroller unterstützt theoretisch, dass man eine Dose statt einem angeschlagenen Kabel anbringt. Da das nicht der Fall ist, wird der Pin nicht angesteuert.
   
   Current configuration 0 einer der Pins mit denen die Schiebeschalter gelesen werden, die auf dem Ladecontroller verbaut sind. Mit den Schaltern wird eingestellt, wie viel Strom das Zuleitungskabel erlaubt. Der Pin (und current configuration 1) können jeweils low, high, oder open, also nicht verbunden, sein. Beim Start des Ladecontrollers legt er einen Pull-Down- und danach einen Pull-Up-Widerstand an um die drei Fälle zu unterscheiden und damit die Stellung der Schalter zu bestimmen. Das der Pin bei dir springt ist erwartet: Du hast eine 16-Ampere-Zuleitung, das wird auf den Schaltern ausgedrückt, indem beide in der Open-Position sind. Der Ladecontroller hat nach dem Start die Pull-Up/Down-Widerstände wieder weggenommen, d.h. es ist auch zufällig welcher Wert da gelesen wird (aber auch egal, eben weil sie nur beim Start ausgewertet werden)
2. Das CP-PWM läuft mit 1000 Hz. Manchmal siehst du dann high, manchmal low
3. Auf dem CP-Trennungspin habe ich im Log und im Video nichts gesehen. Da kannst du eventuell folgendes beobachten: Wenn das Auto 30 Sekunden, nachdem die Wallbox das Laden erlaubt (Zustand Ladebereit), nicht reagiert, machen wir eine CP-Trennung um ggfalls. die Ladeelektronik aufzuwecken. Dann sollte der Pin einmal umspringen und vier Sekunden später zurück. Danach sollte der Wert stabil sein.
4. Wenn das Schütz geschaltet ist, pendeln die beiden GPIOs mit der Netzfrequenz (50 Hz)
5. Die LED atmet während des Ladevorgangs, was durch ein PWM erzeugt wird. Manchmal siehst du dann gerade das PWM high, manchmal low.

Oh sorry. Hier eine WARP1-Firmware.

warp_firmware_2_1_2_649147fc_d5c477b78835162__merged.bin