Ratlosigkeit beim Scripten

Ich frage mich, wie ist die generelle Logik beim Scripten? Gibt es irgendeine Best practice?

Man überlege sich folgendes Szenario: Ich habe ein Keymatic Türschloss (Motor am Schlieszylinder), und iwll dass das Schloss abends zu einer bestimmten Uhrzeit automatisch abgeschlossen wird. Dazu könnte ich einen Event anlegen, der immer zu einer bestimmten Zeit ausgeführt wird.

Wenn allerdings in dem Moment die Tür gerade offen ist, z.B. weil jemand durchgeht, schließt sich trotzdem das Schloss und die Tür lässt sich danach nicht mehr schließen (weil der Schiessriegel raussteht). Also muss ich vor dem Schließen des Schlieszylienders prüfen, ob die Tür nicht gerade offen ist.

Dazu lege ich einen Event an, der um 20 Uhr ausgeführt wird mit einem runScript-Aufruf. In dem Script prüfe ich dann vorher, ob die Tür offen ist. Wenn die Tür offen ist, erzeuge ich einen neuen (einmaligen) Event eine Minute später und versuche es wieder. Das wiederhole ich in einer Schleife bis die Tür zu ist und der Schlieszylinder geschlossen werden kann.

Jetzt wüsse ich gerne, wie man solche Regeln am besten abbildet. Baut man sich dazu eine Art “Scheduler”, ein Haupt-Script welches jede Minute läuft und die Aktionen triggert, oder wie würdet ihr das machen? Gewisse Aktionen müssen ja auch häufiger als minütlich ausgeführt werden. Hier fehlt es mir leider an einer erkennbaren Struktur, wie man sowas gut abbilden kann, ohne dass man nach kurzer Zeit ein Wildwuchs von Scripts hat und Abhängigkeiten von Scripts, die nicht mehr erfüllt werden können. Die Wartbarkeit ist dann schnell dahin …

Würde mich freuen, wenn es hier mal Berichte von euren Setups gäbe.

Gruß, Andreas

Hallo Andreas,

Wildwuch zu verhindern ist nicht ganz einfach :wink:. Ich habe für mich privat die gesamte Logik in PHP-Klassen für die jeweiligen Aufgabenbereiche (Licht, Heizung, Alarm, …) und eine Controller-Klasse organisiert. Ereignisse werden von diesen gepräfixt bei Bedarf automatisch angelegt und auch wieder gelöscht.

Deine Aufgabe oben kannst du in Version 0.6 auch mit dem einen Event um 20 Uhr lösen und das Skript einfach laufen lassen - das ist kein Problem und macht es vielleicht übersichtlicher. Bei der parallelen Ausführung ist nur wichtig, dass standardmäßig maximal 10 Skripte gleichzeitig laufen können. Auf dem RPi 2 kann diese Zahl ohne Probleme in der main.conf verdreifacht werden.

Viele Grüße

Sathya

Hallo Sathya,
Danke für den schnellen Reply.
Von lang laufenden PHP Scripts halte ich ehrlich gesagt gar nicht viel … :slight_smile:
Ich habe auch schon begonnen, eigene Klassen zu implementieren und über die System-Variablen quasi “Semaphores” zu setzen, die dann in einem Scheduler Task ausgewertet werden und dann werden die jeweiligen Actions gestartet. Aber ich habe das Gefühl, dass das kein sauberer Weg ist bzw. es wird schon früh unsauber.
Bevor ich da superviel Arbeit reinstecke, frage ich lieber mal wie man es geschickterweise macht. Wärst Du bereit mehr über Deine Klassen zu erzählen? Ich könnte mir auch gut vorstellen, mal ein Framework zu bauen und es anschließend zur Verfügung zu stellen. Wichtig ist mir, die richtige Methodik von Anfang an zu wählen.

Ich verwende 0.6 aus den nightly builds (aktuell 100x … gibt aber mächtig Schwierigkeiten bei der Installation, musste die .debs von Hand entpacken und Files manuell an die richtigen Stellen kopieren, und start/stop-Script hat Schwierigkeiten den Daemon zu beenden, funktioniert nur mit kill -9 … - sind das bekannte Probleme? Debian 8 auf einem Atom 1.6).

Andreas

Hallo Andreas,

aktuell habe ich es so gelöst, dass ich eine Klasse für die Raum-Konfiguration habe (der Raum ist ein assoziatives Array, welchem Geräte wie Wandthermostat, Stellantrieb, Bewegungsmelder, Fensterkontakte, … zugewiesen sind) und jeweils eine Klasse für Bereiche wie Heizung, Licht und Alarm. Diese speichern Daten in Systemvariablen und Geräte-Metadaten. Dann gibt es noch ein Ereignishandler-Skript, welches bei Ereignissen wie Schalterbetätigung, Temperaturänderung am Wandthermostaten, etc. aufgerufen wird. Dieses Skript erzeugt dann bei Bedarf die benötigten Objekte und ruft die Ereignis-spezifischen Methoden auf. Die meisten Ereignisse werden auf die Änderung einer Gerätevariablen hin aufgerufen, das “Temperaturanpassungsskript” minütlich. Die Heizungstemperaturanpassung ist bei mir vermutlich der komplexeste Teil, da viele Informationen einfließen.

Keine Ahnung, ob das der sinnvollste Weg ist… Ich hoffe, diese grobe Umschreibung hilft dir ein bisschen weiter. Thomas mag vielleicht noch einen besseren Ansatz haben. Aber es funktioniert und ist noch übersichtlich :wink:.

Viele Grüße

Sathya