@gregors Wenn es wichtig ist , okay, neuen Datenpunkt unter Userdata anlegen und dein Skript arbeiten lassen . Aber ich würde nen Issue anlegen . Der Entwickler ist da fix beim Ausbessern.

@meister-mopper Sieht bei mir genauso aus. Der Fehler kommt schon, wenn man den Iobroker neu installiert und danach den zigbee-Adapter. Bedenklich? Keine Ahnung. Ich hab es für mich erst mal als unbedenklich eingestuft.

@lars148 Am Besten Du suchst Dir Dein Device hier: https://www.zigbee2mqtt.io/supported-devices/ Und da sind die Datenpunkte in der Regel beschrieben.

@homoran Klasse, vielen Dank. Sachen gibts :) Werde mich mal damit etwas beschäftigen :) Gruß Thomas

@mickym Vielen Dank...schau mer mal was ich zusammenbring...😁

Ja, ich habe gerade meine Theorie zum letzen Lux Wert überprüft. Es ist tatsächlich so, das der zu letzt ermittelte Lux Wert erst bei der 2. erkannten Bewegung in dem Blockly als korrekt überprüft wird.... Warum auch immer! Das war vor dem Admin 5 Update definitiv nicht so! ;-) Meine Aqara Motion Sensoren liefen seit 1,5 Jahren ohne Probleme ;-) Jetzt weiß ich ja wo ich nachbessern kann ;-) Vielen Dank Euch allen

@skippi Ich habe mal die Parameter angesehen. Da gibt es mehrere Zeitangaben. Ob die Wartezeiten lesend und schreibend sich gegenseitig berücksichtigen, kann ich nicht sagen. Bei Node-Red gibt es weniger Zeiten zu konfigurieren. In Klammern sind meine Werte. Timeout (1000ms) für Geräte, die nicht antworten. Reconnect-Timeout (2000 ms) wenn der Bus wohl hängt. Queue Sendeverzögerung (200ms). Die Pause zwischen zwei Anfragen, egal, ob lesend oder schreibend. Die Geräte brauchen eine gewisse Zeit, um die Befehle abzuarbeiten. Z.B. Register lesen, in den Buffer kopieren und dann senden. Da ist mein Timeout von 1000ms schon recht großzügig. Die Queue Sendeverzögerung hatte ich schonmal testweise auf 1 ms runter. Das geht, wenn man als Trigger zum Senden die Antwort der vorherigen Abfrage nutzt. Seit ich 7 Nodes auf den Bus "parallel" laufen habe, habe ich mich für 200ms entschieden. Der Queue läuft so nicht voll. Sieht in Node-Red so aus: [image: 1638019856023-modbus1.png] [image: 1638019863139-modbus2.png]

@crunchip hat leider auch nichts gebracht. Am ende habe ich den Radar2 Adapter komplett gelöscht und neu installiert. Seither läuft es wieder (zumindest kommt keine Meldung mehr im Log, ob die G-Tags tatsächlich erkannt werden muss ich erst checken)

@thomas-braun OK, danke

Ja, naja read only filesystem sagt an sich alles.

@jensen kann dir da keine direkte Antwort geben verwende den Adapter nicht mehr, ich verwende sourceanalytix 15min ist nur ne ungefähre "Hochrechnungen" kenne dein script nicht, bzw woher deine Daten kommen, wann die Daten geschrieben werden, wie oft aktualisiert wird, ob deine Zeit überhaupt passt.

ich habe das ganze jetzt mal eine weile am laufen nur habe ich das problem das er scheinbar nicht die aktuellen daten zieht er zeigt immer nur die daten an die er zuletzt sich gezogen hat starte ich den script aber neu dann hat er die neuen daten woran kann das liegen ?

@rushmed genau das wollte ich, danke dir dafür :) Funktioniert 1a

@thomas-braun Ja klar. Ich habe aber durch meine fehlerhafte Einstellung als Betanutzer vile Adapter nicht im Stable Mode. Ich beobachte das jetzt und wenn ich Probleme habe, dann gehe ich auf die Stable Version. So für heute genug. Vielen Dank! Ist schon klasse was einem hier geholfen wir.

@robocop Warum aber auch so umständlich, wenn dafür gar keine Cloud und somit auch kein Skill benötigt? Je mehr man dazwischen schaltet, desto mehr Probleme können sich ergeben 😉

@sirmiker Auszüge aus dem LogFile nie als screenshot sondern als Text in </> CodeTags eingebettet. Das will so niemand lesen.

@bauzi sagte in Biobroker öffnet nicht mehr nach der Anmeldung: Adapter "benchmark" : 0.4.0 , installed 0.4.0 was machst du denn damit?

@joergh Danke Dir. Habe es jetzt mal umgestellt und werde schauen.