Es wird halt alles immer komplexer und komplexer mit den Zusammenhängen und den zu organisierenden Scripten.
Nach Rückkehr muss man deaktivierte Instanzen wieder aktivieren etc. etc. Ping ist auch nicht der letzte Schluss, denn nicht alle „dummen“ Devices kennen Ping also muss man weiter differenzieren.
Wenn das Problem auch noch andere haben, könnte man vielleicht Paresy dazu überreden, Instanzen eine weitere Property zu verpassen, die dann die IPS-Checks „staffelt“:
Am Anfang häufig - wie bisher, dann stündlich, 2x täglich, täglich etc.
und evtl. einen System-Event spendieren „check Instances“, der dann z.B. von einem „wieder-zuhause-Sscript“ getriggert werden könnte, was dann auch eine Meldung ausgeben kann: „Bitte xyz wieder einschalten“.
und evtl. einen System-Event spendieren „check Instances“, der dann z.B. von einem „wieder-zuhause-Sscript“ getriggert werden könnte, was dann auch eine Meldung ausgeben kann: „Bitte xyz wieder einschalten“.
Statusänderungen einer Instanz kannst Du doch über den Event-Handler auf ein Skript triggern lassen.
Ich will nicht etwas auswerten, was sich „zufällig eingestellt“ hat. Ich möchte die Erkennung, die zu Deinem beschriebenen Event führt, steuern (und sofort auswerten) können - quasi ein „wie ist denn jetzt gerade der Zustand?“
Im Moment ist das m.E. nicht möglich. Ich bekomme nur entweder den Zustand der letzten Überwachung (was je nach Einstellungen ne Weile her sein kann) und das muss ich auch in einer Loop über alle Instanzen programmieren, oder „zufällig irgendwann“ einen Event.
Ich hätte sozusagen gerne eine „aktuelle Abfrage“. Return könnte ein Array sein mit ID => Status.
Wenn Du aber so ne Lösung schon hast, bitte her damit. Gucke ich mir gerne an.
Wenn ich z.b. einen Connector für einen Verstärker habe und ich den ein- bzw. ausschalte dann ist die Statusänderung dieser Instanz alles andere als zufällig. Damit setze ich z.b. die Bedienelemente des Verstärker im Webfront auf „hidden“ bzw. einen Skripttimer für Statusabfragen auf inaktiv.
Wenn der Initiator aber nicht die Socket-Instanz sein soll dann kannst Du doch auch in deinem Skript - bleiben wir mal bei dem Beispiel- welches Befehle an die UPnP-Geräte schickt den Status der jeweiligen Instanz abfragen. Ist diese Online geht der Befehl raus, wenn nicht dann halt nicht.
Oder habe ich Deine Problemstellung nicht verstanden?
Ich glaube, wir schauen auf dieselbe Sache einfach aus verschiedenen Blickwinkeln.
Oder ich verstehe vielleicht Deine Antworten nicht, kann auch sein.
Mein Blickwinkel ist die Minimierung von Überwachungs-Aufgaben.
Also: Es ist klar, dass man mit Aufwand das auch alles selbst tracken und handeln kann. Der Aufwand besteht dann eben darin, dass man den Event-Handler für jede neue (i/o)Instanz Pflegen muss, sich ein ein- und ausschalte Script bauen muss, die Stati in Variablen Puffern muss etc.
Wenn ich dann auch noch das „zufällige“ wiedereinschalten (ohne zusätzliche Interaktion über IPS) handeln will, muss ich die ausgeschalteten Instanzen regelmässig selbst wieder versuchen, in Betrieb zu nehmen etc. - Nimm z.B. mal zwei oder drei Stunden Stromfreischalten eines Zimmers, weil man „kurz“ was verklemmen will.
Im Grund möchte ich ja nur zwei Dinge geringfügig ändern:
1.) die „überflüssig vielen“ Log Einträge reduzieren, die entstehen „wenn man nix macht“
2.) EINE (einzige) Abfrage stellen können, um den aktuellen (und soeben abgefragten) Status aller Instanzen zurück zu bekommen
Da habe ich zwar noch keine Allgemeinlösung fertig - aber machbar sollte das relativ einfach sein.
Wenn es Dir um die I/O-Instanzen geht dann sollten die Child-IDs der Rubrik abfragbar sein. Wenn Du die hast kannst Du deren Stati abfragen, in ein Array schreiben und auswerten wie es Dir beliebt.