rtrbt

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.

Gut zu hören, danke für die Rückmeldung!

Der Bug ist prinzipiell bekannt, ich bin aber noch nicht dazu gekommen, dem nachzugehen. Es scheint da ein Problem mit der Initialisierungsreihenfolge zu geben, sodass manchmal der Standard-Hostname des ESPs nicht sauber überschrieben wird. Funktioniert es bei dir, wenn du http://warp-ABC.local/ statt http://warp-ABC/ aufrufst? Das wird per mDNS aufgelöst.

Wir schreiben die Tage dazu einen Blog-Post ;) Aber ja die Kurzzusammenfassung ist Spiegelband + 15cm Kabel. Tut es, ja. Denk daran, dass du mit /reboot neustarten musst, damit die neu-konfigurierten Tags verwendet werden. Aus purer Neugierde: Warum willst du die NFC-Config per API befüllen? Hast du so häufig wechselnde NFC-Tags, dass du das nicht über das Webinterface machen kannst? Guter Punkt, füge ich gleich ein. Das der Anchor nicht geht ist ein Bug im API-Docs-Generator. Das müsste korrekterweise auf #evse_button_configuration linken. Edit: gefixt.

Besser spät als nie: Die Beispiel-Konfiguration sollte jetzt wieder funktionieren. Danke für's melden!

Bedenke, dass NFC dann nur so gut funktioniert wie bei WARP 2. Du kannst also Stand jetzt nicht tracken, mit welcher Karte wie viel geladen wurde. Die Ladevorgänge zu tracken wird in der nahen Zukunft als Feature dazukommen. Bei WARP 1 könnte es sein, dass wir da ein paar Einschränkungen machen müssen, weil weniger RAM zur Verfügung steht als bei WARP 2. Ich sehe aber bis jetzt noch nichts was da kritisch werden könnte.

Aus Sicht der Wallbox nicht. Dein Auto wird natürlich, wenn es die Ladung abbricht und du dann wieder versuchst die Ladung zu starten, nicht reagieren, weil es ja (z.B.) seinen Zielwert erreicht hat. Damit meinst du, du startest die Ladung, stoppst dann (per MQTT oder Webinterface), startest nochmal und dann lädt das Auto nicht mehr? Aus debug-report (und dem Video) sieht es so aus, als ob die Wallbox dem Auto Strom anbietet, das Auto aber nicht signalisiert, dass es laden möchte. Meldet das Auto irgendetwas? (Also dass es z.B. nicht angeschlossen wäre o.Ä.?) Was passiert, wenn du in der Situation das Ladekabel abziehst, neu ansteckst und dann nochmal die Ladung startest?

Firmware: WARP2 1.1.0 Lastmanagement überarbeitet. Kompatibel zu WARP1 1.3.0 MQTT-Implementierung ersetzt Layout der Ereignis-Log-Unterseite verbessert Debug-Report und Ereignis-Log zusammengelegt Detektion der Anzeigesprache des Webinterfaces verbessert Taster-API hinzugefügt Stromzähler-Konfigurationsproblem behoben (durch Update auf Ladecontroller-Firmware 2.0.5) Download: WARP2 1.1.0

In WARP1 1.3.0 ist die fertige Version des Lastmanagements enthalten. Feedback bitte weiterhin in diesen Thread.

Firmware: WARP1 1.3.0 Lastmanagement hinzugefügt Web-Server-Implementierung ersetzt Server-Sent-Events entfernt; WebSockets hinzugefügt MQTT-Implementierung ersetzt Unterstützung des NFC-Freigabe hinzugefügt Firmware-Prüfung vor Flashen hinzugefügt WLAN-Verbindungsqualität verbessert Layout der Ladecontroller- und Ereignis-Log-Unterseiten verbessert Debug-Report und Ereignis-Log zusammengelegt Detektion der Anzeigesprache des Webinterfaces verbessert Taster-API hinzugefügt Kompatibilität mit ID.3 u.Ä. verbessert (durch Update auf Ladecontroller-Firmware 2.0.12) Download: WARP1 1.3.0

Analog zum "Veröffentlichungen"-Thread für die Bricks und Bricklets, posten wir hier immer einen Hinweis, wenn es eine Wallbox-Firmware gibt. (Den Thread kann man übrigens abonnieren ;) )