rtrbt

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 ;) )

Was funktioniert ist, wenn eine Wallbox (Wallbox 1) einen AP aufmacht und eine zweite (Wallbox 2) sich zu diesem AP verbindet. Du erreichst dann auch beide Web-Interfaces, wenn du mit dem AP verbunden bist. Problematisch wird es nur, wenn Wallbox 1 neben dem AP auch selbst als Client/Station in einem anderen Netz (lies: deinem WLAN) ist. Da kommt das Routing durcheinander und du kannst nicht mehr auf Wallbox 2 zugreifen. Wenn du sowieso keinen guten Empfang in der Garage hast, kannst du aber den AP von Wallbox 1 für Wallbox 2 benutzen, das Lastmanagement sollte dann funktionieren. Konfiguriere dann aber bitte auf Wallbox 2 den Access Point als Fallback, damit du, falls Wallbox 1 irgendwelche Probleme macht noch an Wallbox 2 kommst.

Versuch erstmal, die Einstellungen zurückzusetzen, wie hier https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf auf Seite 10 beschrieben. Falls das nicht hilft (dann bitte Bescheid sagen, ich würde mir das dann genauer ansehen) kannst du die manuell Flashen, wie im Post den @Backdraft007 verlinkt hat. Falls du die Ladeprobleme, insbesondere dass die Wallbox glaubt ein Fahrzeug wäre angeschlossen, obwohl keins da ist, nochmal erzeugt bekommst, schick bitte einen Debug-Report + Ereignis-Log. Dem würden wir auf jeden Fall nachgehen wollen. Was für ein Fahrzeug lädtst du an der Box?

Moin, Stand jetzt kann die Firmware das nicht. Es gibt in der Firmware-Compile-Konfiguration ein Flag, mit dem die Verbindung funktionieren sollte, das habe ich gerade getestet, es hat aber spontan nicht funktioniert. Ich nehme das mal auf die TODO-Liste auf, eventuell komme ich in ein paar Wochen mit einer Test-Firmware auf dich zurück.

Du brauchst dafür noch den U.FL zu SMA-Adapter und solltest dir eventuell das passende Gehäuse gleich mitbestellen. Das Gehäuse hat ein Loch für das SMA-Ende des Adapters, damit hast du gleich eine Zugentlastung. Sonst ziehen 3 Meter Kabel am U.FL-Stecker. Ob du dann guten Empfang hast, hängt natürlich extrem von externen Faktoren wie der Positionierung, der Art der Tönung usw ab. Es sollte aber aufgrund der größeren Antenne auf jeden Fall besser werden.

Moin, Sorry für die späte Rückmeldung, ich hatte am Freitag einen Blick in die Logs geworfen und dem Problem kurz nachgegangen, hatte aber noch nichts hilfreiches herausgefunden. Ich gebe dir im Laufe der kommenden Woche nochmal eine Firmware zum Testen, in der Hoffnung, dass wir dann mehr sehen.