ioBroker Tutorial-Reihe - Steuere vs. Aktualisiere (Bestätigt?!)

Mit ** gekennzeichnete Links auf dieser Seite sind Affiliatelinks.

ioBroker Tutorial-Reihe - Steuere vs. Aktualisiere (Bestätigt?!)
ioBroker Tutorial-Reihe - Steuere vs. Aktualisiere (Bestätigt?!)
  • Matthias Kleine
  • 02.02.2021
  • Grundlagen
  • Blockly

Nach einer Umfrage auf Facebook habe ich festgestellt, dass viele den Unterschied der Blockly-Bausteine “steuere …” und “aktualisiere …” nicht kennen. Das liegt nicht zuletzt daran, dass die Arbeitsweise von ioBroker-Adaptern nicht bekannt ist. Und genau diese Wissenslücke möchte ich mit dem folgenden Video schließen! Du lernst also, was es mit dem “Bestätigt”-Flag von Datenpunkten auf sich hat und wie man dieses auch in Triggern abfragen kann. Insgesamt ein scheinbar komplexes Thema, welches unterm Strich aber wirklich einfach zu verstehen ist, wenn man sich kurz damit beschäftigt hat.

Video

ioBroker-Kurs

Erklärung

Wie Du im Video gesehen hast, gibt es also für jeden Datenpunkt (Objekt) ein Bestätigt-Flag.

  • steuere schreibt den neuen Wert mit Bestätigt: false
  • aktualisiere schreibt den neuen Wert mit Bestätigt: true

ioBroker Steuere Aktualisiere Unterschied

»ioBroker Steuere Aktualisiere Unterschied«

Wenn man nun z.B. einen Wert im Admin über die Objekt-Ansicht ändert, wird immer mit Bestätigt: false gearbeitet (also mit “steuere”). Warum? Weil Adapter nur auf Befehle (“steuere”) reagieren, welche noch nicht bestätigt sind. Hat alles geklappt, wird danach der gleiche Datenpunkt (in der Regel) noch einmal vom Adapter bestätigt. Das passiert, indem der Datenpunkt ein weiteres Mal geschrieben wird, nur eben vom Adapter selbst (“aktualisiere”).

Merke:

  • steuere = “Befehl” = Bestätigt: false
  • aktualisiere = “Update” = Bestätigt: true

Man kann im Admin auch eine Änderung vornehmen, welche bereits bestätigt ist (also das Verhalten vom “aktualisiere-Baustein” nachbilden). Dafür ist (nicht ohne Grund) der Expertenmodus notwendig.

Der interne Workflow aller Adapter

Der Workflow sieht folgendes vor:

  1. Ein neuer Workflow wird angestoßen, indem ein Datenpunkt mit Bestätigt = false (steuere) geschrieben wird
  2. Diese Änderung registriert dann ein Adapter, welcher diesen Datenpunkt “überwacht” (subscribe)
  3. Der Adapter macht daraufhin seine Arbeit
  4. und schreibt danach den Datenpunkt erneut(!!!) / bestätigt den Wert mit einem Update Bestätigt: true

In diesem Vorgang wird der gleiche Datenpunkt also zwei Mal geschrieben (Punkt 1 und Punkt 4).

Das Problem

Würde nun durch ein Script direkt ein bestätigter Wert geschrieben, reagiert da kein Adapter drauf. Der Grund dafür ist, dass nur unbstätigte Änderungen verarbeitet werden. Würde ein Adapter auch auf bestätigte Änderungen reagieren, würde ein Endlosschleife erzeugt!

Trigger

Was bedeutet das für Dich? Du musst in eigenen Triggern darauf achten, dass dein Logik nicht auch zwei Mal ausgeführt wird. In der Regel sichert man sich dadurch ab, dass man mit “wurde geändert” arbeitet. So führt allerdings bereits Punkt 1 aus dem Workflow (siehe oben) dazu, dass der Trigger ausgelöst wird. Was ist das Problem? Man kann sich nicht sicher sein, ob die Logik vom (eventuell vorhandenen) Adpater auch wirklich ausgeführt wurde.

Wenn man also wirklich sicherstellen möchte, dass ein neuer Wert auch wirklich vom jeweiligen Adapter verarbeitet wurde, sollte man in eigenen Triggern nur auf bestätigte Datenpunkte reagieren.

Achtung: Das ändert auch die Reihenfolge! Reagiert man auf die Änderung, wird an Punkt 1 im Workflow (siehe oben) die eigene Logik ausgeführt. Reagiert man auf bestätigte Änderungen durch den Adapter, wird der Trigger erst nach der Logik innerhalb des Adapters ausgeführt (Punkt 4).

Die zweite Möglichkeit hat also den Vorteil, dass man sich auf diesem Weg sicher sein kann, dass der “steuere-Befehl” auch wirklich erfolgreich verarbeitet wurde.

ioBroker Trigger - Update / Befehl

»ioBroker Trigger - Update / Befehl«

ioBroker Trigger - Neue Beschriftung (gleiche Bedeutung)

»ioBroker Trigger - Neue Beschriftung (gleiche Bedeutung)«

Da allerdings der gleiche Wert zwei Mal geschrieben wird, muss man darauf achten, dass man keine Kombination wählt, welche nie eintritt. “wurde geändert” zusammen mit “Update” (also bestätigte Änderung) wird in den meisten Fällen nie ausgelöst. Denn dann müsste sich der bestätigte Wert (aktualisiere) vom ursprünglichen Wert (steuere) unterscheiden. Und das ist in 99% der Fälle wohl nicht so.

Denke einfach immer an den oben gezeigten Workflow!

Eigene Datenpunkte

Arbeitet man nun mit eigenen Datenpunkten, kann man also entweder direkt “aktualisiere” verwenden (wenn es sich um den finalen Wert handelt) - denn dann übwacht ja schließlich kein Adapter die Wert-Änderungen.

Möchte man aber einen Trigger auf eigene Datenpunkte erstellen (z.B. in 0_userdata), würde ich auch dort mit dem oben genannten Workflow arbeiten. Also auf “steuere-Befehle” reagieren und dann den Wert mit “aktualisiere” innerhalb des Triggers bestätigen. Das sieht dann wie folgt aus:

ioBroker Steuere Aktualisiere Workflow

»ioBroker Steuere Aktualisiere Workflow«

So geht man auch mit eigenen Datenpunkten genau den Weg, wie er vom ioBroker vorgesehen ist und hat genau das gleiche Verhalten wie bei allen anderen Adaptern.

Das write Flag

Jedes Objekt vom Typ state hat die Eigenschaften common.read und common.write. Damit Du als Benutzer weißt, welche Datenpunkte überhaupt angesteuert werden können, wird dies auf dem Objekt definiert. Generell kann mit einem aktualisiere-Baustein natürlich jeder Datenpunkt geschrieben werden - aber das ist natürlich keine gute Idee. Als Benutzer darf man nur Datenpunkte ansteuern, welche write: true gesetzt haben. Alle anderen sollten nur gelesen werden!

Und weil ich öfter die Frage bekommen habe: Natürlich darf man nicht einfach das write-Flag auf einem beliebigen Objekt setzen. Ich nehme dafür als Beispiel ganz gerne die Außentemperatur. Nur weil ich Datenpunkt schreibbar mache, kann ich dadurch ja noch längst nicht das Wetter bestimmen.

Fazit

Das Prizip ist also eigentlich ganz einfach. Leider wurde bei der Deutschen Übersetzung im Admin häufig ein anderes Wort genutzt. Das hat sich im Jahr 2023 deutlich gebessert!

bestätigt == anerkannt == acknowledged == ack

Wenn man das Thema verinnerlich hat, kann man viel genauer mit eigenen Triggern und Datenpunkten arbeiten. Das Thema ist für mich eines der wichtigsten bei der Arbeit mit ioBroker.

Solltest Du es noch nicht verstanden haben, schau auf jeden Fall nochmal das Video und lies diesen Beitrag erneut.

Zusammenfassung

  • Verwende steuere immer dann, wenn ein Adapter noch etwas im Anschluss tun soll oder Du eine Reaktion erwartest.
  • Steuere nur Datenpunkte an, welche das write-Flag gesetzt haben.
  • Nutze aktualisiere nur bei selbst erstellten Datenpunkten unter 0_userdata
  • Bearbeite keine Objekte, welche Du nicht selbst erstellt hast!
Du willst mehr?

Smart-Home-Trainings von A-Z

Steig noch tiefer in die Themen ein und meistere Deine Projekte! Über 13.000 Teilnehmer konnten sich schon von der Qualität der Online-Kurse überzeugen.

ioBroker-Master-Kurs

ioBroker-Master-Kurs

Mehr Infos
Hausbau-Kurs

Hausbau mit KNX

Mehr Infos
Lox-Kurs

Lox-Kurs

Mehr Infos
Node-RED-Master-Kurs

Node-RED-Master-Kurs

Mehr Infos