rtrbt

Ich bemühe mal den kurzen Dienstweg zu den EVCC-Entwicklern.

Damit ich das gerade richtig verstehe: Die NFC-Freigabe sollte komplett an EVCC vorbeigehen, wenn du nicht NFC-Tags benutzen willst, um damit für EVCC unterschiedliche Autos zu identifizieren. Oder willst du andersrum von EVCC aus NFC-Tags injecten, damit ein Ladevorgang auf der Wallbox auf einen Benutzer getrackt wird, ohne dass du ein physisches Tag dranhältst?

Ah dann triffst du den Lastmanagement-Bug, den wir hier: gefunden haben. Sorry, dass ich da nicht eher drauf gekommen bin. Du bekommst in den nächsten Tagen eine Test-Firmware, die das Problem fixen sollte.

Hier die Kalibrierung aus den beiden Protokollen. Die Kalibrierung ist im unteren Bereich sehr stark (bei 6 Ampere muss ich 5 Volt abziehen). Kannst du mit dieser Kalibrierung nochmal die Protokolle erstellen? Dann würde ich das nochmal in unsere magische Kalibrierungs-Exceltabelle werfen, um zu verifizieren, dass die 5 Volt wirklich notwendig sind. Theoretisch würde das gehen, aber wir sollten hoffentlich nie in die Situation kommen, dass man das braucht. calibration.json

Habe das Problem gefunden und behoben. Fix kommt mit der nächsten Firmware. Das stimmt. Deshalb ist das Verteilungsprotokoll normalerweise deaktiviert. Da wir inzwischen auch einige andere relativ "gesprächige" Komponenten in der Firmware haben, müssen wir das mal angehen.

Das gehört nach https://www.warp-charger.com/evcc.html. Ist notiert: https://github.com/Tinkerforge/esp32-firmware/issues/266

Das ist leider immer schwierig herauszufinden. Rein technisch ist die ganze Kommunikation zwischen Wallbox und Auto nur, dass die Wallbox vorgibt, wie viel Strom maximal bezogen werden darf. Was das Auto dann wirklich tut ist ihm überlassen. Noch ein Gedanke: Versuch mal unter Wallbox->Ladeeinstellungen den Boost-Modus zu aktivieren.

Sieh mal nach, ob du schon die EVSE-Firmware 2.1.8 Beta 4 hast. Die sollte sich im Webinterface als 204.1.8 melden (Bei Beta-Versionen setze ich die Major-Version auf 200 + Betanummer), bzw du kannst in deinem Repo nachsehen in software/src/modules/evse/. Für die Kalibrierung selbst: (grad zusammenkopiert ;) ) (Folgendes ist mein grobes Verständnis. Für Details müsstest du @borg (Software) und @batti (Hardware) fragen ) Die Kalibrierung ändert, wie die Wallbox die zurückgemessene Spannung und damit den Widerstand, der vom Auto angelegt wird, interpretiert. Da gibt es das grundlegende Problem, dass die Wallbox den Widerstand nur messen kann, während das PWM High ist. D.h. bei kleinen Stromvorgaben wird die Messung schlechter. Es gibt voltage_diff (Differenz), voltage_div (Divisor) und voltage_mul (Multiplikator), die werden auf die CP-PE-Spannung angewandt, siehe z.B. hier: https://github.com/Tinkerforge/evse-bricklet/blob/36ddc94accdd6aae496a6cd115678d0d2a63998b/software/src/ads1118.c#L211C31-L211C31 resistance_2700 und resistance_880 werden auf den aus der Spannung berechneten Widerstand addiert. resistance_880 ist dabei ein Array, dass von 6 bis 32 Ampere in zwei-Ampereschritten verwendet wird, abhängig vom Strom den wir vorgeben (und damit dem PWM mit dem gemessen wird). Ist in der selben Datei weiter unten. Bisher haben wir noch jede Kombination aus Fahrzeugen an jeder Wallbox zum Laden bewegen können. Wenn ein anderes Fahrzeug so anders ist, dass es mit der Kalibrierung, die wir dir dann erstellen, nicht funktioniert, gib nochmal Bescheid, man kann dann vermutlich einen Mittelweg finden, der mit beiden funktioniert.

Dass EVCC 3,7 kW (230V * 16A = 3680W) anzeigt ist für mich ein Indikator, dass es keine Möglichkeit hat das zu messen. Was Sinn ergibt, weil du eine WARP2 Smart hast, d.h. ohne Zähler. Das heißt EVCC muss davon ausgehen, dass wenn es der Wallbox einen Ladestrom von 16 Ampere vorgibt, diese 16 Ampere auch verbaucht werden. Dass die Information, wie viel Strom das Auto wirklich zieht, fehlt, führt dann dazu, dass EVCC falsch berechnet, wie lange der Ladevorgang dauern wird. Was mir nicht klar ist, ist warum EVCC nicht aus der Fiat-API auslesen kann, wie viel Strom tatsächlich beim vom Auto gezogen wird. Alternativ kann man in der Wallbox noch den Stromzähler nachrüsten um sie praktisch von einer WARP2 Smart in eine WARP2 Pro zu verwandeln. Für PV-Überschussladen (unabhängig von den Fahrzeug-APIs) ergibt das meistens Sinn. Oh sorry, hatte den Post davor übersehen. Wenn du das Schütz hörst und das Fenster auf rot (also stromführend) geht, dann funktioniert das Schütz höchst wahrscheinlich. D.h. das Problem ist vermutlich, dass die Schützüberwachung nicht oder nicht richtig angeschlossen ist. Es müssen die "hinteren" Kontakte (23, 24, siehe Bild) an den Eingang 4 des Energy Managers angeschlossen sein.

Der zweite Bug entsteht (auch) dadurch, dass die Namensauflösung per mDNS relativ lange dauert. Das ist ein bekanntes Problem. Ein Ansatz das zu lösen wäre, die Pakete, die diese Meldungen auslösen: Received packet from unknown 192.168.1.75. Is the config complete? zu akzeptieren. Das hat noch ein paar Fallstricke, steht aber auf der Liste. Aus Ubersichtsgründen habe ich ein eigenes Issue dafür aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/264 (davor war das Teil von #225) Prinzipiell gebe ich dir aber recht, dass überhaupt schon 20 Sekunden nach Neustart Strom umverteilt wird, wenn noch nicht alle Wallboxen wieder aufgetaucht sind, ist definitiv nicht gut. Habe dafür auch ein Issue aufgemacht:https://github.com/Tinkerforge/esp32-firmware/issues/263 und den Debug-Report anonymisiert angehangen. Noch eine Sache aus dem Log: 2023-08-01 15:58:19,628 Charge manager watchdog triggered! Received no available current update for 30000 ms. Setting available current to 10000 mA Der Watchdog hat einmal ausgelöst, danach kommt aber nicht sofort eine Stromumverteilung. D.h. zwischen dem Ablaufen der 30 Sekunden des Watchdogs und der nächsten Stromverteilung (das kann zwischen 0 und 10 Sekunden später passieren) kam dann doch noch ein neuer Stromwert an. Würde ich erstmal auf den WLAN-Empfang schieben. Wobei du einen RSSI-Wert von -61 hast. Das ist nicht so schlecht. Unabhängig von den anderen Sachen ist das ursprüngliche Problem gut sichtbar: 2023-08-01 15:57:19,494 Redistributing current 2023-08-01 15:57:19,495 1 charger requests current. 19950 mA available. 2023-08-01 15:57:19,495 stage 0: Calculated target for eins (127.0.0.1) of 6000 mA. 13950 mA left. 2023-08-01 15:57:19,505 stage 0: 13950 mA still available. Recalculating targets. 2023-08-01 15:57:19,516 stage 0: Recalculated target for eins (127.0.0.1) of 16000 mA. 3950 mA left. 2023-08-01 15:57:19,526 stage 0: 3950 mA still available. Attempting to wake up chargers that already charged their vehicle once. 2023-08-01 15:57:19,536 stage 2: Unthrottled eins (127.0.0.1) to 16000 mA. 2023-08-01 15:57:20,696 Charger state changed from 1 to 2 2023-08-01 15:57:21,727 Charger state changed from 2 to 3 2023-08-01 15:58:19,628 Charge manager watchdog triggered! Received no available current update for 30000 ms. Setting available current to 10000 mA 2023-08-01 15:59:29,573 Redistributing current 2023-08-01 15:59:29,573 1 charger requests current. 19950 mA available. 2023-08-01 15:59:29,573 stage 0: Calculated target for eins (127.0.0.1) of 6000 mA. 13950 mA left. 2023-08-01 15:59:29,584 stage 0: 13950 mA still available. Recalculating targets. 2023-08-01 15:59:29,594 stage 0: Recalculated target for eins (127.0.0.1) of 6000 mA. 13950 mA left. 2023-08-01 15:59:29,604 stage 0: 13950 mA still available. Attempting to wake up chargers that already charged their vehicle once. 2023-08-01 15:59:29,615 stage 1: Throttled eins (127.0.0.1) to 6000 mA. 2023-08-01 15:59:29,625 stage 1: Throttled a charger. Skipping stage 2 2023-08-01 15:59:29,635 Skipping stage 2 Um 15:57 wird Strom verteilt, das führt dazu, dass die eine Wallbox (habe die in eins und zwei umbenannt) anfängt zu laden. Deshalb startet der 120 Sekunden-Countdown der Startphase. Die erste Stromverteilung danach (15:59) gibt dann wieder nur 6 Ampere frei. Ich melde mich nochmal, wenn ich mehr weiß. Danke schonmal für die Hilfe bei der Fehlersuche :)

Das sollte so funktionieren, ja. Der Energy Manager benutzt das Lastmanagement-Protokoll um die CP-Trennung auszulösen. Das entsprechende Paket wird vom EVSE Common-Modul verarbeitet und das wiederrum ruft EVSE::set_control_pilot_disconnected auf. Da gibst du den Befehl an EVSE CPC weiter soweit ich das sehe -> Sollte klappen.

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.