rtrbt

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.

Gute Idee, werden wir im Zuge der Zuordnung von Ladevorgängen zu bestimmten Karten voraussichtlich mit einbauen.

Du musst, wenn du Einträge nicht verändern willst, diese explizit auf null setzen. Also z.B. {"require_tag_to_start": true, "require_tag_to_stop": null, "authorized_tags": null} Dafür wird es voraussichtlich einen konfigurierbaren Default-Wert geben. Der Hintergedanke war an der Stelle mal, dass egal was man an Konfiguration kaputt gespielt hat, nach einem Neustart der Wallbox geladen werden kann. Das ist aber seit dem es das managed-Flag gibt sowieso nicht mehr gegeben.

Die aktuelle LED-Logik ist ungefähr wie folgt: Normalerweise leuchtet die LED durchgängig, geht aber nach ein paar Minuten in den Stand-By -> aus Beim Laden atmet die LED Bei Fehlerzuständen blinkt die LED n-mal für Fehlercode n Flackern sollte nur beim Start des Ladecontrollers für ein paar Sekunden auftauchen, das heißt, dass der DC-Fehlerschutz kalibriert wird Die komplizierteren Muster (siehe Anleitung) sind alles NFC-Anzeigen Prinzipiell können wir die API der LED-Steuerung rausführen. Intern gibt es das schon für die NFC-Rückmeldungen. Das ist etwas kompliziert wegen der Priorisierung (z.B. Ladecontroller meldet Fehler, NFC hätte gerne das Muster für "Karte gesehen" und die API sagt "LED aus", wer gewinnt), aber ich setze es mal auf die TODO-Liste darüber nachzudenken.

Es wird dazu noch etwas offizielleres von uns geben, aber du kannst mal hier einen Blick werfen (Ende Seite 1, Anfang Seite 2):

Ich hatte das hier mal ausprobiert: Was ganz gut klappt ist, das Bricklet oben links (Sicht auf die offene Wallbox) bzw. rechts (Sicht auf den abgeschraubten Deckel) zu kleben, damit es bei einer Pro über dem Zähler ist. NFC funktioniert nicht durch die Frontplatte hindurch, die ist geerdet. Aber Tags, die du oben links auf die Box legst, werden relativ zuverlässig gefunden. Starkes doppelseitiges Klebeband. Für die Mitleser siehe hier: https://github.com/evcc-io/evcc/pull/1700

Im Anhang das Logo als Vektorgraphik und nur das W (das ist das Favicon in groß. Das skaliert sehr sauber hoch, weil nur rechte Winkel vorhanden sind) logo.pdf

Erstell bitte mal ein Ladelog wie folgt: (bei abgezogenem Auto) Auf dem Webinterface unter Ladecontroller auf Ladeprotokoll erstellen -> Start klicken, den Tab auflassen! Auto anstecken, warten bis du erwarten würdest, dass "grün blitzend" angezeigt wird Dann im Webinterface auf Stop + Download klicken Im Idealfall machst du noch ein zweites Log von einer normalen, also nicht zeitversetzten Ladung. Achtung: Die Logs werden recht schnell groß, also erstell keins von der ganzen Ladung, sondern wenn das Auto wirklich Strom ziehst kannst du das Log nach ein paar Sekunden beenden.

Die NFC-Konfiguration wird auf dem Flash der Wallbox gespeichert. Änderungen werden deshalb erst übernommen, wenn du die Wallbox per warp2/XYZ/reboot neustartest.