rtrbt

Die Daten die wir brauchen werden erst gesammelt, wenn du auf Start klickst. Also musst du den Moment abpassen, wenn das Schütz klackert. Das ist im Moment leider noch relativ primitiv gebaut, langfristig wird das besser: https://github.com/Tinkerforge/esp32-firmware/issues/171

Im Anhang eine Testfirmware. Damit sollte das Problem weiterhin auftreten, aber im debug-log sind noch ein paar Informationen mehr. Reproduziere das Problem mit der Firmware bitte nochmal. warp2_firmware_2_1_2_649060b0_d5c477b78835162__merged.bin

Schonmal unabhängig vom Rest: Nein, das würde dazu führen, dass wenn sich ein Auto leer steht, nicht nachgeladen wird. Außerdem gibt es Autos (die Teslas z.B. wenn ich mich richtig erinnere), die im Winter ihre Heizung aus Wallbox-Strom betreiben können. Wir hatten dieses Verhalten mit dem Lastmanagement mal ausversehen implementiert und dann aber geändert. Siehe hier:

Zu der manuellen Ladefreigabe: Das hieß in älteren Firmware-Versionen Auto-Start. Wir haben das geändert und auf die Unterseite gepackt, weil es die meisten Nutzer eher verwirrt hatte. Jetzt ist aber die ganze Benennung noch verwirrender. Das müssen wir besser machen. Dazu noch grundlegend: Die manuelle Ladefreigabe (ex Auto-Start) als Ladestromgrenze ist wie folgt belegt: Der Taster an der Wallbox blockiert (bei WARP1 immer, bei WARP2 konfigurierbar) Wenn du auf der Statusseite auf Stop klickst, blockiert die Ladestromgrenze, wenn du auf Start klickst, gibt sie frei Wenn du die manuelle Ladefreigabe auf der Ladeeinstellungsseite aktiviert hast, dann wird blockiert, wenn ein Auto abgezogen wird (d.h. du musst den ersten Start manuell freigeben) Das ist auch ein Fall von schlechter Benennung: Der Knopf heißt "Stop", er blockiert aber nur die "manuelle Ladefreigabe"-Stromgrenze. Ein Ladevorgang beginnt (im Bezug auf die Zeit/Energielimits und den Ladetracker usw.) wenn du das Auto ansteckst und endet, wenn du es abziehst. (Ausnahme: Wenn du die NFC bzw. Benutzerfreigabe benutzt, dann beginnt der Ladevorgang erst wenn du ein Tag an die Wallbox hältst)

Das geht. Damit ich das richtig verstehe: Willst du den Zähler neben dem WARP Charger lassen, oder willst du ihn in die Wallbox einbauen? Im ersten Fall kannst du die Teile einfach bestellen, in Fall zwei, schreib stattdessen eine Mail an info@tinkerforge.com mit einem Verweis auf diesen Post und deiner Adresse usw. Dann legen wir dir eine Bestellung auf Rechnung an. In jedem Fall brauchst du dafür: mindestens Firmware 2.0.2 auf dem WARP Charger. Aktualisier bei der Gelegenheit am besten gleich auf die neuste Firmware: https://www.warp-charger.com/warp1.html#firmware bzw. warte noch bis Ende der Woche, dann sollte 2.1.3 erscheinen. ein RS485-Bricklet: https://www.tinkerforge.com/de/shop/warp/warp1-spare-parts/rs485-bricklet.html ein 7p-7p Bricklet-Kabel (kannst du da gleich mit bestellen), 15cm reichen Wenn du den Zähler neben dem WARP Charger lässt: Ein möglicherweise langes 3-adriges Verbindungskabel zwischen Zähler und RS485-Bricklet. In den Posts unten hat jemand ein Cat-7-Kabel benutzt. Ein Befestigungskit für das RS485-Bricklet: https://www.tinkerforge.com/de/shop/mounting-kit-12mm.html (kannst du auch beim RS485-Bricklet mit auswählen) und du musst dann ein Loch ins Gehäuse bohren um das Kabel durchzuführen und 4 Löcher in den Berührschutz um das RS485-Bricklet zu befestigen. Wenn du den Zähler in den WARP Charger einbaust: Den Berührschutz für einen WARP Charger Pro. Bei dem sind die Ausschnitte andere, damit der Zähler reinpasst. Den gibt's nicht im Shop, deshalb müsstest du uns dafür die Mail schreiben. Ein Verbindungskabel zwischen Zähler und RS485-Bricklet. Davon haben wir noch welche hier, würden wir dir dann mit reinlegen. Das prinzipielle Vorgehen ist: Wallbox stromlos machen Frontdeckel abnehmen, dabei auf das Fronttaster- und Erdungskabel achten Berührschutz ausbauen 4 Löcher reinbohren oder ESP-Brick auf den neuen Berührschutz setzen Die DIP-Schalter auf dem RS485-Bricklet auf Half-Duplex terminated schalten (1, 2, 3 auf ON; 4 auf OFF) RS485-Bricklet mit dem ESP-Brick verkabeln (Es ist egal an welchen Port du das Bricklet anschließt) und auf dem Berührschutz befestigen Loch in die Gehäusewand bohren oder den Klemmenblock ausbauen, stattdessen den Zähler einbauen und verkabeln Zähler mit RS485-Bricklet verbinden: A+ an RX+, B- an RX-, G an GND (siehe auch den Stromlaufplan hier:https://www.warp-charger.com/documents/WARP_Stromlaufplan.pdf) Berührschutz einbauen Frontdeckel aufsetzen und zuschrauben In der Software musst du nichts ändern. Das RS485-Bricklet sollte, wenn die Wallbox startet, automatisch gefunden werden. Hier haben das schon ein paar Nutzer gemacht:

Das sind ja zwei Probleme hintereinander: 1. Bringt das dritte Tag anscheinend den NFC-Leser durcheinander -> Ich sehe mir den zweiten debug-report gleich an und schreibe dir dann noch was dazu. Im Idealfall können wir das hier reproduzieren und dann hoffentlich fixen. 2. Wenn der NFC-Leser kurz hängt oder neu startet, kommt die Wallbox-Firmware damit nicht zurecht und crasht. -> Das habe ich behoben, d.h. selbst wenn der NFC-Leser crasht läuft die Wallbox weiter. Der Fix wird in der nächsten Firmware (voraussichtlich Ende der Woche) enthalten sein.

MQTT ist kein Umweg, sondern der offiziell unterstützte Weg, einen WARP Charger mit EVCC zu verbinden. Deshalb dokumentieren sowohl wir, als auch EVCC das so. Wenn du über OCPP oder Modbus gehen willst (vermutlich mit dem Hintergedanken, dass du dann keinen MQTT-Broker aufsetzen musst?), dann kannst du das tun. Für Modbus-TCP musst du: Die Wallbox entweder eine Keba-Wallbox oder einen Bender-Ladecontroller emulieren lassen. Kannst du auf der Modbus-TCP-Unterseite als Registersatz wählen Dir für EVCC ein Sponsortoken kaufen Die Wallbox in EVCC konfigurieren. Entweder als https://docs.evcc.io/docs/devices/chargers#kecontact-p20-p30-cx-series- oder als https://docs.evcc.io/docs/devices/chargers#bender-cc612613- Für OCPP musst du auch EVCC entsprechend konfigurieren, siehe hier: https://docs.evcc.io/docs/devices/chargers#ocpp-16j-kompatible-wallbox-mit-smart-charging-profil Die OCPP-Implementierung von EVCC ist aber nur das absolute Minimum (eben weil es nur ein Fallback ist, wenn keine sinnvollere Anbindung existiert), als wir das hier mal getestet hatten, hat das nicht 100%ig überzeugend funktioniert. Siehe z.B. hier: https://github.com/evcc-io/evcc/issues/5055#issuecomment-1305359228

Das bezieht sich nur auf die WARP1 Pro. Der Zähler in der WARP2 Pro kann ein- und dreiphasig betrieben werden.

Das Problem ist nicht die zu große Nachricht, die wird sowieso ignoriert, eben weil sie a) zu groß ist und b) auf ein Topic geht, dass nicht geschrieben werden darf. Ich vermute aber, dass openHAB mehr bzw. alle Topics der Wallbox beschreibt, unter anderem auch evse/stop_charging und evse/start_charging o.Ä. EVCC ist das vermutlich nicht.

Letzte Idee die ich noch habe: Je nach Distribution kann die Gruppe anders heißen. Unter Arch z.B. uucp statt dialout. Du kannst mit ls -l /dev/ttyACM1 (o.Ä.) nachsehen welcher Gruppe die Datei gehört.

Deaktiviere mal testweise die MQTT-Kommunikation. Mir ist im Log gerade aufgefallen, dass diese Meldungen MQTT: Ignoring message with payload length 2526 for topic warp/SzQ/charge_tracker/last_charges. Maximum length allowed is 2048. auch ~alle 45 Sekunden erscheinen und zwar genau zwischen dem Ab- und Anschalten. Das ist an sich schon komisch, weil charge_tracker/last_charges ein State ist, was heißt, dass last_charges von außen sowieso nicht geschrieben werden darf. Die Längenprüfung ist davor, deshalb sehen wir das jetzt im Log, anstatt dass die Nachricht einfach ignoriert wird. Etwas zusammengekürzt: 2023-06-13 13:29:56,780 Charger state changed from 3 to 0 2023-06-13 13:29:57,167 MQTT: Ignoring message[...] 2023-06-13 13:29:58,914 Charger state changed from 0 to 2 2023-06-13 13:30:44,023 Charger state changed from 3 to 0 2023-06-13 13:30:44,751 MQTT: Ignoring message[...] 2023-06-13 13:30:46,169 Charger state changed from 0 to 2 2023-06-13 13:31:31,306 Charger state changed from 3 to 0 2023-06-13 13:31:32,449 MQTT: Ignoring message[...] 2023-06-13 13:31:33,495 Charger state changed from 0 to 2 Kann es sein, dass openHAB regelmäßig (oder z.B. bei Reconnect?) alle MQTT-Topics schreibt, die es findet? Ich weiß das ioBroker das Problem hat, siehe z.B. hier: Das hat im Extremfall dazu geführt, dass ioBroker die Wallbox andauernd neugestartet hat, weil es andauernd auf die /reboot-API geschrieben hat :D

Füg dich mal der dialout-Gruppe hinzu: https://www.tinkerforge.com/de/doc/Software/Brickv.html#flashen

Wir haben uns den Debug-Report angesehen, anscheinend passiert folgendes: Der NFC-Leser selbst schickt entweder > eine Sekunde lang keine Daten mehr, oder die Wallbox ansich hängt aus anderen Gründen so lange Das sorgt dafür, dass ein Code-Pfad genommen wird, der definitiv falsch ist (habe ich verbockt, sorry) Das crasht die Wallbox -> sie startet neu Ich fixe auf jeden Fall den Code, der da crasht, aber: Wenn du das tust: teste bitte nochmal mit genau den NFC-Tags die du davor probiert hast. Falls du mit einem der Tags reproduzierbar den NFC-Leser abschießen kannst, wäre das sehr interessant.

Ja. Das Lastmanagement ist für die Phasenumschaltung notwendig, weil darüber der Ladevorgang gestoppt und das CP-Signal getrennt wird, bevor die Phasenumschaltung durchgeführt wird. Mehrere: Das EVCC-Weltmodell kennt den Energy Manager nicht, er wird praktisch als Teil der Wallbox behandelt und nur für die Phasenumschaltung verwendet. Außerdem ist die Idee, dass EVCC vermutlich bereits eine Solaranlage auslesen und damit besser steuern kann.

Die obligatorische erste Frage: Läuft die aktuelle Firmware (2.1.2) auf der Wallbox? Nicht dass wir alte Bugs jagen. Hattest du nach zwei Karten auf Speichern und dann Neu starten geklickt oder ist die Wallbox von sich auch neugestartet? Im zweiten Fall würde ich gerne herausfinden, warum das passiert ist. Dafür müsstest du einen Debug-Report von der Wallbox ziehen. Bekommst du nach dieser Meldung weitere? Die Meldung wird genau ausgegeben, bevor die Wallbox den NFC-Leser neu initialisiert. D.h. eigentlich sollten spätestens danach wieder Tags erkannt werden. Möglich. Das muss aber etwas nicht offensichtliches sein, wenn die Kommunikation zum NFC-Bricklet noch funktioniert, es sich aber sporadisch zurücksetzt? (so interpretiere ich das Log erstmal). Zieh wie gesagt mal einen Debug-Report von der Wallbox. Ich hoffe, dass wir dann mehr sehen.

Eigentlich sollte kein Problem sein, da der Brick Viewer nicht QtQuick sondern QtWidgets benutzt. Du kannst z.B. mal versuchen, die Verwendung des Fusion-Styles (oder jedes beliebigen anderen) zu verwenden mit sudo QT_STYLE_OVERRIDE=fusion brickv Eventuell hilft das hier?: https://wiki.archlinux.org/title/qt#Theme_not_applied_to_root_applications

Ich habe mal einen Blick in CModules und auch https://docs.micropython.org/en/latest/develop/natmod.html# geworfen. Leider ist das nicht so einfach wie ich mir das vorgestellt hatte. Man müsste in jedem Fall einen Wrapper für die Bindings generieren. Ich kann dir nicht versprechen, dass das in nächster Zeit passiert, sorry.

Das kommt darauf an, wie du den maximalen Ladestrom setzt: Wenn du evse/global_current_update verwendest, wird die Ladestromgrenze verändert, die auch im Webinterface auf der Statusseite als "Konfigurierter Ladestrom" angezeigt wird. Diese Stromgrenze wird in der Tat im Flash des Ladecontrollers gespeichert. Alternativ kannst du in den Ladeeinstellungen die externe Steuerung aktivieren und dann mit evse/external_current_update den Ladestrom setzen. Dieser Wert wird nicht im Flash gespeichert und ist deshalb auch der, der von z.B. EVCC verwendet wird.

Firmware: WARP Energy Manager 1.0.4 Initialiserungsfehler behoben, der auftrat, wenn Stromzähler direkt mit dem Energy Manager verbunden ist Zurücksetzen auf Werkszustand per Knopfdruck repariert Race Condition während des Starts des Webservers behoben Download: WARP Energy Manager 1.0.4

Es gibt in esp32-firmware/software das Script coredump.py. Dem kannst du entweder einen Pfad zu einem Debug-Report geben (an den hängen wir den letzten Coredump an) oder mit -p einen seriellen Port an dem ein ESP angeschlossen ist, von dem der Coredump runtergeladen werden soll. Das Script besorgt sich auf eine der beiden Weisen einen Coredump, sucht in esp32-firmware/software/build nach der .elf-Datei die zu der Firmware gehört und startet dann einen gdb der den Stacktrace dekodiert und ihn und die Register usw. ausgibt.

Firmware: WARP Energy Manager 1.0.3 Neuen Phasenumschaltungs-Modus "Einphasig PV/Dreiphasig schnell" hinzugefügt Anzeige des Zustands der Phasenumschaltung bei externer Kontrolle hinzugefügt Prüfung auf überlappende Netzwerkbereiche bei IP-Konfiguration von LAN, WLAN und WireGuard hinzugefügt Übersetzungen verbessert Sofortiger Start des WLAN Access Points hinzugefügt, falls keine WLAN-Verbindung konfiguriert und kein Ethernet-Kabel verbunden ist Sichtbarkeit der Nulllinie verbessert Alle 48h-Graphen auf mindestens 1500 Watt skaliert Minimalhöhe der Monatsübersicht auf 10 kWh reduziert Ereignis-Log-Meldungen überarbeitet Generierung des Energie-Manager-Protokolls repariert Verwendung des falschen Minimalstroms bei einphasigem Laden repariert Plötzlichen Ladestop bei geringer PV-Produktion behoben Instabiles Verhalten am Anfang eines Ladevorganges bei teilweise bewölktem Wetter behoben Behoben, dass Daten der dritten und weiterer Wallboxen nicht aufgezeichnet worden Überlappende Balken in Monatsübersicht behoben Abgeschnittenen ersten und letzten Balken in Monatsübersicht behoben Hinweis: Version 1.0.3 hat einen Bug der dazu führen kann, dass kein Zugriff auf das Webinterface möglich ist. Bitte direkt 1.0.4 verwenden.

Sorry den Edit hatte ich nicht gesehen. Der ESP crasht in deiner Variante, weil du pixels in der Funktion anlegst. Dann landet das Array auf dem Stack und der ist je nach den Werten von WIDTH und HEIGHT zu klein. Wenn du z.B. das ganze Display füllen willst, also WIDTH 64 und HEIGHT 128, braucht das Array 64 * 128 = 8 kB Speicherplatz. Der Stack ist aber wenn ich mich richtig erinnere nur 6 kB groß. Wenn du die Deklaration von pixels aus der Funktion rausziehst, funktioniert es.

Die Funktion hat den Fallstrick, dass die Endwerte jeweils auch Pixelkoordinaten sind. Das heißt, dass wenn du 16*16 Pixel zeichnen möchtest, die Endwerte jeweils der Startwert plus 16 Pixel sind, weil der Startpixel mitzählt. #include "Arduino.h" #include "bindings/config.h" #include "hal_arduino_esp32_brick/hal_arduino_esp32_brick.h" #include "bindings/errors.h" #include "bindings/bricklet_oled_128x64_v2.h" // Used to report any error encountered while running the example. extern "C" void check(int e_code, const char *c) { if (e_code == TF_E_OK) { return; } #if TF_IMPLEMENT_STRERROR != 0 tf_hal_printf("Failed to %s: %s (error code %d)\n", c, tf_hal_strerror(e_code), e_code); #else tf_hal_printf("Failed to %s: %d\n", c, e_code); #endif } TF_HAL hal; static TF_OLED128x64V2 oled; bool pixels[16*16] = { true, true, true, true, true, true, true, true, true, true, true, true, true, true, true, true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, true, true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, true, true, false, true, true, true, true, true, true, true, true, true, true, true, false, false, true, true, false, true, true, true, true, true, true, true, true, true, true, true, false, false, true, true, false, false, false, false, true, true, false, false, false, false, false, false, false, false, true, true, false, false, false, false, true, true, false, true, true, false, false, false, false, false, true, true, false, false, false, false, true, true, false, true, true, false, false, false, false, false, true, true, false, false, false, false, true, true, false, true, true, true, true, true, false, false, true, true, false, false, false, false, true, true, false, true, true, true, true, true, false, false, true, true, false, false, false, false, true, true, false, true, true, false, false, false, false, false, true, true, false, false, false, false, true, true, false, true, true, false, false, false, false, false, true, true, false, false, false, false, true, true, false, true, true, false, false, false, false, false, true, true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, true, true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, true, true, true, true, true, true, true, true, true, true, true, true, true, true, true, true }; void setup() { Serial.begin(115200); delay(3000); Serial.println("Hello World!"); check(tf_hal_create(&hal), "hal create"); // Create device object check(tf_oled_128x64_v2_create(&oled, NULL, &hal), "create device object"); // Clear display check(tf_oled_128x64_v2_clear_display(&oled), "call clear_display"); // Write "Hello World" starting from upper left corner of the screen check(tf_oled_128x64_v2_write_line(&oled, 0, 0, "Hello World"), "call write_line"); // Draw logo to center of screen check(tf_oled_128x64_v2_write_pixels(&oled, 56, 24, 56 + 15, 24 + 15, pixels, 16*16), "call write_pixels"); } void loop() { // Poll for callbacks tf_hal_callback_tick(&hal, 0); }

USB mit einem Industrial Digital Out, IO4, oder ähnlichen Bricklets zu sprechen funktioniert vermutlich nicht. Dafür ist die Kommunikation zwischen ESP und Bricklet zu langsam. Über die Pins auf der Stiftleiste des ESP32 Brick sollte das theoretisch gehen, spontan finde ich aber nur Implementierungen für den ESP32-S2, der USB-Hardware-Support mitbringt. Der Ansatz, ein RS232-Bricklet und einen USB-Seriell-Wandler zu verwenden sollte funktionieren. Alternativideen: Direkt den USB-Port des ESP-Bricks verwenden. Da musst du das Logging totlegen oder deine Nachrichten speziell markieren, damit der PC sie von den normalen Logs unterscheiden kann Statt USB über das Netzwerk gehen. Du kannst den ESP per WLAN oder wenn es ein ESP-Ethernet-Brick ist auch per LAN ins Netzwerk bringen und die Daten dann über TCP oder UDP übertragen. Noch einfacher für den Anwender ist es, wenn du den Webserver benutzt, dann kann man die Daten z.B. einfach als Dateien herunterladen.

Habe mit Schrecken festgestellt wie alt das Thema ist :D Ich sehe mir das mit den CModules die Tage mal an. Eventuell kann man da eine schnelle Lösung finden.