MatzeTF

Laut Log bricht die Erkennung wegen einer unerwarteten Antwort vom Wechselrichter ab. Es ist möglich, dass es noch weitere Modelle gibt, die dir den Netzbezug liefern könnten. Kannst du uns eine Portweiterleitung einrichten, damit wir uns die SunSpec-Antwort von deinem Wechselrichter genauer ansehen können? Falls ja, leite einfach irgendeinen TCP-Port über 10000 auf Port 502 deines Wechselrichters weiter. Wenn du DynDNS hast, wäre das super, ansonsten kannst du deine IP des Tages per PM an mich schicken oder ich schaue nach, von welcher IP dein letzter Post gesendet wurde. 😉

Wir arbeiten gerade daran, PV-Überschussladen als Feature in die Wallboxen zu integrieren. Um das nutzen zu können, brauchst du einen zweiten Zähler, der den Netzbezug am Hausanschluss misst. Viele Wechselrichter stellen diese Information über SunSpec zur Verfügung, weshalb wir die Wallboxen bereits SunSpec-kompatibel gemacht haben. Wer den Netzbezug auf andere Art misst, kann sich als zweiten Zähler einen API-Zähler einrichten und die Werte über eine eigene Anwendung in die Wallbox schieben. Die Werte deines Wechselrichters sind negativ, weil es sich dabei um PV-Produktion bzw. Energieabgabe aus dem Speicher handelt. Der Wert ist offensichtlich nicht der Netzbezug bzw. -einspeisung am Hausanschluss. Ich interpretiere die Grafik so, dass du ab 8 Uhr morgens etwas Sonne hattest und bis kurz nach dem Mittag ein paar Mal viel Strom gebraucht hast und sonst der Speicher geladen wurde, der gegen 13 Uhr voll war und den Stromverbrauch deines Hauses bis ca. 23 Uhr gedeckt hat. Wechselrichter, die den Netzbezug messen können, stellen dafür üblicherweise ein zweites Gerät per SunSpec zur Verfügung. Kannst du die SunSpec-Gerätesuche nochmal laufen lassen und das Log hier posten?

Es gibt leider keine Möglichkeit, die Batteriespannung aus der Ferne auszulesen. Wenn man nur den Stromverbrauch vom RTC Bricklet beachtet, liegt die theoretische maximal Batterielebensdauer bei ca. 2 Jahren. Dabei ist es unerheblich, ob der RPi läuft oder nicht. Das Problem ist, dass die Batterie auch ohne Verbraucher altert und die zwei Jahre nicht erreichen wird. Dazu kommt, dass die Batterie wahrscheinlich vor dem Versand schon ein paar Monate im Regal lag. Wenn da einiges unglücklich zusammenkommt, kann es passieren, dass sie schon nach einem halben Jahr leer ist. Ich habe gerade mal ein RTC Bricklet mit eingesetzter Batterie aus der Schublade gekramt und da war nach ca. einem Jahr auch die Batterie leer. Die Batteriespannung beträgt da aktuell noch 0,3 V. Wahrscheinlich hatte das Bricklet die Uhrzeit also schon vor längerer Zeit vergessen. Die gute Nachricht ist, dass du mit etwas Bastelei eine fast beliebige andere Batterie oder auch einen Akku oder Supercap anschließen kannst. Letztere müsstest du allerdings selbst nachladen. Der verwendete IC akzeptiert laut Datenblatt alles von 0.9 bis 5 V. Du könntest dir z.B. einen Adapter für AA Batterien basteln und dann für besonders lange Haltbarkeit eine AA Batterie auf Lithium-Basis nehmen. Ich nehme für sowas die Energizer Ultimate Lithium (#notsponsored). Bei dem geringen Verbrauch des RTC Bricklet dürfte die Batterie somit nur durch ihre Lager-Lebensdauer von 20 Jahren begrenzt sein. Ansonsten tut’s natürlich auch jede andere „dickere“ Knopfzelle, wobei ich wahrscheinlich bei ca. 1,55 V Zellenspannung bleiben und keine CR2032 nehmen würde.

Ja, das Beispiel geht davon aus, dass du die Bricklets über einen Master Brick an den PC anschließt, auf dem tinkerforge_mqtt läuft. Die Verwendung eines ESP32 Bricks wird da in der Tat nicht berücksichtigt.

Da dein erster Post schon von letztem Jahr ist, bin ich mir gerade nicht ganz sicher, in welchem Zustand sich dein Setup gerade befindet. Wenn du diese Fehlermeldungen im Ereignis-Log des ESP32 Brick hast, dann hast du das MQTT-Modul mit in die Firmware kompiliert? Das korrekte Setup sollte so aussehen: Auf dem ESP32 Brick läuft die Standardfirmware. Auf der VM mit dem MQTT-Broker läuft kein Brick Daemon. Dem tinkerforge_mqtt Script musst du außer den Zugangsdaten für den MQTT-Server noch mittels --ipcon-host die Adresse des Gerätes mit den Bricklets angeben. In deinem Fall ist das die Adresse vom ESP32 Brick. Aktuell verbindet sich das tinkerforge_mqtt Script mit dem Brick Daemon der VM, aber an der VM sind gar keine Bricks oder Bricklets angeschlossen. Dementsprechend wird da nichts gefunden. Wenn du versuchst, MQTT-Nachrichten direkt an den ESP32 Brick zu schicken, versteht der die nicht, weil er keine automatische Übersetzung für die angeschlossen Bricklets durchführen kann.

Ja, mach mal bitte einen neuen Thread auf. Poste da dann nicht nur das Log vom Scan, sondern auch ein Debug-Log, das du am besten direkt nach dem Schließen den Scan-Fensters runterlädst. Es würde uns auch sehr helfen, wenn du uns eine Portweiterleitung auf dein Smart Meter einrichtest und wir damit testen können. Falls das okay für dich ist, nimm einfach irgeindenen TCP Port über 10000 und leite ihn auf Port 502 deines Smart Meter weiter. Wenn du DynDNS hast, wäre das super, ansonsten kannst du deine IP des Tages per PM an mich schicken oder ich schaue nach, von welcher IP dein letzter Post gesendet wurde. 😉

Bekommst du da mit der WARP sinnvolle Werte raus? Viele Hersteller haben eine sehr eigene Interpretation von Sunspec und wir hatten noch kein elgris-Gerät zum Testen. Falls zumindest der Leistungswert für den Netzbezug richtig ausgelesen wird, kannst du damit voraussichtlich ohne evcc direkt PV-Überschussladen nutzen, wenn wir die Integration für WARP 1, 2 und 3 fertig haben.

„Connection reset by peer“ bedeutet, dass die Wallbox versucht, eine Verbindung aufzubauen, die dann von der Gegenstelle abgelehnt wird. Entweder ist in der Wallbox nicht die richtige Adresse vom MQTT-Server eingetragen, oder der Server lehnt die Verbindung ab weil der MQTT-Daemon entweder auf dem falschen Interface läuft oder eine Firewall die Verbindung blockiert. Da du vermutlich mit Home Assistant und evcc zum MQTT-Server verbinden kannst, vermute ich, dass du einfach einen Tippfehler in der Adresse vom MQTT-Server in der Wallbox hast. Wir hatten auch schon mal das Problem, dass jemand die Adresse der Wallbox als MQTT-Server eingetragen hatte. Falls es das beiden nicht ist, lade doch mal hier ein Debug-Log von der Wallbox hoch.

Wenn der Hilfskontakt richtig eingerastet ist, bekommt man ihn meiner Erfahrung nach eigentlich nur mit Werkzeug oder roher Gewalt wieder los. Seltsam. Wir behalten das mal im Hinterkopf für den Fall, das sich noch jemand anderes mit mysteriösen Schützfehlern bei uns meldet. Ansonsten freuen wir uns einfach darüber, dass bei dir jetzt wieder alles zu funktionieren scheint. 😀

Zwischen Schütz und Hilfskontakt sollte gar kein Luftspalt sein, im Sinne von < 0,5 mm. Bei korrekter Installation hängen die eigentlich auch sehr fest aneinander und wir hören jetzt zum ersten Mal davon, dass sie sich von alleine voneinander gelöst haben.

Dann hattest du vorher wahrscheinlich die Beta-Firmware installiert. Danach ist das zu erwarten. Da niemand in dem Beta-Thread geantwortet hat, hatten wir den Eindruck, dass niemand die Beta ausprobiert hat. 😉

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.