MatzeTF

Die Umstellung von HT40 auf HT20 für die WiFi Station haben wir doch schon seit über einem Jahr drin, nur war sie vorher an anderer Stelle. Warum führt das jetzt dazu, dass Multicast-Packete abgeschnitten werden, obwohl alles andere noch funktioniert? Insbesondere, wenn die Verbindung in beiden Fällen angeblich mit HT20 hergestellt wird, selbst wenn HT40 nicht deaktiviert wurde. Meine Abneigung gegenüber WLAN bestätigt sich mal wieder. 🤢 Vielen Dank für deine umfangreiche Fehlersuche. Ich werde kommende Woche mal versuchen, das bei uns mit WLAN zu reproduzieren. Bisher haben wir unseren SHM 2.0 nämlich immer per LAN ausgelesen. Wenn du noch weiter motiviert bist, kannst du mal versuchen, den Code reinzunehmen, und im Aufruf von esp_wifi_set_bandwidth das WIFI_BW_HT20 durch WIFI_BW_HT40 zu ersetzen. Mich interessiert, ob der Funktionsaufruf an der Stelle das Problem ist, oder die gewünschte Einstellung.

Ja, das ist möglich. Im Gegensatz zum Eltako-Zähler möchte der aber mit GND angeschlossen werden. Ein passendes Kabel findest du bei den Warp2-Ersatzteilen.

Das ist … unerwartet. Wenn ich das richtig sehe, wurden da nur Dinge verschoben und die TX-Power von 21 dBm angefragt, was allerdings keinen Unterschied machen sollte, da sie in der DE-Zone eh auf 19,5 dBm begrenzt wird. Bist du zufällig motiviert, rauszufinden, welcher Teil von dem Commit das Problem verursacht? Edit: Wo ich so drüber nachdenke, haben wir ja die Reihenfolge, in der bei WiFi AP und Station gestartet werden, geändert. Ich frage mich, ob das nun dazu führt, dass die IGMP-Join-Nachricht für die Multicast-Nachrichten vom SHM 2.0 auf dem AP-Interface rausgeht, bevor das Station-Interface existiert. 🤔

Ich glaube, die Werte werden einzeln gelesen. Bei float32 also immer zwei Register auf einmal. Wäre super, wenn du das herausfinden könntest. Hast du zufällig einen ESP32, den du mit einer unserer Release-Firmwares flashes könntest? Da sowohl Release als auch Master mit dem SHM 2.0 bei uns funktionieren, würde mich interessieren, ob das Problem eher bei deinem Fork oder einer Inkompatibilität mit deinem SHM 2.0 zu suchen ist. Meinst du mit „upstream/master“ eigentlich, dass du unseren Master-Stand ohne eigene Änderungen gebaut hast?

Hm, interessant. Der SHM 2.0, den wir haben, lässt sich problemlos auslesen. Sehen wir uns an. Meinst du mit deinem „ursprünglichen Modul“ eigentlich deine Variante vor dem Merge in unseren Code oder die die direkt nach dem Merge von uns umgeschriebene Variante? Die Wallbox braucht mindestens alle zwei Sekunden neue Daten. Ab 2,5 Sekunden wird der Graph unterbrochen gezeichnet. Wenn ich mir das Log ansehe, dauert es ca. 4 Sekunden, um alle 72 Werte auszulesen. Auf Seiten der Wallbox ist keine Verzögerung drin, also kann ich mir nur vorstellen, dass die Modbus-Bridge die Daten zu langsam liefert. Teilweise werden nur sieben Werte innerhalb einer Sekunde ausgelesen. Kann es sein, dass noch ein anderer Prozess über die Bridge Daten aus dem Zähler liest und die Daten nicht gecacht werden? Ja, gibt es. Wir benutzen die kostenlose Variante vom Vorhersageserver, die nur 12 Abfragen pro Stunde erlaubt. Das Firmennetz hängt auf einer öffentlichen IP, sodass wenn wir alle gegen den richtigen Server testen würden, in kürzester Zeit das Limit überschritten wäre. Da wir zum Testen immer unsignierte Firmwares bauen, haben wir die Testdaten damit gekoppelt. Um deine implizite Frage zu beantworten: Du kannst das gerne auskommentieren und richtige Daten verwenden. Wenn du zu häufig, bzw. zu schnell, neustartest, wirst du aber das Limit treffen. Alternativ erstellst du dir ein eigenes Zertifikat und baust auch signierte Firmwares.

Es gibt LAN-Erdkabel mit unterschiedlichen Durchmessern. Je größer der Durchmesser, umso größer ist der beim Verlegen benötigte minimale Biegeradius. Die Kabeleinführungen unserer Wallboxen sind nur bis 8 mm Durchmesser geeignet. Dickere Kabel sollten nicht verwendet werden, da im Innern der Wallbox nicht genug Platz für die großen Biegeradien ist.

Aktuell ist das in der Tat irrelevant. Ansonsten ist der Unterschied, dass „PV“ für reine PV-Erzeugung steht und „Wechselrichter“ ein nebulöser Leistungswert vom Wechselrichter ist, der bei Hybrid-Wechselrichtern auch Leistung aus dem Batteriespeicher mit einschließen kann. Wenn du weißt, dass das nur PV-Leistung ist, stell es auf PV.

Naja, jetzt wird schließlich im PV-Modus gar nicht mehr geladen, weil ein Zähler ohne Werte erkannt wird. Das ist vielleicht auch nicht so gut…

Dann schon Mal für Dienstag: Schließ die PoE-Variante zuerst an und am besten gar nicht die Variante ohne PoE. Nur für den Fall, dass du Probleme mit gecachten ARP-Anfragen oder restriktiven Netzwerkswitches hast. Hast du eigentlich einen eigenen Switch auf dem Tisch stehen oder benutzt du nur die Netzwerkports vom Institut?

Hat die PoE Extension überhaupt Link? Auf den Bildern sieht das so aus, als wären keine der Link-LEDs an. Wenn du kein USB-Kabel anschließt, startet der Master Brick, wenn du die PoE Extension an einen PoE-Port anschließt?

Der ESP32 hat zwei Firmware-Slots. Wenn du per USB flasht, wird immer der Erste geschrieben und der Zweite invalidiert. Hier ist kein Rollback möglich. Du kannst von hier aus aber problemlos in den unten genannten Zustand kommen. Wenn du die Firmware per Webinterface (oder API) hochlädst, wird immer der nicht laufende Slot überschrieben. Falls die Firmware in dem Slot dann crasht, wird wieder der andere gestartet, also der Slot, der lief, als du die neue Firmware hochgeladen hast. Das funktioniert auch mit selbstgebauten Firmwares (vom aktuellen Master-Stand) und es wird immer wiederhergestellt, was auch immer sich im anderen Slot befindet. „Wiederhergestellt“ ist vielleicht auch der falsche Begriff. Die alte Firmware bleibt schließlich einfach da stehen, wird nur standardmäßig nicht mehr gestartet.

Ich konnte dein Problem leider noch nicht reproduzieren. Spontane Idee: Was passiert, wenn du bei der Wallbox das maximale MQTT-Sendeintervall wieder zurück auf 1 stellst? Zusatzfrage 1: Welchen MQTT-Broker verwendest du? Zusatzfrage 2: Warum nutzt du noch Firmware 2.6.6 und nicht die neueste Version?

Did you install the PoE Ethernet Extension above or below the Master Brick? The extension must be installed above the Master Brick to work correctly, ideally directly above it. If the extension is installed below the Master Brick, it will show up in the Brick Viewer and can be configured, but it won’t be able to communicate and thus won’t answer pings.

Wenn die Firmware innerhalb der ersten fünf Minuten crasht, wird sie automatisch auf die alte Firmware zurückgesetzt. Hält sie länger als fünf Minuten durch, hat aber irgendwelche anderen Probleme, kannst du jederzeit wieder eine ältere Firmware von Hand einspielen. Es kann allerdings sein, dass bei einem Downgrade manche Einstellungen verloren gehen, wenn sich deren Format für die neue Firmware geändert hat. Die letzten Formatänderungen betrafen aber nur den Fernzugriff bei Version 2.5.0 und 2.6.6. Für andere Dinge war die letzte Formatänderung bei Version 2.2.0.

I guess the Industrial Dual Relay’s status LED is still blinking when everything should be powered off? In that case, the power isn’t actually shut off. I can’t test that here right now, but as a workaround, you could try to use this right before setting the HAT’s sleep mode: tf_industrial_dual_relay_set_monoflop(n, true, 20000) Replace n with the number of the relay that’s switching the power. This call will instruct the Industrial Relay Bricklet to switch on relay n (which it already is) and then switch it off by itself after 20 seconds, effectively killing its own power. Adjust the time to match however long your system needs to shut down and what the HAT’s sleep time is. I chose 20 seconds, assuming that shutdown takes 10 seconds and the HAT’s sleep mode is set to 15 seconds.

Wir suchen wieder Beta-Tester für Firmwares. Es war an der Zeit, einige grundlegende Softwarepakete der Firmwares für WARP Charger und Energy Manager zu aktualisieren. Wie man vielleicht gemerkt hat, haben wir dabei seit Anfang des Jahres mächtig viel Staub aufgewirbelt. Nun ist es soweit: Der Umstieg ist geschafft und es muss getestet werden. Bei uns läuft zwar alles bestens, aber die Erfahrung zeigt, dass es immer wieder Kombinationen mit anderen Geräten gibt, bei denen dann doch nicht alles auf Anhieb funktioniert. Bitte testet diese Firmwares für eure WARP 3, WARP 2 und WARP 1, sowie Energy Manager 2.0 und 1.0 und meldet alles, was vorher funktioniert hat und jetzt nicht mehr funktioniert. Spannende neue Features gibt es in diesem Release nicht. Die wahrscheinlich einzige sichtbare Änderung ist, dass nach einem fehlgeschlagenen Firmware-Update jetzt automatisch wieder die vorige, lauffähige Firmware gestartet wird, statt die Geräte zu bricken. 😉 Ein Stromausfall innerhalb der ersten fünf Minuten nach einem Firmware-Update gilt dabei auch als Absturz, nach dem wieder die alte Firmware aktiviert wird. Für die Entwickler: Es wurden das IDF und das Arduino-ESP32-Framework aktualisiert. Ihr müsst jetzt in allen printf-Strings für uint32_t %lu und für int32_t %li (oder %ld) benutzen. Update 15.4.: Anbindung für SAX Power Batteriespeicher repariert SMA Speedwire über WLAN repariert Bekannte Probleme: Energy Manager 1.0/2.0 zeigen bei der monatlichen Energieanalyse nicht alle Balken an. Edit: Veraltete Firmware-Dateien entfernt.

Wenn ich das richtig sehe, hast du den zurücksetzbaren Energiewert eingetragen. Das Energielimit braucht aber den Wert seit Herstellung.

Bei WARP 2 und 3 kann man einstellen, wie sie angeschlossen sind. Ich bin mir nicht sicher, ob man das in einer alten WARP 1-Firmware jemals konnte, da der Zähler einer WARP 1 Pro keinen einphasigen Anschluss unterstützt und die Einstellung deswegen nicht existiert. Zu WARP 1-Zeiten war PV-Überschussladen noch gar nicht vorgesehen. Da wir versuchen, für alle Wallbox-Versionen möglichst die gleiche Software zu verwenden, haben wir es bei der WARP 1 gewissermaßen als Bonusfeature nachgelegt, falls jemand seine Wallbox nicht upgraden möchte und stattdessen ohne Extrakosten mit nur dreiphasigem PV-Überschussladen zufrieden ist. Man kann den Minimalüberschuss übrigens bereits einstellen. Das Minimum liegt bei einer dreiphasig angeschlossenen Wallbox allerdings bei 4140 W. Darunter kannst du nichts einstellen.

Ich glaube, jetzt verstehe ich, was du eigentlich versuchst zu erreichen. Du hast eine eigene Phasenumschaltung vor die Wallbox gebaut und willst der Wallbox nun mitteilen, ob gerade auf einphasig oder dreiphasig geschaltet wurde. Bei WARP 1 wird der einphasige Anschluss leider nicht unterstützt. Es gibt dementsprechend auch keine Möglichkeit, der Wallbox mitzuteilen, wie sie gerade angeschlossen ist. Die Anzeige der Phasen-Icons auf der Zählerseite ist dort rein kosmetisch. Die Sache mit dem Energielimit schauen wir uns an.

Die Phasenumschaltung ist leider auch recht unintuitiv für den Nutzer. Den genauen Grund für die drei Phasen kann ich dir nicht sagen, da ich dafür einen Debug-Report vom WEM für den Zeitraum gebraucht hätte. Bei Autos, die nicht laden wollen, kann es aber passieren, dass unnötigerweise auf dreiphasig geschaltet wird. Wenn dem Auto Strom zugeteilt wird, es aber nicht lädt, sieht der WEM weiterhin Überschuss am Netzanschluss und erhöht daraufhin die Stromzuweisung an die Wallbox. Reicht der Strom für dreiphasiges Laden, wird dann auch auf dreiphasig geschaltet. Das ist zwar sinnlos, aber leider nicht ganz so einfach zu verhindern. Da das aber nur auftritt, wenn ein Auto nicht richtig laden will, nehmen wir das aktuell so hin. Doch, das ist erlaubt. Das Auto wurde in dem Fall als einphasig erkannt, da es nur auf der ersten Phase etwas Strom gezogen hat. Bei einphasig ladenden Autos wird auch im Schnell-Modus auf einphasig umgeschaltet.

Zumindest dieses Rätsel lässt sich einfach lösen: Das sollte nämlich passieren. Es gibt leider relativ viele Autos, die eine Wallbox ablehnen, wenn sie nicht direkt nach dem Anstecken Strom bekommen. Dann „schlafen sie ein“ und fangen nicht an zu laden, wenn sie später noch Strom bekommen. Um das Problem zu umgehen, bekommt ein Auto direkt nach dem Anstecken immer für ca. drei Minuten mindestens den Minimalstrom (üblicherweise 6 A), auch im PV-Modus. Das behebt bei den meisten Autos das Problem mit dem „Einschlafen“. Wenn nach den drei Minuten nicht genug PV-Überschuss da ist, wird die Ladung wieder beendet. In deinem Fall ist es aber so, dass das Auto ja fast keinen Strom zieht. Die Wallbox sieht also am Netzanschluss Überschuss und lässt das Auto weiter laden. Ca. um 09:25:30 wurde ein anderer Verbraucher eingeschaltet, sodass um 09:27:34 die Ladung beendet wurde. Die zwei Minuten Wartezeit entsprechen genau der Wolkenfiltereinstellung, die du anscheinend auf „schwach“ geändert hast. Wir arbeiten gerade daran, die Gründe für eine laufende oder beendete Ladung besser im Webinterface darzustellen. Aktuell ist das für den Nutzer ohne Hintergrundwissen nicht ersichtlich. Für mich sieht es jedenfalls so aus, als würden WEM und Wallbox korrekt funktionieren und sich wie erwartet verhalten. Hast du dich schon mal über das kaputte VW-Update vom letzten Jahr informiert, nach dem manuell das BMS durch Ziehen einer Sicherung neugestartet werden muss? Vielleicht hat der e-up das erst jetzt bekommen, nach dem die ID.3s und ID.4s letztes Jahr schon dran waren.

Die drei Phasenspannungen fehlen. Du brauchst L1N, L2N und L3N.

Nein, eigentlich nicht. Die Regelung ist lediglich im dreiphasigen Modus um 1/3 schlechter, was aber nur dazu führt, dass es 1/3 länger dauert, bis nach einer Last- oder PV-Änderung der Netzanschluss wieder ausgeglichen ist.

Mir ist aktuell nichts Entsprechendes bekannt. Bei VW gab es letztes Jahr für verschiedene Modelle fehlerhafte Software-Updates, die allerdings üblicherweise dazu geführt haben, dass statt dreiphasig nur zwei- oder einphasig geladen wurde.

Bitte von der linken Wallbox einen Debug-Report runterladen wenn ein Auto angeschlossen ist und laden soll, das aber nicht macht. Meinst du damit den Fronttaster der Wallbox oder die Start/Stop-Buttons der Web-Oberfläche? Den Fronttaster konnte man bei der Warp1 noch nie umkonfigurieren aber die Warp2 kann das. Der „Autostart“ für die Start/Stop-Buttons wurde „umgedreht“ und heißt jetzt „Manuelle Ladefreigabe“.