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

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

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

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

Der Workflow sieht also folgendes vor:

1. Ein neuer Workflow wird angestoßen, indem ein Datenpunkt mit Bestätigt = false 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).

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.

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:

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.

Fazit

Das Prizip ist also eigentlich ganz einfach. Leider wird bei der Deutschen Übersetzung im Admin häufig ein anderes Wort genutzt. Mal schauen ob ich mit das mal mit einem Pull-Request in Zukunft gerade ziehe.

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.