rtrbt

Über eine PDF-Generierung haben wir auch nachgedacht. Das ist aber, wenn wir das überhaupt implementieren, definitiv ein Post-2.0.0-Feature. Das ist tatsächlich ein Problem. Nicht nur wegen dem Speicherplatz, vorallem wegen der Rechenleistung. Sinnvollerweise würde man die PDF nicht auf dem Mikrocontroller generieren, sondern über Javascript im Browser des Nutzers, der die PDF herunterladen möchte.

Indirekt ja: In der WARP2 Beta, die wir gerade veröffentlicht haben sind uptime und time_since_state_change nicht mehr in evse/state sondern im Low-Level-State. Das führt dazu, dass wenn du nur auf evse/state subscribst nicht mehr sekündlich "Änderungen" reinkommen. Alles weitere, also Kontrolle über Intervalle bzw. welche Topics überhaupt geschickt werden, gibt es noch nicht, wir werden aber voraussichtlich vor der finalen 2.0.0 (die dann auch für WARP 1 kommt) ein anderes Problem mit der MQTT-API angehen (dieses: https://github.com/Tinkerforge/esp32-firmware/issues/77). Im Zuge dessen sehen wir uns dann auch nochmal die Problematik an.

Ich würde nicht ausschließen, dass wir das implementieren, aber rechne nicht damit, dass es in der 2.0.0 schon hübsche Graphen geben wird. Was auf jeden Fall zeitnah kommt ist, dass du die CSV vor dem Download nach User und/oder Zeitraum filtern kannst und ein paar Statistiken wie "wie viele Ladungen wurden getrackt", "was ist die älteste getrackte Ladung" angezeigt werden.

Firmware: WARP2 1.9.90 (2.0.0 Beta 1) Details hier:

Edit: Die fertigen Firmwares WARP 2.0.0 und WARP2 2.0.0 sind jetzt auf warp-charger.com verfügbar. Edit: Beta 4 für WARP2 bzw. Beta 3 für WARP1 ist jetzt weiter unten im Thread verfügbar: tl;dr: WARP2 Firmware 2.0.0 Beta 1 mit Ladetracker, Benutzerverwaltung und mehr. Achtung: API-Bruch! Was gibt's neues? Das große neue Feature ist das Tracken der Ladungen pro Benutzer mit CSV-Export. Damit zusammenhängend sind folgende neue Features: Die Benutzerverwaltung: Hier können bis zu 8 Benutzer angelegt und geändert werden. Jedem Benutzer kann ein maximaler Ladestrom zugeordnet werden. Falls der Login des Webinterfaces aktiv ist, kann pro Benutzer konfiguriert werden, ob dieser sich anmelden darf. Umbau des NFC-Moduls: NFC-Karten können jetzt Benutzern zugeordnet werden Der Ladetracker: Der WARP Charger kann jetzt bis zu 7680 Ladungen aufzeichnen. Bei jeder Ladung werden Startzeitpunkt, Nutzer, Zählerstart bei Start und Ende der Ladung, sowie Ladedauer gespeichert. Die gesammelten Daten können als CSV-Datei über das Webinterface heruntergeladen werden. Zeitsynchronisierung per NTP (Prototyp): Per DHCP kann der WARP Charger die eines NTP-Servers erfragen, über den dann eine Zeitsynchronisierung erfolgt. Die gesetzte Zeit wird für Ladetracker und Ereignislog verwendet. Entkopplung der NFC-Freigabe von anderen Ladefreigaben: Eine externe Steuerung wird, falls die NFC-Freigabe aktiv ist, nicht mehr blockiert. Außerdem haben wir diverse Bugs gefixt und kleinere Verbesserungen am Webinterface vorgenommen. Verbindungsabbrüche des Webinterfaces sollten jetzt deutlich seltener auftreten. Warum der Versionssprung auf 2.0.0? Wir haben die interne Verwaltung der Stromgrenzen und Blockaden (Button, NFC, Lastmanagement, Benutzerverwaltung, externe Steuerung usw.) komplett umgebaut. Diese Umbauten haben es notwendig gemacht, dass wir die HTTP-/MQTT-API anpassen. Deshalb wird die Versionsnummer, entsprechend des Semantic Versionings auf 2.0.0 gesetzt. Die veränderte API ist noch nicht dokumentiert, die Dokumentation wird aber in Kürze folgen. Wie beeinflusst der API-Bruch externe Projekte, z.b. EVCC? EVCC ist Stand jetzt nicht mit dieser Betaversion kompatibel. Wir stehen aber im Kontakt zu den EVCC-Entwicklern, bevor die fertige Version 2.0.0 erscheint, wird eine kompatible Version von EVCC zur Verfügung stehen. Warum gibt es die Beta nur für WARP 2? Wird WARP 1 nicht mehr weiterentwickelt? Ein klares Nein: Die neuen Features werden alle für WARP 1 nachgezogen, die fertige Version 2.0.0 wird wie gewohnt für alte und neue Hardware parallel veröffentlicht. Wir haben die internen Umbauten der Kommunikation zwischen Ladecontroller und ESP zunächst nur für WARP 2 vorgenommen und wollen uns dafür zunächst von euch Feedback abholen, bevor wir sie für WARP 1 übernehmen. Ist der Ladetracker kompatibel zum WARP Charger Smart? Ja. Es kann dann allerdings nicht die geladene Energie gemessen werden. Warum ist die Zeitsynchronisierung nur ein Prototyp? Bisher wird nur ein per DHCP gesetzter Zeitserver zur Synchronisierung verwendet, es fehlt noch eine sinnvolle Standardeinstellung. Außerdem fehlt noch ein Abschnitt im Webinterface zur Konfiguration, sowie die Anbindung eines möglicherweise verbautem RTC-Bricklets. (Siehe https://github.com/Tinkerforge/esp32-firmware/issues/26 ) Wie geht's weiter? Neben dem Umsetzen eures Feedbacks werden wir in den nächsten Wochen die API-Dokumentation und die Anleitung aktualisieren, die Änderungen für WARP 1 nachziehen und einige Features (allen voran den NTP-Sync) finalisieren. Wie kann ich die Beta testen? Die Firmware ist an diesen Post angehangen. ACHTUNG: Die Konfiguration vorheriger Firmwares ist teilweise nicht kompatibel zur Beta-Version. Netzwerkeinstellungen müssen nach dem Flashen der Beta-Firmware neu konfiguriert, NFC-Tags neu angelernt werden. Die finale Version 2.0.0 wird voraussichtlich die Konfiguration älterer Firmwares migrieren können. Das Ladetracking ist automatisch aktiv. Damit Ladungen einem Nutzer zugeordnet werden können, muss dieser unter System->Benutzerverwaltung angelegt werden und ihm muss ein NFC-Tag zugeordnet werden. Damit nur bekannte Nutzer laden dürfen, muss unter Ladecontroller die Benutzerautorisierung aktiviert werden. Andernfalls erlaubt die Wallbox (wie gehabt) das Laden ohne Benutzerzuordnung, im Ladetracker tauchen diese Ladevorgänge dann mit "unbekannter Nutzer" auf. warp2_firmware_1_9_90_6214b55e_merged.bin

Moin, Je nachdem wie oft und vor allem wie schnell start/stop aufgerufen wird wird, kann das durchaus ein Selbstschutz des Autos vor defekten Wallboxen ausgelöst wird. Wenn das der Fall ist, dann ist auch erwartet, dass das Auto dann erst wieder erlaubt zu laden, wenn man es einmal abgezogen hat. Von welchen Zeitintervallen zwischen dem Umschalten reden wir hier? Edit: Zeigt eins eurer Autos in dem Fall irgendetwas an? Rote LED am Ladeport oder irgendwelche Meldungen im Kombiinstrument?

Klar, das ist nichts geheimes. Ich poste die Firmware ins Forum, wenn sie soweit brauchbar ist.

Du brauchst dafür den Zähler + das passende Kabel zum Ladecontroller: https://www.tinkerforge.com/de/shop/warp/warp2-spare-parts/stromzaehler-sdm630.html Hier haben das schon ein paar Nutzer gemacht: Vorallem sollte hilfreich sein.

@StefanOHAN Sorry den Post hatte ich gelesen und dann vergessen zu antworten. Sowohl als auch: Die Python-Konfigurationsdateien werden vom Generator benutzt um das openHAB-Binding zu erstellen. (Die Beta-Zip-Dateien fallen aus dem Generator raus) D.h. aus Sicht von openHAB werden die vom Binding gesetzt, das Binding "weiß" die Werte aber aus der Python-Config. Hm man könnte da eventuel einen "Standard"-Alarm vordefinieren, ja. Ich habe aber noch etwas anderes rausgefunden: Die PaperUI schreibt, wenn du Things hinzufügst nach [dein-openhab-ordner]/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json. Darin kannst du die Konfigurationswerte pro Channel setzen (such mal nach brickletpiezospeakerv2). Im Gegensatz zu den "offiziellen" Konfigurationsdateien werden Änderungen da aber nicht zur Laufzeit übernommen und eventuell schreibt PaperUI das parallel, wenn du darin rumeditierst. Du könnteste aber alle Things (oder auch nur den Piezo Speaker) über die PaperUI anlegen, konfigurieren und diese Datei als dein Text-Backup verwenden. Das sollte kein Problem sein, nach einem Reset sollten höchstens Werte gelesen werden. @riro Welche Probleme hast du denn mit der MQTT-Dokumentation? Das kann man alles verbessern, aber nur wenn man weiß wo es klemmt.

Bei Apple scheint es noch komplizierter zu sein: Kartenemulation läuft nur über Apple Pay, soweit ich das ergooglen konnte. Das soll wohl verhindern, dass man an Apple vorbei Zahlungssysteme auf iOS implementieren kann. D.h. wenn du nicht gerade dein iPhone jailbreaken willst, musst du wohl warten, ob Apple mehr Zugriff auf den NFC-Chip erlaubt bzw. von der EU dazu "motiviert" wird: https://www.reuters.com/technology/exclusive-eu-antitrust-regulators-charge-apple-over-its-nfc-chip-tech-sources-2021-10-06/

Moin, Gibt es in der Tat: Voraussichtlich Ende der Woche gibt es eine Beta-Version mit Ladetracking.

Moin, Die Smart hat keine Möglichkeit den Stromverbrauch zu messen. Da müsstest du wirklich auf eine Pro umrüsten. Den Stromverbrauch pro Karte bzw. Benutzer auszulesen geht mit der kommenden Firmware-Version. Voraussichtlich wird es diese Woche noch eine Beta-Version davon geben. Du kannst dann eine CSV-Datei von der Wallbox herunterladen, die alle aufgezeichneten Ladungen (mit Startzeitpunkt, Ladedauer, geladener Energie und Benutzerzuordnung) enthält.

Moin, Das sollte eigentlich garnicht gehen: Wenn require_tag_to_start aktiviert wird, sollte auto_start deaktiviert werden und die entsprechende API blockiert. Ziehe bitte mal einen Debug-Report von der Wallbox und häng ihn hier an, vielleicht sehen wir dann mehr.

Moin Stefan, Ich habe kurz in der Config nachgesehen, die Parameternamen sollten wie folgt sein: Für Beep: defaultFrequency defaultVolume duration Für Alarm: startFrequency endFrequency stepSize stepDelay defaultVolume duration Das Problem ist aber, dass das Konfigurationen der Channels, nicht des Things sind. Du musst also vermutlich den Channel von Hand definieren, wie hier: https://v2.openhab.org/docs/configuration/things.html#defining-channels dokumentiert. Mir ist da spontan nicht klar, ob du bei eigenen Channel-Typen die Konfiguration setzen kannst. Die Channeltypen sind BrickletPiezoSpeakerV2Beep bzw BrickletPiezoSpeakerV2Alarm.

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.