@peterredl "aktualisiere" nutze ich. Wäre "steuere" das richtige ?

Update: ich habs ausprobiert und tatsächlich: damit funktioniert es. Danke, dass ihr auch meine DAU Fragen beantwortet und mir dadurch beim Dazulernen helft ! Also merke: "steuere" macht auch was und "aktualisiere" nicht.

@peterredl hab ich selbsredend schon überprüft und wenn das der Fehler wäre, sollte doch auch die Änderung über den Objektbaum nicht im Wechselrichter ankommen, oder?
Das ist ja bei mir das seltsame: manuell im Objektbaum eingepflegte Werte werden übertragen, über blockly eingepflegte nicht ...

@lars72 Bei mir gibt es ein ähnliches Thema: Wenn ich das Objekt "limit_nonpersistent_relative" im Objektbaum anpasse (und mit Eingabetaste bestätige), wird das Limit von der DTU relativ zeitnah an den WR gesendet und dort umgesetzt. Wenn ich allerdings per Blockly das Objekt anpasse (was einwandfrei funktioniert), passiert im WR gar nichts... als wenn die "Eingabetaste" im Objektbaum das "Senden" erste auslöst und das bei der Anpassung über Blockly nicht passiert. Siehe hier:

Hat jemand eine Idee, ob ich etwas übersehe, dass die Objekt-Anpassung per Blockly nicht an den WR übertragen wird, die "manuelle" Änderung im Objektbaum aber schon?

@idlebit @crunchip , danke euch für die Antworten und insb. die Aufklärung zu der Echtzeitübertragung per Websocket. 10s ist ja wirklich eigentlich easy. MQTT hab ich ganz aus, das brauch ich mit dem openDTU Adapter ja gar nicht (da geht ja alles über Web API).

Stromversorgung sollte eigentlich passen, ich werde mir aber nochmal ein stärkeres Micro-USB Kabel mit garantierter Stromstärke bis 2,4A holen. Das Netzteil selbst liefert das, aber evtl das Kabel nicht. Ist ein Versuch wert. Und ich berichte auch gern, ob was bei dem Festsetzen des WLAN Kanals bei der Fritzbox rausgekommen ist. Außerdem lasse ich mal die Konsole der openDTU mitlaufen, um evtl den Fehler auf "frischer Tat zu ertappen". Danke euch auf jeden Fall!

@indie Leider war ich zu voreilig. Das Problem tritt weiterhin auf. Problem tritt immer im Zusammenhang mit dem Event auf, dass fast sekündlich neue Websockets eröffnet werden. Was das auslösende Moment ist, weiß ich nicht. Ich google mir aktuell mal was zusammen (auch im openDTU Projekt selbst, natürlich). Ich versuche mal, den Wifi Kanal 2.4GHz bei meiner Fritzbox fest zu setzen, da wurden immer mal wieder Wifi Probleme mit berichtet (hab ich eigentlich nicht, könnte aber vllt die x-fache Neueröffnung von WebSockets auslösen?!?).

Eine Frage wäre, in welchem Intervall vom openDTU Adapter die Web API der openDTU aufgerufen wird? Kann man das konfigurieren?

Kurzes Update: nachdem ich in der dtu das refresh interval von 2s auf 5s gesetzt habe und jeder String einen Namen bekommen hat, tritt das Problem seit 30h schon nicht mehr auf. Ich gehe also davon aus, dass die dtu tatsächlich mit der Last überfordert war und der Fehler im Adapter durch fehlerhafte Übertragung von der dtu ausgelöst wurde. Ich entschuldige mich für die falsche Verdächtigung des Adapters und habe auch auf GitHub das issue geschlossen :-). Danke für die Hilfe!

@thomas-braun okay, ich mache alles, was helfen kann, auch wenn ich nicht sehe, wie das helfen kann...(klar, es steht jetzt etwas an einer Stelle, wo vorher nichts stand, das war aber btw vor dem Firmware Update inkl. Reflash anders, da hatte ich jeweils einen Namen für die Strings). Mal sehen ...evtl kann man aus dem langen logeintrag ja rauslesen, wo genau der Fehler Auftritt, aber mir fehlt da der konkrete Einblick in den Code (bzw die Fähigkeit dazu)

@thomas-braun eigentlich ja, "Garagendach" und "Balkon". Hier sollte eigentlich das Problem nicht liegen ... Ah ja und die panele (also strings der Wechselrichter) habe ich nicht umbenannt (also weiterhin "string 1" und "2").

Hallo zusammen, ich hab ein Problem mit dem Adapter und sowohl die neueste Firmware von opendtu geflasht, als auch das passende node.js drauf und die aktuelle Adapter Installation drauf. Das Problem trat auch mit einer älteren Firmware Version von opendtu schon auf, ich hatte gehofft, dass es mit der neuen Version gelöst wäre, aber nach ca 18 Stunden Betrieb ging das ganze schon wieder los: nach einer Weile ganz normalem Betriebs wird im Adapter eine unhandled exception geworfen und der Adapter Gerät dann in eine "restart loop", sodass iobroker den Adapter killt, nachdem 4-5 Mal in 1,5 min neu gestartet wurde.
Das logfile zu dem Fehler im Adapter in iobroker ist folgendes (nur eine "Fehlerinstanz", diese tritt dann mehrfach nacheinander auf). 2 hinweise noch zur Fehler Eingrenzung:

1. Mqtt ist in opendtu aus, zufriff läuft über http.
2. Im Kontext des Fehlers verändern sich die Namen der 2 verbundenen wechselrichter in der Webansicht und enthalten plötzlich seltsame Sonderzeichen oder werden komplett durch solche ersetzt.

Ein Ansatz könnte sein, dass es einen overflow beim opendtu gibt, der zb durch nicht geschlossene web connections Auftritt und durch den Adapter ausgelöst wird?

Würde mich sehr freuen, wenn ich einen Tipp von euch bekomme oder mit der Fehlerbeschreibung die Weiterentwicklung des Adapters unterstützten kann
Vielen Dank!

Edit: hab es auch auf GitHub als issue geöffnet

2023-04-18 12:56:52.639 error The id is empty! Please provide a valid id.

opendtu.0
2023-04-18 12:56:52.638 error Error: The id is empty! Please provide a valid id. at Utils.validateId (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/lib/adapter/utils.js:114:19) at Opendtu.extendObject (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/lib/adapter/adapter.js:1935:23) at /opt/iobroker/node_modules/@iobroker/js-controller-common/lib/common/tools.js:2126:16 at new Promise (<anonymous>) at Opendtu.extendObjectAsync (/opt/iobroker/node_modules/@iobroker/js-controller-common/lib/common/tools.js:2125:16) at DataController.processInverterData (/opt/iobroker/node_modules/iobroker.opendtu/lib/dataController.js:23:36) at Opendtu.processMessage (/opt/iobroker/node_modules/iobroker.opendtu/main.js:163:28) at WebSocket.<anonymous> (/opt/iobroker/node_modules/iobroker.opendtu/main.js:142:18) at WebSocket.emit (node:events:525:35) at Receiver.receiverOnMessage (/opt/iobroker/node_modules/ws/lib/websocket.js:1184:20)

opendtu.0
2023-04-18 12:56:52.634 error unhandled promise rejection: The id is empty! Please provide a valid id.

opendtu.0
2023-04-18 12:56:52.616 error Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().