Was ein Programm ein Script eine Direktverknüpfung ist werde ich nicht erklären.
Du bist selber in der Pflicht Initiative zu zeigen.
TheLight hat geschrieben: ↑04.01.2022, 10:14
Ich habe schon ein paarmal gelesen, dass man immer eher über Direktverknüpfungen als über Programme oder Skripte schalten sollte. Das "Warum" ist mir jedoch nicht ganz klar. Sicher, wenn ich nicht aufpasse und die technischen Voraussetzungen gegeben sind, könnte ich dabei versehentlich den Kühlschrank aus- und das Bügeleisen einschalten. Geht es dabei also nur um die Risiken oder gibt es noch andere Gründe, die ich noch nicht sehe?
Dann hast du nicht genügend gelesen.
Direktverknüpfungen sind einfach
funktechnisch die erste Wahl.
Allgemeiner Vorteil bei den Funkern: es können mehrere Aktoren "zeitgleich" geschalten werden ohne großartige Gefahr, das da was kollidiert / schief geht im Funk. Grundsätzlich wäre es so, wenn du denn z.B. echte Taster direkt mit den einzelnen Aktorkanälen verknüpfst. Dann wäre das auch funktional, wenn die CCU weggerannt wäre. Nachteil, ist nur innerhalb der Familien möglich, HM kann nicht mit HM-IP direkt verknüpft werden.
Benutzt man
Programme um zig Funkaktoren zu schalten sollte man / muss man Verzögerungen einbauen und alles staffeln, damit die CCU Senden/Empfangen/Senden/Empfangen ..... fein abarbeiten kann. Ist im Forum zu Hauf zu lesen.
Scripte ebenso wie Programme
Das obige ist aber ein allgemeines reines FUNK Problem und nur zum Verständnis angemerkt.
TheLight hat geschrieben: ↑30.12.2021, 12:05
Im Einsatz habe zum größten Teil Wired-Komponenten, vereinzelt aber auch ein paar BSM oder BDT.
Neben der Haustür habe ich einen FIO6 (6fach IO-Modul) an einen 6fach-Taster mit Kontrollleuchten montiert, der grundsätzlich funktioniert und ansteuerbar ist.
Wired sollte da ja keine Probleme haben.
Trotzdem würd ich mir Strukturen schaffen. Das Ganze untergliedern.
TheLight hat geschrieben: ↑04.01.2022, 10:14
In meinem Fall gehe ich momentan von dem Gedanken aus, dass es weit einfacher ist, alle Lampen in einer Gruppe (Gewerk) zusammen zu fassen, um dann mit einem Skript die Gruppe abzufragen und im nächsten Schritt entsprechende Lampen zu deaktivieren (eben genau so, wie es Dein Skript macht). Kommt mal etwas Neues dazu, müsste ich das dann nur dem Gewerk zuordnen, womit es automatisch Bestandteil der Funktion wäre oder umgekehrt aus dem Gewerk entfernen.
Das ist korrekt und aus diesem Grund habe ich auch solche Scripte geschrieben.
Das funktioniert auch durchaus mit einer gewissen Anzahl an Kanälen usw.
Aber nun kommst du, packst alle deine 50 Aktorkanäle in ein Gewerk, lässt mein Script losrennen und alle 50 Kanäle schalten.
Nun 45 wired & 5 Funker, wird wahrscheinlich problemlos gehen. Du nennst ja nix genaues.
Der nächste nimmt alle seine 50 Funkkanäle. Was folgt?
Irgendetwas funzt nicht, Probleme, Hexenverbrennung, Scripte sind böse.....
Auch hier wieder allgemein über mir geschrieben.
Von daher muss ich immer darauf hinweisen, es nicht zu übertreiben.
TheLight hat geschrieben: ↑04.01.2022, 10:14
Andersrum müsste ich doch erstmal eine riesige Programmkette bauen (oder einzelne Segmentprogramme in einem Hauptprogramm zusammenfassen). Ich habe 40-50 Lampen, die ich abfragen und ggf. ausschalten möchte, vom Gefühl hätte ich gedacht, dass das sehr unübersichtlich wird. Zusätzlich müsste ich bei geänderten Lampen im Programm selbst arbeiten, worin ich eine größere Fehlerquelle sehen würde. Vor allem auch, weil man sich nach ein paar Jahren erst in den einzelnen Programmen wieder einfinden und diese verstehen muss.
Natürlich ist ein Programm mit 50 zu Aktoren unübersichtlich & Fleißarbeit. Aber nicht immer ist das leichte auch das Beste
Aber dazu unten mehr.
TheLight hat geschrieben: ↑04.01.2022, 10:14
Und noch eine zweite Anfängerfrage: "Ein solches Script müsste aber getriggert werden"
Das verstehe ich, aber wie und wo?
Muss ich in der Direktverknüpfung jeder einzelnen Lampe den Start des Kontroll-LED-Skripts einbauen? Die Idee, es alle 2 Sekunden zu starten ist sicher auch dämlich
Hab ich doch geschrieben.
Du selber bestimmst doch was du gern hättest. Nur warum willst du das?
Du willst bei jeder Änderung der Lichter eine Prüfung, also musst du auch:
+ ein
Programm triggern mit jeder Änderung der Bedingungen/Lichter. Steht auch schon vorn von anderen bebildert
ODER
- zyklische Prüfungen durchführen
Wie du selber schon bemerkt hast ist zyklisches Prüfen eine dumme Idee zumindest in dem angedeuteten Zeitraster.
Außerdem stellt sich mir die Frage, wieso du in einem Haus überhaupt auf 2 Sekunden kommst. Ist doch kein Atomreaktor.
Gehen wir mal praktisch ran.
Du nimmst ein 30minütliches Zeitraster wo du das Script zur Prüfung eingeschaltener Lichter prüfst und die Status LED schaltest
UND / ODER
ein heimlicher Bewegungsmelder (der sowieso im Flur neben dem IO Modul rumhängt
) macht das zusätzlich, wenn wer in den Flur kommt.
Denn ob die Status LED an oder aus ist spielt keine Geige, wenn sie ja keiner sieht.
Wäre doch auch ne Lösung
TheLight hat geschrieben: ↑04.01.2022, 10:14
Hier hätte ich mir etwas Ähnliches wie: "In dem Gewerk ist etwas passiert, also starte das Skipt um festzustellen ob die LED leuchten soll" erhofft.
Siehe oben, du legst doch fest was du willst.
Schon mal in der Klickibunti rumgespielt?
Besteht da in der Programmerstellung irgendwo die Möglichkeit auf ein Gewerk / Raum / Favorit zu prüfen?
Das kannst du dir nur selber schaffen, indem du dir Hilfssystemvariablen erstellst mittels Strukturen.
Hat ja auch Roland
viewtopic.php?f=60&t=71698#p697442 angedeutet.
Alchy