MatzeTF

Okay, über WLAN kann ich das Problem bei uns auch reproduzieren. Dass das Zählermodul der Multicastgruppe beitritt, bevor die WLAN-Verbindung steht, ist prinzipiell kein Problem. Im funktionierenden Fall werden die entsprechenden IGMP-Pakete sofort nach Aufbau der Verbindung rausgesendet, auch wenn der entsprechende Aufruf im Zählermodul schon ein paar Sekunden her ist, da sich irgendwas unten drunter anscheinend merkt, welchen Multicastgruppen man beitreten möchte. Das seltsame ist, dass wenn esp_wifi_set_bandwidth nach dem Multicast-Join ausgeführt wird, anscheinend alle Multicast-Mitgliedschaften vergessen werden und nach anschließendem WLAN-Verbindungsaufbau keine IGMP-Pakete rausgeschickt werden. Der aktuelle Master-Stand lässt sich reparieren, indem entweder der Aufruf von esp_wifi_set_bandwidth wieder in die setup-Funktion verschoben wird, wodurch er vor dem Multicast-Join ausgeführt wird, oder der Aufruf bleibt wo er ist und der Multicast-Join wird per Task Scheduler so lange verzögert, dass er wieder hinter dem esp_wifi_set_bandwidth-Aufruf ausgeführt wird. Da ich keine Lust habe, in dem Closed Source WiFi-Blob rumzustochern, werde ich den esp_wifi_set_bandwidth-Aufruf wieder in die setup-Funktion schieben und mit einem entsprechenden Kommentar versehen, damit ihn nicht nochmal jemand verschiebt. Die 58 Byte langen Pakete, die immer durchkommen, sind übrigens Broadcasts vom SHM. Als Broadcasts kommen sie auch ohne Multicast-Join an und aus irgendeinem Grund empfängt der Multicast-Port auch die Broadcasts. Das war schon immer so, ist nur niemandem aufgefallen.

Bitte einen Debug-Report runterladen (unter System → Ereignis-Log) und hier anhängen, wenn du die Freigabe per MQTT erteilt hast und das Auto eigentlich angefangen haben sollte zu laden, das aber nicht tut.

Das Minimum ist da immer 1380 W, da das auch für phasenumschaltbare Wallboxen im Lastmanagement greift.

HT20 hat einen besseren Störabstand als HT40. Heißt, bei gleicher Entfernung zum AP ist die Signalqualität besser. HT40 hat außerdem den Nachteil, dass es doppelt so viel Überlappung mit anderen WLANs in der Umgebung hat und somit die Wahrscheinlichkeit für eine Kollision höher ist. Bei viel Traffic in der Umgebung müssen also deutlich häufig Pakete neu gesendet werden. Dem gegenüber steht als einziger Vorteil, dass die Übertragungsrate theoretisch fast doppelt so hoch ist. Da der ESP nicht mal HT20 voll auslasten kann, ist das in diesem Fall aber kein Vorteil. Somit hat HT40 bei der Wallbox nur Nachteile. Dementsprechend habe ich auf HT20 umgestellt, um die bessere Signalqualität nutzen zu können. Letzteres hilft all denen, deren Wallbox schlechten Empfang hat. Für mobile Geräte ist WLAN ok, aber Wallboxen sind üblicherweise nicht so mobil.

Erstens: Gute Wahl. Zweitens: Warum funktioniert es dann nicht richtig, wenn man HT20 auf dem ESP auswählt? Ich weiß, dass ich mich wiederhole, wenn ich erwähne, dass ich eine Abneigung gegen WLAN habe…

Wird ja immer seltsamer… Wenn du den Aufruf mit HT40 drin hast, was steht dann im Ereignis-Log, wenn das WLAN verbunden ist? HT40 oder immer noch HT20? Weißt du zufällig, was von beidem dein AP aktiviert hat?

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.