MatzeTF

Nein. Das Einzige, was du auf den Bricklets permanent schreiben kannst, ist die UID. Du könntest also dem immer vorhandenen IO-4 Bricklet eine UID nach einem festen Muster geben, z.B. Seriennummer + Typ * 1000. Die UIDs von Master Bricks kann man leider nicht ändern.

„Manuelle Ladefreigabe“ bedeutet, dass jemand im Webinterface auf „Start“ oder den Taster an der Wallbox drücken muss (sofern der so eingestellt ist, dass eine Ladung damit gestartet werden kann). Das ist also eine zusätzliche Freigabe, unabhängig von EVCC. Üblicherweise ist das nicht das, was du in Kombination mit EVCC haben willst, und du solltest es wieder ausschalten. Was du brauchst, ist die Externe Steuerung. Ist die aktiviert?

Mit der Option „Externen Steuerung“ funktioniert das nicht, da die nur den Ladestrom begrenzen kann. Schau dir mal die inject_tag API an. Damit kann man eine NFC-Karte vortäuschen, um einen Ladevorgang zu starten oder zu stoppen.

Es gab leider ein Speicherleck in der Firmware, das wir erst vor kurzen gefunden haben. Bei der WARP 1 wurde es dadurch wahrscheinlicher, dass sie wegen zu wenig Speicher abstürzt, und gerade MQTT ist ziemlich speicherhungrig. @mattsches müsste bei Gelegenheit auf den aktuellen Entwicklerstand aktualisieren.

Kurz zur Info: rtrbt ist aktuell krank. Dementsprechend dauert es leider noch etwas, bis er sich dein Log ansehen kann. Jetzt sollte aber alles notwendige drinstehen.

In dem Protokoll steht wieder nichts von dem drin, was wir brauchen. Nur nochmal zur Sicherheit: Start klicken Browser und Tab offen und sichtbar lassen Das Problem möglichst reproduzieren Stop klicken Du darfst zwischen Start und Stop auf keinen Fall Tab oder Browser schließen. Du solltest in der Zeit auch nicht zu einem anderen Tab oder einer anderen App wechseln oder das Display ausschalten bzw. zuklappen. Die Datei sollte anschließend deutlich größer als 60 kB sein.

V2L ist nicht netzsynchronisiert. Das sollte man besser nicht mit einer Steckdose im Haus verbinden. 😉

Bidirektionales Laden behalten wir im Auge, allerdings ist da im Moment außer viel heißer Luft nichts zu holen. Einige Fahrzeuge unterstützen bereits bidirektionales Laden per DC, allerdings braucht man dafür eine sehr teure DC-Wallbox. Ich bin mir gerade gar nicht sicher, ob es überhaupt schon bidirektionale DC-Wallboxen für Privatnutzer gibt. Es gibt AC-Wallboxen anderer Hersteller, die damit werben, bidirektionales Laden zu unterstützen, allerdings gibt es noch gar kein Fahrzeug, das bidirektionales Laden per AC unterstützt. Das Problem bei bidirektionalem Laden ist, dass es aus technischer Sicht Unsinn ist, da die Cobalt-basierten Lithium-Ionen-Akkus in Autos nicht für häufige Ladezyklen im stationären Einsatz geeignet sind. Wenn du ein Einfamilienhaus an ein Auto hängst, ist dein Akku schon nach wenigen Jahren auf unter 70 % SOH gesunken, was üblicherweise als Grenze angesehen wird, ab wann ein Tausch fällig wird. Die Fahrzeughersteller garantieren meist >100.000 km bis der Akku so weit verschlissen ist, aber wenn dein Auto nur zu Hause steht, machst du keinen einzigen Kilometer und könntest dann theoretisch alle paar Jahre einen neuen Akku vom Hersteller fordern. Da die Hersteller das verständlicherweise nicht wollen, ist die maximale Energieentnahme im V2G/V2H-Betrieb so weit begrenzt, dass sich das Fahrzeug bei regelmäßigem V2G/V2H-Einsatz z. B. schon nach zwei Jahren weigert, weiter Energie abzugeben, und das Ganze somit nur bedingt praktisch nutzbar ist. Im stationären Einsatz werden übrigens Lithium-Eisenphosphat-Akkus eingesetzt, die eine viel größere Anzahl Ladezyklen vertragen. Die haben allerdings nur die halbe Energiedichte, was egal ist, wenn du irgendwo im Keller einen großen Klotz hinstellen kannst, aber bei Autos bedeuten würde, dass sich die Reichweite halbieren würde.

The error simply means that iao is declared elsewhere and therefore inaccessible. You could make it accessible, but the actual problem is that you cannot call API functions from within callback handlers. Our usual strategy to escape from callback handlers is using a scheduled task with a delay of 0. If you look around our ESP32 firmware code, you will find it in several places. #include "task_scheduler.h" […] if (value[0]== 0 && value[1] == 0) { task_scheduler.scheduleOnce([]() { logger.printfln("00 output 0%%"); set_iao_out(0); }, 0); } […] void set_iao_out(uint16_t voltage) { tf_industrial_analog_out_v2_set_voltage(&iao, voltage); } You will have to make iao accessible to the set_iao_out() function, either by making it global or public in your module’s class. Btw, you can write "%%" if you want to print a % with a printf-style function.

Die Wallbox gibt nur den maximal erlaubten Ladestrom vor. Dem Fahrzeug ist es dann freigestellt, einen beliebigen Ladestrom unterhalb dieser Grenze zu nutzen. Die meisten Fahrzeuge bleiben sicherheitshalber immer ca. 1 A unter dem erlaubten Ladestrom, um nicht zu riskieren, dass eine Sicherung fliegt. Daher ist es nicht verwunderlich, dass dein e-UP bei erlaubten 6 A tatsächlich mit 5 A lädt. Weniger kann die Wallbox übrigens nicht vorgeben, da das der minimal erlaubte Wert ist und das Fahrzeug einen geringeren Wert als Fehler interpretieren muss. Der Sprung von 7 A auf 5 A kann verschiedenste Gründe haben. Da denken sich die Fahrzeughersteller vieles aus. Zwei Faktoren sind aber definitiv SOC und Temperatur. Ist der Fahrzeugakku fast voll, wird die Ladeleistung reduziert. Bei den aktuellen Außentemperaturen kann es auch einfach sein, dass der Akku kalt ist. Zum Schutz der Zellen wird dann nur langsam geladen. Teilweise wird auch erst etwas schneller geladen und dann reduziert, wenn das Batteriemanagementsystem feststellt, dass den Zellen das aktuell nicht gefällt. Die instabilen Ladevorgänge bei 6 A muss sich @borg ansehen.

Prinzipiell hat der Motortreiber vom Bricklet einen Bremsmodus. Wenn der aktiviert ist, sollte die Motordrehzahl ungefähr proportional zum PWM sein. Ist der Motorstrom höher, als bei dem eingestellten PWM zu erwarten wäre, sollte der Motortreiber anfangen zu bremsen. Ich würde also erwarten, dass der Motor selbst bei gleicher Drehrichtung ein Bremsmoment erzeugt, wenn du versuchst, ihn mit einem anderen Motor zu beschleunigen. Falls das nicht der Fall ist, solltest es möglich kein, den Motor in der Gegenrichtung anzusteuern, wie du bereits vorgeschlagen hast. Der Motortreiber ist gegen Überhitzung und zu hohe Motorströme geschützt; da sollte nichts kaputtgehen. Bei großen Gegenmomenten über einen längeren Zeitraum könnte eine aktive Kühlung für das Bricklet sinnvoll sein. Behalte mal den integrierten Temperatursensor im Auge. Da das Bremsmoment vom Motortreiber generiert werden sollte, könnte es für dich schwer werden, ein definiertes Bremsmoment einzustellen. Null Bremsmoment bei null Velocity funktioniert wahrscheinlich nicht. Du kannst versuchen, den vom Bricklet ausgegebenen Stromverbrauch für einen Bremsregler zu verwenden, da der Strom proportional zum Drehmoment sein sollte. Wie genau das ist, kann ich dir nicht sagen. Für ein genaues Bremsmoment brauchst du wahrscheinlich ein Torsionselement mit Sensor in der Achse zwischen den Motoren.

Wenn der WEM schon auf dreiphasig steht und dreiphasig geladen werden soll, wird keine Phasenumschaltung mit der dazugehörigen CP-Trennung durchgeführt. Es kann allerdings sein, dass die einfache CP-Trennung zum Aufwecken durchgeführt wird, falls das Auto nach der Freigabe nicht gleich anfängt zu laden.

Schau dir mal das Tutorial zur ESP32-Firmware an. Dann musst du dir ein Backend-Modul bauen, das deine drei Bricklets regelmäßig nach den Strom- und Spannungswerten fragt und diese in einem „state“ zur Verfügung stellt. Wann du dann MQTT aktivierst, kannst du die Daten in Node Red per MQTT empfangen.

Bei RS485 handelt es sich üblicherweise um einen Bus, der an beiden Enden terminiert werden muss. Befindet sich das Bricklet an einem Ende, muss die Terminierung aktiv sein, befindet es sich in der Mitte, muss sie deaktiviert sein. Master oder Slave spielt dabei keine Rolle. Das hört sich schon mal sehr gut an. Was ist mit Holding Register 1100 und 1102? Direkt hinter dem Register 1100 steht im Register 1101 auch eine 1 (für die Baudrate). Es ist also immer noch nicht ganz klar, welches Register du ausgelesen hast. Lies doch auch mal 401102 aus, wo eine 100 oder 101 drinstehen sollte. Manche Geräte mögen es nicht, wenn Einzelwerte ausgelesen werden, die nicht dafür vorgesehen sind. Versuch doch mal zwei Register ab Adresse 300201, 300202 oder 300203 auszulesen. Laut Anleitung ist das der Distanzwert, der einzeln gelesen werden kann. Da der Wert zwei Register belegt, müssen die aber gleichzeitig gelesen werden. Ansonsten versuch einfach nochmal 13 Werte ab 300119, 300200 und 300201 auszulesen.

First Input Number sollte korrekt sein. „Function ID 4“ bedeutet „Read Input Registers“, was du korrekt ausgewählt hast. Wenn die Sensoren für Halbduplex vorgesehen sind, muss das Bricklet auch auf Halbduplex eingestellt werden. Dabei werden RX und TX durch die DIP-Schalter gebrückt. Man kann die RX- und TX-Klemmen am Bricklet dann nicht unabhängig voneinander verwenden. Ob du deine Sensoren an den RX- oder TX-Klemmen anschließt, ist egal. Meine Verschläge: Überprüfe, ob die DIP-Schalter auf „Half-Duplex Terminated“ eingestellt sind, also 1, 2 und 3 ON, 4 nicht. Auf der Unterseite vom Bricklet ist das auch abgebildet. Überprüfe, ob RX/TX+ und RX/TX- vom Sensor korrekt angeschlossen sind. Im Zweifelsfall einfach mal tauschen. Da kann nichts kaputtgehen. Lies erstmal nur einen Wert ab Adresse 200 aus, also „Number of Inputs“ auf 1. Sind die Sensoren neu oder besteht die Möglichkeit, dass sie auf eine andere Adresse oder oder Baudrate eingestellt wurden? Ich bin mir übrigens nicht sicher, warum du meinst, dass du die Slave-Adresse der Sensoren nicht ändern kannst. Laut Anleitung steht die Adresse in Holding Register 1100 und kann einfach mit einer anderen Adresse überschrieben werden. Du kannst also bis zu 247 Sensoren an einem Bricklet anschließen.

Möchtest du den WARP Charger über FEMS steuern oder möchtest du, dass sich der WARP Charger die Stromwerte aus dem FEMS holt und selbst verarbeitet? Falls du den WARP Charger über FEMS steuern möchtest: FEMS gibt an, Wallboxen per openEMS steuern zu können. openEMS unterstützen unsere WARP Charger nicht direkt, aber für openEMS gibt es eine generische OCPP-Anbindung und OCPP wird vom WARP Charger unterstützt. Wie das genau funktioniert, kann ich dir leider nicht sagen. Falls du möchtest, dass sich der WARP Charger die Stromwerte aus dem FEMS holt, muss FEMS die Werte vom Stromzähler am Hausanschluss per SunSpec zur Verfügung stellen. Wenn das der Fall ist, kann der WARP Charger damit selbst Überschlussladen anbieten. Irgendwelche schlaue Ladelogik aus FEMS, die vielleicht Auto gegen Batteriespeicher balanciert wird dann allerdings nicht greifen.

Nein, leider nicht. Laut Protokoll gibt die Wallbox Strom frei und das Fahrzeug fordert keinen an. Warum das so ist, können wir nur mutmaßen, und inzwischen sind uns die Ideen ausgegangen. Leider ist da auch jedes Fahrzeug eine Black Box, aus der man nichts außer „geht nicht“ rausbekommt. Würden uns die Fahrzeuge irgendwelche Anhaltspunkte liefern, wäre das Ganze ein Kinderspiel. Dazu kommt noch, dass diese ganzen schönen Features wie PV-Überschussladen, Phasenumschaltung, Fahrzeuge aufwecken und sowas im ursprünglichen Standard nicht vorgesehen waren und die Fahrzeughersteller prinzipiell nur für den Anwendungsfall „Fahrzeug einstecken und sofort mit maximaler Leistung laden“ planen.

Glaube ich auch nicht so recht, aber ich habe gerade keine anderen Ideen. 😉 Würdest du hier in der Region wohnen, hätte ich da echt gerne selbst mal einen Blick drauf geworfen.

Da wüsste ich jetzt ja echt gerne, was das gewesen sein könnte. 🤔 Hört sich aber irgendwie nach einer schlechten Verbindung an, die durch den Druck deiner Messproben nun wieder Kontakt hat. Seltsam.

Wie war das Schütz denn jeweils geschaltet? War es geschlossen oder geöffnet?

Klar kann man das machen. Ich halte das allerdings für sehr viel aufwändiger und fehleranfälliger, als einfach die dafür vorgesehene Komponente vom Arduino ESP32-Framework zu nutzen. Schau doch mal hier und anschließend hier unter „Client class“. Wenn du dir WiFiServer-Beispiele von irgendwelchen anderen Webseiten ansiehst, musst du nur bedenken, dass die loop()-Funktion in unseren Modulen nicht blockieren darf. Es darf also nirgends ein „while (client.connected())“ vorkommen. 😉

Wenn das kein Standardformat wie z. B. JSON ist, wirst du das selbst auseinandernehmen müssen. Dafür haben wir aktuell nichts. Es gibt vom Arduino ESP32-Framework aber sicherlich einen TCP-Server, den du dafür benutzen kannst. Du musst dann ein Modul in unserer Firmware anlegen und in der (pre_)setup-Phase den TCP-Server starten und entweder per Callbacks oder polling in der loop-Funktion eingehende Daten behandeln.

Mit reinen Strings statt JSON könnte man das ggf. machen, aber wenn du einfach nur einen Port mit Daten bewerfen willst, kannst du die Config-Objekte nicht nutzen. Läuft das Ganze überhaupt über TCP oder UDP? Vermutlich wirst du nach einer TCP- oder UDP-Server Lösung mit dem Arduino ESP32-Framework suchen müssen, das wir verwenden. Für UDP kannst du auch einen Blick in cm_protokoll.cpp werfen und nach „recvfrom“ suchen. Das ist aber nicht sehr einsteigerfreundlich.

@TMA84 @kagehisa Um das Problem weiter eingrenzen zu können, brauche ich ein Debug-Protokoll (System → Debug → Protokoll erstellen), auf dem der Schützfehler aufgezeichnet ist. 10 Sekunden vor der Phasenumschaltung, die das Problem verursacht, bis 10 Sekunden nach der Sicherheitsabschaltung reichen. Es wäre auch hilfreich, wenn ihr in Hörweite des Schützes das normale Ereignis-Log im Auge behaltet könntet und darauf achtet, zu welchem Zeitpunkt rund um das Auftreten des Fehlers ihr das Schütz schalten hört, also eher beim Auslösen der Schützüberwachung oder beim Übergang in „state 3“. Könnt ihr außerdem ein Foto machen, auf dem WEM, Schütz, die Verkabelung dazwischen und ggf. andere Geräte in direkter Nähe möglichst gut sichtbar sind? Was und wie hast du das gemessen? Hast du auf den Schraubkontakten vom Stecker am WEM gemessen, zwischen 12 V und Eingang 4? Welche Spannungen hast du gemessen? Im einphasigen Modus, also bei offenem Schütz, sollten da 11-12 V anliegen, im dreiphasigen Modus, also bei geschlossenem Schütz, nahe 0 V. Was mich am Fehler_log.txt verwundert, ist, dass der Schützfehler einfach so nach einiger Zeit aufgetreten ist, obwohl zu dem Zeitpunkt keine Phasenumschaltung durchgeführt wurde. 🤔 Hier wäre es sehr interessant, ob du irgendwas am Schütz hörst, wenn du die Einstellung in EVCC änderst, die das Problem verursacht. Zu schnell abspielen kann sich da eigentlich nichts. Während eine Phasenumschaltung durchgeführt wird, werden weitere Anfragen blockiert. Erst nach Abschluss der Umschaltung kann wieder eine neue Umschaltung angefordert werden und wenn man unbedingt möchte, kann man nach einer Umschaltung sofort die nächste anfordern, so oft man will. Das Schütz kann permanent angezogen bleiben, wenn EVCC das so möchte. Bei aktivierter externer Steuerung bleibt die Phasenumschaltung immer in dem Zustand, den EVCC als letztes angefordert hat. Hat EVCC dreiphasig angefordert und will 24 Stunden lang nichts anderes, bleibt das Schütz halt 24 Stunden angezogen.

Der Debug Brick ist nur zum Debuggen von allem im Stapel geeignet. Bei den alten Bricklets mit 10-poligem Stecker lief der Code auf einem Master-Brick, sodass man die auch damit debuggen konnte. XMC-basierte Bricklets mit 7-poligem Stecker kann man damit leider nicht debuggen. Zum Debuggen deines XMC-Codes kannst du die serielle Schnittstelle vom Logger auf einen Pin legen und dort einen TTL-Seriell-zu-USB-Wandler anschließen.