rtrbt

Moin Thomas, Das ist gerade in der Tat so und wird voraussichtlich noch etwas so bleiben. Der Hintergrund ist, dass wir die API des EVSE 2.0 Bricklets komplett umgebaut haben. Der Commit passt das entsprechende ESP-Firmware-Modul darauf an, und zieht die Änderungen bis ins Lastmanagement durch. In den nächsten Tagen kommt eine Beta-Version (erstmal nur für WARP 2) mit den API-Änderungen, dem Ladetracking usw. Wenn das alles so funktioniert, wie wir uns das vorstellen, ziehen wir die Änderungen für das EVSE 1.0 nach und bauen das entsprechende ESP-Firmware-Modul genauso um. Das hat den Vorteil, dass danach die Firmwares einheitlicher sind. tl;dr: Bleib mit deinem Fork erstmal hinter dem Commit, ich gebe Bescheid, sobald das EVSE-Modul wieder kompiliert.

Moin, Ein paar Fragen dazu: Passiert das bei dir sofort wenn du den Brick Viewer aufmachst und den IMU-Tab auswählst oder musst du dafür irgendetwas tun? Auf was für einem Pi lässt du den Brick Viewer laufen? Sind die Bricklets per Master Brick oder HAT angeschlossen oder verbindest du dich zu einem anderen Rechner an dem die hängen?

Gut zu hören. Wir müssen in der Doku deutlicher machen, dass die init-files und die Beispiele nicht das selbe sind. (oder eventuell auch init-files als Beispiele generieren.) Grüße, Erik

Ah sorry, JSON kann kein Komma hinter dem jeweils letzen Eintrag. So sollte es laufen: { "pre_connect": { "tinkerforge/register/outdoor_weather_bricklet/SEz/station_data": {"register": true}, "tinkerforge/register/outdoor_weather_bricklet/SEz/sensor_data": {"register": true} }, "post_connect": { "tinkerforge/request/outdoor_weather_bricklet/SEz/set_station_callback_configuration": {"enable_callback": true}, "tinkerforge/request/outdoor_weather_bricklet/SEz/set_sensor_callback_configuration": {"enable_callback": true} } }

Die Beispiele auf den einzelnen Seiten der MQTT-Dokumentation sind nicht in der Syntax für das init file, sondern eher Anweisungen an den Leser. Für ein init file müsste das aussehen wie hier beschrieben: https://www.tinkerforge.com/de/doc/Software/API_Bindings_MQTT.html#laden-initialer-nachrichten-aus-einer-datei Also in deinem Fall: { "pre_connect": { "tinkerforge/register/outdoor_weather_bricklet/SEz/station_data": {"register": true}, "tinkerforge/register/outdoor_weather_bricklet/SEz/sensor_data": {"register": true}, }, "post_connect": { "tinkerforge/request/outdoor_weather_bricklet/SEz/set_station_callback_configuration": {"enable_callback": true}, "tinkerforge/request/outdoor_weather_bricklet/SEz/set_sensor_callback_configuration": {"enable_callback": true}, } }

Bisher gibt es noch nichts neues. Ich will nicht versprechen, dass das in die nächste Firmware-Version mit reinkommt, aber es sollte auch nicht mehr Monate entfernt sein, das zu implementieren. Ich gebe Bescheid ;)

Die Idee war dass sichergestellt ist, dass nicht weiter gerundet wird, wenn du einen Int schickst, der nicht als Float repräsentierbar ist. Wenn ich da gerade genauer drüber nachdenke ist das aber nicht sinnvoll: die erste Int, die gerundet werden würde ist die 16777217 (dann auf die 16777216). Der Wert ist so groß das ich nicht davon aus gehe, dass irgendeine (schreibende) API den brauchen würde. Ich werfe die Prüfung mal raus. Danke für den Anstoß!

Moin, Zwei Gedanken dazu: 1. Wie versorgst du den Stapel per Strom? Also mit was speist du in die Step-Down Power Supply ein? 2. Wenn du den Stapel ohne eingestecktes USB-Kabel hochfährst (und ~ 30 Sekunden wartest, der RED-Brick braucht ja etwas zum booten), dann erreichst du den Stapel ja nicht. Was passiert, wenn du dann an den laufenden Stapel das USB-Kabel ansteckst und mit dem Brick Viewer auf localhost gehst? Taucht dann alles auf? Was gibt der RED Brick unter Settings -> Network (ist der erste Tab) als Network Status usw. aus? Hast du eventuell einfach das Problem, dass der RED-Brick auf einer anderen IP auftaucht als du das erwartest? Das ist soweit erwartet, der RED-Brick muss immer der unterste Brick im Stapel sein.

(Disclaimer: Das ist etwas her, dass ich das programmiert habe, Details könnten also nicht 100%ig passen. Außerdem sorry für die Textwand.) Die Diagrammskalierung auf der Statusseite funktioniert folgendermaßen: Wir nehmen die fixen Stromgrenzen des Zuleitungs- und Typ-2-Kabels (da die sich nur mit einem Neustart der Box ändern können), berechnen daraus den theoretischen Maximalwert der Leistung (also Stromgrenze in Ampere * 3 Phasen * 230 Volt) skalieren das Diagramm so, dass dieser Wert noch reinpasst. Da außerdem dem Diagramm ein Seitenverhältnis vorgegeben wird, und auch die Achsenbeschriftungen usw. mitspielen, kann die tatsächliche Obergrenze je nach Auflösung usw. höher liegen, bei großen Bildschirmen werden es dann 30 kW. Ich hatte zwei Gründe das so zu implementieren dass das Status-Diagramm nicht skaliert, das auf der Stromzählerseite aber schon: Eeinerseits sind so beide Varianten (also ein "fixes" Diagramm und eines, dass dynamisch skaliert) verfügbar. Zweitens kann man sich so langfristig daran gewöhnen, was es bedeutet, wenn z.B: die Leistung gerade bei 50% der Diagrammhöhe ist. Gerade auf der Statusseite finde ich es wichtig, dass auf einen Blick erkannt wird, was der Zustand der Box ist. Wenn jetzt also z.B. zwei Tage nicht geladen wurde und danach klemme ich ein Auto an, dass wegen irgendeiner absurden Konfiguration nur mit 6 Ampere lädt, dann würde ich das bei einem fixen Diagramm sofort sehen, ohne dass ich einen Blick auf die Zahlen werfen muss. Wenn das Diagramm jetzt so skaliert, dass 6 Ampere Vollausschlag sind, würde ich das u.U. garnicht bemerken. Ich gebe euch aber Recht, dass das, gerade wenn die Wallbox nur einphasig angeschlossen und deshalb zwei Drittel des Diagramms immer leer sind, eher unpraktisch ist. Eventuell ist es sinnvoller eine dynamische Skalierung mit einem gut gewählten Minimum zu fahren, also etwas in Richtung die kleinste Y-Achse geht von 0 bis 2kW (das ist gerade so mehr als 6 Ampere einphasiges Laden) und wenn größere Werte im Verlauf sind skaliert die Y-Achse so dass diese Werte passen. Damit wurde man den zweiten Punkt meiner Gründe verlieren, aber das könnte ein esoterisches Problem sein. Fazit: UI-Programmierung ist schwierig ;) Zu den anderen Punkten: Das ist schwierig, weil intern alles über Ampere läuft. Wenn du jetzt z.B. 8300 Watt konfigurierst müsste ich das intern zu 12 Ampere dreiphasig übersetzen. Was passiert dann, wenn z.B. der Energie Manager, der ja bald(tm) kommt, auf einphasig umschaltet? Die Wallbox müsste sich dann das Watt-Ziel merken und auf 32 Ampere gehen? Was eventuell gehen würde, wäre ein zusätzliches Label, dass berechnet, welcher Leistung die aktuelle Einstellung entspricht o.Ä.. Das ist ein Punkt. Da die Stepper-Pfeile im Input auf Smartphones eher schwer zu treffen sind, baue ich eventuell etwas in die Richtung: Edit: Issues dafür: https://github.com/Tinkerforge/esp32-firmware/issues/104 https://github.com/Tinkerforge/esp32-firmware/issues/105

Die Fehlermeldung in dem Fall ist leider etwas unschön weil es im Endeffekt ein Übersetzungsplatzhalter ist. Wir haben hier: https://github.com/Tinkerforge/esp32-firmware/issues/42 ein Issue dafür, das etwas aufzuhübschen.

Moin, Bridge tinkerforge:brickd:local [host="127.0.0.1"] Thing tinkerforge:brickletio16v2:ioA "Meine IO16" (tinkerforge:brickd:local) [uid="ioA", pinConfiguration0=1, pinConfiguration1=0] Funktioniert bei mir und setzt Pin 0 auf Output (Initial high) und Pin 1 auf Output (Initial low). Das interessante ist natürlich, wie man das rausbekommt. Ich bin folgendermaßen vorgegangen: Die Konfigurationsparameter-Namen sind in headlessCamelCase, also erster Buchstabe klein und dann immer der erste eines Wortes in groß. Typischerweise ist das einfach 1:1 der Anzeigename. Die Werte sind meistens selbsterklärend, kompliziert ist es bei Choice-Inputs. Um z.B. rauszubekommen, dass 0 für Output (Initial high) steht, musste ich in der Konfiguration nachschlagen. Die Konfiguration ist aber etwas unleserlich weil es im Endeffekt einfach Python mit einem großen Haufen impliziter Ableitungen ist. Da das etwas knifflig ist, werde ich eventuell den Dokumentationsgenerator noch etwas aufbohren, damit die Konfigurationsnamen und Werte, so wie sie in die Textdateien einzutragen sind, angezeigt werden. Bei den Channels zeige ich ja auch die UIDs an.

Moin, Das kann verbessert werden und wird es auch. Wir bauen gerade die Interna der Ladesteuerung etwas um, dabei wird sich das Speichern der Autorisierung bis zum Disconnect automatisch ergeben.

Das stimmt soweit, ja. Du musst dann noch ein Loch ins Gehäuse bohren, damit du das Kabel in die Wallbox bekommst.

Zwei spontane Ideen: Wie blinkt die Wallbox, wenn du den Legic davorhältst? Es gibt "dieses Tag kenne ich"-Blinken das ist dreimal ein Fade, dann eine Pause bei der die LED an bleibt und das "dieses Tag kenne ich nicht"-Blinken, das ist ein Ausfaden, solange bis du das Tag wegnimmst. Kannst du dir in der Anleitung auf Seite 17 ansehen: https://www.warp-charger.com/documents/WARP2_Betriebsanleitung.pdf Zweite Idee: Hast du die Wallbox nach dem Anlernen neugestartet?

Moin, Wir haben den Grenzwert nochmal deutlich erhöht. Teste bitte mal, ob das Problem bei der Firmware 1.1.2 noch besteht. Grüße, Erik

Firmware: WARP2 1.1.2 Leere Client-IDs für MQTT verboten Lastmanagement: Hinzugefügt, dass versucht wird, Wallboxen die bereits einmal geladen haben, aufzuwecken Grenzwert für aktive Phasen auf 300mA erhöht (durch Update auf Ladecontroller-Firmware 2.0.7) Firmware-Updates erlaubt, wenn Fahrzeugzustand auf "Fehler" steht Webinterface für Bildschirme mit einer Breite von 320 bis 360 px benutzbar gemacht Warnung über Passwort-Reset bei Aktivierung des Logins hinzugefügt Oberfläche der Zugangsdaten-, Ereignis-Log-, WLAN- und MQTT-Unterseiten verbessert Korrekte Anleitung verlinkt Hängenden Webserver, wenn ein Client nicht mehr erreicht werden kann, repariert Zu häufige WLAN-Verbindungsversuche behoben Download: WARP2 1.1.2

Firmware: WARP1 1.3.3 Lastmanagement: Hinzugefügt, dass versucht wird, Wallboxen die bereits einmal geladen haben, aufzuwecken Firmware-Updates erlaubt, wenn Fahrzeugzustand auf "Fehler" steht Webinterface für Bildschirme mit einer Breite von 320 bis 360 px benutzbar gemacht Warnung über Passwort-Reset bei Aktivierung des Logins hinzugefügt Oberfläche der Zugangsdaten-, Ereignis-Log-, WLAN- und MQTT-Unterseiten verbessert Korrekte Anleitung verlinkt Hängenden Webserver, wenn ein Client nicht mehr erreicht werden kann, repariert Zu häufige WLAN-Verbindungsversuche behoben Download: WARP1 1.3.3

Gut zu hören. Das mit den Browser-Caches die teilweise alte Informationen anzeigen ist leider ein Problem. Ja, wir haben ein Issue dafür, damit das nicht verloren geht: https://github.com/Tinkerforge/esp32-firmware/issues/36

In die Richtung wird das gehen. Voraussichtlich fällt erstmal eine CSV-Datei dabei heraus. Auf der Wallbox speichern wir dann pro Ladung folgendes: Datum und Zeit (so bekannt), Zählerstand bei Ladestart, ID der Karte/des Nutzers, Ladedauer, Zählerstand bei Ende In die CSV können dann noch ein paar hilfreiche Einträge reinkommen, z.B. Anzeigename von Karte/Nutzer und die Differenz aus den Zählerständen (also die geladene Energie in kWh) Details hier: https://github.com/Tinkerforge/esp32-firmware/issues/3

Moin, Das ist ein WARP 1. WARP 2 gibt es erst seit ~ August 2021. Die EVSE-Fehlermeldung ist nicht wirklich ein Fehler. Was da pssiert ist, dass die Wallbox-Firmware beim Booten nachsieht, welche Firmware auf dem EVSE, also dem Ladecontroller, ist. Wenn das nicht die zur Wallbox-Firmware passende ist, wird umgeflasht. Du müsstest also danach eingerückte Ausgaben in die Richtung bekommen haben. Wenn alles geklappt hat ist die letzte Ausgabe "Firmware flashed successfully". Das klingt seltsam. Lad mal das Webinterface neu, geh dann auf System->Firmware-Aktualisierung und sieh nach was die Firmware-Version (die obere von beiden) ist. Flashe dann gleich die 1.3.2 (du musst nicht alle FIrmwares nacheinander flashen, immer direkt auf die aktuellste zu gehen ist am sinnvollsten). Falls das nicht funktioniert, ziehe bitte einmal einen Debug-Report + Ereignis-Log (unter System->Ereignis-Log) und häng beides hier an.

Fixed. The docs are generating right now.

@MiRo Please test the attached version of the bindings. For some reason "value has to change" was indeed set to true for the IO 4 2.0 and IO 16 2.0 Bricklets (and only those). tinkerforge_openhab_bindings_2_0_0_beta24_io16fix.zip

Der höchst ungenaue und inoffizielle Zeitplan sagt "Richtung Ende Januar". Das ist das aktuelle große Feature an dem wir arbeiten.

Das EVSE kann nur an ein CP-Signal und ein Schütz verkabelt werden. Da du aber sowieso in der Firmware des ESP Bricks rumhackst: Du kannst auf jeden Fall über die Bindings mit zwei EVSE Bricklets reden. Das ganze Firmware-drumherum ist darauf aber nicht ausgelegt. Eventuell kannst du aber ein DeviceModule für das zweite EVSE anlegen, da es anhand der Device-ID nach EVSEs sucht. Die Logik in tf_hal_get_tfp sollte clever genug sein, dass das DeviceModule dir erst das in Portreihenfolge erste EVSE und danach das zweite gibt. Du musst dann die APIs dann auf /evse2/ registrieren und eventuell das Frontend-Modul kopieren und die Pfade patchen. Das ist aber natürlich nicht offiziell unterstützt ;)

Moin, Tatsächlich teste ich meistens nur bis auf 360px runter. Dein iPhone hat mit einer Device Pixel Ratio von 2 nur 320px Breite. Zumindest die Änderung, damit der Button in der ersten Zeile bleibt ging relativ problemlos, sollte mit der nächsten Firmware kommen. Das Logo schiebt sich jetzt einfach etwas kleiner, wenn die Breite sonst nicht für beides reicht. Was leider nicht so einfach zu fixen ist, ist die X-Achsenbeschriftung der Stromzählergraphen. Da möchte ich nicht garantieren, dass ich den Aufwand investiere. Es gibt jetzt aber trotzdem ein Issue dafür, damit wir uns das nochmal in Ruhe ansehen: https://github.com/Tinkerforge/esp32-firmware/issues/93