rtrbt

Moin, Die Fehlerbehandlung übernimmt die Wallbox, ja. Einen Reset solltest du nicht brauchen. Es sollte reichen, wenn du: Die Ladung beendest (falls eine lief), Sicherheitshalber auto-start ausmachst (das solltest du sowieso deaktivieren, wenn du abhängig von deiner PV-Leistung selbst steuern willst wann geladen wird) Wartest bis du iec_state 0 (also A) siehst Dann die Phasen ab/zuschaltest Wartest dass dein Schütz geschaltet hat Dann das Laden wieder startest Das musst du mit deinem Aufbau ausprobieren. Je nach Trägheit des Autos würd

Stimmt.

Moin, Testet mal bitte diese Version. Wir hatten das Zertifikat für den Download-Server gewechselt, der Brick Viewer hat aber noch die alte Zertifikatskette mitgeliefert. Deshalb konnte er keine TLS-Verbindung aufbauen.

Grundlegend ist der Vorteil des ESP32-Bricks, dass du kein Linux darauf hast, sondern direkt mit der Hardware reden kannst, z.B im Arduino-Stil. Da verwechselst du Dinge. Der ESP32 Brick hat einen Proxy-Modus, was aber nicht über MQTT läuft, sondern das normale Tinkerforge-Protokoll. D.h. du kannst ihn genau wie alle anderen Bricks verwenden und z.b. dich mit dem Brick Viewer darauf verbinden. Deshalb funktionieren dann auch die MQTT-Bindings damit. Aktiv macht der Brick aber nichts über MQTT, es sei denn man schreibt eine entsprechende Firmware.

Moin, Stand jetzt kannst du das nicht einstellen. Die Wallbox schickt MQTT-Nachrichten nur bei Änderung der Werte, prüft aber jede Sekunde auf Änderungen, auch damit das Webinterface nicht extrem langsam ist (das Webinterface benutzt bis auf MQTT selbst die selben Mechanismen). evse/state und ein paar andere Topics beinhalten Werte, die sich praktisch immer ändern (z.B. die Uptime), deshalb bekommst du jede Sekunde eine Nachricht. Ich habe noch auf der TODO-Liste mir zu überlegen ob und wenn ja wie man das limitieren kann.

Moin, Sorry für die späte Antwort, war im Urlaub. Benötigt wird die Verbindung garnicht. Wenn das RS485-Bricklet nicht gefunden wird, deaktiviert das Webinterface den entsprechenden Teil der Oberfläche. Prinzipiell sollte dein Plan funktionieren. Die eModbus-Bibliothek sollte sich gut in die Firmware einfügen, PlatformIO und AsyncTCP benutzen wir auch. Wenn du dir das sdm72dm-Modul aus der Firmware umschreibst und die API einhältst (also sowohl die des Moduls, als auch die "nach außen", meter/state und so) sollte das funktionieren. Die interne API zwischen den Modulen ist

Moin, Der Zähler gibt einen Messwert mit bis zu 3 Nachkommastellen aus (also 0,001 kWh = 1 Wattstunde). "Bis zu " weil es ein float ist, Nullen hinten werden also abgeschnitten. Die Wallbox reicht die Messwerte des Zählers unverändert weiter.

Hi Gustav, Ich habe deine Anmerkungen mal in die Anleitung eingepflegt. Die aktuelle Version findest du hier: https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf

Hi, I don't think so, sorry. Finishing the binding will take some time, I would estimate about two to four weeks. So it is not really squeezeable. I will continue to work on the binding as soon as the heap of tasks for our charging station is done.

Moin, Gibt es leider nicht. Wenn du nur Pixel zeichnest, kannst du die Koordinaten flippen, bei Text müsstest du auf eine Bitmap-Schrift umsteigen und die selbst zeichnen.

Gemergt. Ich biege die Partitionstabelle noch etwas um, das große SPIFFS brauchen wir Stand jetzt nicht und bei ESPs die man zur Entwicklung nutzt ist es kein Problem die Partitionstabelle noch umzuändern. Andere Frage: Wenn du bei dir die upload_port-Zeilen beide auskommentierst, funktioniert dann die Auto-Detection? Dann würde ich das so in die ini packen, damit man nicht seine seriellen Ports jedes Mal anpassen muss.

Firmware: IMU 2.0 Brick 2.0.15 Fixed response size of the temperature callback Download: IMU 2.0 Brick

Firmware: IMU 2.0 Brick 2.0.15 Größe des Antwortpakets des Temperature-Callbacks repariert Download: IMU 2.0 Brick

Das war ein Firmware-Bug, mit der frisch veröffentlichten 2.0.15 geht es bei mir. Hintergrund war, dass die Größe des Antwortpakets zu groß war (copy-paste-Fehler, es hat die Größe des AngularVelocityCallbacks benutzt). Die Bindings prüfen die Länge von Callback-Paketen und ignorieren zu kurze und zu lange Pakete, deshalb kam bei dir nichts an. Da gibt es tatsächlich Unterschiede: Die Bricks und Bricklets laufen mit einer Tickrate von 1 kHz. Pro Tick kann nur ein Paket erzeugt werden. Wenn du also Werte aus zwei Callbacks brauchst, kannst du jeden Wert nur noch mit 500 Hz auslesen. Aus

Das OLED kann von sich aus nur die eine Textgröße darstellen. Die großen Zahlen für das Beispielvideo werden als Bild gezeichnet: https://github.com/Tinkerforge/oled-128x64-bricklet/blob/master/software/examples/python/example_draw_servo_poti.py Etwas ähnliches müsstest du dann auch machen. Du könntest dir zum Beispiel eine Bitmap-Font suchen oder Text mit einer Graphikbibliothek rastern und dann die Pixel auf das Display schieben.