rtrbt

Kurzes Update: Das Problem sollte in Firmware 1.0.2 entgültig behoben sein. Hatte noch eine zweite Stelle mit dem selben Bug übersehen.

:D Die Idee hatte ich auch, aber dann würden im Log nicht die ganzen Verbindungsversuche aufschlagen. Ich wühle mich gleich nochmal durch die MQTT-Bibliothek, in der Hoffnung herauszufinden, wo es bei dir hakt. Schonmal als Teaser: Jedes "Connecting to MQTT broker" sollte danach einen Fehler und/oder ein "Disconnected" mit Fehlercode erzeugen (das sind in der Firmware Callbacks aus der MQTT-Bibliothek). Da das nicht passiert, muss irgendetwas in der Bibliothek verquer sein. Auffällig ist, dass die Box relativ lange braucht, um einen IP zu beziehen: 5407 Ethernet connected 8376 Had to configure softAP ip 1 times. 10377 Soft AP started. 10377 SSID: warp2-WFk 10377 hostname: warp2-WFk 10730 IP: 10.0.0.1 10849 Connecting to MQTT broker 12568 Ethernet MAC: A8:03:2A:31:66:2F, IPv4: 192.168.12.24, Full Duplex, 100 Mbps 12569 Ethernet got IP address: 192.168.12.24. 12580 Network connected. Stopping soft AP 70861 Connecting to MQTT broker Das dauert so lange, dass der erste Verbindungsversuch passiert, wenn die LAN-Verbindung noch nicht besteht. Eventuell kommt da das Routing durcheinander und versucht über den Soft-AP zu gehen, obwohl der ja gestoppt ist. Ich melde mich nochmal, wenn ich mehr weiß.

Moin Patrick, Teste mal bitte die angehangenen Firmware, mit der du mehr Ausgaben in das Ereignis-Log bekommen solltest. Damit sollten wir rausfinden können, woran es hängt. Grüße, Erik Edit: Die Wallbox 1-phasig betreiben ist kein Problem. warp2_firmware_1_0_1_615d6394_merged.bin

Moin Henning, Das Problem scheint nichts mit den Sonderzeichen zutun zu haben, sondern nur mit kaputter Fehlerbehandlung beim Abschalten des APs, wenn die WLAN-Verbindung hergestellt wurde. Teste mal bitte die angehangene Firmware, da sollte der Bug behoben sein. Grüße, Erik warp2_firmware_1_0_1_615c5b77_merged.bin

Moin Christoph, Hast du die Wallbox bei der Installation der Zuleitung und dem Anschluss des LAN-Kabels jeweils ohne die Frontplatte betrieben? Das wäre die beste Erklärung warum die Konfiguration verloren gegangen ist. Zur Erklärung: Bei WARP 1 war es so, dass einer der Buttons auf dem ESP selbst einen Factory Reset (lies: ein Formatieren der Konfigurationspartition) auslöst. Das klappt bei WARP 2 so nicht, weil auf dem selben Signal wie der Button der Ethernet-Takt liegt. Deshalb hatte ich als Alternative dazu eingebaut, dass wenn man die Wallbox bestromt und der Taster in der Frontplatte gedrückt ist, der Reset ausgeführt wird. Das führt jetzt dazu (ganz ehrlich: da habe ich einfach nicht dran gedacht), dass der Reset ausgelöst wird, wenn du die Wallbox ohne die Frontplatte betreibst. Für die nächste Firmware-Version setzen wir den Factory Reset anders um, voraussichtlich muss man dann den ESP aus der (unbestromten!) Wallbox ausbauen, an einen PC anschließen und den Reset per Brick Viewer machen. Ist komplizierter, aber im Normallfall sollte der Reset ja unnötig sein. Danke für's melden! Erik

Moin Alex, Warp 2 unterstützt nur den SDM630. Das Lastmanagement funktioniert aber ohne Zähler, da es nur Maximalströme vorgibt, ob das Fahrzeug diesen Strom dann auch zieht ist ein anderes Problem. D.h. wenn du anderweitig den Shelly 3EM in deine Unterverteilung baust und in dein WLAN bekommst, müsste das funktionieren. Stand jetzt nicht. Ich hatte mir das Thema OCPP vor ein paar Monaten angesehen, habe es aber aufgrund der Komplexität erstmal hinten angestellt. OCPP-Unterstützung (dann voraussichtlich OCPP 1.6 JSON) wird irgendwann kommen, ich kann dir aber nicht versprechen wann. (Nur dass es dieses Jahr nichts mehr wird, das Jahr ist ja nicht mehr lang, die TODO-Liste aber schon ;) ) Aufgrund dessen wie OCPP funktioniert, sind die Wallboxen dann aber nur "Clients", werden also von einem OCPP-Server gesteuert, den du dann auch bräuchtest. Das ist aber bei den cfos-Boxen genauso soweit ich das spontan gelesen habe.

Korrekt. Das wird voraussichtlich die 1.3.0, aber ja darin sind sowohl die aktuelle Ladecontroller-Firmware, als auch der neue Web-Server und das Lastmanagement.

Moin Henning, Das ist auf jeden Fall ein Bug. Spontan wäre meine einzige Idee, dass das Konfigurieren des Access Points nicht klappt, aber aus irgendeinem Grund der AP trotzdem geöffnet wird. Lade von der Wallbox bitte den Debug-Report und das Ereignis-Log runter (beide unter System->Ereignis-Log) und hänge sie hier an, eventuell findet sich da etwas. Grüße, Erik

Moin Patrick, Mir ist absolut unklar, warum deine Box in den Zustand gekommen ist. Zur Erklärung: Username und Passwort, sowie ein Flag ob der Login aktiviert ist, werden im Flash der Wallbox gespeichert. Das Firmware-Update ändert an diesen Daten nichts. Selbst wenn jetzt z.B. das Speichern der Datei schiefgegangen ist, würde die Wallbox die Standardeinstellungen laden, bei denen der Login natürlich aus ist. Damit du erstmal wieder auf die Wallbox zugreifen kannst, müsstest du die Einstellungen zurücksetzen. Das ist wie man WARP 2 zurücksetzt, bei WARP 1 musst du die Frontplatte abnehmen und den IO0-Button 10 Sekunden gedrückt halten. Siehe hier: https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf (Seite 10)

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:

Mit genau dem Commit, ja. Jetzt verstehe ich aber die Verwirrung: getDeviceInfo() ruft tf_hal_get_device_info auf, das erzeugt aber keine Kommunikation, sondern fragt nur die Informationen ab, die der HAL ganz am Anfang gesammelt hat. Was in tf_hal_create bzw. tf_hal_common_prepare (was von _create aufgerufen wird) passiert, ist dass der HAL an allen verfügbaren Ports abfragt, welche Devices angeschlossen sind. Mit tf_hal_get_device_info kannst du die abgefragten Daten dann auslesen. Wenn du permanent Kommunikation auf allen Ports erzeugen willst, kannst du entweder tf_hal_callback_tick verwenden, dann ist es aber nur unidirektional, weil die Bricklets vermutlich nichts antworten werden (es sei denn du hast eins der Bricklets mit nicht deaktivierbaren Callbacks die auslösen z.B. ein RGB LED Button den du immer mal drückst) oder du baust dir etwas in die Richtung: TF_Unknown unknown; for(int i = 0; i < port_count; ++i) { tf_unknown_create(&unknown, "1", hal, (uint8_t)i, 0); int rc = tf_unknown_get_identity(&unknown, nullptr, nullptr, nullptr, nullptr, nullptr, nullptr); tf_unknown_destroy(&unknown); } (ungefähr geklaut aus tf_hal_common_prepare) Das gute am Unknown Bricklet ist, dass es einen Konstruktor hat, bei dem du explizit den Port angeben kannst. UID "1" ist Broadcast. Nein die includes brauchst du nur, wenn du mit dem Bricklet kommunizieren willst, der HAL verwendet intern nur bricklet_unknown und includet das selbst. Mit PlatformIO: pio run -e esp32-poe -t upload -t monitor Das benutze ich sowieso für die Wallbox-Firmware (falls du spionieren willst: https://github.com/Tinkerforge/warp-charger/tree/master/software) Wenn das HAT bei dir aufschlägt, funktioniert die Kommunikation prinzipiell. Siehst du auf der seriellen Konsole dann auch folgendes? Found device XYZ of type 112 at port E