rtrbt

Passiert :D Wir haben noch offen, auf der Seite deutlicher anzuzeigen, wenn man ungespeicherte Änderungen hat (und auch anzuzeigen, wenn es gespeicherte Änderungen gibt, die aber noch nicht verwendet werden weil der Neustart fehlt)

Moin,

Eigentlich sollte das genau so funktionieren. Bist du auf der aktuellen Firmware? (2.0.5) Die kannst du hier herunterladen: https://www.warp-charger.com/#firmware Falls ja, zieh bitte einen Debug-Report von der Box (unter System->Ereignis-Log) und häng ihn hier an.

Firmware: ESP32 Brick 2.0.1, ESP32 Ethernet Brick 2.0.1

• Weitere WebSocket-Verbesserungen vorgenommen
• Repariert, dass Initialized-Flag für manche Module nicht gesetzt wurde
• Möglicherweise nicht gestartete WLAN-Scans repariert
• Hinzugefügt, dass WLAN-Access-Point beim Start einen möglichst unbelegten Kanal wählt

Download: ESP32 Brick, ESP32 Ethernet Brick

17 hours ago, int5749 said:

Was müsste ich denn für den SDM630 einstellen?

Das RS485-Bricklet musst du, egal welcher Zähler das ist, auf Half-Duplex Terminated stellen. Also DIP-Switch 1,2 und 3 auf ON und 4 auf OFF.

15 hours ago, MartinJ said:

•  "Admin"-User erzeugt und diesem ein Passwort verpasst.
• Erfolglos versucht, die Box so einzustellen, daß man sich mit User/Passwort einloggen muss. Die kümmert sich da nicht drum (trotz mehrerer Versuche incl. Reboot)

Wer bis hier gelesen hat, kann mir vielleicht verraten, wie letzteres geht.... Ansonsten: schmerzfreie Umrüstung, dank dieses Forums problemarm.

Steht in der Benutzerverwaltung bei dem Nutzer unter Passwort "unverändert" oder "Anmeldung deaktiviert"? Falls ersteres solltest du ganz oben die Anmeldung aktivieren können, dann auf speichern und den Neustart durchführen, dann sollte es gehen.

Ich habe fairerweise gerade noch einen Bug gefunden mit dem man sich aus dem Webinterface aussperren kann. Neue Firmware kommt diese Woche noch.

15 hours ago, michaelst said:

esp32_brick ist ebenfalls false ...

Ich vermute, dass das nicht nur beim Ethernet Brick true sein sollte.

esp32_brick soll beim Ethernet Brick false sein, ist ein anderes Modul. Mit dem Commit von oben ist aber esp32_ethernet_brick dann true ;)

Nebenbei: Die info/modules-API zu benutzen sollte fast immer unnötig sein. Du bekommst damit nur raus, ob ein Modul initialisiert ist, aber nicht ob das, was das Modul repräsentiert (z.B. das Stromzähler-Modul) auch funktioniert. Die API ist eher für das Webinterface gedacht. Wenn du z.B. rausfinden willst, ob Stromzählerwerte lesbar sind, benutze lieber info/features

40 minutes ago, michaelst said:

War das beabsichtigt?

Nope, das ist nur bisher keinem aufgefallen. Danke für den Hinweis! Ist gefixt: https://github.com/Tinkerforge/esp32-firmware/commit/be3b55e9e4c548e69422e11411a3b5c3c01c3915

Hi,

We've received freshly produced ones yesterday. It should be marked as in stock already.

1 hour ago, Andreas_Mainz said:

Das mit der Fehlermeldung für die Konfiguration „Warp“ finde ich sogar verständlich, da in der Plattform.ini  nur das env: prepare angelegt ist.

Die anderen envs werden durch extra_configs = *.ini (Zeile 13 in der platformio.ini) importiert. Wenn du die Meldung weiterhin bekommst wenn du z.B. pio run -e warp2 im software-Ordner ausführst, dann ist noch irgendetwas kaputt.

Kurzes Update zu den "Ignore unknown configuration option"-Warnungen: Stellt sich raus das die Warnungen nicht kommen, wenn die Optionen die man einfügt mit custom_ anfangen. Das habe ich zumindest gerade aus dem platformio-core Code gekratzt: https://github.com/platformio/platformio-core/blob/c0cfbe2ce0e62f37708f16b4d5496dad009b6364/platformio/project/config.py#L158

Dementsprechend habe ich die Optionen alle umbenannt: https://github.com/Tinkerforge/esp32-firmware/commit/349be90e0f1839d7b6837aa6b6073cc52e690b58

Danke für den Anstoß ;)

Ja das ist höchst wahrscheinlich das Problem. Falls du über das Webinterface kein Firmware-Update mehr hochladen kannst, geh stattdessen mal auf http://10.0.0.1/recovery

Moin Andreas,

11 hours ago, Andreas_Mainz said:

Das platformio.ini welches auf der Ebene meines Projektes liegt, ist leer. Auf dieser Ebene existieren aber die Subdirs include und lib.

Kann es sein, dass dir diese Datei von VSCode angelegt wurde? Im Repo gibt es die nicht. Wenn du mit VSCode nicht den Repo-Ordner selbst, sondern den Software-Unterordner öffnest, dann sollte es das eigentlich verstehen.

11 hours ago, Andreas_Mainz said:

Jetzt gibt es aber eine wesentlich besser platformio.ini im Subdir "software", dort fehlen aber die lib und include dirs.

lib gibt es nicht, weil alle Abhängigkeiten in der platformio.ini (bzw. in den .ini-Dateien pro Firmware-Typ, in pio-Sprech "environment", also z.B. warp2.ini) angegeben sind. Wir liefern im Repo selber keine Bibliotheken aus.

include gibt es nicht, alle Header liegen mit in src. Das ist sicherlich Geschmackssache, aber es wird ja eine Firmware gebaut, das ganze wird keine Bibliothek bei der man ein öffentliches Interface über Header definiert.

11 hours ago, Andreas_Mainz said:

Wenn ich dann die Befehle platformio run -e prepare ausführe kommt es zu folgenden Fehlermeldungen: Error: Unknown environment names 'warp'. Valid names are 'prepare'.

Wenn ich diesen Befehl im Subdir "software" ausführe, kommt folgende Fehlermeldung;

Prinzipiell ist das korrekt, alle Befehle in software auszuführen. Die Warnungen kannst du ignorieren, pio unterstützt Custom Options (dokumentieren sie sogar!), aber trotzdem wird, sobald man die verwendet diese Warnung ausgegeben. Bekommst nach den ganzen Warnungen (und dem Teil der tatsächlich etwas tut) folgendes?

Environment    Status    Duration
-------------  --------  ------------
prepare        SUCCESS   00:00:00.507

(Zeit darf variieren, bei mir musste das gerade nichts tun)

Falls ja sollte pio run -e warp2 (im software-Verzeichnis) funktionieren.

Sowohl als auch. Der SDM72 V2-Support ist tatsächlich sehr neu. Der SDM630 misst außerdem ein paar Werte mehr. Zum Beispiel Phasenwinkel, Total-Harmonic-Distortion-Werte und ein paar Mittelwerte über ein konfigurierbares Intervall.

Kurzer Einwurf: Damit global_current gesetzt werden kann musst du die externe Steuerung nicht aktivieren. Das brauchst du nur, wenn du evse/external_current benutzt und der Ladecontroller das auch berücksichtigen soll.

Prinzipiell wäre es aber eine gute Idee auf external_current zu wechseln, global_current ist der Strom, der auch im Webinterface gesetzt werden kann. Die beiden Eingaben (also was der Nutzer möchte und was die IOBroker-Steuerung) zu trennen ist hilfreich, damit sich nicht beide Seiten permanent überschrieben.

15 hours ago, oheli said:

OK, ich hatte jetzt gerade nochmal nachgeschaut, weil ich mit dem Stopbit nicht sicher war und dann die Adresse auf 001 gestellt.

Ah sorry, die Addresseinstellung hatte ich vergessen zu erwähnen. Das ist eine gute Erklärung, warum es erst nicht geklappt hat.

15 hours ago, oheli said:

Die externe Steuerung (EVCC) ist standardmäßig blockiert; wenn ich sie freigebe zeigt es im STATUS ein paar Sekunden "Erlaubter Ladestrom: 16A durch Zuleitung, Konfiguration" und springt dann wieder zurück auf "0,00A durch externe Steuerung".
Da der Twingo noch produziert werden muss kann ich nicht ausprobieren, ob es daran liegt, dass kein EV dran hängt.

Da musst du eventuell bei EVCC nochmal fragen, aber ja das liegt vermutlich daran, dass kein EV angeschlossen ist. EVCC fragt periodisch bei der Wallbox ab, ob eins eingesteckt ist.

Moin,

Ich habe den Code etwas umgebaut, so funktioniert es bei mir:

<?php
$d1 = $_GET["d1"];

if ($d1 == 'ein'){
    $url = "http://192.168.0.140/evse/start_charging";
    senden($url, "null");
}
if ($d1 == 'aus'){
    $url = "http://192.168.0.140/evse/stop_charging";
    senden($url, "null");
}

if ($d1 == '6A'){
    $url = "http://192.168.0.140/evse/global_current_update";
    senden($url, '{"current": 6000}');
}

if ($d1 == 'strom'){
    $url = "http://192.168.0.140/evse/global_current";
    echo senden($url, '');
}

function senden($url, $payload) {
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_ENCODING, "utf-8");

    if ($payload != "") {
        // Payload ist nicht leer, wir wollen Daten zur Wallbox schicken. Benutze PUT und setze payload
        curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/json','Content-Length: ' . strlen($payload)));
        curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'PUT');
        curl_setopt($ch, CURLOPT_POSTFIELDS, $payload);
    } else {
        // Payload ist leer, wir wollen Daten von der Wallbox empfangen. Benutze GET
        curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');
    }
    
    $content = curl_exec($ch);
    $ergebnis = curl_error ($ch );
    echo $ergebnis."\r\n";
    curl_close($ch);
    return $content;
}
?>

Ich habe den Code, der die Dateien liest und schreibt erstmal weggelassen, habe ja nicht die selben Dateien bei mir wie du.

Die senden-Funktion bekommt die Daten, die sie schicken soll übergeben, wenn du da einen leeren String übergibst, kannst du stattdessen Daten von der Wallbox lesen.

Zusätzlich zu ?d1=ein und ?d1=aus habe ich eingebaut, dass du das Script mit ?d1=6A, aufrufen kannst (als Beispiel für komplexere Daten), damit wird der Ladestrom auf 6 Ampere gesetzt.

Außerdem kannst du auch ?d1=strom benutzen, als Beispiel, wie du Daten von der Wallbox lesen kannst. Damit wird der Strom wieder abgefragt. Das ist der selbe Ladestrom, den du auf dem Webinterface der Wallbox sehen kannst.

17 hours ago, michael99 said:

Auch über das Mqtt Protokoll wären ein paar Beispiele hilfreich um das ganze zu verstehen.

Für MQTT musst du erst einen Broker aufsetzen und die Verbindung auf der Wallbox konfigurieren.

Prinzipiell funktioniert die Benutzung über MQTT dann aber fast genauso wie die über HTTP. Also wenn du z.B. über HTTP den Ladestrom auf 8 Ampere setzen willst, musst du {"current": 8000} an http://192.168.0.140/evse/global_current_update schicken. Über MQTT kannst du die selben Daten, also {"current": 8000} an warp/AbC/evse/global_current_update schicken. warp/AbC ist dabei der Präfix, den du auf der MQTT-Seite der Wallbox konfigurieren kannst.

Zum Schicken per MQTT kannst du z.B. mosquitto_pub benutzen. Es gibt hier: https://www.warp-charger.com/api.html#mqtt_section noch ein paar Erklärungen zur Verwendung davon.

Also have a look at https://rpilocator.com/

Falls du Commit a6ca582a hast: Ruf mal http://123.123.123.123/info/ws auf und ziehe dann über http://123.123.123.123/event_log das Log runter (IP ersetzen nicht vergessen ;) )

Ich würde erwarten, dass du am Ende Ausgabe mit worker_active yes und queue_len > 0 bekommst. Falls ja, dann hast du die Race Condition getroffen, die ich auch gerade gefunden habe. Fix ist hier https://github.com/Tinkerforge/esp32-firmware/commit/7b28f480 Firmware 2.0.4 kommt gleich.

Prinzipiell ist es so, dass du über einen Master Brick ~ 1000 Nachrichten pro Sekunde verarbeiten kannst. D.h. wenn du z.B. nur Getter benutzt schaffst du nur 500 Abfragen pro Sekunde, weil das ja die Abfrage-Nachricht und die Antwort involviert. Deshalb sind die Callbacks effizienter.

Theoretisch kannst du jetzt also durchrechnen, wie viele Nachrichten das Continuous-Acceleration Callback bei deiner Konfiguration erzeugt, z.B. wie folgt:

• In einer Nachricht sind bei 16-Bit Messwerten 30 Werte enthalten
• D.h. bei 1000 Nachrichten pro Sekunde schaffst du es 30000 Messwerte rauszuziehen
• D.h. wenn du z.B. zwei Achsen verwendest kannst du pro Achse und Sekunde 15000 Messwerte verwenden
• -> 15000 Hz ist die maximal sinnvolle Messfrequenz, konfigurieren kannst du dann 12800 Hz

(So werden z.B. die Werte in der Tabelle hier: https://www.tinkerforge.com/de/doc/Software/Bricklets/AccelerometerV2_Bricklet_Python.html#BrickletAccelerometerV2.set_continuous_acceleration_configuration berechnet)

Wenn du jetzt das Counter-Bricklet parallel abfragen willst (sinnvollerweise auch per Callback), musst du von den verfügbaren 1000 Nachrichten in der Rechnung so viele abziehen, wie du für den Counter zur Verfügung haben willst.

Wenn du z.B. alle 10 Millisekunden den aktuellen Encoder-Wert bekommen willst, heißt dass, dass 100 Nachrichten vom Counter-Bricklet erzeugt werden. Du kannst dann also nur noch 900 Nachrichten für das Accelerometer-Bricklet verwenden, also 27000 Messwerte, bei zwei Achsen also max. 13500 Hz, d.h. die (konfigurierbaren) 12800 Hz schaffst du weiterhin.

Soweit die Theorie. In der Praxis musst du das dann natürlich ausprobieren und gegebenenfalls die Timings nicht ganz so eng wählen. Falls sich Nachrichten beim Brick aufstauen, kann es passieren, dass du dann veraltete Werte bekommst.

Noch ein paar Performance-Optimierungs-Ideen:

• Du kannst die Datenrate der Kommunikation zwischen Master und Bricklets erhöhen: https://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_Python.html#BrickMaster.set_spitfp_baudrate. Der Default sind 1,4 MHz, je nach Bricklet sind aber bis zu 2 MHz drin.
• Falls du einen Raspberry Pi und ein HAT Brick zur Hand hast, kannst du versuchen die Bricklets da anzuschließen. Der Pi kann, je nach Modell, in Summe mehr als 1000 Nachrichten pro Sekunde von allen angeschlossenen Bricklets lesen.

22 hours ago, FFrankHB said:

ist es auch möglich sie die Abrechnungstabelle per Mail schicken zu lassen?

Stand jetzt nicht. Das steht aber auf der (langen) Liste an Features die wir eventuell implementieren. Wie wir das konkret umsetzen ist aber noch unklar.

Hast du die aktuelle Firmware (2.0.3) installiert? Die brauchst du, damit der SDM72 V2 unterstützt wird. Ansonsten prüfe nochmal die Verkabelung, aus persönlicher Erfahrung weiß ich, dass man die Kabel sehr gut vertauschen kann.

Das EVSE sollte die Standardparameter des Zählers kommunizieren, also Half-Duplex, 9600 Baud, 8N1.

Ah ich glaube ich sehe das Problem: Du kompilierst noch gegen arduino-esp mit dem Stand von WARP 2.0.0: https://github.com/poohnet/esp32-firmware/blob/9c79722309dc1e29b3142aacdb87cfb2159bbce6/software/poohnet_warp.ini#L4 Wenn du da auf file://packages/arduino-esp32-warp-2.0.2 wechselst und die update_packages.py aus unserem Repo nachziehst, sollte es wieder funktionieren.

Das Problem ist, dass in arduino-esp32 eine vorkompilierte Variante des esp-idf eingebettet ist. Ich habe für die Wallbox-Firmware einen Fork angelegt, damit ich eigene Versionen vom esp-idf einbetten kann, da wir ein paar Patches fahren müssen (die liegen hier: https://github.com/Tinkerforge/esp32-firmware/tree/master/software/patches)

Nach dem 2.0.0 Release ist ein Patch dazugekommen, der sicherstellt, dass der Web-Server vom ESP-IDF meinen Code benachrichtigt wenn ein WebSocket-Close-Frame empfangen wird. Wenn der Patch fehlt, dann funktioniert die Keep-Alive-Logik nicht sauber und die Verbindungen funktionieren irgendwann nicht mehr.

Ich setze hier trotzdem mal einen Langzeittest auf, nicht dass es unabhängig davon noch einen Bug mit dem MQTT-Stromzähler gibt.

Moin,

In WARP 2.0.3 ist ein experimenteller Support für den SDM630 und den SDM72DM V2 enthalten. Experimentell deshalb, weil man die Zähler auf 3-phasigen bzw. 1-phasigen Betrieb konfigurieren muss und die Firmware das noch nicht kann. D.h. das musst du erstmal selbst von Hand machen, wie in der Anleitung des SDM630 beschreiben. D.h. zuerst (Seite 8) das Passwort eintippen damit du in die Einstellungen kommst (falls du es nicht verändert hast ist das 1000) und dann (Seite 11 unten) SYS auf 3p4 (dreiphasig mit Neutralleiter) oder 1p2 (einphasig mit Neutralleiter) konfigurieren.