rtrbt

Laut der Logs sieht es in der Tat so aus, als ob das Schütz zum Phasenumschalten entweder nicht richtig angeschlossen oder defekt ist. Eine Sache kannst du noch probieren: Wenn das Schütz umschaltet, sollte das hörbar sein. D.h. du kannst dich neben den Schaltschrank stellen und dann EVCC von ein- auf dreiphasig umschalten lassen und mal lauschen. Bezüglich des Ladevorgangs: Der Fiat scheint ein etwas seltsames Ladeverhalten zu haben. Ich habe spontan hier: https://www.goingelectric.de/forum/viewtopic.php?p=1806963#p1806963 Leute mit einem ähnlichen Problem gefunden. Da du das SoC-Laden von EVCC benutzt, müsstest du vermutlich mal die EVCC-Entwickler fragen, was da genau los ist: https://github.com/evcc-io/evcc/discussions Sinnvollerweise fixen wir aber erst das Schützproblem ;) Was ich aus dem goingelectric-Thread rauslese ist, dass der Fiat deutlich weniger Strom zieht, als ihm vorgegeben wird, und die Verlustleistung bei niedrigen Strömen scheint hoch zu sein. Ich vermute jetzt, dass EVCC die Ladeleistung runtergedreht hat, weil die SoC-Ziel-Berechnung sagt, dass noch viele Stunden Zeit sind und du deshalb lange im ineffizienten Bereich geladen hast. Du kannst den Minimalstrom aber konfigurieren: https://docs.evcc.io/docs/reference/configuration/loadpoints/#mincurrent Beim Renault Zoe macht es z.B. keinen Sinn dreiphasig mit weniger als ~ 9A zu laden, weil die Effizienz dann in den Keller geht. Eventuell gibts für den Fiat vergleichbare Erfahrungswerte. Edit: Habe vergessen den 2. goingelectric-Thread zu verlinken: https://www.goingelectric.de/forum/viewtopic.php?p=1775589#p1775589

Die Pinleiste scheint kompatibel zum HAT Brick zu sein. Zumindest die SPI-Pins die wir auf jeden Fall brauchen (19, 21, 23) sind korrekt. Es kann sein, dass das HAT nicht automatisch detektiert wird. Wenn das der Fall ist, musst du dir eine Konfiguration für den Brick Daemon schreiben, der den CS-Pins für jeden Port korrekt setzt. Das ist hier: https://www.tinkerforge.com/de/doc/Hardware/Bricks/HAT_Brick.html#kompatibilitat-zu-anderen-boards-und-images erklärt. Das sollte also funktionieren (alle Angaben ohne Gewähr ;) ) Was ich noch gefunden habe: https://wiki.radxa.com/Rock4/hardware/gpio Das scheint aber laut https://wiki.radxa.com/Rockpi4/hardware/spi_flash eher ältere Modelle zu betreffen.

Stimmt, die Variable wird bei Stream-Funktionen in beide Richtungen generiert, aber nur bei Streams vom Bricklet zum PC verwendet. Gefixt: https://github.com/Tinkerforge/generators/commit/aaf854e9 Das sind alles gute Punkte. Muss ich mit meinem Kollegen mal besprechen ob und wenn ja wie viel davon wir übernehmen können. Wir melden uns dazu nochmal ;)

Erstelle bitte mal ein Energy Manager-Protokoll. Dazu unter System->Debug bei "Protokoll erstellen" auf Start klicken, dann in EVCC auf dreiphasig umstellen, warten bis der Schützfehler auftritt und dann auf Stop + Download klicken. Wichtig: Das Protokoll wird in deinem Browser-Tab gesammelt. Den musst du also zwischen Start und Stop offenlassen.

Das ist in der Tat ein Fehler, danke für den Hinweis! Die Fehlerbehandlung, die das streamStateObject zurücksetzt usw. gibt es an mehreren Stellen, alle außer dieser sind aber in Hilfsfunktionen, die device als Parameter übergeben bekommen. Das ist laut git blame seit 2017 niemanden aufgefallen. Ich habe das im Generator gefixt: https://github.com/Tinkerforge/generators/commit/fdcc67f1b8f1f210a7aa0d6944f633cab6a9318d und dir neu generierte Bindings angehangen. Versuchst du auch die Interna zu typisieren, oder nur das Interface nach außen? Eventuell könnten wir das auch generieren. Das für 150 Geräte von Hand zu schreiben stelle ich mir anstrengend vor ;) tinkerforge_javascript_bindings_2_1_34.zip

Das funktioniert mehr oder weniger identisch: Du rufst modbusMasterReadHoldingRegisters und bekommst dann das entsprechende Callback mit der Antwort.

Das sieht nach dem Problem hier aus: Du kannst testweise mal die dort angehangene Firmware ausprobieren (ohne Phasenumschaltung). Wenn dann, nachdem dein Auto "voll" (oder eben auf dem konfigurierten SoC) ist, keine neuen Ladevorgänge mehr entstehen, ist es dieses Problem.

Anstatt dass du die Modbus-Pakete von Hand parst, kannst du das RS485-Bricklet im Modbus-Master-Modus benutzen. Ein Beispiel dafür gibts hier: https://www.tinkerforge.com/de/doc/Software/Bricklets/RS485_Bricklet_JavaScript.html#modbus-master-node-js (bzw. weiter unten in der nicht-NodeJS-Variante)

Eventuell. Da muss ich meinen Kollegen, der das programmiert hat, mal fragen. Der ist aber noch im Urlaub.

Das ist beabsichtigt. Laut Anleitung heißt ein grünes "Atmen" (also langsameres Pulsieren als das Blinken im Fehlerfall), dass alles OK ist und entweder PV-Überschussladen deaktiviert ist, oder gerade Strom ins Netz eingespeist wird. Soweit ich das im Code sehe müsste das aber auch schon immer so gewesen sein. Es gibt keinen Standby-Modus o.Ä. der nach einer Weile das "Atmen" stoppt.

Aus dem vollständigen Log sehe ich folgendes: Es dauert nach Start der Wallbox ~ eine Minute, bis die Slave-Box per MDNS aufgelöst wird. Das erklärt 2023-07-27 16:11:48,661 Received packet from unknown 192.168.1.75. Is the config complete? 2023-07-27 16:11:49,673 Received packet from unknown 192.168.1.75. Is the config complete? 2023-07-27 16:11:56,874 Resolved warp-um6-west.local to 192.168.1.75 (via mDNS scan) Es wird zwei Mal Strom umverteilt: 2023-07-27 16:12:04,203 Redistributing current 2023-07-27 16:12:04,203 1 charger requests current. 16900 mA available. 2023-07-27 16:12:04,203 stage 0: Calculated target for warp-ULS-Ost (127.0.0.1) of 6000 mA. 10900 mA left. 2023-07-27 16:12:04,214 stage 0: 10900 mA still available. Recalculating targets. 2023-07-27 16:12:04,224 stage 0: Recalculated target for warp-ULS-Ost (127.0.0.1) of 16000 mA. 900 mA left. 2023-07-27 16:12:04,234 stage 0: 900 mA still available. Attempting to wake up chargers that already charged their vehicle once. 2023-07-27 16:12:04,245 stage 2: Unthrottled warp-ULS-Ost (127.0.0.1) to 16000 mA. 2023-07-27 16:12:05,352 Charger state changed from 1 to 2 2023-07-27 16:12:07,384 Charger state changed from 2 to 3 2023-07-27 16:13:14,269 Redistributing current 2023-07-27 16:13:14,270 1 charger requests current. 17500 mA available. 2023-07-27 16:13:14,270 stage 0: Calculated target for warp-ULS-Ost (127.0.0.1) of 6000 mA. 11500 mA left. 2023-07-27 16:13:14,280 stage 0: 11500 mA still available. Recalculating targets. 2023-07-27 16:13:14,291 stage 0: Recalculated target for warp-ULS-Ost (127.0.0.1) of 6000 mA. 11500 mA left. 2023-07-27 16:13:14,301 stage 0: 11500 mA still available. Attempting to wake up chargers that already charged their vehicle once. 2023-07-27 16:13:14,311 stage 1: Throttled warp-ULS-Ost (127.0.0.1) to 6000 mA. 2023-07-27 16:13:14,321 stage 1: Throttled a charger. Skipping stage 2 2023-07-27 16:13:14,332 Skipping stage 2 Am Anfang macht der Verteilungsalgorithmus alles richtig, bei der zweiten Verteilung gibt er der Box aber nur 6 Ampere. Ich vermute, dass das mit einer der Lastmanagement-Änderungen in 2.1.3 zusammenhängt. Kannst du testweise in den Experteneinstellungen die Länge der Start­phase auf z.B. 120 Sekunden umstellen? Wenn dann erst nach zwei Minuten der Strom auf 6 Ampere geregelt wird, weiß ich, wo ich suchen muss.

Aktiviere unter Wallbox -> Lastmanagement in den Experteneinstellungen mal das Stromverteilungsprotokoll. Dann schreibt der Lastmanager jedes Mal wenn er Strom verteilt in sein Ereignislog, was er tut. Dann erzeuge das Problem nochmal und zieh einen Debug-Report. Damit sollten wir sehen wo der Strom hin ist.

Sehr gut! Vermutlich nicht. Die alte Kalibrierung auf deiner Wallbox war im unteren Bereich ziemlich stark, vermutlich um unabsichtlicherweise die anderen Bugs auszugleichen. Das ursprüngliche Problem, dass das Schütz hin- und herschaltet hatten wir aber bisher meines Wissens nur bei dir und einem anderen Kunden.

Ich hoffe es :D Gib nochmal Bescheid, falls das wieder auftritt.

Genau richtig. Hier die Kalibrierungsdatei. Die kannst du unter Wallbox -> Ladestatus im Low-Levelzustand unter Kalibrierung hochladen. Danach sollte der erste Wert unter "Wider­stands­ka­li­brie­rung 880Ω" -3553 sein und die Zustandswechsel wenn das Auto voll ist (und du 7 Ampere oder weniger vorgibst) sollten nicht mehr auftreten. calibration.json

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

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.

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 (Hervorhebung von mir) Der ChargingSchedule hat aber keinen startSchedule gesetzt. Wieder laut Spec 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: und für das transactionId-Feld des ChargingProfiles: 2. ChargePointMaxProfiles sind explizit zur Lastverteilung gedacht. Dabei sollte egal sein, ob gerade eine Transaktion läuft oder nicht: 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: