rtrbt

Fast übersehen, sorry: Hast du nachdem du den User zugeordnet hattest die Wallbox neugestartet? Sonst werden die NFC- und User-Konfigurationen nicht angewandt. Wie verhält es sich denn? Kannst du mit der Konfiguration garnicht mehr laden oder wartet die Wallbox nicht auf ein NFC-Tag? Schick mir mal einen Debug-Report.

Zeitsynchronisierung an, DHCP ist egal (kann parallel zu einem fest konfigurierten Server verwendet werden). Als Zeitserver kannst du 0.pool.ntp.org eintragen. Das machen wir nicht standardmäßig, weil der NTP-Pool das aus Traffic-Gründen nicht möchte. Siehe hier: https://www.ntppool.org/de/vendors.html (Wir haben uns schon darum gekümmert eine Vendor Zone zu bekommen, das scheint sich aber zu ziehen) Die MQTT-Werte wurden noch nie regelmäßig gepusht, sondern immer nur, wenn es Änderungen an den Werten gab. Dass z.B. evse/state jetzt nicht mehr sekündlich kommt liegt daran, dass die uptime in den low_level_state gewandert ist. Statt evse/energy_meter_values solltest du eher meter/values und meter/phases benutzen. meter/detailed_values wurde in meter/all_values umbenannt. Ich wollte gerade auf die API-Docs verweisen, hatte aber garkeinen Link dazu gepostet. Solange die 2.0.0-Firmwares noch nicht fertig sind, findet ihr die API-Dokumentation hier: https://www.warp-charger.com/api_beta.html Steht doch da? bzw. hier: https://www.warp-charger.com/api_beta.html#mqtt_config noch ein paar Details dazu (der interval-Eintrag).

Gut zu wissen, dann habe ich daran gedacht alle Repos zu pushen :D Noch nichts konkretes, aber das ist in Arbeit.

Ja. Geh aber gleich auf Beta 2, die gerade frisch in dem Thread erschienen ist ;)

Firmware: WARP 1.9.90 (2.0.0 Beta 1) und WARP2 1.9.91 (2.0.0 Beta 2) Details hier:

tl;dr: Ladetracking Beta 2 bzw. Beta 1 für WARP1 Was gibt's neues? Die Änderungen an der Ladecontroller-Firmware, sowie das Ladetracking stehen jetzt auch für WARP1 zur Verfügung. Außerdem gibt es neben einigen Bugfixes jetzt eine neue Konfigurationsunterseite für die Zeitsynchronisierung, Benutzer- und Zeitfilter für das Ladetracking und die Möglichkeit, Wallboxen einen Anzeigenamen zu geben. Zusätzlich haben wir die Verwendung der API vereinfacht und ein konfigurierbares Mindest-Interval für MQTT-Nachrichten eingebaut. API-Änderungen Um es zu erleichtern, die API zu verwenden, haben wir folgende Änderungen vorgenommen: Unter info/features kann eine Liste von Funktionalitäten abgefragt werden, die von der konkreten Wallbox unterstützt werden. Bei einer WARP1 Smart mit nachgerüstetem NFC wird beispielsweise ["evse","nfc"] zurückgegeben, bei einer WARP2 Pro ["evse","cp_disconnect","button_config","ethernet","meter","meter_phases","meter_all_values","nfc"] Die API akzeptiert jetzt auf Topics, die einen leeren Payload erwarten (z.B. Kommandos wie evse/start_charging), nicht nur null, sondern auch folgende JSON-Werte: "", false, 0, [] und {} Kommandos und Konfigurations-Updates, die ein JSON-Objekt mit genau einem Eintrag erwarten, können jetzt direkt mit dem Wert des Eintrags aufgerufen werden. Zum Beispiel akzeptiert evse/external_current_update nicht mehr nur {"current": 13000} sondern auch direkt 13000 Edit: Die für die neue API aktualisierte Dokumentation findet sich hier: https://www.warp-charger.com/api_beta.html Achtung: Solange 2.0.0 noch nicht final veröffentlicht ist, garantieren wir keine API-Stabilität. Große Änderungen sind aber nicht mehr zu erwarten. warp2_firmware_1_9_91_62273012_merged.bin warp_firmware_1_9_90_62272ff1_merged.bin

Hi, The embedded font is Code page 437. For the openHAB bindings I've used the following mapping to convert from UTF-16: static final List<Integer> CP437 = Arrays.asList(0x0000, 0x263A, 0x263B, 0x2665, 0x2666, 0x2663, 0x2660, 0x2022, 0x25D8, 0x25CB, 0x25D9, 0x2642, 0x2640, 0x266A, 0x266B, 0x263C, 0x25BA, 0x25C4, 0x2195, 0x203C, 0x00B6, 0x00A7, 0x25AC, 0x21A8, 0x2191, 0x2193, 0x2192, 0x2190, 0x221F, 0x2194, 0x25B2, 0x25BC, 0x0020, 0x0021, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 0x0027, 0x0028, 0x0029, 0x002A, 0x002B, 0x002C, 0x002D, 0x002E, 0x002F, 0x0030, 0x0031, 0x0032, 0x0033, 0x0034, 0x0035, 0x0036, 0x0037, 0x0038, 0x0039, 0x003A, 0x003B, 0x003C, 0x003D, 0x003E, 0x003F, 0x0040, 0x0041, 0x0042, 0x0043, 0x0044, 0x0045, 0x0046, 0x0047, 0x0048, 0x0049, 0x004A, 0x004B, 0x004C, 0x004D, 0x004E, 0x004F, 0x0050, 0x0051, 0x0052, 0x0053, 0x0054, 0x0055, 0x0056, 0x0057, 0x0058, 0x0059, 0x005A, 0x005B, 0x005C, 0x005D, 0x005E, 0x005F, 0x0060, 0x0061, 0x0062, 0x0063, 0x0064, 0x0065, 0x0066, 0x0067, 0x0068, 0x0069, 0x006A, 0x006B, 0x006C, 0x006D, 0x006E, 0x006F, 0x0070, 0x0071, 0x0072, 0x0073, 0x0074, 0x0075, 0x0076, 0x0077, 0x0078, 0x0079, 0x007A, 0x007B, 0x007C, 0x007D, 0x007E, 0x2302, 0x00C7, 0x00FC, 0x00E9, 0x00E2, 0x00E4, 0x00E0, 0x00E5, 0x00E7, 0x00EA, 0x00EB, 0x00E8, 0x00EF, 0x00EE, 0x00EC, 0x00C4, 0x00C5, 0x00C9, 0x00E6, 0x00C6, 0x00F4, 0x00F6, 0x00F2, 0x00FB, 0x00F9, 0x00FF, 0x00D6, 0x00DC, 0x00A2, 0x00A3, 0x00A5, 0x20A7, 0x0192, 0x00E1, 0x00ED, 0x00F3, 0x00FA, 0x00F1, 0x00D1, 0x00AA, 0x00BA, 0x00BF, 0x2310, 0x00AC, 0x00BD, 0x00BC, 0x00A1, 0x00AB, 0x00BB, 0x2591, 0x2592, 0x2593, 0x2502, 0x2524, 0x2561, 0x2562, 0x2556, 0x2555, 0x2563, 0x2551, 0x2557, 0x255D, 0x255C, 0x255B, 0x2510, 0x2514, 0x2534, 0x252C, 0x251C, 0x2500, 0x253C, 0x255E, 0x255F, 0x255A, 0x2554, 0x2569, 0x2566, 0x2560, 0x2550, 0x256C, 0x2567, 0x2568, 0x2564, 0x2565, 0x2559, 0x2558, 0x2552, 0x2553, 0x256B, 0x256A, 0x2518, 0x250C, 0x2588, 0x2584, 0x258C, 0x2590, 0x2580, 0x03B1, 0x00DF, 0x0393, 0x03C0, 0x03A3, 0x03C3, 0x00B5, 0x03C4, 0x03A6, 0x0398, 0x03A9, 0x03B4, 0x221E, 0x03C6, 0x03B5, 0x2229, 0x2261, 0x00B1, 0x2265, 0x2264, 0x2320, 0x2321, 0x00F7, 0x2248, 0x00B0, 0x2219, 0x00B7, 0x221A, 0x207F, 0x00B2, 0x25A0, 0x00A0); public static String utf16ToCP437(String utf16) { StringBuilder result = new StringBuilder(); utf16.codePoints().map(c -> CP437.indexOf(c)).map(i -> i == -1 ? 0xDB : i) .forEach(c -> result.append((char) c)); return result.toString(); } The lookup table should work in any language. Many programming language standard libraries can do this conversion. For example in Python: 'test ½'.encode('cp437', 'replace') will return b'test \xab' Using 'replace' will insert encoded '?' chars if a non-encodeable unicode character is encountered.

Dass die Box keinen NTP-Server bekommt ergibt Sinn, weil du statische IPs konfiguriert hast. Damit ist DHCP erstmal außen vor. das behebt sich wie gesagt, sobald wir andere Serverquellen haben. Dann ist es seltsam, dass der Zähler da noch nicht gefunden wurde. Ich versuche das hier mal nachzustellen. Was mich zwischenzeitlich auch verwundert hatte war, dass auch das Ende der ersten Ladung keinen Zählerstand hat. Das war aber nur ein Bug in der CSV-Konvertierung, den habe ich gefixt. Hat sich also schon gelohnt ;) Im Debug-Report sehe ich sehr häufige MQTT-Reconnects. Das scheint aber ein Empfangsproblem zu sein. Falls du damit Probleme hast musst du vermutlich einen Repeater aufstellen oder ein LAN-Kabel ziehen o.Ä.

Moin, Ja, hier gehört es hin. Und schonmal danke fürs Testen! Das hängt davon ab, ob deine Box die Zeitsynchronisierung hinbekommen hat. Wirf mal einen Blick in das Ereignislog. Wenn die Zeitsynchronisierung klappt sollte da eine Meldung wie diese hier stehen: 2022-02-28 16:12:50,749 NTP synchronized at 34,286! und alle Meldungen danach haben eine sinnvolle Zeit. Wenn das fehlt kann es sein, dass die Wallbox keinen NTP-Server per DHCP bekommt. Das können leider nicht alle Router. In der fertigen Version werden wir auch andere Zeitserver als die über DHCP zugeteilten benutzen. Das ist seltsam, dass die Zählerstände nicht eingetragen sind. Hast du die Ladung sehr schnell nachdem du die Beta installierst oder nachdem die Wallbox vom Strom getrennt war, gestartet? Eventuell hatte der Ladecontroller den Zähler da noch nicht gefunden. Falls du die Box seit dem nicht neugestartet hast würde mich ein Debug-Report interessieren. Das Log wird binär in den Flash der Wallbox geschrieben. Beim Trennen vom Strom bleibt es erhalten, ein Reset auf Werkszustand löscht es aber. In der fertigen Version 2.0.0 wird es noch etwas GUI dafür geben, wie viele Einträge im Log sind, Einträge zu löschen usw. So wie es aussieht hatte die Wallbox auch beim Ladeende keine Zeitsynchronisierung. Das Erheben der Zeiten funktioniert folgendermaßen: Startzeitpunkt und Entzeitpunkt kommen über die NTP-synchronisierte Zeit. Die Ladedauer ist davon komplett unabhängig, die messen wir über den Ladecontroller. Wir werden das Format auch dokumentieren. Das musst du nicht reverse engineeren. Grüße, Erik

Das wird mit der nächsten Firmware-Version kommen. Eine Beta gibt es schon hier: Der Ladetracker kann 7680 Ladungen speichern. Das reicht bei 10 Ladungen am Tag für ungefähr zwei Jahre und einen Monat.

Hi, Are you doing a full calibration, i.e. "Calibrate Zero" and "Calibrate Weight"? Also please update to the latest Brick Viewer version (2.4.21), maybe this is already fixed.

Ü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.