Die Fehlermeldung ist nachvollziehbar weil "TEMPERATUR" der falsche Datenpunkt zum übergeben der Temperatur ist.

"SET_TEMPERATUR" wäre richtig.

Ich vermute noch immer ein falsch erstelltes oder konfiguriertes CuXD Gerät.

Wenn man z.B. ein anders Icon (z.B. Temperatursensor innen) verwendet, dann sind auch andere Datenpunkte verfügbar.

Schon merkwürdig das Du nur 2 Datenpunkte im ioBroker angezeigt bekommst, das kann schon nicht richtig sein, selbst die einfachsten CuXD Geräte haben deutlich mehr Datenpunkte.

Sollten wirklich alle Einstellungen zu 100% identisch mit den oben gezeigten sein, dann bin ich auch ratlos.

@wowbagger:

was trage ich da als Seriennummer oder Geräteidentifikation ein?

Ich habe hier bislang HM-WDS-TH-1 eingetragen.

Ist das richtig oder habe ich hier einen Denkfehler? ` Wenn ich mich nicht täusche ist es egal was dort eingetragen wird, getestet habe ich es aber nur HM-WDS-TH-1.

Den hm-rpc adapter der für CuXD eingerichtet ist stoppen, in den Einstellungen den Haken bei „Geräte einmalig synchronisieren“ setzen, speichern und den Adapter wieder starten.

Oder das Gerät komplett aus den Objekten löschen und dann wie beschrieben die Geräte nochmals synchronisieren.

Dann hast Du entweder das falsche CuXD Gerät angelegt, es muss ein Gerät (90) Wrapper Device Seriennummer CUX9002001, oder die Kanäle wurden nicht richtig synchronisiert.

Die Datenpunkte liegen im Kanal 1 des CuXD.

@ramses:

Der Gas-Melder wird per Netzteil betrieben und steht somit immer auf 100%. `
Welches Meldeverhalten der Gas-Sensor hat kann ich nicht sagen da ich keinen besitze.

Ansonsten ist "bei Aktualisierung" die richtige Wahl… Die Sensoren melden ja auch unveränderte Batteriewerte...

@ramses:

Nur um sicher zu gehen, dass das Gerät auch das Gateway erreichen kann, wäre so ein state praktisch. `
Eine „unreach“ Meldung oder ähnliches ist bei Xiaomi anscheinend nicht üblich. Auch in der App habe ich bisher keine Meldefunktion bei Nichterreichbarkeit gefunden.

Die Rauchmelder aktualisieren mind. 1x pro Stunde ihren Batteriestatus, was man wiederum gut als „alive“ Meldung weiterverarbeiten kann. Meldet sich das Gerät nicht innerhalb 1 Stunde ist etwas faul… Ich überprüfe jedes Gerät einzeln per Blockly:

viewtopic.php?f=8&t=18566#p219932

@Johan2009:

Habe ich den 'stop Timout' so richtig eingebaut?. Könntest mir vielleicht noch erklären was ein 'stop Timeout' hier bringt? `
Ja, so hatte ich das gemeint. Sobald einer der BWM "keine Bewegung" meldet wird ja bekanntlich ein Timeout gestartet. Ohne das vorherige "stop" könnte es passieren das beide BWM kurz nacheinander "keine Bewegung" melden und dadurch parallel mehrere Timeout laufen. Mit der Änderung können jetzt keine ungewollten doppelten Verzögerungen der selben Aktion laufen. In Deiner Umsetzung macht das fehlende zusätzlich "stop" keinen großen Unterschied, in komplexeren Skripten welche evtl. häufig getriggert werden kann es dadurch aber schnell zu Problemen kommen. Bei dem gesamte Thema Timeout und Intervall muß man genau aufpassen das man wie programmiert.

@Johan2009:

Last motion -> die ersten 2 Minuten passiert nichts, dann erscheint '120 seconds'

-> nach 3 Minuten erscheint '180 seconds'

-> nach 5 Minuten erscheint '300 seconds' `
Last Motion (bei mir heißt der "no motion") zeigt in Sekunden an wie lange der letzte "Bewegung erkannt" Status her ist.

Is Motion (bei mir heißt der "Occupancy") zeigt "true" = Bewegung erkannt und "false" = keine Bewegung.

Is Motion bleibt ca. 1 Minute fix auf "true" und wechselt nach dieser Zeit IMMER zumindest kurz auf "false", Bewegungen innerhalb dieser Zeit werden nicht verarbeitet.

Aus diesem Grund muss die Einschaltdauer bzw. die Ausschaltverzögerung (Timeout) der Lampe deutlich über einer Minute liegen weil der Statuswechsel des BWM sonst ungewollte Schaltungen auslösen würde.

@Johan2009:

Licht wird ausgeschalten nach 5 Minuten. Stimmen die Einstellungen im Skript dann noch? `
Grundsätzlich würde ich ja sagen. Allerdings ist das auch von Euren persönlichen Verhaltensweisen und Abläufen abhängig. Und natürlich auch davon wie gut die BWM die zu überwachenden Fläche abdecken. Der Praxistest wird es zeigen… Du kannst aber ja problemlos mit den Timeout-Zeiten variieren.

Das Skript selbst sollte jetzt genau das tun was Du erwartest.

Wurde repariert, altuell gibt es die Version 2.1.7

Hmm… um zu verhindern das doppelte „Timeout“ laufen weil beide BWM zeitnahe auslösen könntest Du direkt vor den „Timeout“ ein „stop Timeout“ einbauen.

Außerdem sind oben im „Falls“ beide „unwahr“ per oder verbunden, das würde ich auf und ändern. (Sorry, den Fehler hatte ich übersehen). Es macht nämlich Sinn das beide BWM „keine Bewegung“ melden müssen bevor der Timer fürs ausschalten anläuft.

Außerdem kannst Du mal überprüfen wie lange der BWM wartet bis der Status „Bewegung“ zurückgesetzt wird (ich meine es ist 1 Minute). Sollte die Rückstellzeit länger sein wäre es evtl. nötig den Timeout zu erhöhen.