hab’ mir schon 'nen Wolf gesucht, aber nichts gefunden , (ggf. bitte Hinweis posten, Danke).
Folgendes möchte ich machen:
Einige Sensoren (z.B. Tür-/Fenster-Kontakte) werden auf einen bestimmten Zustand überwacht, zur Zeit löse ich dies mit einer Aktion pro Variable. Funktioniert, Haken drann.
Leider ist das ganze recht unübersichtlich, nun suche ich eine Funktion um eine Kategorie auf Änderung zu überwachen. Dann sollte wie gehabt ein Script starten, die Variablen-ID und der Wert sollten übergeben werden.
Was ist daran unübersichtlich? Die Ereignisse liegen ja alle unter dem Script.
Und ein Ereignis kann nur eine Variable als Auslöser haben, somit nein geht nicht.
Ausnahme:
Installation von Modulen welchen Variablen überwachen.
Wie ‚Variablenüberwachung‘ Watchdog, Universal-Trigger…usw.
Michael
Hallo kea, hast Du eine schlaue Lösung gefunden? ich suche das gleiche und das Einhängen eines Aktion-Skripts unter alle möglichen Variablen finde ich persönlich auch unübersichtlich, man hat einfach keinen Überblick, welche Variablen genau von diesem Skript beobachtet werden.
Ich fände es logisch und übersichtlicher, die zu überwachenden Variablen in eine Liste in einem Skript einzutragen und nicht umgekehrt ein Skript unter X variablen hängen zu müssen.
Der Beitrag über Deinem beschreibt doch schon die Lösung.
Die genannten Optionen sind genau dafür geschaffen und sind bei den meisten Usern in der Nutzung.
Überwachungsbedüftige Variablen sind bei mir alle per Watchdog überwacht. Je nach Anforderung gesammelt oder einzeln.
LG
Es gibt hier nicht um Aktionsskripte.
Diese brauchen kein Ereignis und ein Script kannst du, sofern es programmtechnisch Sinn macht, bei mehreren Variablen unter eigene Aktion eintragen.
Michael
Hallo Nall-chan,
ich bin wirklich für jeden Vorschlag, wie man Dinge in symcon macht und wie man es besser nicht macht, dankbar, aber leider bin ich jetzt immer noch nicht zufrieden.
Ich habe z.B. 30 Variablen, die ich auf Veränderung überwachen und entsprechend reagieren möchte. Wenn V01 = true, dann mache A, wenn V02 = true, dann mache B, usw.
Variante A: Ich hänge hinter jede Variable ein eigenes Skript (AktionSkript?) was sich um diese Variable kümmert. Klingt nicht sehr sinnvoll.
Variante B: Ich lege ein Skript an, in dem ich die Aktionen für alle diese Variablen festlege und hänge dieses Skript hinter alle Variablen. Das geht in einem Rutsch. Muss ich nur drauf achten, wenn noch 10 Variablen dazu kommen, diese dann in das Skript einzutragen UND zusätzlich noch hinter die neuen 10 Variablen zu hängen. Das hat der Thread-Opener mit unübersichtlich gemeint und das würde ich auch genau so unterschreiben.
Also gibt es noch Variante C: Ich erstelle ein Skript, welches zyklisch läuft und die in ihm verwalteten Variablen auf Änderungen überprüft und entsprechend reagiert. Dann mache ich bei Bedarf einfach 10 Variablen dazu und fertig. Nachteil dieses klassischen Pollings ist, dass es eher träge ist und vermutlich auch für das Laufzeitverhalten des Systems nicht optimal ist und zudem grundsätzlich einem Eventbasierten System zuwider läuft.
Also ist doch die grundsätzliche Frage, was der beste Ansatz ist, bzw. der, aus sich von symcon beste Weg.
Und deine Variante A und B sind doch gleich?
Ein Skript kann nicht unter mehreren Variablen hängen, sind dann doch mehrere Skripte
Eine mögliche Umsetzung ist:
Ein Skript, dann für jede Variable ein auslösenden Ereignis und fertig.
Sobald eine Variable dazukommt, ein Ereignis ergänzen.
Das Skript weiß über die die Systemvariablen welche Variable es war, da muss man also nix ergänzen.
Weiter Informationen für das Skript, kann dieses auch aus den beteiligten Objekten wie dem Ereignis oder der Variable beziehen; z.b. aus dem Namen oder der Beschreibung.
Michael
Interessant… Ich habe ein Skript angelegt, welches bei der Änderung der 10 Variablen etwas machen soll. Dann habe ich alle diese 10 Variablen markiert und dann habe ich Objekt-Ändern aufgerufen und dort als Aktion dann das neue Skrip VariableChangeListener für alle 10 Variablen eingetragen
Dein Vorschlag wäre also anders… Hinter jede der variablen ein ausgelöstes Ereignis hängen und dann immer dort das Skript aufrufen, in dem man dann vermutlich den Auslöser ermitteln kann?
Das AKTION Script wird ausgelöst, wenn man als BEDIENER über Webfront o.ä. die Variable ändern möchte und schaltet das GERÄT. Wenn sich die Variable ändert (Statusrückmeldung oder durch Benutzerinteraktion) und du möchtest darauf reagieren, benötigst du ein ausgelöstes Ereignis. Sieht bei mir z.B. so aus:
Doch, aber das reagiert nicht auf geänderte Werte einer Variable.
Wie @tobiasr schon schrieb, ist das zum Bedienen einer Variable.
Schau dir bitte die Grundlagen in der Doku dazu an:
Was soll ich sagen, ich glaube euch ja gerne, aber wenn ich in meinem Popup die Variable A oder B ändere wird definitiv das dahinter gehängte Skript aufgerufen. Auch ohne ausgelöstes Ereignis. es ist ja als Aktion hinter die Variable gehängt.
Was meinst du hier?
In der Konsole? Die fragt sogar ob du nur den Wert setzen (simulieren) oder schalten (Aktion der Variable Ausführen) willst.
Das hat aber alles nix mit auf Änderungen von Werten reagieren zu tun, das können nur ausgelöste Ereignisse.
Hier missverstehen wir uns.
Ich setze durch die Slider in meinem IPSView-Popup bestimmte Variablen im Objektbaum. Hinter alle Variablen, die fachlich zu einem Zeitintervall gehören (StartMinute, StartStunde, StopMinute, StopStunde) habe ich das gleiche Skript gehängt. Dieses wird bei den Änderungen über IPSView bei jeder Änderung aufgerufen.
Von diesen Zeitintervallen habe ich in der View insgesamt 4 Stück (Szene 01 von/bis, Szene 02 von/bis, Szene03 von/bis und Szene 04 von/bis). Ich habe die Anforderung, dass ich mit dem Beenden des Popups für jede dieser Szenen ein anders Skript aufrufen will, welches mit den geänderten Zeiten, mal die Außenbeleuchtung, mal die Flurbeleuchtung etc. beeinflusst.
Über das einheitliche Skript hinter den Variablen habe ich im ersten Ansatz festgestellt, zu welcher Szene die beeinflussten Variablen gehören und habe dann in einer zentralen Variable die ID des auszuführenden, szenenspezifischen Zielskriptes eingetragen. Dieses wurde dann beim Beenden des Popups aufgerufen , nimmt die vorher geänderten Zeiten und macht damit, was es machen muss.
Mit Hilfe Eurer Hinweise mach ich es nun ganz anders.
Aufruf des Popups über Skript-Button (statt über Popup-Button und Verzicht auf Alias-Ids) und direktes Speichern der Skript-ID des, für die weitere Verarbeitung zuständen Skriptes in einer Variable. Dann Ändern der Zeitvariablen durch das Popup. Beim Beenden des Popups, Aufruf des Skriptes mit der vorher gespeicherten Skript-ID, die dann die manipulierten Variablen nimmt und weiterverarbeitet. Fertig.
Ja, weil es bei dir wirklich um Aktionsskripte geht. Das Thema vom TE war aber auf Änderungen von von Variablen zu reagieren.
Bei dir geht es um das Bedienen von Variablen.
Michael
Jo, so wird ein Schuh draus… Um bei Änderungen von Variablen (z.B. aus KNX) zu reagieren, brauche ich ein Ereignis und um auf Manipulationen durch die View zu reagieren reicht ein Skript.
Für Sammelmeldungen (also Fenster EG geschlossen) habe ich das so gelöst, das ich eine Dummyvariable erstellt, darunter aliasse der Fensterkontakte reingepackt und mir dann Ereignisse erstellt habe. Ist Fummelig, geht mit kopieren/einfügen aber gut und ich sehe es an einer zentralen stelle.
Hallo Kris,
sieht gut aus. Zum Verständnis… Über die Aktions bekommst Du die Änderungen der Kontakte mit. In Deinem Loop referenzierst Du über die Links auf die tatsächlichen Stati. Die Werte „1“ oder „2“ in deinem ParentGroupArray sind vermutlich Konstanten für das Erkennen ob Fenster auf oder Zu, oder Licht an oder aus? Und damit setzt Du dann den Merker, bzw. den Wert der ParentGroup (hier Fenster EG)
Kennst du das Etagenlicht ?
Da geht dann auch das ausschalten aller Lampen einer Gruppe.
Die Zuordnung erfolgt über Namen der Ereignisse und Variablen. Somit braucht es kein separaten Code im Ereignis.
Michael
Schaue ich mir auch mal an… Gute Ideen sind ja , besonders am Anfang Gold wert… Und kein separater Code im Ereignis klingt wie weniger Klicken, was ich persönlich immer gut finde…