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?