Skript um alle Rolladen auf einmal zu öffnen

[dtp]

Da bin ich ja durchaus bei dir.

Bei mir ist es aber so, dass ich mich über nahezu alles, was meine CCU3 so treibt, per Push-Nachricht informieren lasse. Und da brauche ich dann eh ein Skript. Wenn ich dann noch die Anzahl von Programmen durch entsprechende Skripte in einem für mich überschaubaren Rahmen lassen kann, dann treibe ich durchaus gerne den Aufwand der Skript-Programmierung.

Die Rollladensteuerung ist ein gutes Beispiel dafür. Ich habe - glaube ich - insgesamt sechs oder sieben WebUI-Programme für die Steuerung sämtlicher Rollläden im Haus. Wollte ich das ohne Skripte machen, dann wäre die Anzahl ungleich höher. Und irgendwann wird es unübersichtlich, wann welche Programme miteinander interagieren. Vor allen Dingen, da das WebUI alles andere als komfortabel zu bedienen ist, weil es sich z.B. nicht merken kann, von welcher Maske aus der Bediener die letzte Aktion ausgeführt hat.

Ich habe mit meinem Rollladen-Skript ähnlich angefangen, wie der TO. Was daraus wurde, zeigt ein Klick in meiner Signatur. Das kann man jetzt gut finden, oder nicht. Meine persönlichen Anforderungen habe ich mir damit auf alle Fälle erfüllt.

[Xel66]

Und da brauche ich dann eh ein Skript.

Das ist Dein Denkansatz. Wirklich brauchst Du es zur Steuerung nicht, lediglich für das Handling von Strings für die Zusammenstellung der zu pushenden Informationen. Und da reicht ein einziges zweckgebundenes Script allein.

Wenn ich dann noch die Anzahl von Programmen ...für mich überschaubaren Rahmen...

Genau das ist das Grundproblem. Die Anzahl der Programme ist für die CCU eher kein Problem. Progammierfehler durch unpräzise Scripte eher. Zyklische Monsterscripte ebenso (keine parallele Abarbeitung möglich - und das ist die wahre Beschränkung des Systems). Es ist nur ein Anwenderübersichtsproblem und keines in irgendeiner Weise technischer Natur, welches man mit einer sinnvollen Namensgebung durchaus in den Griff bekommen kann. Und bei der Übersicht hilft die Filterung in der WebUI ungemein. Dort kann man bequem die Anzeige auf Programme, oder Geräte oder was auch immer mit bestimmten Begriffen im Namen einschränken lassen und erhält bzw. behält somit einen guten Überblick.

Die Rollladensteuerung ist ein gutes Beispiel dafür. Ich habe - glaube ich - insgesamt sechs oder sieben WebUI-Programme für die Steuerung sämtlicher Rollläden im Haus.

Ich habe für meine Rollladensteuerung insgesamt derzeit 24 Programme. So what? Dafür ist das System von Haus aus ausgelegt. Und es macht keinerlei Probleme. Alle tragen die Bezeichnung "Rollladen..." im Namen. Dann folgt die Funktion ("...Beschattung..., Sollwert... etc.). und zuletzt die Raumbezeichnung oder das entsprechende Fenster, wenn mehrere vorhanden sind. Es gibt pro Rollladen nur ein einziges Programm, welches Zugriff auf den Aktor hat und die Stellung entsprechend der Vorgaben in den Systemvariablen. Somit gibt es auch keinerlei Probleme mit konkurrierenden Zugriffen unterschiedlicher Programme. Die restlichen Programme steuern nur Sollwerte (pro Rollladen ein boolscher für "hoch/runter" und zwei vom Typ Zahl für die Behanghöhe "oben" für Beschattungsstellungen und "unten" für Lüftungsstellungen.

Wollte ich das ohne Skripte machen, dann wäre die Anzahl ungleich höher.

Ja, aber eben die Anzahl der Programme ist kein Problem.

Und irgendwann wird es unübersichtlich, wann welche Programme miteinander interagieren.

Wenn alle konkurrierend auf die gleichen Geräte zugreifen, kann einem schon mal die Übersicht verloren gehen. Nun sind ja nur die beiden Bereiche "Rollladen-" und "Heizungssteuerung" solche Bedarfsträger, weil hier viele gleichartige Geräte zur vermeintlich gleichen Zeit gesteuert werden sollen/müssen. Wenn man hier ein Konzept benutzt, das konkurrierende Zugriffe vermeidet, bekommt man auch keinen Knoten ins System.

Vor allen Dingen, da das WebUI alles andere als komfortabel zu bedienen ist

Nun ja, es gibt sicherlich viel Optimierungspotenzial. Aber der Einsteiger kommt damit im Gegensatz zum Scripting durchaus zurecht, auch wenn es an manchen Stellen eher wenig intuitiv ist. Auch die Logik der CCU ist gewöhnungsbedürftig, was man aber mit dem Vermeiden von Monsterprogrammen mit vielen SONST WENN durchaus handhaben kann. Einfach mehrere Programme anlegen, die immer nur einen begrenzten Funktionsumfang haben. Wie gesagt, die Anzahl der Programme ist für die CCU eher das kleinere Problem. Nur der Anwender hat eines, wenn er keine zuortbaren, aussagekräftigen und beschreibenden Namen, die sich für eine gefilterte Darstellung eignen, verwendet.

Gruß Xel66

[dtp]

Genau das ist das Grundproblem. Die Anzahl der Programme ist für die CCU eher kein Problem.

Für die CCU nicht, aber für mich. Und das, obwohl ich eine strikte Nomenklatur für sämtliche Geräte, Programme, Systemvariablen, etc. einhalte.

Der CCU dürfte es übrigens egal sein, ob sie ein reines Programm oder ein in einem Programm verpacktes Skript ausführen soll. Für sie ist es alles Code.

[Black]

gerade Rolladensteuerung sind immer arg individuell und in den seltensten Fällen von A nach B 1:1 übertragbar.

Klar, für ein einfaches raufrunter, würde sich eine DV anbieten. fullAck. Nur jetzt ist die Beschalterung in HMClassic mit Türgriff, schon braucht es für Aussperrschutz ein Programm. Möchte man jeden Rolladen einzeln Hand/Automatik schalten können : Programm nötig.
Beschattung, auch Programm nötig. Auch da gibts nun für die Umsetzung auch wieder bestimmte Vorlieben der einzelnen und auch programmstile.

Bei mir ist es zum Beispiel eine Kombination aus WebUI und SubprogrammScript. Ich denke mal DIE eindeutig beste Universallösung gibts für den Anweundungsfall nicht.

Black

[Xel66]

Ich denke mal DIE eindeutig beste Universallösung gibts für den Anweundungsfall nicht.

100%ACK. Das Problem nur, die Scriptlösungen werden immer als All-in-One- aka Universallösung dargestellt und die Einsteiger sind zumeist hoffnungslos damit überfordert, weil sie meinen, wenn sie selbst mit der Programmierung anfangen, dass ihnen dabei etwas "verloren geht". Das sieht man auch an dem massiven Supportbedarf in der Folge solcher Lösungsvorstellungen. Es gibt teilweise eben schon simpelste Verständnisprobleme, weil Einsteiger eben nicht mal einen Scriptlauf an Hand des Lesens nachvollziehen können. Bei Programmen kann man meist den Ablauf nachvollziehen (wenn man die Eigenheiten der CCU-Logik kennt). Darum eben mein permanentes "Wettern" gegen die Umsetzung "simpelster" logischer Steuerung auf Scriptbasis, die man aber problemlos als Programm abbilden könnte. Scipte da wo sie benötigt werden, ja - als globaler Programmersatz, eher nicht.

Gruß Xel66

[dtp]

Das sieht man auch an dem massiven Supportbedarf in der Folge solcher Lösungsvorstellungen. Es gibt teilweise eben schon simpelste Verständnisprobleme, weil Einsteiger eben nicht mal einen Scriptlauf an Hand des Lesens nachvollziehen können. Bei Programmen kann man meist den Ablauf nachvollziehen (wenn man die Eigenheiten der CCU-Logik kennt).

Das sehe ich aber etwas differenzierter. Aus meiner Sicht ist der Support-Aufwand bei der Programmlogik höher. Wie oft wird hier z.B. immer und immer wieder dasselbe durchgekaut, wenn es um die Logik von "bei Änderung auslösen", "bei Aktualisierung auslösen" und "nur prüfen" geht? Und was passiert, wenn man diese verundet oder verodert? Wie oft ist den Leuten unklar, wie ein Programm durch die ReGaHSS abgearbeitet wird (das ist ja auch fernab der üblichen Programmierlogik)? Wie oft verstehen die Leute das mit dem Setzen der Einschaltzeit nicht richtig? Etc. pp.

Klar, auch die HM-Skripte haben ihren eigenen Kopf (z.B. Abarbeitung mathematischer Befehle innerhalb einer Zeile von links nach rechts - was schon etwas von umgekehrter polnischer Notation hat -, oder der grundsätzlich beschränkte Codewort-Schatz im Vergleich zu anderen Programmiersprachen), aber auch HM-Skripting kann man lernen. Genau so, wie die Programmlogik. Ich persönlich finde das HM-Skripting übrigens deutlich einfacher zu verstehen, als z.B. Javaskript. Mit dessen Funktionen-Logik stehe ich irgendwie immer noch auf Kriegsfuß. Aber ich bin ja auch kein Informatiker, sondern habe das Programmieren nur so nebenbei in der Schule und während des E-Technik-Studiums gelernt.

[Xel66]

Aus meiner Sicht ist der Support-Aufwand bei der Programmlogik höher. Wie oft wird hier z.B. immer und immer wieder dasselbe durchgekaut

Weil die Anwender sich eben nicht die Mühe machen und die verfügbare Dokumentation zu Rate ziehen und stattdessen erst mal das Forum befragen. Das ist aber mit jeder Programmiersprache und in jeder Programmierumgebung unumgänglich. Selbst nach einer Lösung zu suchen gilt vermutlich heutzutage als oldschool. Man chillt lieber und lässt andere die Hausaufgaben machen.

Und was passiert, wenn man diese verundet oder verodert?

Wenn es selbst an einfachstem logischen Verständnis fehlt, läuft alles ins Leere. Beispiel: Ich will die Deckenlampe im Flur mit dem Taster an der Eingangstür UND an der Wohnzimmertür UND an der Badtür etc. einschalten. Das entspricht zwar der menschlichen Logik, aber eben nicht der technischen, denn hier sind die Bedienmöglichkeiten zu verODERn. Wer hier ein Verständnisproblem hat, bekommt keine funktionierende Programmierung hin.

Wie oft verstehen die Leute das mit dem Setzen der Einschaltzeit nicht richtig? Etc. pp.

Das ist wirlich etwas ungünstig gelöst, aber in der Scriptingumgebung auch nicht einfacher zu handhaben.

Abarbeitung mathematischer Befehle innerhalb einer Zeile von links nach rechts - was schon etwas von umgekehrter polnischer Notation hat -, oder der grundsätzlich beschränkte Codewort-Schatz...

Das lässt sich nun wirklich nicht mit Bordmitteln umgehen und ist der eingeschränkten Implementation des Funktionsumfanges der Scriptingengine geschuldet.

Aber ich bin ja auch kein Informatiker...

Ich auch nicht (zu meiner Ausbildungszeit steckte das alles noch in den Kinderschuhen). Ich bin Autodidakt und denke eigentlich elektrisch.

Gruß Xel66

[Sebman]

Ich denke auch das man Grundfunktionen mit einfachen und gegebenen Mitteln realisieren sollte.
Was nützen mir die besten Programme und Skripte, wenn ich bei Ausfall der Zentrale nicht mal mehr die Grundfunktionen meiner Anlage bedienen kann.^^

[dtp]

Selbst nach einer Lösung zu suchen gilt vermutlich heutzutage als oldschool. Man chillt lieber und lässt andere die Hausaufgaben machen.

Das kann man so pauschal aber nun auch wieder nicht sagen. Ich denke, hier im Forum und auch in anderen Foren (z.B. ioBroker) sind sehr viele Leute unterwegs, die sich sehr für die Sache engagieren. Natürlich wird es immer wieder User geben, die sich - sagen wir mal - bedienen lassen, aber solche Menschen gibt's leider überall. Wem das dann zu sehr auf den Keks geht, der muss sich halt zurückziehen oder es den anderen gleichtun.

Wenn es selbst an einfachstem logischen Verständnis fehlt, läuft alles ins Leere.

Nee, das meinte ich nicht. Ich meinte z.B. die UND-Verknüpfung von "auf Änderung auslösen". Wer erwartet da schon, dass das gar nicht der gleichzeitigen Änderung der verknüpften Bedingungen entspricht, sondern dass es vielmehr genügt, wenn sich eine der Bedingungen ändert und die andere jeweils erfüllt ist; also, dass

Bedingung A auf Änderung auslösen UND Bedingung B auf Änderung auslösen

gleichzusetzen ist mit

(Bedingung A auf Änderung auslösen UND Bedingung B nur prüfen) ODER (Bedingung B auf Änderung auslösen UND Bedingung A nur prüfen)?

Was nützen mir die besten Programme und Skripte, wenn ich bei Ausfall der Zentrale nicht mal mehr die Grundfunktionen meiner Anlage bedienen kann.

Ja, daran sollte man immer denken. Vielleicht einfach mal die CCU für einen Tag ausschalten und sehen, was dann noch geht und was nicht. Wenn der Haussegen danach nicht schief hängt, hat man einiges richtig gemacht.

Übrigens gab es kürzlich im Macuser-Forum einen Versicherungsmitarbeiter (zumindest "outete" er sich als solcher), der meinte, dass ernsthaft über höhere Prämien von Versicherten nachgedacht wird, die ihr Haus mit smarten Funktionen - insbesondere für den Komfortzugang - ausstatten. Einfach, weil dadurch das Einbruchsrisiko steige. Hat jetzt nichts mit Skripten zu tun, aber passt ein wenig in den Kontext der obigen Aussage.