Es ist jetzt fast ein Jahr vergangen, da haben wir mit unseren Einsteigerguides für das Fibaro HomeCenter 2 und dem HomeCenter Light begonnen. In der Zwischenzeit hatten wir viele andere Projekte und Tutorials auf siio.de veröffentlicht. Nun geht es unter einem neuen Namen weiter...
Nachdem wir uns bereits mit den zeitgesteuerten Szenen und den Triggern einer Szene auseinander gesetzt haben, schauen wir uns im dritten Teil der Serie mal die Trigger etwas genauer an. Die Trigger starten beim HC2 oder beim HCL nicht nur die Szenen, sondern es werden auch Informationen mitgeliefert, um welchen Auslöser es sich genau handelt.
3 verschiedene Trigger-Returns
Wenn eine Szene durch eine Änderung des Zustandes eines Moduls oder durch das manuelle Ausführen gestartet wird, dann wird immer auch ein Array mit Informationen zurückgegeben. Grundsätzlich müssen hier drei verschiedene Arten unterschieden werden:
- ‘property’ – Für Trigger, basierend auf der Statusänderung eines Moduls
- ‘global’ – Für Trigger, basierend auf der Änderung einer Variable
- ‘other’ – andere Möglichkeiten (manuelles Ausführen beim Klick auf 'Start' oder den Start der Szene durch eine andere Szene)
Dies ist soweit auch von Fibaro auf deren Developer-Plattform (Hier finden sich viele LUA-Befehle, welche relativ unbekannt sind -> Anmelden lohnt sich) dokumentiert und kann dort eingesehen werden. Es gibt allerdings Ausnahmen, auf die wir im weiteren Verlauf des Artikels noch genauer eingehen werden.
Szene zum Auswerten
In einer Szene kann man sich diese Informationen, welche zurückgeliefert werden, zunutze machen. Wir zeigen euch mal an einem kleinen Beispiel, was wir genau meinen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
--[[ %% properties XX value XX value %% globals XXvar --]] local trigger = fibaro:getSourceTrigger() if (trigger['type'] == 'property') then fibaro:debug('Szene wurde durch Modul getriggert') elseif (trigger['type'] == 'global') then fibaro:debug('Szene wurde durch Variable getriggert') elseif (trigger['type'] == 'other') then fibaro:debug('Anderer Trigger') end |
Mit dieser Szene könnt Ihr jetzt auslesen, wodurch die Szene getriggert wurde und dementsprechend die Debug-Ausgaben steuern. Wie bei jedem anderen Skript auch müsst Ihr natürlich im Header die IDs der Module anpassen und eure Variable eintragen. Die Variable ist optional, das Skript funktioniert natürlich auch ohne globale Variable. (In eigener Sache: In einer der nächsten Folge erläutern wir Globale Variablen) Gehen wir mal die wichtigen, einzelnen Teile des Skriptes durch:
1 |
local trigger = fibaro:getSourceTrigger() |
Hiermit wird das zurückgegebene Array, welches die benötigten Informationen enthält, in einer lokalen Variablen gespeichert, um es dann im weiteren Verlauf des Skriptes weiter auswerten zu können. Dies passiert dann im folgenden Teil:
1 2 3 4 5 6 7 |
if (trigger['type'] == 'property') then fibaro:debug('Szene wurde durch Modul getriggert') elseif (trigger['type'] == 'global') then fibaro:debug('Szene wurde durch Variable getriggert') elseif (trigger['type'] == 'other') then fibaro:debug('Anderer Trigger') end |
Wie Ihr sehen könnt, wird hier in einer if/elseif-Abfrage der Inhalt von
1 |
trigger['type'] |
mit den oben genannten Punkten verglichen und anhand des Inhaltes entschieden, in welche if/elseif-Kombination das Skript läuft und dann die unterschiedlichen Debug-Texte ausgeführt werden. So könnt Ihr also sehen, durch was das Skript gestartet wurde und damit unterschiedliche Aktionen ausführen.
Weitere Informationen
Es werden je Return auch weitere Informationen zurückgegeben. Anbei findet Ihr eine kleine Übersicht, welche Infos von der API zurückgegeben werden. Diese findet Ihr auch unter der bereits erwähnten Developer-Plattform:
Anhand dieser Tabelle könnt Ihr erkennen, dass bei dem Trigger-Type 'other' keine weiteren Informationen zurückgegeben werden. Wenn Ihr also die Szene manuell startet oder durch eine andere Szene starten lasst, dann könnt Ihr nur den Wert other auswerten. Weitere Informationen zu diesem Punkt gibt es nicht.
Dies sieht allerdings bei den Typen 'global' und 'property' anders aus. Bei den globalen Variablen wird der Name der triggernden Variablen zurück gegeben. Diese könnt Ihr euch dann ausgeben lassen:
1 |
fibaro:debug(trigger['name']) |
Wie Ihr an dem Beispiel erkennt, muss in die eckige Klammer immer der Name des Feldes im Array eingetragen werden, damit der Inhalt ausgegeben wird. So ist es dann natürlich auch bei 'property'. Um hier die ID des Modules oder die ausführende Eigenschaft (z.B. power siehe HIER) auszugeben. Dies würde dann so aussehen:
1 |
fibaro:debug(trigger['deviceID']) ODER fibaro:debug(trigger['propertyName']) |
Die automatische Ermittlung des Triggers haben wir bereits in einigen Szenen umgesetzt. Als Beispiel können wir hier das Rauchmelder-Skript anführen, dort wird anhand der ID der betroffene Sensor und der betroffene Raum ermittelt.
Sonderfälle
Beim HomeCenter gibt es zwei Sonderfälle beim Auswerten. Dies sind zum Einen die %%autostart-Szenen und zum Anderen die Szenen, welche durch die Z-Wave-Klasse 'centralSceneEvent' ausgeführt werden. Ihr findet ein Beispiel für das Auswerten des Triggers in dem folgenden Artikel Kleine LUA Scripte Teil 9: Fibaro Button via LUA nutzen.
Bei den zeitgesteuerten Szenen steht in der Response von der API als Wert immer 'autostart'. Dadurch können dann Skripte realisiert werden, welche zu bestimmten Zeiten Aktionen ausführen.
1 2 3 |
if (trigger["type"] == "autostart") then startTimeScene() end |
Wir hoffen, dass wir euch die Funktionen ein wenig näher bringen konnten. Leider gibt es derzeit keine Möglichkeit die Trigger mit dem Fibaro HomeCenter Light auszulesen. Wie bereits erwähnt werden wir bald einen Guide über globale Variablen folgen lassen. Solltet Ihr Wünsche haben, welche Einsteiger-Themen von uns mal durchleuchtet werden sollen, dann könnt Ihr gerne einen Kommentar hinterlassen.
Alle Einsteigerguides findet Ihr hier:
- Zeitgesteuerte Szenen
- Trigger einer Szene
- Trigger auswerten (Dieser Artikel)
Welches Gerät ist bei Multi Channel Devices das auslösende Gerät? Welche ID muss ich für die "sceneActivation" verwenden, welche ID liefert "trigger['deviceID']"?
Ein Universalsensor z.B. hat vier Geräte: Master X mit ID 10, erster Slave X.0 mit ID 11, zweiter Slave X.1 mit ID 12 (der Eingang IN1) und dritter Slave X.2 mit ID 13 (der Eingang IN2). Eine Szene mit "12 sceneActivation" scheint auch auszulösen, wenn sich das Potential am Eingang IN2 ändert, obwohl 12 die ID des Eingangs IN1 ist. Hier suche ich den Fehler.
Ebenso beim Dimmer 2: Dessen zweiter Eingang/Taste S2 löst ebenfalls Szenen aus mit sceneActivation auf der ID des ersten Eingangs/Taste S1.
Welche Slaves lösen welche "ID sceneActivation" aus, und wie finde ich heraus, welcher Eingang denn tatsächlich ausgelöst hat? Liefert "trigger['deviceID']" den wahren Auslöser, oder auch nur die ID der sceneActivation?
Leider hab ich mich nie so wirklich mit der sceneActivation-Klasse auseinander gesetzt. CentralSceneEvent find ich da deutlich smarter.
Vielleicht weiß Chris mehr zu diesem Thema, werde ich mal fragen.
Gruß
Wenn die SceneActivation wie auch die Value derselben ID getriggert wird, gibts da eine Möglichkeit diese im Script auszuwerten? Denn der Type ist bei beiden "property"
--[[
%% properties
146 SceneActivation
146 value
%% events
%% globals
--]]
Hi,
bei welchem Modul soll das so sein? Ich kann mir nicht vorstellen, dass 2 unterschiedliche Funktionen auf eine ID gelegt werden.
Gruß
Für einen Dimmer2
SceneActivation löst nur aus wenn eine Taste gedrückt wird. Wenn aber das Licht per App, andere Szene oder manuell eingeschaltet löst nur der Value aus. Nun wär es hilfreich zu wissen ob nun das Licht per Schalter oder per Software eingeschaltet wurde.
Das sollten aber unterschiedliche IDs sein. Auslesen, was jetzt genau getriggert hat, funktioniert nicht.