rtrbt

The bricklet returns its UID in the enumerate response. For the enumerate request you don't have to set a UID, but use 0 (or "1" if base58-encoded) This is basically the "normal" enumerate: https://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html#broadcast-functions but with another function ID (252).

Moin, Modbus-TCP können die Wallboxen derzeit nicht. Ich habe noch auf meiner Liste, mir anzusehen ob und wenn ja wie man Support dafür hinzufügt. Der SolarLog-Zähler wird aber von EVCC unterstützt: https://docs.evcc.io/docs/devices/meters/#solarlog D.h. du könntest dir eine EVCC-Instanz aufsetzen, die den Zähler ausliest und die Wallboxen steuert.

Hi, You don't have to implement the SPI protocol yourself if you don't want to. Instead you can use the C/C++ bindings for microcontrollers. Those bindings implement the SPI-TFP protocol for you, so that you can use more or less the same API as with the normal C bindings. See for example here for the Load Cell Bricklet API. To use the bindings you have to use a Hardware Abstraction Layer (HAL) for your Arduino, but currently there is no generic one available. (We've released the bindings just some weeks ago). You basically have two options here: Patch the Arduino ESP32 Brick HAL or try to use the prototype Arduino HAL, however I'm not sure if this one works right now. If you really want to implement the SPI protocol yourself, you have to take a look at our implementations, as there currently is no documentation of the SPI protocol. The implementation used in the microcontroller bindings is here: https://github.com/Tinkerforge/generators/tree/master/uc (have a look at spitfp.h/.c) As a very short overview (so you know what to grep for ;) ): The SPI protocol (called SPITFP) wraps the TFP protocol that is also used over TCP. See here for the TFP protocol: https://www.tinkerforge.com/en/doc/Low_Level_Protocols/TCPIP.html and for example the Load Cell 2.0 packets: https://www.tinkerforge.com/en/doc/Software/Bricklets/LoadCellV2_Bricklet_TCPIP.html SPITFP consists of two header bytes, a wrapped TFP packet (if it is not only an ACK) and one footer byte: The packet length: 3 bytes for an acknowledgement or 11 to 83 bytes for a payload packet The sequence number of this packet (4 bit) and the sequence number that is acknowledged with this packet (also 4 bit) (Footer) A checksum over all packet bytes except this one. This is a Pearson hash . See here for an implementation Only one packet in flight is allowed in each direction. A bricklet will resend the last packet if you don't acknowledge it. Bricklets expect that you send a CoMCU-enumerate as first packet. If you don't, the bricklet will send a response for the enumerate by itself.

Ja, das ist egal, die Firmware fragt am Anfang an allen Ports ab, was für ein Bricklet jeweils angeschlossen ist.

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 More WebSocket fixes Fix initialized flag not being set for some modules Fix WiFi scan sometimes not starting Select unoccupied channel when starting WiFi AP Download: ESP32 Brick, ESP32 Ethernet Brick

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

Firmware: WARP 2.0.5 und WARP2 2.0.5 Weitere WebSocket-Verbesserungen vorgenommen Taster-Stop-Logik verbessert (durch Update auf Ladecontroller-Firmware 2.1.2 (WARP) bzw. 2.1.4 (WARP2)) Repariert, dass Initialized-Flag für manche Module nicht gesetzt wurde Löschen veralteter Tag-IDs in nfc/last_seen repariert Sichergestellt, das Webinteface-Anmeldung nie aktiviert werden kann, falls keine Benutzer mit Passwort konfiguriert sind Möglicherweise nicht gestartete WLAN-Scans repariert Hinzugefügt, dass WLAN-Access-Point beim Start einen möglichst unbelegten Kanal wählt LED-Blinken entfernt, falls Ladevorgang wegen einer nicht NFC-bezogenen Ladefreigabe nicht gestartet werden kann (WARP1) Verschiebung des Stromzählergraphen repariert Download: WARP 2.0.5 bzw. WARP2 2.0.5

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

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

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.

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

Ah sorry, die Addresseinstellung hatte ich vergessen zu erwähnen. Das ist eine gute Erklärung, warum es erst nicht geklappt hat. 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. 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/

Firmware: WARP 2.0.4 und WARP2 2.0.4 Unbenutzbares Webinterface durch WebSocket-Race-Condition repariert Download: WARP 2.0.4 bzw. WARP2 2.0.4

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.