rtrbt

Einen Termin gibt es noch nicht, ich arbeite aber gerade an der OCPP-Implementierung. Bekommst du über die OCPP-Anbindung bei CityWatt noch Details raus? Also z.B. ob OCPP-J unterstützt wird und ob das Core-Profile reicht? Die Webseite von CityWatt schweigt sich darüber leider aus. Gibt es meines Wissens nicht, das wäre aber auch recht kompliziert.

Moin, Die Anleitung auf unserer Seite ist leider veraltet. Ich nehme mir mal vor, die zeitnah zu aktualisieren. EVCC kann inzwischen die Konfigurationsdatei selbst erzeugen, dazu kannst du evcc configure starten. Ich habe das kurz mit einer WARP Pro getestet und folgendes ausgewählt: Standard (PV System) Mein Gerät ist nicht in der Liste (Nein zu allen Punkten bis Ladepunkt) (Ladepunkt) Standardname (Wallboxwahl) TinkerForge WARP Charger Pro (Firmware v2 installiert) ja (IP-Adresse) Achtung das ist die Adresse des MQTT-Brokers, nicht der Wallbox. 192.168.178.72 (musst du ändern ;) ) (Port) 1883 (Topic) warp/Sx7 (müsste bei dir warp2/Wqg sein) (Zeitüberschreitung) Standardwert Alles danach musst du dir aussuchen Dabei fällt bei mir folgende .yaml raus: # open evcc at http://evcc.local:7070 network: schema: http host: evcc.local # .local suffix announces the hostname on MDNS port: 7070 log: info levels: cache: error interval: 10s # control cycle interval chargers: - type: template template: tinkerforge-warp fw2: true host: 192.168.178.72 port: 1883 topic: warp/Sx7 timeout: 30s name: wallbox1 loadpoints: - title: Garage charger: wallbox1 mode: off phases: 3 mincurrent: 6 maxcurrent: 16 resetOnDisconnect: false site: title: Mein Zuhause meters: Wenn du da den chargers:-Block übernimmst und den Namen wallbox1 auf warp änderst sollte es eigentlich klappen. Edit: Die meter müssen type custom statt default haben und source: script statt type: script. z.B. so: meters: - name: gridmeter type: custom power: source: script cmd: /bin/sh -c 'echo 1000' - name: pvmeter type: custom power: source: script cmd: /bin/sh -c 'echo 10000'

Was der Exception Decoder eigentlich nur tut ist addr2line auszuführen. Ich habe mir dafür ein Python-Script (esp32-firmware/software/decode) geschrieben, dass das selbe auf der Kommandozeile tut. Benutzen kannst du das indem du den Backtrace kopierst und dann im software-Ordner ./decode [dein backtrace] ausführst, also z.B. ./decode 0x4000c341:0x3ffc9ce00x40161c6e:0x3ffc9cf0 0x4011123a:0x3ffc9d50 0x400e891c:0x3ffc9de0 0x4012daa6:0x3ffca470 Das Script läuft standardmäßig gegen die aktuellste Firmware im build-Verzeichnis, du kannst aber mit -f [pfad/zur/elfdatei.elf] mit einer spezifischen Firmware decoden. Das hat noch eine Kurzschreibweise: z.B. -f warp2 nimmt die aktuellste warp2-Firmware, -f esp32 die aktuellste ESP32-Brick-Firmware, die im build-Verzeichnis liegt. ELF-Dateien zu den veröffentlichten Firmwares liegen hier: https://github.com/Tinkerforge/warp-charger/tree/master/firmwares Dafür brauchst du einen JTAG-Adapter und musst dich an ein paar Pins des ESPs dranhängen. Anleitung ist hier: https://docs.platformio.org/en/latest/tutorials/espressif32/arduino_debugging_unit_testing.html#debugging-the-firmware Das hat aber noch nie jemand getestet. Ich kann dir auch nicht garantieren, dass die Schaltung an den Pins nicht das Debuggen stört. Alternativ das gute alte printf-Debugging ;) (logger.printfln bzw. Serial.println falls die Probleme vor der Initialisierung des Event-Logs auftreten.)

Könnte das in einem kurzen Test gerade nicht reproduzieren. Hast du den Benutzer nach dem anlegen auch gespeichert und ihm dann das Tag zugeordnet oder ist das unabhängig voneinander? Wie kommst du aus dem Zustand dann wieder raus? Musst du die Seite neuladen, die Wallbox neustarten, o.Ä.?

So weit so gut. Der ESP ist konfiguriert, dass er sich zu deinem WLAN verbindet, den Access Point aber offen lässt. Du könntest noch testen, ob es klappt, wenn du mit deinem Mac auch in deinem WLAN (nicht dem des ESPs) bist und dann versuchst dich per Brick Viewer und mit dem C-Programm zu 192.168.178.55 bzw. esp32-Zj7 zu verbinden. Wenn du aber per Brick Viewer und per Browser auf den ESP zugreifen kannst, kann es ja eigentlich kein reines Netzwerkproblem sein. (Bin kein macOS-Experte) Musst du dem Programm eventuell Zugriff auf das Netzwerk erlauben o.Ä.? Ich habe hier mit einem Mac getestet und musste das nicht, aber vielleicht ist dein Setup subtil anders. Falls du mit z.B. Wireshark umgehen kannst, könntest du einen Blick auf den Verbindungsaufbau werfen. Du kannst auch mal andere Bindings testen, falls du z.B. Python installiert hast. Vielleicht ist es ein C-Bindings-spezifisches Problem.

Das ist nur das Event-Log. Im Debug-Report steht zusätzlich noch die Konfiguration des ESPs. Dann ist der ESP darauf konfiguriert sich zu deinem WLAN zu verbinden. Da aber die Zeile "Network connected. Stopping soft AP" fehlt sollte der Access Point des ESPs weiterlaufen, d.h. du hast ihn nicht auf "nur als Fallback" konfiguriert.

Versuch mal esp32-xyz statt 10.0.0.1. Aufs Webinterface kommst du noch? Falls ja, zieh unter System->Ereignis-Log mal einen Debug-Report und lad ihn hier hoch. Ich glaube nicht dass da was hilfreiches drinsteht, aber man weiß ja nie ;)

Moment. Ist dein Mac im WLAN des ESPs oder sind beide im WLAN deines Routers? Die IP 10.0.0.1 funktioniert nur wenn du mit dem Access Point des ESPs verbunden bist (oder sehr ungewöhnliche statische IPs konfiguriert hast). Statt 10.0.0.1 sollte übrigens auch (egal in welchem Netz du bist, solange es bei Mac und ESP das selbe ist) der Hostname warp2-xyz [Edit: esp32-xyz, nicht alles ist eine Wallbox] funktionieren (siehe Aufkleber auf dem ESP)

Der Code sieht soweit korrekt aus. Mir sind aber keine Probleme mit dem ESP32 und macOS bekannt. Ein paar Ideen: Teste sicherheitshalber mal das unmodifizierte IP-Connection-Enumerate-Beispiel (die Host musst du natürlich ersetzen, der Rest kann so bleiben) Hast du mehrere Brick Viewer-Instanzen offen? Der ESP erlaubt im Moment maximal vier TFP-Verbindungen (erhöhen wir mit der nächsten Firmware auf 10) Welche Version von Bindings, ESP-Firmware und Brick Viewer verwendest du?

Moin, Nein kannst du nicht. Du kannst keine USB-Geräte an die Wallbox anschließen, da ist "nur" ein Mikrocontroller, kein PC, Raspberry Pi o.Ä, verbaut. Wenn es M-Bus zu USB gibt, findest du eventuell auch einen Konverter auf Ethernet bzw. WLAN. Dann kannst du die Daten beliebig auslesen.

Die Fehlermeldung wenn das Update nicht sauber durchläuft ist auch zu leicht zu übersehen. Habs mir mal aufgeschrieben: https://github.com/Tinkerforge/esp32-firmware/issues/148

Firmware: WARP2 2.0.7 Weitere WebSocket-Verbesserungen vorgenommen Behoben, dass fälschlicherweise ein SDM630 detektiert wurde, wenn kein Stromzähler angeschlossen ist (durch Update auf Ladecontroller-Firmware 2.1.6) Download: WARP2 2.0.7

Moin, Das klingt verwirrend. Eventuell ein Browser-Cache-Problem? Versuch z.B. mal (je nach Browser) STRG+F5. Edit: Was für einen Browser benutzt du?

Stimmt, das sollte so nicht sein, ist auch nicht der Normalzustand: Bei der 7590 die wir hier im Netz haben funktioniert die Verbindung problemlos. Eventuell hat das Umkonfigurieren bei deiner Fritzbox den WLAN-Stack neugestartet und das hat was auch immer schiefgelaufen ist repariert.

Das ist Absicht, ja. Die Konfigurationsversion ist immer die letzte Version in der es Änderungen im Konfigurationsformat gab. Das bedeutet z.B. dass Downgrades bis auf die 2.0.0 möglich sind, ohne dass Einstellungen verloren gehen sollten. Der entsprechende Code kommt direkt aus lwIP, also dem Netzwerkstack den wir einsetzen und ist leider sehr schweigsam. Synchronisierungsversuche sollten aber wie gesagt alle 150 Sekunden oder schneller durchgeführt werden. Die Beschriftung kommt vom Browser. Prinzipiell alles an Zeiten, was nicht direkt die Startzeitpunkte der aufgezeichneten Ladevorgänge sind, wird auf der Wallbox nur relativ zum Zeitpunkt an dem die Wallbox gebootet ist (der Uptime), betrachtet. Der Browser bekommt die aktuelle Uptime regelmäßig übertragen und kann dann z.B. die absoluten Zeiten für die Diagrammbeschriftungen über die aktuelle Systemzeit deines Browsers berechnen. Ja. Das funktioniert wie die Anzeige der IP-Adresse bei der LAN/WLAN-Verbindung. Sobald die Synchronisierung klappt, wird die Systemzeit der Wallbox angezeigt: Damit wir rausfinden warum die Synchronisierung nicht klappt: Häng hier mal einen Debug-Report an (Kannst du unter System->Ereignis-Log runterladen), eventuell finden wir darüber das Problem.

Moin, Sorry dein Thread ist irgendwie untergegangen. Wenn du nach WLANs scannst, taucht dein Netz dann auf? Hast du eventuell Repeater mit dem selben Netzwerknamen und der Brick versucht sich aus irgendwelchen Gründen zu dem Repeater zu verbinden? (Das kontrolliert das BSSID-Lock) Du kannst dir die Liste der gefundenen WLANs unter http://10.0.0.1/wifi/scan_results runterladen.

Der Work-Around ist in der frisch veröffentlichten 2.0.6, damit sollte der Fehlerzähler nicht mehr beim Reset hochzählen.

Moin, Testet beide bitte mal die Firmware 2.0.6, wir hatten mit 2.0.5 einen esoterischen Bug mit dem Schlüsselschalter gefixt, aber uns damit mehr Probleme eingehandelt, als gelöst. Außerdem haben wir die ID.3-Kompatibilität nochmal verbessert. In Summe sollte es jetzt wieder problemlos klappen.

Moin, Testet beide bitte mal die Firmware 2.0.6, wir hatten mit 2.0.5 einen esoterischen Bug mit dem Schlüsselschalter gefixt, aber uns damit mehr Probleme eingehandelt, als gelöst. Außerdem haben wir die ID.3-Kompatibilität nochmal verbessert. In Summe sollte es jetzt wieder problemlos klappen.

Moin, Gute Idee! Ist in der frisch veröffentlichten Firmware 2.0.6. Wenn die Synchronisierung klappt bekommst du einen separaten Eintrag dafür (und alle danach haben dann richtige Zeitstempel). Falls du etwas Ausgabe erzeugen willst kannst du z.B. einen WLAN-Netzwerkscan starten. Wenn die Synchronisierung klappt wiederholt die Wallbox sie nach 6 Stunden. Wenn eine Synchronisierung nicht klappt, hat der entsprechende Code einen Timeout von 15 Sekunden, der bei jedem Fehlschlag verdoppelt wird, bis maximal 150 Sekunden, also 15s, 30s, 60s, 120s, 150s, 150s, ... Das du Tagelang keine Synchronisierung bekommst würde ich also tendenziell eher auf die WLAN-Probleme schieben.

Firmware: WARP 2.0.6 und WARP2 2.0.6 WLAN-Scan-Timeout für Access-Point-Kanalsuche erhöht Aussehen der Form-Validierung repariert Netzwerk-Zeitsynchronisierungszustand und aktuelle Uhrzeit auf Statusseite hinzugefügt (WARP1) Work-Around für SDM72DM-Bug beim Zurücksetzen des Zählers hinzugefügt (WARP1) Sichergestellt, dass Ladevorgang nie gestartet werden kann, wenn Schlüsselschalter auf "aus" steht (durch Update auf Ladecontroller-Firmware 2.1.3) (WARP1) Längere Wartezeit für ID.3-Zustandswechsel hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.3) (WARP1) Sichergestellt, dass LED bei jedem Zustandswechsel bis zum Stand-By reagiert (durch Update auf Ladecontroller-Firmware 2.1.3) (WARP2) Sichergestellt, dass Ladevorgang nie gestartet werden kann, während Taster gedrückt ist (durch Update auf Ladecontroller-Firmware 2.1.5) (WARP2) Kompatibilität mit einigen Versionen des SDM630 erhöht (durch Update auf Ladecontroller-Firmware 2.1.5) Download: WARP 2.0.6 bzw. WARP2 2.0.6

Ich bin dem mal nachgegangen: Anscheinend hat der Stromzähler einen Bug in der Modbus-Kommunikation. Was beim Reset intern passiert ist, dass ich einen Schreibbefehl auf ein spezielles Register schicke, worauf hin der Zähler den Wert zurücksetzen und mir darauf antworten sollte, dass er das getan hat. In Modbus funktioniert das so, dass die Slaves (also der Zähler in dem Fall) IDs haben, damit wenn mehrere an einem Bus angeschlossen sind, der Master spezifisch mit einem Slave reden kann. Damit die Antworten unterschieden werden können, müssen die Slaves ihre eigene ID in die Antwort schreiben. Wenn ich z.B. einen Zählerwert lese sieht das mit dem Logic Analyzer so aus: Request an DeviceID 1 (den Zähler): Response von DeviceID 1: Der Zähler schickt jetzt aber, wenn ich den Reset auslöse eine Antwort nicht mit seiner ID (der 1) sondern aus irgendeinem Grund mit einer 0. Die 0 ist reserviert für Broadcasts, die darf von Slaves überhaupt nicht verwendet werden. Request an DeviceID 1: Response vom Zähler mit falscher DeviceID: Das Problem tritt aber nur bei dem Reset auf, beim Lesen der Zählerwerte, selbst beim Schreiben anderer Konfigurationswerte (mit der selben Funktions-ID) ist die Antwort korrekt. Das RS485-Bricklet (mit dem wir mit dem Zähler kommunizieren) sieht beim Reset dann die kaputte Antwort, wirft sie weg und betrachtet das als einen Timeout. Die Lösung des Problems wird sein, dass wir in der Wallbox-Firmware, falls beim Reset auslösen ein Timeout auftritt diesen ignorieren. In der Praxis habe ich es bisher nicht beobachten können, dass der Reset nicht funktioniert. Das sollten wir aber trotzdem prüfen, z.B. indem die Firmware dann den Wert, der zurückgesetzt wird, nochmal ausliest und prüft, dass er erwartet klein ist (also z.B. maximal x ms * 32 A * 230 V * 3 Phasen groß, wobei x die Zeit vom Auslösen des Resets bis zum Empfang des neuen Werts ist). Falls der Wert dann zu groß ist, lösen wir den Reset nochmal aus, mit maximal z.B. 3 Versuchen. Das zu implementieren ist etwas Aufwand, deshalb habe ich erstmal ein Issue dafür angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/147 Als schnelle Lösung für die nächste Firmware nehme ich erstmal raus, den Fehlerzähler bei Reset-Timeouts hochzuzählen. Das fühlt sich immer etwas falsch an zu sagen "nein nein hier zählt der Fehler nicht weil..." aber ich glaube in dem Fall ist es berechtigt: https://github.com/Tinkerforge/esp32-firmware/commit/7ec89afcbad67460b14527bbf318f7d266800392

Gibt es derzeit nicht, will ich jetzt auch nicht versprechen. Ich habe mal ein low-priority Issue angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/145

Das sind durchschnittlich 21,5 Minuten zwischen den Fehlern, ~ 0,012% Fehlerrate, aber trotzdem mehr als ich erwarten würde. Exception Code -1 heißt, dass das RS485-Bricklet (das kommuniziert per Modbus mit Zähler) eine Antwort des Zählers nicht innerhalb des Timeouts (eine Sekunde) bekommen hat. Was mir jetzt beim Schreiben auffällt: Es werden keine Request-IDs mit ausgegeben. Bist du auf der aktuellen Firmware? Falls ja, dann sind das alles Fehler, die beim Zurücksetzen der Zählerwerte aufgetreten sind. Eventuell ist der Timeout da einfach zu kurz gewählt.

Habe mal ein Issue dafür angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/144 Ansich wäre das schon ein cooles Feature, ich will aber nicht versprechen, dass wir das implementieren.