MatzeTF

Die MQTT-API ist praktisch eine Schnittstelle zwischen einem MQTT-Broker und einem PC mit Brick Daemon und angeschlossenem Master Brick. Mit einem ESP kannst du das nicht verwenden. Willst du den ESP benutzen, kannst du entweder die Arduino IDE benutzen, womit du wahrscheinlich einiges selbst machen musst, also z.B. Ethernet aktivieren, MQTT-Verbindung aufbauen und Daten darüber versenden, etc. Alternativ kannst du unsere ESP32 Firmware benutzen. Da ist der Einarbeitungsaufwand wahrscheinlich größer, aber dafür ist einiges schon fertig und es gibt ein Tutorial zum Bauen eigener Module für neue Funktionalität. Ethernet und MQTT sind schon fertig. Wenn du die Module drin hast, kannst du die Einstellungen einfach über das Webinterface des ESP anpassen. Legst du einen neuen „State“ für irgendwelche Daten an, werden die dann automatisch per MQTT bereitgestellt. Hier mal als Beispiel ein Modul, das ich benutze, um einfach die Temperatur von einem Humidity Bricklet per MQTT bereitzustellen: #include "module_dependencies.h" #include "temperature.h" #include "bindings/hal_common.h" extern TF_HAL hal; #include "api.h" #include "event_log.h" void Temperature::pre_setup() { state = Config::Object({ {"temperature", Config::Int(-27316, -27316, 65535)}, // in centicelsius (cC) }); } static void temperature_cb(TF_HumidityV2 * /*device*/, int16_t temperature, void *user_data) { ConfigRoot *state = static_cast<ConfigRoot *>(user_data); state->get("temperature")->updateInt(temperature); } void Temperature::setup() { if (tf_humidity_v2_create(&bricklet_humidity, nullptr, &hal) == TF_E_OK) { tf_humidity_v2_register_temperature_callback(&bricklet_humidity, temperature_cb, &state); tf_humidity_v2_set_temperature_callback_configuration(&bricklet_humidity, 500, false, 'x', 0, 0); initialized = true; } if (initialized) { logger.printfln("Ready"); } else { logger.printfln("No Humidity Bricklet 2.0 found"); } } void Temperature::register_urls() { api.addState("temperature/state", &state); } In pre_setup einen State anlegen, der hier nur einen Temperaturwert enthält. In setup das Bricklet einrichten und den Callback für die Temperatur aktivieren. Der Callback schreibt einfach die Temperaturwerte in den State. In register_urls den State registrieren, damit er automatisch per MQTT bereitgestellt wird. Das Auslesen eines RS485-Zählers ist da natürlich deutlich aufwändiger. Außer, du willst zufällig einen Eastron SDM72DM, SDM72DMv2 oder SDM630 auslesen. Das haben wir schon fertig und wenn du die Module „meters“ und „meters_rs485_bricklet“ einbaust, bist du praktisch fertig. Für andere Zähler kannst du dir letzteres Modul ansehen und etwas Ähnliches für deinen Zähler implementieren oder alternativ das Modul erweitern.

Aktuell ist das die Lösung für dich. Demnächst™ gibt es irgendwann zwar von uns ein neues Lastmanagement, das PV-Überschussladen mit mehreren Wallboxen kann, aber SoC-Auslesen kann es dann noch nicht, sodass du wohl bei evcc bleiben musst.

Du kannst prinzipiell beides gleichzeitig verwenden. Auf jeder Wallbox greift das jeweils niedrigere Limit. evcc kann gerne beiden Wallboxen sagen, dass sie mit 32 A laden sollen, da das Lastmanagement beiden jeweils nur 16 A erlaubt, wenn beide gleichzeitig aktiv sind. Begrenzt evcc den Ladestrom auf 10 A, darf nur mit 10 A geladen werden und die 16 A vom Lastmanagement haben keinen Einfluss. Nachteilig an der Kombination ist allerdings, dass es zu einer zusätzlichen Verzögerung kommt, wenn evcc den Strom erhöht. Die Erhöhung muss nämlich zusätzlich vom Lastmanagement abgesegnet werden, was bei einer aktuellen Firmware fünf Sekunden benötigt, wenn ich mich recht erinnere.

Dann ist die Wallboxseite jetzt das einzige, was du noch nicht getestet hast. Wenn du keinen anderen Switch hast und dir auch keinen leihen kannst, hast du einen Laptop mit LAN-Port? Wenn der halbwegs aktuell ist, sollte der Auto-MDI-X können, sodass du ihn direkt an die Wallbox hängen kannst. Ansonsten kann EEE bei manchen Verbindungen Probleme machen, wenn ein Kabel fälschlicherweise als kurz erkannt wird und das Signal dann zu schwach eingestellt wird. Hast du schon ausprobiert, das zu deaktivieren? Was mir gerade noch einfällt: Wenn du ein „Fabrik-Kabel“ benutzt, wie hast du das mit Stecker durch die Kabeldurchführung bekommen? Eigentlich muss man für den Anschluss der Wallbox mindestens an einer Seite einen Stecker selber crimpen.

Der Ethernet-Brick kann nur 100 MBit. Der Test mit den Switches war nur dafür gedacht, um das Kabel zu testen. Wenn da irgendwas nicht passt, kommt üblicherweise keine Gigabit-Verbindung zustande. Von Link-Problemen beim Ethernet-Brick ist mir nichts bekannt. Es ist eigentlich immer die Verkabelung Schuld. Da ich selbst schon Probleme mit schlecht gecripten Kabeln oder vertauschten Adern hatte, was ich meistens selbst verursacht hatte, halte ich das für die wahrscheinlichere Ursache. Weitere Ideen: Hast du schon einen anderen Port am Switch ausprobiert? Hast du schon versucht, den Switch, an dem die Wallbox hängt, nach draußen zu tragen und die Wallbox direkt anzuschließen? Falls der Switch nicht bewegbar ist, hast du schon versucht, einen anderen Switch draußen direkt an die Wallbox anzuschließen? Falls der Switch, an dem die Wallbox hängen sollte, EEE (Energy-Efficient Ethernet) kann, kannst du das auf dem Port deaktivieren? Da es ein managed Switch ist, kannst du mal die Verbindungsgeschwindigkeit von dem Port fest auf 100 MBit stellen? Wenn es die entsprechende Option gibt, Auto-negotiation an lassen aber Gigabit bei den möglichen Geschwindigkeiten abwählen. Hilft das alles nicht, mal die Geschwindigkeit fest auf 10 MBit Full-Duplex stellen?

In deinem ersten Log, das du auch oben zitiert hast, sieht man, dass es ca. 60 Sekunden gedauert hat, bis nach dem Start der Ethernet-Schnittstelle dann auch tatsächlich ein Link da war. Normalerweise liegen zwischen Start und Connect nur wenige Millisekunden, wenn eine gute Verbindung besteht. Zusammen mit der ansonsten instabilen Verbindung deutet das darauf hin, dass das Netzwerkkabel irgendein Problem hat. Wenn ein anderes Gerät am Kabel Verbindung hat, heißt das nicht, dass das Kabel in Ordnung ist. Wenn die Verbindungsqualität gerade so an der Grenze ist, kann es sein, dass einige Geräte eine Verbindung hinbekommen, andere nicht. Leider ist es oft schwierig, bei Kabelproblemen die tatsächliche Ursache rauszufinden. Bei selbst gecripten Kabeln ist oft die Crimpung nicht ganz richtig oder bei an beiden Enden selbst gecripten Kabeln sind gerne mal zwei Adern vertauscht, so dass die Aderpaare nicht paarig sind. Sind auf der Strecke zwischen Switch und Endgerät auch noch Netzwerkdosen, trifft das da genauso zu. Wenn du noch einen anderen Switch hast, häng den doch mal testweise an der Wallboxseite ans Kabel und die Wallbox dann daran. Wenn beide Switches Gigabit können, achte auch mal darauf, ob der Link mit Gigabit zustande kommt oder nur 100 MBit schafft.

Wenn du „WLAN als Fallback“ aktiviert hast, musst du u.U. das Netzwerkkabel ausstecken, damit sich der Accesspoint nach 10-30 Sekunden aktiviert. Solange die Wallbox glaubt, dass eine LAN-Verbindung besteht, wird der Fallback-Modus nicht aktiviert. Der Aufkleber im Inneren der Wallbox befindet sich üblicherweise auf der Front von einem der Schütze. Würde mich wundern, wenn der da nicht ist, kann aber natürlich versehentlich vergessen worden sein. Den zweiten, identischen Aufkleber auf der Rückseite der Anleitung hast du ja schon gefunden. Was meinst du mit „WLAN-Verbindung aktiviert“? Hast du den AP dauerhaft aktiviert oder die Wallbox in deinem WLAN angemeldet? Letzteres ist zusammen mit einer LAN-Verbindung nicht empfehlenswert, da das paradoxerweise zu Verbindungsabbrüchen führen kann, wenn beide Verbindungen abwechselnd versuchen, die Netzwerkkonfiguration zu setzen. Hast du eine LAN-Verbindung, solltest du die WLAN-Verbindung ausschalten. Der Accesspoint der Wallbox ist davon unabhängig und kann dementsprechend entweder dauerhaft oder im Fallback-Modus aktiviert sein.

4 mA? Ich sehe eine Fußnote mit 3 mA. Aber jetzt wo du’s sagst: Die Temperatur habe ich komplett vergessen. Die Angaben im Datenblatt beziehen sich auf 25 °C Umgebungstemperatur. Die 2 mA und 1,5 V können sich also auf die Grenzen des zulässigen Arbeitsbereiches von -40 °C bis 85 °C beziehen.

War bei mir noch nicht angekommen. Dann musst du deine 22 kW-Wallbox nur noch anmelden, damit der Energieversorger zumindest weiß, warum in der Nachbarschaft die Lichter ausgehen, wenn du dein Auto einsteckst. 😉 Die ebenfalls seit Januar 2024 geforderte Möglichkeit zum Runterregeln einer Wallbox ist bei uns schon Thema und soweit ich weiß hat das noch kein Energieversorger flächendeckend ausgerollt. Mal abgesehen davon, dass es außer den klassischen potentialfreien Schaltkontakten noch keine standardisierte Schnittstelle dafür gibt.

Bei der Angabe „Input Control Current to Activate“ steht ein typischer Wert von 0,55 mA und ein maximaler Wert von 2 mA. Das bedeutet, dass das SSR ab 2 mA garantiert voll durchschaltet, üblicherweise aber 0,55 mA ausreichen. Die Vorwärtsspannung hätte man auch bei 2 mA angeben können. 5 mA ist entweder ein weit verbreiteter Standardwert oder in dem Bereich befindet sich die Änderung der Vorwärtsspannung schon im asymptotischen Bereich und ändert sich nicht viel. Geh einfach davon aus, dass 5 mA mehr oder weniger zufällig >2 mA gewählt wurde. Bei „Input Voltage Drop“ sieht man aber auch, dass die Vorwärtsspannung üblicherweise bei nur 1,36 V liegt. Bei den Grafiken zur Performance hätte ich gerne eine Grafik mit Vorwärtsspannung vs. Vorwärtsstrom gehabt, gibt es aber leider nicht. Stattdessen sieht man in der ersten Balkengrafik, dass es unter den getesteten Chips keinen mit einer Vorwärtsspannung über 1,37 V gab. In der zweiten Balkengrafik sieht man, dass es unter den getesteten Chips keinen mit einem Vorwärtsstrom über 0,7 mA gab. Prinzipiell hätte man das Bricklet so designen müssen, dass man vom Worst Case ausgeht, also 1,5 V Vorwärtsspannung und mindestens 2 mA Vorwärtsstrom. In der Praxis reicht der Vorwärtsstrom aber immer aus. Geht man von einer Vorwärtsspannung von 1,37  V aus, kann ein Strom von 1,93 mA fließen, was deutlich über 0,7 mA liegt. Geht man von den 0,7 mA Vorwärtsstrom aus, liegen 2,6 V Vorwärtsspannung an, was deutlich über 1,37 V liegt. Es wäre möglich, dass ein Chip tatsächlich bei beiden Werten das Maximum brauch. Praktisch tritt das aber nicht ein. Falls doch, wird dann vielleicht mal ein Bricklet bei der Qualitätskontrolle aussortiert. Meine Vermutung wäre, dass du im eingeschalteten Zustand ca. 1,37 V über das SSR misst und ca. 1,9 V über den Vorwiderstand. Der Rest geht beim XMC verloren.

Die Warp2 kann prinzipiell selbst PV-optimiert laden. Das „Problem“ ist gewissermaßen, dass die Stromzählerwerte vom Hausanschluss irgendwie zur Warp2 kommen müssen. Eine Funktion vom Energy Manager ist, einen Zähler am Hausanschluss direkt auszulesen. Ist bereits ein auslesbarer Zähler vorhanden, was hier ja für EVCC bereits der Fall sein sollte, braucht man den Energy Manager dafür nicht. Die Frage ist, ob der Zähler mit der Warp2 kompatibel ist. Eine Übersicht dazu findest du hier. Ist dein Zähler nicht kompatibel aber du kannst etwas programmieren, kannst du die Daten auch selbst aus dem Zähler lesen und per API an die Warp2 füttern. Bekommst du deine Zählerwerte nicht in die Warp2, spricht aber auch nichts dagegen, einfach bei EVCC zu bleiben, wenn du das bereits eingerichtet hast. Ansonsten ist eine weitere Funktion vom Energy Manager die Phasenumschaltung für Warp2 zum Nachrüsten. Damit kann die Warp2 sowohl dreiphasig als auch einphasig laden. Wenn du aktuell ohne auskommst und du die Zählerfunktion vom Energy Manager auch nicht brauchst, brauchst du den Energy Manager also nicht.

An Wallbox-Hardware muss nur das Kabel und der Widerstand zur Kabelcodierung getauscht werden. Alles andere in der Wallbox ist bereits für 22 kW geeignet. Als Widerstand brauchst du so einen. Ansonsten müssen natürlich Zuleitung und Absicherung der Wallbox für 32 A Dauerbelastung ausgelegt sein. Je nach Länge der Zuleitung bedeutet das 6 oder 10 mm². Außerdem muss eine 22 kW-Wallbox bei deinem Energieversorger angemeldet und genehmigt werden.

Das bedeutet, dass dir irgendwas geantwortet hat. Entweder sprichst du mit dem falschen Gerät, oder du sprichst mit der Ethernet Extension und die Portnummer passt nicht.

Try this version.

Okay, dann ist die Wallbox also nicht mit der Fritzbox verbunden, sondern mit einem anderen Switch. Ich vermute stark, dass das Problem dort zu suchen ist. Vielleicht startet der entweder selbst neu, wenn es ein gemanageter Switch ist, oder irgendwas schaltet um 20 Uhr immer kurz den Strom ab.

Eine automatische Netzwerktrennung ist nicht vorgesehen und wir haben bisher auch noch nie von derartigen Problemen gehört. Ich habe zu Hause die gleiche Netzwerkhardware, die auch in der Wallbox steckt, an einer alten Fritzbox hängen, und die Verbindung besteht ohne Unterbrechung seit über einem halben Jahr (da war Stromausfall 😒). Es gibt ansonsten in der Wallbox auch keine Möglichkeit, zur Laufzeit die Netzwerkverbindung zu unterbrechen; dafür wäre ein Neustart nötig, der aber laut Log nicht stattfindet. In der Fritzbox gibt es auch ein Ereignisprotokoll. Steht da irgendwas rund um 20:00 drin? Vielleicht auch etwas, das nicht mit LAN zu tun hat, also Internet-Neueinwahl oder WLAN-Probleme? Oder beginnt das Log immer um 20:00, was auf einen Neustart hindeuten würde? Ansonsten könnte es einen mechanischen Einfluss oder EMI geben. Vielleicht wird das Netzwerkkabel durch irgendwas bewegt? Garagentor oder Rolladen, der sich um 20:00 bewegt? Sind andere elektrische Leitungen parallel zum Netzwerkkabel verlegt und die daran angeschlossenen Verbraucher schalten sich um 20:00 ein oder aus? Interessant finde ich, dass nach der ersten Trennung am Tag immer eine weitere Trennung nach 18 Sekunden Verbindungsdauer folgt (abgerundet auf 17). Plus Verbindungsaufbau von ca. 6 Sekunden macht das zwei Trennungen im Abstand von 24 Sekunden. Am 21.5. gab es 32 Sekunden später noch eine Trennung, inklusive einer weiteren Trennung 18 Sekunden später. Ein Neustart der Fritzbox verursacht üblicherweise zwei Trennungen kurz nacheinander. Wenn die Fritzbox allerdings erwiesenermaßen nicht neustartet, muss es irgendein sehr regelmäßiger externer Einfluss sein, der am 21.5. zweimal aufgetreten ist. Irgendwas, das sich um 20 Uhr einschaltet und exakt 24 Sekunden später wieder ausschaltet. Und am 21.5. war das dann zweimal kurz nacheinander aktiv. Wie lang ist eigentlich das Netzwerkkabel und welchen Typ hat es? Und ist es irgendwo an einer geerdeten Netzwerkdose aufgelegt oder ist es auf Fritzbox-Seite nicht geerdet? Ein Ladevorgang würde nur dann unterbrochen werden, wenn das integrierte PV-Überschussladen oder etwas anderes aktiviert ist, was Messwerte übers Netzwerk bekommt. Ansonsten wird einfach weiter geladen. Wenn ist das richtig sehe, hast du EVCC aktiviert. Wenn mich meine Erinnerung nicht gerade im Stich lässt, wird bei einem Netzwerkausfall einfach mit dem letzten vorgegebenen Stromwert weiter geladen.

Der Renault Zoe, der kein Ladelimit hat, verwendet NMC-Akkus, die üblicherweise eine Ladeschlussspannung von 4,2 V haben. Laut OBD-Leser werden die Zellen allerdings nur bis 4,05 V geladen. „100 %“ sind also gar nicht 100 %, bezogen auf die Akkutechnologie. Dementsprechend werden die Zellen gar nicht so stark gequält. Mein Educated Guess wäre, dass dadurch quasi ein 90-95 % Ladelimit permanent eingebaut ist. Möglicherweise laden andere Autos die Zellen bis 4,2 V voll und bieten deswegen ein Ladelimit an, um die Zellen bei Bedarf doch nicht so sehr zu quälen. Über Sinn und Unsinn von Ladelimits bzw. Vollladen kann man streiten. Generell mögen Lithium-basierte Akkus es nicht, längere Zeit vollgeladen oder sehr tief entladen gelagert zu werden. Vollladen und dann das Auto einen Monat rumstehen lassen, ist keine gute Idee. Vollladen an sich ist aber prinzipiell kein Problem. Man kann also einfach vollladen, wenn man bald losfahren will. „Bald“ kann auch „am nächsten Tag“ sein. 😉 Ich wage zu behaupten, dass regelmäßiges Vollladen wahrscheinlich kein so großes Problem ist, wie es manchmal behauptet wird, solange man den Akku nicht dauernd auf 100 % hält, z.B. durch Nachladen nach jeder Fahrt. Vereinfacht würde ich das mal mit Laptop-Akkus vergleichen: Meist ist ein Laptop-Akku schon nach wenigen Jahren unbrauchbar, wenn man den Laptop permanent am Netzteil betreibt und der Akku dauerhaft auf 100 % gehalten wird. Baut man den Akku stattdessen aus, wenn der Laptop am Netzteil betrieben wird (sofern möglich), hat er auch noch nach Jahren viel Kapazität. Letzteres habe ich bei meinem vorletzten Laptop gemacht und dessen Akku hatte nach 12 Jahren immer noch ca. 70 % der ursprünglichen Kapazität. Nach inzwischen 20 Jahren schafft er nur noch ca. 30 % der ursprünglichen Kapazität, was daran liegen dürfte, dass ich ihn zu lange nicht mehr benutzt habe. Womit wir bei der Tiefentladung wären, was der absolute Lithium-Killer ist. Ansonsten ist bei Autos noch die Frage, wie das Ausbalancieren der Zellen im Zusammenhang mit dem Ladelimit umgesetzt ist. Wenn die Zellen beim Erreichen des Ladelimits nicht ausbalanciert werden und der Ladevorgang einfach beendet wird und zusätzlich der Nutzer nie bis 100 % vollläd, werden die Zellen nie ausbalanciert. Das ist auf Dauer schädlicher, als jedes Mal vollzuladen und auszubalancieren.

Die Ethernet Extension hat auch eine Versionsnummer. Wahrscheinlich hast du 1.1. Die Kombination funktioniert bei mir problemlos, wenn die Extension oben ist. Wie hast du den Stapel aufgebaut? Verwendest du Schrauben, bzw. Abstandsbolzen, oder hast du einfach nur beides aufeinander gesteckt? Wenn beides verschraubt ist, kann es passieren, dass die Platinen zu stark gebogen werden und dann einige Pins keinen Kontakt haben. Hat es eigentlich schon mal funktioniert und funktioniert jetzt nicht mehr oder hast du es noch nie zum Laufen bekommen?

Also bei mir war es gerade genau das. Mit der Extension unten gingen keine Pakete rein oder raus. Mit der Extension oben lief alles so wie es sollte. DHCP war aber ziemlich lahm und hat teilweise 15 Sekunden gebraucht, bis der Stack eine IP bekommen hat. Welche Version vom Master Brick und der Ethernet Extension hast du?

Tausch mal Master Brick und Ethernet Extension. Die Extension muss auf dem Master sitzen, nicht darunter. Ich bringe das auch immer durcheinander. 😑

Das offensichtliche zuerst: Haben Laptop und Ethernet Extension überhaupt Link? Wenn keines der Geräte Auto-Crossing unterstützt und du ein 1:1-Kabel verwendet hast, haben sie vielleicht einfach keine Verbindung? Wie hast du herausgefunden, dass der Stack beim Verbinden nicht nach einer IP fragt?

Bitte einfach auf der Seite mit dem Ereignis-Log einen Debug-Report runterladen und hier anhängen. In deinem Fall hätte ich allerdings einen Report zwischen 9:02 und 9:33 gebraucht, um zu sehen, warum nach dem Switch on-Ereignis kein Strom freigegeben wird. Wenn du den Fall nochmal siehst, bitte sofort einen Debug-Report runterladen. Ansonsten hat uns dein Log-Ausschnitt schon mal dabei geholfen, ein Problem mit der automatischen Phasenumschaltung für einphasig ladende Autos zu finden. Die zwei Phasenumschaltungen im Abstand von 22 Sekunden sind Unsinn. Die Zweite hätte nicht stattfinden sollen. Wird mit der nächsten Firmware repariert.

ocpp/state ist nur für uns zum Debuggen und deswegen nicht dokumentiert, da sich der Inhalt jederzeit ändern kann und dein Programm dann vielleicht nicht mehr funktioniert. Du kannst in evse/slots Slot 11 abfragen. Wenn der active ist, bedeutet das, dass OCPP eingeschaltet ist. Dann bedeutet max_current != 0, dass OCPP eine Freigabe erteilt hat.

Ja, das stimmt. Dann musst du wohl doch deine erste Idee mit dem NFC-Tag senden implementieren. Ich sehe gerade, dass ich deine „Heimatomatisierung“ als „Halbautomatisierung“ gelesen habe. So oder so müsstest du das selbst programmieren, da es da noch nichts gibt. Du kannst aber den OCPP-Zustand per API abfragen und du kannst NFC-Tags per API vortäuschen.

Das mit der Halbautomatisierung sollte funktionieren. Die Frage ist eher, wozu brauchst du noch eine lokale NFC-Authentifizierung wenn CaF bereits deine Tag-IDs kennt und per OCPP die Ladung freigibt, wenn du eins der Tags dranhältst?