rtrbt

Das ist interessant, weil es bedeutet, dass sowohl Ladecontroller, als auch der ESP, der das Webinterface hostet, noch liefen. Vermutlich war die Kommunikation zwischen beiden gestört. Ich versuche weiterhin mal das hier zu reproduzieren, bin aber wie gesagt die nächsten zwei Wochen im Urlaub, dauert also etwas.

Moin, Das sieht nach dem klassischen VW-Ladeproblem aus: Wenn das Auto von "Ich bin hier" auf "Ich will laden" umschaltet, springt der Widerstandsmesswert kurz extrem hoch, was die Wallbox als "Das Auto ist nicht mehr angeschlossen" interpretiert. Wir haben in der Firmware 1.2.3 dafür den ID.3-Modus eingebaut, der auf die Änderung träger reagiert. Welche Firmware hast du laufen? Falls es nicht 1.2.4 ist, teste mit der aktuellen nochmal (Findest du hier). Wenn das Problem dann immer noch auftritt, erstell bitte nochmal ein Ladelog. Du musst die Konfigurationen übrigens nicht rauslöschen: Passwörter können über das Webinterface nicht ausgelesen werden, d.h. du leakst höchstens deinen WLAN-Namen und den Hostnamen der Box (die kannst du natürlich gerne löschen, aber alles, was mit evse/ anfängt könnte hilfreich zum Debuggen sein ;) ) Grüße, Erik

Kurze Bestandsaufnahme: Damit meinst du, dass die Wallbox auf der das Lastmanagement läuft, die zweite Wallbox nicht mehr erreichen konnte. An welcher von beiden hattest du das Auto angeschlossen? (Das Lastmanagement schaltet sicherheitshalber alle Boxen ab, wenn eine nicht erreicht werden kann) Warst du auch auf dem Webinterface der anderen Box? War da etwas suspekt, hast du eventuell Ereignis-Logs? Das heißt, dass der Ladecontroller selbst noch lebt und nur der ESP32 auf dem das Webinterface läuft Probleme macht (oder die Kommunikation zwischen den beiden oder zwischen den Wallboxen) Dann können wir schonmal Netzwerkprobleme ausschließen (es sei denn die Wallbox selbst hat nicht bemerkt dass sie nicht mehr im WLAN ist o.Ä.) Mir ist unklar, was du damit meinst. Hast du es mehr als einmal geschafft, dass das Lastmanagement blockiert und es ist egal welche Box du neustartest, damit es wieder funktioniert? Hoffentlich nicht ;) Ich halte ein reines Speicherleck für unwahrscheinlich, da würde es bei dir nicht > einen Monat problemlos laufen, soviel RAM hat der ESP nicht. Falls du das Problem nochmal erzeugen kannst würde mich folgendes interessieren: Kannst du das Webinterface beider Wallboxen noch erreichen? Falls ja: Ein Ereignis-Log und einen Debug-Report beider Wallboxen (im Debug-Report ist u.A. auch der aktuelle Zustand des Lastmanagers) Wie lange bleibt der Zustand so? Reicht es eine Box neuzustarten damit es wieder funktioniert? Wir haben hier einen Lastmanagement-Verbund aus vier Wallboxen, der lief aber meines Wissens noch nie länger als zwei bis drei Wochen, weil man immer irgendwelche Dinge testet. Ich bin aber nächste und übernächste Woche im Urlaub und habe meinem Kollegen mal bescheid gesagt, dass er aufpassen soll, dass niemand die Boxen neustartet. Ich habe mir die aktuelle RAM-Auslastung der vier Boxen notiert, für den Fall, dass es wirklich ein Speicherleck ist. Eventuell wissen wir dann Anfang Oktober mehr.

Moin Thomas, Teste bitte mal die Lastmanagement-Beta. Ich habe ein paar Fälle gehabt, bei denen sich der (alte) Webserver und der MQTT-Client auf den Füßen standen. MIt dem neuen Webserver sind die Probleme dann verschwunden. Achtung: Falls du den Login des Webinterfaces aktiviert hast, musst du u.U. deinen Browser nach dem Update neu starten, die Beta unterstützt den Loginprozess nicht.

Die Getter zu benutzen ist die einfachste Variante, du könntest aber alternativ auch die Callback-Frequenz runterdrehen auf etwas, dass du auf dem ESP verarbeiten kannst. Das hätte den Vorteil, dass weniger Traffic erzeugt wird. (Der Unterschied ist aber im Vergleich zu Stacks über USB nicht so stark). Da die Temperatur typischerweise eher träge ist solltest du mit z.B. 50 ms Callback-Interval noch gut hinkommen.

Aus Sicht der Wallbox sind Schlüsselschalter, Taster und dein Relais alle identisch. Da der Taster einen Ladeabbruch auslöst, beginnt die Wallbox nicht wieder mit dem Laden, bis du das Auto abgezogen und wieder angesteckt hast. Das Auto ist nachdem du den Taster loslässt ja noch angeschlossen. Die Wallbox ignoriert dann Auto-Start bis auf irgendeine Weise (dazu gleich mehr) eine Ladung beginnt oder du das Auto abziehst und wieder ansteckst. Du kannst das auch im Webinterface beobachten: Auf der Ladecontroller-Unterseite springt die Ladefreigabe von "Automatisch" auf "Manuell", wenn du den Taster drückst und loslässt. Anstatt dass du das Auto abziehst, kannst du auch über das Webinterface eine Ladung starten: Sobald die Ladefreigabe auf manuell steht und das Auto noch angeschlossen ist, solltest du auf der Status-Seite "Start" drücken können. Wenn du das automatisieren willst (z.b. über die selbe Steuerung die dein Relais schaltet?) kannst du die HTTP- oder MQTT-API verwenden und evse/start_charging aufrufen.

You are using the STM32F0-HAL? It looks like the HAL only initializes the SPI peripherals that are configured to be used. So if you only use SPI0_INSTANCE or SPI1_INSTANCE in your port configuration, the other one should be left unmodified.

Das Industrial PTC Bricklet ist neuer als die letzte Bindings-Beta. Wirf mal die beiden Dateien im Anhang in den bindings-Ordner. bricklet_industrial_ptc.c bricklet_industrial_ptc.h

So wird es funktionieren, ja. Die Tag-IDs bekommst du auch per MQTT, aber (noch) nicht die Kopplung welches Tag gerade jetzt den Ladestart ausgelöst hat. Das geht auch, es wird (voraussichtlich ;) ) die API nfc/seen_tags geben, wo Tag-Typ, -ID und die Zeit wann es zuletzt erkannt wurde, enthalten sind.

Moin Stefan, Das ist kein Problem, wundert mich warum ich das nicht schon gemacht hatte. Ich setze es mal auf die TODO-Liste. Habe gerade keine funktionsfähige Umgebung um das Binding zu bauen, sonst hätte ich das gleich gemacht.

Bindings: Rust 2.0.19 Fix compilation issues caused by yanked dependency Add set/get_display_driver functions and DISPLAY_DRIVER constants to E-Paper 296x128 Bricklet API Add simple_get_tag_id function and NFC_BRICKLET_MODE_SIMPLE constant to NFC Bricklet API Download: Rust

Bindings: Rust 2.0.19 Kompilierfehler durch zurückgezogene Abhängigkeit behoben set/get_display_driver-Funktionen und DISPLAY_DRIVER-Konstante zu E-Paper 296x128 Bricklet API hinzugefügt simple_get_tag_id-Funktion und NFC_BRICKLET_MODE_SIMPLE-Konstante zu NFC Bricklet API hinzugefügt. Download: Rust

Moin Niels, Mit etwas Bastelei sollte das gehen. Habe spontan das hier gefunden: https://community.home-assistant.io/t/multi-sensor-using-same-mqtt-topic/172552/3 Der Teil mit dem "data demultiplexer" sieht nützlich aus. In diesem Fall wäre es sinnvoller, aber so funktionieren die Bindings nicht. Die Bindings mappen 1:1 auf die Python-API und in der sind die Sensor-IDs ein Rückgabewert. Das ist immer das Problem bei "generischen" MQTT-Bindings, wenn es ein reines HA-Binding wäre, sähe das anders aus. Hast du die Bindings auf dem Pi als Debian-Paket installiert? Falls ja kannst du deine cmdline-Datei nach /etc/tinkerforge_mqtt.cmdline packen bzw. mit der Datei zusammenlegen. Falls du die Bindings von Hand heruntergeladen hast kannst du die .service-Datei aus dem Zip bearbeiten und --cmdline-file daemon-cmd-args einfügen.

Hm kaputte Jumperkabel hatte ich bei der Binding-Entwicklung auch. (Mein Aufbau sah übrigens sehr ähnlich aus ;) ) Wegen der Robustheit solltest du die Ports, die du nicht benutzt wieder in die Konfiguration aufnehmen, zumindest wenn du Bricklets angeschlossen hast: Das HAT hat Trennerchips, die sicherstellen, dass SPI nur an das selektierte Bricklet geht. Wenn du dann die Enable-Leitung der Chips floating lässt (das ist einfach das Chip-Select-Signal) könnten sich komische Effekte ergeben.

Außer dem Zähler brauchst du noch die entsprechenden Kabel. Statt dem Klemmenblock in der Smart kann dann der Zähler eingebaut werden. Wir planen in nächster Zeit die ganzen internen Kabel usw. als Ersatzteile zu verkaufen. Siehe hier: