Alle Aktivitäten

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.

Ist das eigentlich schon die Frühjahrsputz-Firmware @photron?

Ja, den zeitlichen Versatz hatte ich auch gesehen, ihm aber nicht allzu viel Bedeutung beigemessen. Gut zu wissen, dass ihr das mit dem Batterie laden auch auf dem Schirm habt. Falls ich also mit meinen begrenzen Fähigkeiten scheitern sollte, kann ich darauf ja noch zurückgreifen. Trotzdem bin ich jetzt erstmal neugierig, ob ich das mit HA und EVCC nicht doch irgendwie hinbekomme. Wirklich akut wird es wenn die Sonne wieder niedrigere Bahnen nimmt, so ab September etwa. Nochmal vielen Dank für Euren Support. Das ist nicht selbstverständlich👆

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.

Danke für's Testen! Das sieht alles gut aus. Interessant ist der zeitliche Versatz zwischen den beiden Zählern. Sieht nach 5 Sekunden aus. Das ist aber kein Problem. Denn Netzanschlusszähler vom SAX Power kannst du wieder löschen. Da wollte ich ja nur mal die Werte sehen. Du kannst auch bei dieser Firmware bleiben. Die Unterstützung für SAX Power wird dann auch in der nächsten offiziellen Firmware mit drin sein. Den Speicher vom Netz zu laden, wenn der Strom günstig ist kommt auch von unserer Seite bald als Teil der Batterie-Steuerung.

Hallo, ich würde gerne die Freigabe zum laden über MQTT an die WARP3 senden. Laut Anleitung geht dies über "Vortäuschen eines NFC-Tags" mittels: mosquitto_pub -h $BROKER -t $PREFIX/nfc/inject_tag -m '{ "tag_type": 0, "tag_id": "01:23:AB:3D" }' Ich bin mir sicher, die Richtige Tag ID sowie Tag Type ausgewählt zu haben. Allerdings tut sich an der WARP3 nichts. Hat jemand einen Tipp was ich tun kann? Viele Grüße Marco

Als nächsten Schritt möchte ich EVCC in Homeassistant so implementieren, dass ich bei Schlechtwetter den Sax Home Speicher mit preiswertem variablen Strom vom Octopus laden kann und die teuren Phasen überbrücke. Eine neue Herausforderung für mich aber wer hier sonst noch mitliest und weiß, wie das geht, mag mich gerne kontaktieren. Zum Glück sitze ich Dank Eurem Support nun nicht vor einem gänzlich weißem Blatt Papier.

16:40:29 neuen Zähler hinzugefügt bei Sax Home Speicher voll 16:44 1P Laden 16:48 3P Laden Für mich sehen die parallel verlaufenden Kurven stimmig aus. PV geht bei vollem Speicher komplett ins Auto. Hatte heute Vormittag auch schon beobachtet, dass Home Speicher vor Auto lädt, also Überschuss ins Auto. Ich bin zufrieden... und du?

TL;DR: Es tut jetzt! ✅ Was ich geändert habe: den Wert/Slot für die Bezugs-Wirkenergie nicht nur auf "seit Herstellung" zurückgeändert, sondern den Wert gelöscht und neu angelegt den Messort per API in `/meters/0/config` (an der GUI geht es nicht) auf "Wallbox" (location=2) geändert (bei `/evse/meter_config` stand in `slot` aber davor auch schon der korrekte Wert 0) Jetzt wird die Energie des aktiven Ladevorgangs korrekt erkannt und vom Limit abgezogen. Welche der beiden Änderungen für den Erfolg zuständig ist kann ich nicht einschätzen. Falls es nur Punkt 1. war, dann lag es wohl daran, dass der API-Zähler anfangs noch einen zu großen Wert (hatte vergessen, die Zahl, die ich an die API sende, durch 1000 zu teilen) erhalten hat. Nach Faktor 1000 Korrektur hätte ich wohl den Wert löschen und neu anlegen müssen. Falls das das Problem war, wäre es ggf. sinnvoll, eine Warnmeldung auszugeben, falls der erhaltene Wert kleiner als der gespeicherte Bezugswert ist. Unabhängig davon, ob Punkt 2. den Ausschlag gemacht haben könnte, fand ich es verwirrend, dass die Auswahl "Wallbox" als Messort an der GUI nicht möglich ist. Bei Wallboxen ohne eingebautem Zähler macht die Auswahl ja schon Sinn und sollte ermöglicht werden. Jetzt funktioniert so weit fast alles, was ich mir von der WARP1 wünschen könnte - Energielimit, Batteriesteuerung, Überlastschutz am Netzanschluss. Wenn da nur nicht das Problem mit dem falschen PV-Ladestart bei 4140W (statt 1380W) Überschuss wäre. Das könnte noch der einzige Grund sein, warum ich dann doch wieder auf EVCC umsteigen muss (Ziel ist eigentlich, die Anzahl der Softwarekomponenten klein zu halten). Viele Grüße Alex PS: Bei "Min + PV: Mindestladeleistung" kann ich auf 1380W gehen, d.h. hier scheint die Box richtig zu erkennen, dass sie nur 1-Phasig angeschlossen ist.

Ok, hab's nun mit den oben angegebenen Daten doch noch auf dem Victron Multiplus-II GX zum Laufen gebracht (ist zu Hause am PC auch leichter zu testen als remote per VPN übers Smartphone 😉). Man muss, bevor man per "Ausführen" die Einstellungen überhaupt testen kann, diese final speichern und die Box neustarten. Erst dann konnte ich per "Ausführen" einen Test machen und die Batterie ist zuverlässig der Ansage der Wallbox gefolgt. IMHO ist das für den Nutzer nicht zu erwarten, denn der "Ausführen" Knopf dient nach meinem Verständnis dem Zweck, die eingetragenen Registerwerte zu testen. Dass man dazu auf "Übernehmen", "Speichern" und "Neu starten" muss, damit man weiß, ob die Eingaben stimmen, war zumindest für mich nicht ersichtlich - zumal das Auslesen auf der Debug-Seite ja auch ohne Reboot geht. Hier nun die Einstellungen, die bei mir (über "Ausführen") funktionieren: Mit "Entladen verbieten" wird die Batterie auf "Charger only" gesetzt, bei "Verbot zurücknehmen" wieder auf "On" Viele Grüße Alex @andyknownasabu: Jetzt kannst Du auch 😜

Du fügst noch einen weiteren Zähler hinzu und konfigurierst den genau so wie den Zähler für den Batteriespeicher. Aber für den viruellen Zähler wählst du "Netzanschluss" anstelle von "Speicher". Ich würde gerne sehen, ob diese Messwerte auch passen.

Hi MatzeTF It works perfectly. Thank you very much. In my case, I use the: IndustrialDualRelay.set_monoflop(channel, value, time) as the very last command. Before this command, I call the HAT to power-off: HAT.set_sleep_mode(power_off_delay, power_off_duration, raspberry_pi_off, bricklets_off, enable_sleep_indicator) The set_monoflop is called with slightly longer delay (e.g. 1 second) than the set_sleep_mode. With this concatenation, I have a deterministic power-off of the entire system. Looking forward to see it working in the real-world. Cheers, Yvo

SPI war das richtige Stichwort. Das Aktivieren über raspi-config an sich hat nichts gebracht. War bereits aktiv. Das /dev/spidev0.0 war nicht aktiv, nur /dev/spidev10.0. Etwas rumprobieren, neustarts, evtl. das deinstallieren eines nicht mehr benutzten Touch-Displays, irgendwann war /dev/spidev0.0 aufgeführt, und brickv funktioniert - nachhaltig. 446 0 crw-rw---- 1 root spi 153, 1 13. Apr 19:15 spidev0.0 445 0 crw-rw---- 1 root spi 153, 0 13. Apr 19:15 spidev10.0 Herzlichen Dank für den Hinweis!

Ok, das sind definitiv alles valide Argumente, die vermutlich auf fast jedes IoT-Device zutreffen. UniFi hat übrigens einen extra „IoT-Modus“, in dem u. a. das entsprechende WLAN nur im 2.4 GHz-Band ausgestrahlt wird, vielleicht teste ich die diversen Settings auch mal…

Ich erinnere mich nicht mehr, warum ich das maximale Sendeintervall auf 10 hochgestellt habe, vermutlich habe ich damals am Zusammenspiel mit EVCC experimentiert. Da ich mehrere Warps im Einsatz habe, werde ich auf dieser Warp, dass Sendeintervall zurück auf 1 setzen und bei der anderen das Intervall auf 10 belassen. Beide Warps haben schon das Verhalten gezeigt. Ich verwende den mosquitto in der Version 1.5.7 Die Warp Charger sowie EVCC update ich nur wenn triftige Gründe vorliegen. Ich lebe das Motto, Never Chance a Running System. In den changelogs konnte ich nicht erkennen, dass sich am mqtt was geändert hat, was dieses Verhalten behebt. Ich werde jetzt trotzdem alle Warps auf die aktuelle Firmware hochziehen. Ich berichte weiter! Vielen Dank!

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.

Tja, wenn ich das wüsste… Ich bin auf jeden Fall gespannt, was eure Tests ergeben. Sollte sich das Problem nicht reproduzieren lassen, dann hätte ich auch kein Problem damit, den jetzigen Fix nur in meinem Fork vorzunehmen. Nur aus Neugier: Welches ursprüngliche Problem löst(e) das explizite Setzen auf HT20? Na ja, immer ein Kabel mit sich rumzutragen ist auch keine Lösung 😂

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…

Im Log steht immer noch HT20, mein UniFi AP hat im 2.4 GHz Band aber auch nur 20 MHz Kanäle aktiv. EDIT: Auf meinem „richtigen“ WARP-Charger erhalte ich beim Reboot übrigens die Fehlermeldung „Setting HT20 for AP failed: 258“…

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?

@photron hatte mir letztes Jahr zwar ein paar Infos dazu zukommen lassen, ganz trivial war das dann aber doch nicht. Letztendlich hat's jetzt aber funktioniert 🙂 0,011 | | **** TINKERFORGE WARP CHARGER V2.7.7+67FBD1BA **** 0,012 | | 332K RAM SYSTEM 296588 HEAP BYTES FREE 0,022 | | READY. 0,023 | | Last reset reason was: Software reset via esp_restart. 0,432 | fs | Mounted data partition. 81920 of 3538944 bytes (2.3 %) used 0,585 | api | WARP Charger config version: 2.6.6 (warp) 0,590 | esp32_brick | ESP32 Brick UID: SMH 0,931 | device_module | No EVSE Bricklet found. Disabling EVSE support. 0,979 | ntp | Set timezone to Europe/Berlin 1,101 | wifi | Starting scan to select unoccupied channel for soft AP 1,193 | firmware_update | Firmware is signed by: poohnet 1,196 | firmware_update | Partitions: app0 (valid, 2.7.7+67fbc33b), app1 (pending-verify, running, 2.7.7+67fbd1ba)

Klar, kein Problem. "WIFI_BW_HT40" funktioniert, d. h. der Funktionsaufruf an sich ist nicht das Problem. Schiebt man den Funktionsaufruf wieder in "Wifi::setup()", dann funktioniert's auch "WIFI_BW_HT20".

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.