ioBroker Blockly Beispiele

Hast du dich schon einmal gefragt, wie andere ihr Smart Home aufbauen? Wie wohl die Skripte aussehen mögen und was wer so alles gezaubert hat? Ich möchte dir heute ein paar ioBroker Blockly Beispiele in diesem Artikel zeigen, um dir einen noch besseren Eindruck aus meinem Smart Home zu liefern.

Dabei habe ich mir drei unterschiedliche ioBroker Blockly Beispiele rausgesucht, die in ihrer Komplexität sehr verschieden sind. Solltest du hierzu grundlegende Fragen haben, dann musst du unbedingt einen Blick auf meinen Artikel werfen, in dem ich dir ein paar ganz elementare Informationen zu diesem Thema gegeben habe. Den Link dazu findest du am Ende der Einleitung.

Grundsätzlich ist von meiner Seite zu erwähnen, dass du jedes Skript (und damit auch jedes Blockly-Skript) so sparsam wie möglich aufbauen solltest. Und dennoch sollte eine gewisse Übersichtlichkeit nicht verloren gehen. Nur weil man an manchen Stellen noch kürzen kann, muss das nicht zwangsläufig immer so hilfreich oder gut sein.

Allerdings darf man natürlich auch nicht jedes Skript enorm aufblähen. Gerade um schnell einen Überblick über die Funktion zu haben hilft es enorm, wenn das Skript auf das Notwendige reduziert ist. Dann solltest du in der Regel auch ganz ohne Kommentare und Ergänzungen auskommen.

Ich möchte außerdem ganz gerne noch anmerken, dass es in den nachfolgenden Skripten durchaus noch Potenzial für eine Verschlankung geben wird. Im Moment überarbeite ich verschiedene Skripte Stück für Stück.

Wenn du mehr zu Blockly erfahren willst, schau dir meinen Artikel genauer an oder besuche die offizielle Website.

Beispiel 1: Präsenzmelder steuert das Licht

Eine der wohl am häufigsten genutzten Automationen in meinem Smart Home ist die automatische Lichtsteuerung. Im nachfolgenden Skript sehen wir, dass das Gäste WC durch einen Präsenzmelder automatisch beleuchtet wird, sofern ein gewisser Schwellwert unterschritten wurde. Doch schauen wir mal Stück für Stück auf das Skript.

In diesem Fall ist der Trigger der geänderte Zustand des Präsenzmelders. Hierbei unterscheide ich zwischen den beiden verschiedenen Zuständen Bewegung erkannt und Keine Bewegung erkannt. Der entsprechende Wert wird mir beim Ausführen des Skripts direkt mitgegeben. Du findest ihn in der Variable Wert, die sich auf den geänderten Zustand des Datenpunkts bezieht, der die Automation auslöst. In diesem Fall der Präsenzmelder.

Sollte eine Bewegung erkannt werden, werden weitere Dinge geprüft. Ist etwa die Automatik aktiviert? Ist das Licht gerade in seinem Zustand blockiert? Und ganz wichtig, welche Helligkeit gerade im Raum herrscht. Nur wenn die Helligkeit unter 10 ist, wird an dieser Stelle weitergemacht und das Licht wird eingeschaltet. So verhindere ich zum Beispiel, dass das Licht am Tag eingeschaltet wird. Außer es ist natürlich so dunkel, dass Licht gebraucht wird. Zum Beispiel an einem stark bewölkten Tag oder wenn der Rollladen noch unten ist.

Wird hingegen gemeldet, dass es keine Bewegung mehr gibt, dann wird das Licht ausgeschaltet. Allerdings auch nur wieder dann, wenn die Automatik aktiv ist und das Licht nicht blockiert ist.

Der Sinn hinter dem Blockieren der Lichter ist, dass ich sie in ihrem aktuellen Zustand festsetzen kann. Zum Beispiel beim Putzen, wenn ich mal kurz den Raum verlasse, muss nicht jedes Mal das Licht ausgeschaltet werden. Zumindest dann nicht, wenn ich sowieso in den nächsten 1-2 Minuten wieder im Raum sein werde. Alles andere würde auch der Lampe vermutlich auf Dauer nicht so gut tun.

Homematic IP Smart Home Präsenzmelder – innen, schaltet Licht bei Bewegung,...*

• Für den Betrieb ist der Homematic IP Access Point in Verbindung mit der App (Cloud-Service), die...
• Erkennt zuverlässig die Anwesenheit von Personen durch die Erfassung feinster Bewegungen (z. B....
• Der integrierte Dämmerungssensor erfasst zusätzlich die Umgebungshelligkeit für Aktionen, die...

Bei ELV kaufen * Jetzt shoppen * Preis inkl. MwSt., zzgl. Versandkosten

Zuletzt aktualisiert 2024-12-21 / (*) Affiliate Links / (**) Affiliate Links, Preis kann abweichen (andere Plattform) / Bilder von der Amazon Product Advertising API / Der angegebene Preis kann seit der letzten Aktualisierung gestiegen sein.

Mögliche Verbesserungen

An diesem Skript ist sehr schön zu erkennen, dass es ein paar Optimierungen geben könnte. Zum Beispiel muss ein sogenannter Wahrheitswert nicht explizit auf wahr geprüft werden. Die Bedingung würde ohnehin nur dann gelten, wenn der Wert tatsächlich wahr ist.

Das hängt damit zusammen, dass jede Bedingung in einem System immer darauf geprüft wird, ob sie wahr ist. Einen Wert, der sich auf wahr befindet nochmal explizit auf wahr zu prüfen, ist damit sozusagen eine doppelte Prüfung. Einfacher wäre es also definitiv, den Vergleich an dieser Stelle zu entfernen.

Etwas anders hingegen ist es, wenn ich explizit auf falsch prüfen möchte. Hier könnte man den Wert negieren oder tatsächlich die Prüfung (das Gleichheitszeichen) in der Bedingung lassen.

Unschön und auch fehleranfällig ist, dass ich die Zahl 10 als Text verwende. An dieser Stelle sollte es eigentlich eine wirkliche Zahl sein. Den passenden Block dazu findet man im Bereich Mathematik. Denn ein Text an sich kann ja an sich nicht kleiner oder größer als etwas anderes sein. Ein Text ist und bleibt nun mal ein Text.

Um Dopplungen zu vermeiden wäre an dieser Stelle zudem denkbar, dass man Prüfungen an eine andere Stelle schiebt. Zum Beispiel kann das Skript schon direkt prüfen, ob die Automatik aktiviert ist und ob das Licht blockiert ist. Sollte eines der beiden sein, muss das Skript gar nicht weiter ausgeführt werden. Es ist demnach etwas sinnlos, das in jedem Zweig der Bedingung nochmal einzeln zu überprüfen.

Die Sache mich den Wahrheitswerten

Für den einen oder anderen Leser kann es an dieser Stelle etwas verwirrend sein, wenn wir mit Wahrheitswerten arbeiten. Und das ist nicht schlimm. Denn schließlich kann die Entwicklung von Skripten durchaus mal sehr schnell kompliziert werden.

In der Softwareentwicklung (oder Skript-Entwicklung) wird in einer Bedingung immer auf wahr geprüft. Das bedeutet, dass das Ergebnis dieser Prüfung immer wahr sein muss, damit der entsprechende Skriptblock aufgerufen wird.

Prüfen wir nun einen Wert nochmal explizit auf wahr, ist das so gesehen eine doppelte Prüfung und wir können sie uns sparen. Lass mich das an einem Beispiel erklären.

Wenn wir eine Ja/Nein-Antwort auf eine Frage möchten, stellen wir die Frage in der Regel sehr simpel.

Liest du gerade diesen Blogartikel?

Nun kannst du auf diese Frage mit Ja oder mit Nein antworten. Abhängig von deiner Antwort könnte es von mir eine bestimmte Reaktion geben. Das ist die einfache Form der Frage, so wie man sie in der Praxis auch abkürzen würde.

Prüfen wir nun aber, ob eine Wahrheitsfrage wahr ist, würde die Frage ganz anders lauten.

Ist es wahr, dass du gerade diesen Blogartikel liest?

Hier sehen wir jetzt ganz deutlich, dass das Endergebnis genau das gleiche bleibt. Die Frage ist allerdings komplizierter formuliert. Und genau so verhält es sich auch bei der Erstellung eines Skripts.

Ist der Wert einer Variable wahr oder falsch, müssen wir nicht explizit auf wahr oder falsch prüfen. Das tut bereits die Bedingung für uns und erspart uns damit einen ganzen Teil an Arbeit. Vor allem, wenn derartige Bedingungen öfter auftreten.

Vorsicht, Ausnahme!

Nun kann es aber natürlich auch sein, dass wir in einer Bedingung explizit darauf prüfen wollen, ob ein Zustand falsch ist. In diesem Fall würde es nicht funktionieren, nur den Datenpunkt zu überprüfen. Stattdessen müssen wir an dieser Stelle die Bedingung verändern.

Das bedeutet nun in der Praxis, dass wenn du einen Wert auf falsch prüfen willst, musst du den Vergleichsoperator verwenden. Das ist das Gleichheitszeichen, das auch in Blockly als eigener Block existiert.

Vereinfacht gesagt wäre der Aufbau dann folgender:

Datenpunkt = Falsch

Diese Bedingung kann wiederum wahr sein, sobald der Datenpunkt auf falsch steht. Und genau dann ist auch wieder zu erkennen, dass eine Bedingung immer auf wahr prüfen wird. Nur fragen wir eben nicht, ob der Datenpunkt wahr ist, sondern ob er falsch ist.

Würde man die Frage so ausformulieren, dass sie unserer Bedingung standhält, würde sie vermutlich wie folgt lauten:

Ist es wahr, dass du gerade nicht diesen Blogartikel liest?

Wärst du nun nicht mit dem Lesen beschäftigt, wäre die Antwort auf diese Frage ein Ja. Demnach wäre die Bedingung wieder wahr, obwohl wir explizit darauf geprüft haben, ob du gerade etwas nicht tust. Wir haben somit die Bedingung negiert, um an das gewünschte Wahrheitsergebnis zu kommen.

Klingt kompliziert? Glaub mir, das wird sich nach ein paar Mal nicht mehr kompliziert anfühlen. Und in der Praxis ist der logische Zusammenhang meist sowieso besser zu verstehen.

Beispiel 2: Eine Szene in der ganzen Wohnung aktivieren

Das nächste Beispiel resultierte ursprünglich daraus, dass ich die Funktion der Szenen nicht kannte. Das war noch sehr weit am Anfang und irgendwie habe ich es nie geschafft, das Skript entsprechend zu ändern. Doch schauen wir es uns erstmal genauer an.

Wie wir im Blockly sehen können, schalte ich hier unterschiedliche Geräte. Natürlich alles in Abhängigkeit davon, ob ein bestimmter Wert gesetzt wird. Hierzu habe ich mir in meiner VIS einen Button gebaut, über den ich die Weihnachtsszene für die Wohnung aktivieren und deaktivieren kann.

Je nachdem, ob ich den Button nun aktiviere oder deaktiviere, werden die einzelnen Geräte ein- beziehungsweise ausgeschaltet. Ebenso setze ich für die Beleuchtung die gewünschten Farbwerte und kann so meine Stimmung auf Knopfdruck wieder erzeugen.

Wenn man es genau nimmt, ist auch dieses Skript nicht sehr kompliziert. Es setzt verschiedene Werte in unterschiedliche Datenpunkte und macht genau das, was ich sonst händisch tun müsste. Da ein Smart Home Standardabläufe durchaus automatisieren kann, ist es aber in meinen Augen ein sehr tolles Beispiel für eine Automation.

jetzt 17% günstiger

Twinkly Strings 400 LED RGB, LED-Lichterkette für Draußen und Drinnen, Smarte...*

• LICHTERKETTE FÜR DEN INNEN- UND AUßENBEREICH: LED-Licht mit einer Länge von 32 Metern, geeignet...
• BENUTZERDEFINIERTE EFFEKTE: Genieße eine Vielzahl von anpassbaren Effekten oder kreiere dein...
• WASSERFEST: Diese LED-Lichterkette ist wetterfest mit IP44-Zertifizierung, wodurch sie auch im...

−17%

Jetzt shoppen * Preis inkl. MwSt., zzgl. Versandkosten

Zuletzt aktualisiert 2024-12-21 / (*) Affiliate Links / (**) Affiliate Links, Preis kann abweichen (andere Plattform) / Bilder von der Amazon Product Advertising API / Der angegebene Preis kann seit der letzten Aktualisierung gestiegen sein.

Vorsicht, Irrweg

Natürlich kann man nun an dieser Stelle zurecht sagen, dass das mit Blockly kein Problem ist. Das Skript funktioniert und erledigt genau das, was es soll. Allerdings bietet ioBroker für genau solche Fälle eine wesentlich elegantere Lösung, die man unbedingt kennen sollte.

Ich spreche hier von den sogenannten Szenen. Immer wenn ein bestimmtes Ereignis eintritt, wird die Szene durchlaufen. Das Ereignis kann in diesem Fall die Veränderung des Werts des Datenpunkts Weihnachtsbeleuchtung sein. Dieser kann entweder ein- oder ausgeschaltet werden.

Nun schaut die Logik von ioBroker, welcher Wert gesetzt ist und durchläuft genau diesen Teil der Szene, den wir vorgegeben haben. Wird der Datenpunkt auf wahr gesetzt, wird dieser Pfad durchlaufen, der im oberen Teil des Skripts steht. Wird der Datenpunkt hingegen auf falsch gesetzt, der untere Teil.

Wir haben es hier also mit der klassischen Szene zutun, die man vielleicht bereits aus anderen Smart Home Systemen kennt. Demnach wäre es die logische Konsequenz, dieses Skript in die Szenen zu packen und nicht extra ein Blockly dafür zu nutzen.

Ein großer Vorteil bei der Nutzung von Szenen wäre darüber hinaus, dass die Sache weniger fehleranfällig ist und vor allem übersichtlicher wird. So kann man auch im Nachgang ganz schnell etwas verändern, ohne dass das komplette Blockly nicht mehr funktioniert.

Wir sehen außerdem, dass ich in der Falls-Bedingung nochmal den Wert des Datenpunkts Weihnachtsbeleuchtung abrufe. Das könnte ich mir an dieser Stelle sparen und über den Trigger auf den jeweiligen Wert zugreifen. Das beschleunigt nicht nur das Skript, sondern senkt auch die Zugriffe auf den jeweiligen Datenpunkt.

Beispiel 3: Kalender auslesen

Das nächste Beispiel wird dich vermutlich auf den ersten Blick etwas erschrecken. Und auch ich habe eine ganze Weile gebraucht, um meine Idee in ein fertiges Blockly zu gießen. Ausgangspunkt war, dass es im hauseigenen Kalender Termine gibt, zu denen ein Wecker gestellt werden soll. Da die Termine jedes Mal bereits mindestens eine Woche im Voraus eingetragen wurden, konnte man damit eine tolle Automation erstellen.

Das Skript wird immer dann aktiv, wenn die Daten aus dem Kalender aktualisiert wurden. Das geschieht über iCal, was ioBroker glücklicherweise dank des passenden Adapters auslesen kann. Im Anschluss daran, werden die einzelnen Termine nach einem speziellen Text durchsucht und diese Termine in eine Liste geschrieben.

Damit auch genug Zeit für das Aufstehen und Fahren bleiben, wird vom eigentlichen Termin eine bestimmte Zeit zurück gerechnet. Auf genau diese Zeit wird dann der Wecker gestellt. Besonders clever daran ist, dass der Wecker auf einem bestimmten Amazon Echo gestellt wird. Dieser übernimmt dann die Aufgabe des eigentlichen Weckens.

Natürlich ist dieses Skript nicht sehr übersichtlich und es muss auch sehr viel Logik durchlaufen. Aus diesem Grund sollte man in meinen Augen mit solch umfassenden Berechnungen immer etwas vorsichtig sein, sofern der Server nicht ausreichend viel Leistung dafür bietet. Und man muss natürlich auch im Auge behalten, wie häufig der Kalender aktualisiert und abgerufen wird.

Was wir damit gelernt haben

Kaum zu glauben, dass man Erkenntnisse aus einem Blogpost mitnehmen kann, was? 😉

Doch wie wir in den Beispielen gesehen haben, können auch diese ioBroker Blockly Beispiele unterschiedlich komplex aufgebaut sein. Die Komplexität bemisst sich dabei in der Regel an dem, was das Skript leisten soll. So konnten wir sehen, dass einfache Steuerungen sehr locker umzusetzen sind. Andererseits ist das Auslesen eines Kalenders und damit verbunden das automatische Stellen eines Weckers wesentlich komplizierter.

Und genau da sieht man sehr schön, was ich schon in einem vorherigen Absatz gemeint habe. Ein Skript sollte immer nur so komplex sein, dass es seine Aufgabe ordnungsgemäß erfüllen kann. Niemals sollte man das Skript künstlich vergrößern und komplizierter machen. Denn das ist nicht nur dann hinderlich, wenn man das Skript einmal weitergeben will. Es ist genauso hinderlich, wenn man das Skript Monate später noch einmal ansieht und einen Fehler darin finden will.

Wir haben aber auch gesehen, dass meine Skripte wahrhaftig nicht fehlerfrei sind. Genauso besteht bei mir jede Menge Optimierungsbedarf. Und woher kommt das?

Ganz einfach. Die eigenen Erkenntnisse erweitern sich mit jedem eigenen Skript. So weiß man fünf Skripte später schon wieder besser, wie man etwas bestimmtes umsetzen sollte. Genau dann ist der Moment gekommen, um diese alten Skripte zu verbessern. In der Softwareentwicklung fassen wir das zum Beispiel mit dem Begriff Refactoring zusammen. Es handelt sich dabei um einen kontinuierlichen Verbesserungsprozess, der auch im Smart Home angewandt werden sollte.

Und was ebenso wichtig ist, hab keine Angst vor Fehlern. Wir machen sie alle. Die Frage ist dann nur, wie wir mit Fehlern umgehen. 😉