rtrbt

Hi, If you can still reach the web interface over WLAN when the LAN connection is interrupted, please download a debug report (System -> Event-Log -> Download debug report and event log) and post it here.

Ich habe dafür ein Issue aufgemacht, das Problem kam ja schon ein paar Mal auf: https://github.com/Tinkerforge/esp32-firmware/issues/77 Frage dazu: Wäre dir geholfen, wenn zusätzlich ein leeres Objekt erlaubt ist? Oder ist das auch schwierig und man müsste eher z.B. false auf Top-Level erlauben?

Ich habe dafür ein Issue aufgemacht, das Problem kam ja schon ein paar Mal auf: https://github.com/Tinkerforge/esp32-firmware/issues/77 Frage dazu: Wäre dir geholfen, wenn zusätzlich ein leeres Objekt erlaubt ist? Oder ist das auch schwierig und man müsste eher z.B. false auf Top-Level erlauben?

Die Pinbelegung ist (von links nach rechts wenn du auf das EVSE siehst) nicht belegt rot (A+; RX+) grün (B-; RX-) schwarz Ground Das Kabel ist (ohne den Teil, der im JST-Stecker verschwindet) etwas über 19cm lang. Ich habe mal ein Bild gemacht:

Moin Thomas, Das sieht im ersten Moment in der Tat so aus, als wäre es ein SPIFFS-Problem, ist es aber vermutlich nicht. Die verwirrenden Meldungen kommen daher, dass wir in letzter Zeit von SPIFFS auf LittleFS umgestellt haben, weil das schneller und vorallem robuster ist. Damit dann bei einem Update von einer SPIFFS auf eine LittleFS-Firmware nicht die Konfiguration verloren geht, macht die (neue) Firmware einen Migrationsschritt, der unter anderem involviert, dass die zunächst geprüft wird, ob die Konfigurationspartition eine SPIFFS-Partition ist, und wenn ja, wird die Migration ausgeführt. Diese Prüfung führt aber noch dazu, dass Meldungen wie angezeigt werden. Das aufzuhübschen ist einer der nächsten Schritte, ich hatte dann als Schnellschuss erstmal die Meldung davor eingebaut: D.h. du kannst das ignorieren. Es hatte erstmal nicht die höchste Priorität, die verwirrenden Meldungen loszuwerden, da man sie ja nur auf der seriellen Konsole sieht. Diese Kombination aus Logmeldungen sagt dann übrigens, dass alles soweit okay ist, die Konfigurationspartition ist ein LittleFS und lies sich erfolgreich mounten. Zu deinem eigentlichen Problem: Da das Mounten klappt, steckt der Fehler wo anders. Am besten decodierst du den Backtrace, der ausgegeben wird, dann siehst du, in welchem Codestück der ESP sich aufhängt: Dazu brauchst du die zugehörige .elf-Datei zu der .bin-Datei, die du geflasht hast (die sollte im build-Verzeichnis liegen und die selbe Versionsnummer haben. Also zu warp2_firmware_1_3_0-61a119ca.bin z.B. die warp2_firmware_1_3_0-61a119ca.elf.). Das Dekodieren kannst du mit xtensa-esp32-elf-addr2line auf der Kommandozeile machen machen, das liegt im Platformio-Ordner (https://docs.platformio.org/en/latest/projectconf/section_platformio.html#directory-options) unter packages/toolchain-xtensa-esp32/bin/ xtensa-esp32-elf-addr2line -pfiaC -e /pfad/zur/warp2_firmware_1_3_0-61a119ca.elf 0x4008a8e1:0x3ffb1f900x40089c1a:0x3ffb1fa0 0x40089c09:0x3ffb1fc0 0x40137329:0x3ffb1fe0 0x401383ec:0x3ffb2000 0x40138be3:0x3ffb2040 0x400f2e00:0x3ffb2090 0x400e0f11:0x3ffb21e0 0x4010627e:0x3ffb2820 Sollte dir dann einen sinnvollen Backtrace ausgeben, mit Dateinamen und Zeilennummern. Den kannst du gerne hier posten, dann werfe ich auch mal einen Blick darauf, vorallem wenn das Problem nicht in deinem Code auftritt. Grüße, Erik

Ah, dass du mit MaxMSP direkt ohne Code und SDK TCP-Pakete schicken/empfangen kannst war mir nicht klar. Das ändert natürlich einiges. Ich bin da beim googlen falsch abgebogen und dachte, dass du mit dem SDK ein C-Modul schreibst. Wenn du das TFP-Protokoll händisch benutzen willst, musst du im Endeffekt nur die Bricklets dazu bringen, dass sie ihre Callbacks aktivieren, lies: dass sie von sich aus Daten zu dir senden. Das RGB LED Button Bricklet macht das automatisch, deshalb funktioniert das einfach so, bei den anderen müsstest die entsprechende Funktion aufrufen (was heißt, das entsprechende TCP-Paket schicken) Um an den Payload zu kommen, kannst du also entweder in der TCP/IP-Dokumentation die einzelnen Paketformate nachschlagen (z.B. hier für die Position des Motorized Linear Poti Bricklets) oder du schneidest den Traffic des Brick Viewers oder eines kleinen Testprogramms mit.

Du hast vollkommen recht, das ist in der Firmware kaputt. Das Problem ist, dass der Lastmanager auf der Wallbox nicht die API benutzt, sondern ein eigenes Protokoll mit den anderen Boxen spricht. Wenn du über die API managed_current aktualisierst, fehlt der Aufruf, der den Watchdog entschärft. Ich habe das im Quellcode gerade gefixt. https://github.com/Tinkerforge/esp32-firmware/commit/d2834cf2af5f8e3f20cff4da682db36afccb10e5 Es kommt diese Woche noch Firmware 1.3.1, der API-Fix wird enthalten sein, eventuell kommt dann auch der Fix für das eigentliche Problem mit dem Lastmanager, das kann ich dir aber noch nicht versprechen. Edit: Firmware 1.1.1, wir reden ja von WARP 2.

Das ist eine gute Erklärung, der Firefox cacht das in der Tat, bis er einmal komplett neustartet. Jain, die Loginseite fragt den Server nur, ob der komplette Satz Login-Daten korrekt ist, die Rückmeldung ist dann aber immer "falsches Passwort". Hm dass ein richtiges Passwort wieder die Anmeldeseite lädt ist interessant: Das heißt, dass Edge scheinbar für jede Unter-URL einen eigenen Cache hat und dann mit der neuen Realm die Login-Daten geprüft hat, aber für die Hauptseite wieder die alte verwendet.

Moin Christoph, Einem Neustart wovon? Prinzipiell musst du die Wallbox, auf der du den Lastmanager eingerichtet hast, einmal neustarten, wenn die Konfiguration verändert wird (also wenn du auf der Lastmanagement-Unterseite Änderungen vornimmst). Danach sollte es aber ohne Neustart funktionieren. Das ist ein sehr interessanter Punkt. Der Lastmanager nimmt nachdem ein Ladevorgang abgeschlossen ist die Ladeerlaubnis weg (indem eben der Strom auf 0A gesetzt wird), damit andere Ladevorgänge die gleichzeitig laufen könnten mehr Strom zur Verfügung haben. Die Box bleibt dann blockiert, bis das Auto einmal abgezogen wird. Der Grund dafür ist, dass die Kommunikation zwischen Wallbox und Auto sehr limitiert ist: Wenn das Lastmanagement gerade blockiert, kann nicht unterschieden werden, ob ein Auto gerade Strom möchte oder nicht. Das erklärt auch das Verhalten wenn du den Ziel-SoC änderst bzw. die Heizung verwendest. Ganz ehrlich: Das Problem, dass ein Auto sich dann einmal voll laden und dann über Wochen wieder leerstehen kann, bzw. die Sache mit der Heizung hatte ich nicht auf dem Schirm. Wir werden aber eine Lösung dafür bauen. Der erste Schnellschuss wäre, dass wenn Strom nach der üblichen Verteilung übrig ist, dieser dann auf Wallboxen verteilt wird, deren Autos bereits einmal geladen haben. Eventuell dafür dann nur der Minimalstrom von 6 A, um praktisch zu testen ob das Auto wieder Strom möchte. Das muss ich aber nochmal in Ruhe überdenken, Änderungen auf dem Niveau sind immer gefährlich. Ich habe mal ein Issue dafür aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/73 Da musst du aufpassen: Das ist der Watchdog für eine externe Steuerung. Die Dokumentation dazu ist leider noch etwas dünn (Siehe auch: https://github.com/Tinkerforge/esp32-firmware/issues/58) Die Kurzzusammenfassung ist: Wenn du von extern dem Lastmanager vorgegen willst, wie viel Strom er gerade verteilen darf, z.B. weil du eine PV-Anlage hast, dann kannst du das über die API machen und den Watchdog aktivieren, der dann, falls deine externe Steuerung ausfällt, den Ladestrom zurück auf den Default-Wert setzt. Es gibt noch einen zweiten Watchdog, der immer auf 0A setzen sollte, der ist dafür da, dass wenn der Lastmanager selbst ausfällt, einzelne Boxen nicht durchdrehen können. (Das betrifft die Lastmanagement-Ladestromgrenze die du unter Ladecontroller sehen kannst). Das sollte so funktionieren. Die einzige Erklärung die ich hätte ist, dass du eventuell deinen eigenen Lastmanager und den eingebauten gleichzeitig aktiv hast? Ansonsten gehe ich dem mal nach. Das ist genau der, den du benutzt. Wenn du ein GET auf "managed_current" (ohne _update) machst, kannst du den Strom den du gesetzt hast wieder auslesen. Wenn du ihn setzen willst musst du aber die Variante mit _update benutzen (und ein PUT machen), das ist damit die API einheitlich zur MQTT-API ist, bei der man sonst nicht unterscheiden kann welche Updates von der Box selbst kamen.

Die erste Frage dazu: Hast du die TCP-Verbindung selbst aufgebaut und versuchst das TFP-Protokoll händisch zu sprechen? Höchstwahrscheinlich ist es einfacher, wenn du nicht direkt per TCP/IP mit dem Stapel bzw. mit dem Brick Daemon redest, sondern eins unserer Bindings dafür verwendest. Ich habe kurz danach gesucht, es gibt ein SDK mit dem man eigene C-Erweiterungen schreiben kann: https://cycling74.com/sdk/max-sdk-8.2.0/ (Bitte korrigiere mich falls ich da falsch abgebogen bin, MaxMSP sagte mir soweit nichts.) Am einfachsten ist es deshalb vermutlich, wenn du mit dem SDK ein Plugin für MaxMSP schreibst, dass unsere C-Bindings benutzt. Sieh dir am besten mal die Beispiele für den RGB-LED-Button an, um ein Gefühl dafür zu bekommen. Du musst nichts auf den Master Brick oder die Bricklets hochladen, das ist kein Arduino, bei dem du eine eigene Firmware schreiben musst. Prinzipiell kannst du das zwar machen, aber das ist ein sehr esoterischer Anwendungsfall. Das geht prinzipiell auch, du gewinnst aber nichts gegenüber den C-Bindings.

Okay, ich kann das Problem hier nachstellen: Das Update von 1.2.4 auf 1.3.0 wechselt ja unter anderem den ganzen Webserver aus. Der neue Webserver hatte keinen Support für die Login-Variante die wir benutzen, deshalb hatte ich das nachimplementiert. Dabei habe ich aber die Realm von asyncesp auf esp32-lib geändert. Firefox versteht jetzt nicht, dass er sich auf die neue Realm einloggen muss. Interessanterweise hat Firefox die neue Realm bei mir aber akzeptiert, als ich ihn neugestartet habe. Wenn du über Edge noch das Webinterface erreichst, kannst du den Login deaktivieren, neustarten, dann einmal mit Firefox draufgehen (damit er vergisst, dass man sich einloggen muss), dann Firefox neustarten und den Login wieder aktivieren. Ich würde erwarten, dass das dann wieder funktioniert. Unabhängig davon kommt in Version 1.3.1 ein Fix dafür: Der Webserver akzeptiert dann einfach sowohl die alte, als auch die neue realm. Danke für's melden!

Hilft es den Firefox neuzustarten? Ich teste hier mal das selbe, vielleicht kann ichs reproduzieren. Hast du danach neugestartet? Das ist eine Konfigurationsänderung ;)

Das sollte natürlich nicht passieren. Mit welchem Browser (und welcher Version) hast du das getestet? Von welcher Firmware-Version bist du auf die 1.3.0 gegangen? Ich würde das gerne hier reproduzieren, damit ich einen eventuellen Bug fixen kann. Notfalls retten kannst du das ohne Reset, indem du per MQTT den Login deaktivierst: https://www.warp-charger.com/api.html#reference-authentication

Prinzipiell kannst du das NFC-Bricklet extern verbauen, musst dann aber selber eine Kabeldurchführung in das Wallbox-Gehäuse bohren. Die maximale Kabellänge sind 2 Meter, du kannst aber ein Isolator-Bricklet dazwischenhängen, das frischt u.A. das Signal wieder auf, dann kommst du auf 4 Meter. Wichtig: Isolator-Bricklets kannst du nicht hintereinander schalten, d.h. mehr als 4 Meter werden es nicht. Außerdem funktioniert der Isolator-Hack nicht mit der aktuellen Wallbox-Firmware, weil der Code noch einen Bug hat, den ich gerade gefixt habe. Du müsstest dann auf das nächste Firmware-Release warten, bevor du das Bricklet einbaust.

Moin, Das Hauptproblem ist tatsächlich, dass nicht 100%ig stimmt. Ich bin mal die noch offenen Punkte durchgegangen, folgendes wäre noch zutun: Features Allgemein Deutsche Dokumentation Advanced-Mode: Device führt dann keine Channels mehr raus, aber den kompletten Satz Java-API als Actions. Konfiguration per Textdatei Reset als Action rausführen Device-Spezifisch Thermal-Imaging: Neue Config-Parameter LED Strip: ColorCommands akzeptieren, den Rest per Rule Ambient Light v2/v3: Auto-Modus der Sättigung/Integrationszeit einstellt Neu hinzugefügte API einfügen, z.B. Barometer I²C-Mode Device-Gruppen-Spezifisch Motorbricks wie DC-Brick bauen Default-Werte des Update-Intervals kleiner machen wenn value_has_to_change verwendet wird, 1000ms sind gerade für IO-16 recht lang Things mit Error-LEDs: Trigger-Channel hinzufügen, der nur im Show-Error-Modus der LED erzeugt wird, der Channel resettet die LED, indem setErrorLEDConfiguration(ShowErrors) nochmal aufgerufen wird. Switch->Contact beim IO4/16 usw. Problem: Braucht Generatoränderungen Dokumentation Allgemeines Tutorial: Installation, Konfiguration von: Outdoor Weather Station, Remote Switch, LCD 128x64, irgendein normales Bricklet. Damit zeigen wie die "speziellen" Bricklets funktionieren, wie man sinnvoll Rules schreibt usw. Outdoor Weather Station: relative rain fall example (https://www.tinkerunity.org/topic/5092-outdoor-wetter-station/?tab=comments#comment-28855) in der API-Doku explizit erklären wie man einen Brick Daemon hinzufügt nach "You can then connect the bindings by adding a Brick Daemon thing in openHAB's Paper UI." Bugfixes Prüfen ob alle Callbacks deaktiviert werden https://github.com/openhab/openhab-core/issues/1265 (Actions sind nach Binding-Neustart kaputt) https://github.com/openhab/openhab-core/issues/1233 (Uneindeutige Actions, wird von openhab-core nicht gefixt, heißt die Bricklet-Prefixe sind für die Ewigkeit) dispose-Code dauert ewig/timeouts wenn Device ab ist Display Bricklets zeigen auf der Übersichtsseite, solange noch kein Text gesendet wurde, '-' als Text an, wenn darauf geklickt wird NULL. Read-Only Flags in den Channel-Typen setzen. Auto-Deduce? Zip so bauen dass das zip-diff script funktioniert, also nicht nur unterorder einpacken Reachabilitycheck doch single-threaden? Im Moment funktionierts, aber wenn jemand >= 5 Brick Daemons benutzt kann es doch passieren, dass die Threads lahmgelegt werden. Alternativ: Nicht blocken auf "sind die futures alle fertig" sondern pollen und yielden. Dann kann der Thread selbst die Tasks abarbeiten. Außerdem die "Burstigkeit" des ganzen verringern. Dinge die durchgestrichen sind, würde ich jetzt droppen, damit man zu einem sinnvollen Abschluss kommt und das nicht noch Monatelang Vollzeitentwicklung ist. Dinge die kursiv sind, kommen vielleicht, das hängt konkret davon ab, wie viel Arbeit ich reinstecken muss/kann/will. Ich werde dann jetzt voraussichtlich immer ~ einen Tag die Woche in die Bindings stecken, da die Liste so zusammengestrichen ist, sollte das dann nicht Monate dauern, bis eine "fertige" Version dabei rausfällt.

Sprechende Namen sind schwierig ;) https://github.com/Tinkerforge/esp32-firmware/issues/52

Kurzes Update: https://github.com/Tinkerforge/esp32-firmware/issues

Damit ich das kurz eingeworfen habe: Wir haben letzte Woche die Struktur der Firmware vereinfacht. Du findest den aktuellen Kram jetzt nicht mehr im warp-charger-Git sondern hier: https://github.com/Tinkerforge/esp32-firmware Das ist in Endeffekt der Inhalt der esp32-lib, und der software-Verzeichnisse von esp32-brick und warp-charger zusammengelegt. Im Idealfall kannst du deine Änderungen darauf übernehmen und alles funktioniert wie bisher weiter, nur mit weniger Verrenkungen, weil nicht mehr der Zustand von 3 Git-Repos auseinanderlaufen kann.

So oder so ähnlich habe ich es auf die TODO-Liste gegossen ;) https://github.com/Tinkerforge/esp32-firmware/issues/36

Moin Matthias, Zu Frage 1 und 2: Wenn du die Firmware nicht aktualisieren willst, kannst du dir den ganzen DeviceModule-Kram sparen. Das hatte ich so generalisiert, damit die doch recht vielen Firmwares alle gleich eingebettet werden und Devices gleich behandelt werden (EVSE, EVSE 2.0, RS485 und NFC). Du musst dann nur händisch das Device initialisieren, so wie das DeviceModule::setup_device() tut, nur ohne den ensure_matching_firmware-Teil. Also UID raussuchen mit find_uid_by_did, dann die create-Funktion, z.B. tf_industrial_quad_relay_v2_create aufrufen. Der Großteil der anderen Logik ist nur dafür da, die Firmware zu flashen und eventuell darauf zu reagieren, dass die Firmware gerade geflasht wird (deshalb der loop-Check ob das Device im Bootloader-Modus ist). Mach das am besten über api.callCommand, ja. Du kannst händisch auf dem EVSE arbeiten, das kannst du dir z.B. im NFC-Modul ansehen, aber über die API ist es robuster, für den Fall dass gerade auch andere Teile der Software mit dem EVSE interagieren. Grüße, Erik

seen_tags sollte immer nach last_seen sortiert sein. D.h. wenn du nur das zuletzt erkannte Tag willst, kannst du einfach immer den ersten Eintrag lesen. Dann würde im Webinterface die Anzeige, wann Tags zu letzt gesehen wurden nicht mehr funktionieren. Kannst du in HA darauf reagieren, wenn last_seen kleiner als der Wert aus der letzten Nachricht wird? Falls nicht behalte ich das für die künftige Erweiterung der NFC-API mal im Hinterkopf.

Die vage Roadmap ist im Endeffekt meine TODO-Liste. Auf der steht (jetzt ganz oben, eventuell komme ich da heute/Montag dazu ;) ), die in Github-Issues zu übersetzen, damit ihr da etwas Einblick habt.

Moin Jochen, Wir haben ein Hutschienengehäuse im Angebot, bei dem auch eine Seitenwand für Raspi + HAT dabei ist: https://www.tinkerforge.com/de/shop/rail-mounting-case.html Grüße, Erik

Moin, Die Zeit wird mit dem Takt des Prozessors des Ladecontrollers gemessen, da läuft keine RTC, keine Netzwerkzeitsynchronisierung oder ähnliches. Der Anwendungsfall ist bisher nur Zeitintervalle im Bereich Minuten bis zu ein paar Stunden zu messen (lies: z.B. die Dauer eines Ladevorgangs). Deshalb können wir die 0,4% Drift verschmerzen. Falls du das länger beobachtest: Lass dich nicht davon verwirren, dass der Zähler nach ~ 50 Tagen auf 0 zurückspringt. Der ist nur 32 Bit breit ;) Wenn wir später Features wie z.B. verschiedene Ladeströme zu verschiedenen Tageszeiten nachlegen, brauchen wir dann natürlich eine bessere Zeitmessung und absolute Zeiten. Voraussichtlich werden wir dann NTP implementieren. Edit: Ich habe einen entsprechenden Hinweis in die Dokumentation gepackt.

Der Energy Manager wird auch "nur" die normale API nutzen, bzw. die API wird für den Energy Manager erweitert.