Bevor es losgeht, einige grundsätzliche Überlegungen zur Fernsteuerung der CCU
Auf dieser Seite
Jedes Projekt beginnt mit einem guten Plan. Auch für den CCU-Bot müssen zunächst einige Rahmenbedingungen festgelegt werden.
Benennung von Systemvariablen
Prinzipiell kann man Systemvariablen – so wie allen Objekten in der CCU – beliebige Namen geben, also z. B. auch Umlaute und Sonderzeichen verwenden. Ich empfehle jedoch, sich auf reguläre Buchstaben (a-z, A-Z) zu beschränken: Bei Umlauten und Sonderzeichen besteht die Gefahr, dass Systemvariablen in Scripten nicht überall gefunden werden.
Die Schnittstelle von Telegram zur Außenwelt ist gut dokumentiert (Telegram-API), darum hier nur in Kürze die für meinen Bot relevanten Besonderheiten.
Da ist zunächst die Frage, wie man den Bot anspricht. Die einfache Variante ist eine REST-API: Die CCU sendet periodisch eine Anfrage an Telegram, ob neue Nachrichten für den Bot vorliegen, und bekommt als Antwort ein JSON-Objekt mit dem Ergebnis. Wie so ein Ergebnis aussieht, hat man schon auf der T-Framework-Seite gesehen – und natürlich wird es auf der folgenden awk-Seite noch etwas ausführlicher.
Der Nachteil ist die Reaktionszeit: Wenn die CCU Neuigkeiten alle fünf Minuten abruft, kann es bis zu fünf Minuten dauern, bis sie auf Befehle reagiert. Außerdem wird sie nutzlosen Traffic erzeugen, denn sie wird meistens vergeblich nach neuen Nachrichten suchen – wenn die CCU gut programmiert ist, macht sie alles automatisch und man muss nicht viele Befehle an sie senden.
Eleganter wäre es, die CCU bei Telegram zu registrieren, so dass Telegram von sich aus neue Nachrichten pusht. Auch das geht – aber dazu müsste die CCU aus dem Internet erreichbar sein, und das ist grundsätzlich eine schlechte Idee. Das „Internet of Things“, zu dem auch die CCU dann zählen würde, ist ja nicht gerade für hohe Sicherheitsstandards bekannt. Bei einem System, das das ganze Haus steuert, sollte man vielleicht doch etwas vorsichtiger sein.
Da ich den Programmierkünsten von eQ-3 nur so weit vertraue, ich wie die CCU werfen kann, fällt dieser Weg also flach. Ich bin ein schlechter Werfer. Es bleibt bei der REST-API: Mit der Verzögerung kann ich leben und Traffic spielt keine Rolle. Es sind eh nur ein paar Bytes pro Abfrage.
Nachdem ich auf dieser Seite einen Plan angekündigt habe, kommt hier nun der Plan.
Ein WebUI-Programm auf der CCU wird den Systemtakt nutzen, um regelmäßig über die REST-API nach neuen Nachrichten zu suchen. Das Ergebnis wird mit awk ausgewertet, weil alles andere mit der Script-Sprache der CCU geradezu schmerzhaft wäre, trotz der jüngst neu eingeführten Script-Befehle zur String-Bearbeitung. An regulären Ausdrücken geht nichts vorbei und meine Erfahrungen mit exzessiver String-Bearbeitung in CCU-Scripten sind eher durchwachsen.
Wenn in der Antwort ein Befehl erkannt wird, dann wird dieser in eine Systemvariable geschrieben. Damit ist das CCU-Bot-Script dann fertig – den Rest erledigt ganz langweilig die Logikschicht der CCU.
Klingt nach einem Plan.
Im Prinzip könnte man den kompletten CCU-Bot vollkommen ohne das T-Framework installieren. Der Bot soll aber natürlich auch auf Befehle reagieren, indem er Nachrichten zurückschickt. Auch das wäre wiederum ohne das T-Framework möglich, aber deutlich unkomfortabler.
Nicht zuletzt sind in der Anleitung zum T-Framework die Einrichtung des Bots sowie erste Informationen zu Telegram enthalten, auf die ich in dieser CCU-Bot-Anleitung nicht weiter eingehe.
Also: Nein, wenn man sich das Leben unnötig schwer machen möchte, braucht man das T-Framework nicht.
In der Zeit, in der die CCU das CCU-Bot-Script ausführt, tut die Logikschicht nichts anderes. Wenn also aus irgendeinem Grunde Telegram 30 Sekunden braucht, um die Anfrage des Bots nach neuen Nachrichten zu beantworten, dann hängt die Haustechnik in dieser Zeit. Wer gerade dann auf den Lichtschalter drückt, steht erst mal im Dunkeln. (Die Lösung sind natürlich direkte Verknüpfungen, z. B. zwischen Fernbedienung und Schaltaktor, die auch funktionieren, wenn die CCU gerade steht, aber es geht ums Prinzip.)
Die gute Nachricht: Zufällig stockte mein Internet, als ich gerade am CCU-Bot herumprogrammiert habe – das ist natürlich weniger gut. Der CCU-Bot hat diesen Ausfall aber ohne spürbare Verzögerungen überstanden, und das ist super.
Es ist also nicht ausgeschlossen, dass durch den Bot die Reaktionszeit des Systems beeinträchtigt wird, aber ich konnte bisher noch keine negativen Effekte feststellen.
Telegram übermittelt bei Nachrichten an den CCU-Bot eine Chat-ID, die effektiv die ID des Absenders darstellt. Anhand dieser ID kann mein CCU-Bot erkennen, dass eine Nachricht von mir stammt. Das ist schon eine gewisse Sicherheit, aber wenn jemand mein Smartphone hackt, dann kann er auch mein Haus steuern.
Man sollte daher dem CCU-Bot keine sicherheitsrelevanten oder sonstwie kritischen Aufgaben übertragen. Es ist zwar irgendwie schick, über einen Telegram-Befehl die WinMatic zu steuern und die Fenster zu öffnen, aber ich persönlich wäre da eher zurüchaltend.
Es wäre schon sicherheitskritisch genug, wenn jemand mein Smartphone hackte …