KR_Ready, Konfiguration von einer Instanz auslesen und in eine andere schreiben

Erweiterungen PHP-Module (Entwicklung)
1

Hallo,

ich brauche mal einen Denkanstoß…

  1. Ist es richtig, wenn KR_Ready erreicht wird, dass ich davon ausgehen kann, dass alle Module geladen und verfügbar sind? (Habe im Kopf, dass IP-Symcon die Modul nach einem „Zufallsprinzip“ startet, somit ist dann nicht auszugehen, dass wenn ein Modul „ready“ ist, das andere auch schon „ready“ ist.

So nun zu meinem Vorhaben:

Ich habe ein Modul A, welches als (ich nenne es mal) Hauptinstanz dienen soll.

Ich habe ein weiteres Modul B, mit dem n-Instanzen angelegt werden. Diese sind und arbeiten eigenständig. Diese Instanzen sehe ich mal als-Subinstanzen von Modul A.

D.h. ich kann z.B. einen Switch in einer Instanz in Modul B betätigen.

Angenommen ich habe nun 10 Instanzen von Modul B und will bei „allen“ Instanzen von Modul B den Switch betätigen. Damit ich dies nicht 10 mal machen muss, nutze ich die Instanz von Modul A, welche dann in einer foreach-Schleife alle Instanzen von Modul B durchläuft.

Das klappt auch soweit, weil das schalten ja im laufenden Betrieb erfolgt und KR_READY vorhanden ist.

Modul A ist wie eine Art „Kontrollzentrum“ zu verstehen.

Nun zum Punkt:

In Modul A versuche ich mit IPS_GetProperty Daten der Konfiguration von Modul B auszulesen, welche in die Instanz von Modul A geschrieben werden sollen.

Ich habe es schon mit MessageSink probiert aber wenn ich einen manuellen Modul-Reload (MC_ReloadModule) mache bekomme ich als Fehlermeldung „InstanceManager*| Could not create instance interface“, was aus meiner Sicht bedeutet, dass das Modul noch nicht geladen ist.

Gibt es eine Möglichkeit abzufragen, ob ein „fremdes“ Modul gestartet ist oder welchen Lösungsansatz sollte man verfolgen?

Hoffe, es ist verständlich.

Gruß
UB

2

Zuerst mal… Falscher Bereich ich verschiebe das mal.
Dann fahre ich immer gerne; warum willst du das machen? Wo in IPS gibt eine Instanz welche 10 andere schalten soll. Sicher das dein Vorhanden nicht anders umzusetzen geht?

Bei einem ModulReload passiert genau das gleiche mit den Instanzen wie beim Neustart von IPS. Sie sind nicht verfügbar, erst wenn das Update durch ist.

Eine definierte Update-Funktion welche IPS im Anschluss startet gibt es nicht.
Michael

3

Hallo Michael,

ups, falsche Rubrik erwischt :wink:

Es geht um eine EMA. Die soll aus mehreren Zonen bestehen. Jetzt kann es sein, dass man nur eine Zone oder zwei schalten will oder auch alle.

Daher das Kontrollzentrum für alle.

Die Zonen können unterschiedliche Eigenschaften haben. D.h. wenn in einer Zone eine Eigenschaft vorhanden ist, soll sie im Kontrollzentrum sichtbar sein. Gibt es diese Eigenschaften in allen Zonen nicht, dann wir im Kontrollzentrum die Funktion versteckt. Zur Not kann ich das auch „manuell“ mit der Sichtbarkeit regeln, wollte es aber automatisieren.

Auch wenn in der Zone ein bestimmte Eigenschaft verändert wird, muss ich alle Zonen abfragen, ob in irgendeiner Zone die Eigenschaft noch vorhanden ist.

Hast du ne Idee?

Uli

4

Klassische EMAs haben keinen Bereich (Melder) in zwei Zonen (Meldebereichen).
Habe vor einiger Zeit eine physische EMA mit IPS verbunden.
Hier wird einfach alles einzelnen betrachtet.
Es gibt jeden Melder einmal, jede Area einmal usw…
Sichtbarkeit, welche Melder welcher Area angehört usw… Ist in dem IPSModul nicht abgebildet.
Sondern wurde durch Kategorien erreicht.
Bei Thema Sichtbarkeit ist es auch entgegen dem Best Practice, da es dem User die Kontrolle entzieht.

Wenn es darum geht die Funktion einer EMA mit IPS umzusetzen, Frage ich mich nur warum du die Eigenschaft von anderen Instanzen wissen musst.
So eine Art Kontrollzentrum gibt es ja bisher nicht.

Michael

5

Meine Idee ist folgende:

Es gibt unterschiedliche Zonen, z.B. EG und OG.

In der Zone EG gibt es zugewiesene Sensoren, wie z.B. Tür-/Fenstersensoren, Bewegungsmelder, Rauchmelder.
Diese Sensoren gehören zur Zone EG und gibt es auch nur einmal in dieser Zone und in keiner anderen.

Das gleiche gilt für die Zone OG.

So das klassische Beispiel.

Jetzt kann es aber sein, dass es einen Bewegungsmelder in der Zone EG gibt, aber nicht in der Zone OG.

Bei mir hat man zwei Möglichkeiten die Zone mit Bewegungsmelder zu schalten:

  1. Vollschutz, d.h. Tür/Fenstersensoren inkl. Bewegungsmelder (alle Sensoren)
  2. Hüllschutz, d.h. nur Tür/Fenstersensoren, also Anwesenheit der Bewohner

Wenn ich jetzt ein „Kontrollzentrum habe“ muss dort ja der Schalter „Hüllschutz“ sichtbar sein, da ja eine Zone diese Möglichkeit bietet und zwischen Voll- und Hüllschutz unterschieden werden kann. Die Bewegungsmelder werden für den Zeitraum „deaktiviert“, bzw. lösen bei Erkennung keinen Alarm aus.

Falls es in keiner Zone einen Bewegungsmelder gibt, so gibt es im gesamten System keine Unterscheidung zwischen Hüll- und Vollschutz. D.h. ein Schalter im „Kontrollzentrum“ ist unnötig und sollte ausgeblendet werden (weniger ist mehr).

Du hast recht mit BestPractise… das es aber ein privates Modul ist kann ich das verschmerzen.

Habe es jetzt mit einem manuellen Button im Actions Bereich des Konfigurationsformulars vom Kontrollzentrum gelöst, der die Sichtbarkeit regelt.

Stell dir vor du hast 4 oder mehr Zonen: Garage, Keller, EG, OG, DG und musst diese alle einzeln schalten, das ist doch kein Komfort, die Handsender schalten ja auch alle Zonen.

Ich kann mit dem Workarround leben, gerne nehme ich Anregungen auf…

Welche EMA setzt du denn ein?

Uli

6

Allgemein so etwas komplett in IPS nachzubauen wird nicht leicht.
Entweder bewerten die Zonen die Meldungen oder die Melder selber.
Letzteres würde ich persönlich umsetzen wollen. Geht aber nicht wenn ich hier fertige IPS-Instanzen bzw. Variablen von Instanzen haben.
Wobei ich selber gerade schon grübel, so etwas wird schnell komplex wenn man alle Eventualitäten berücksichtigen will.

Ich würde vermutlich nur ein Modul Typ ‚Area‘ / Bereich bauen.
Dieses bekommt ein Konfigurationsformular mit einer Liste, in dieser Trage ich alle IPS-Variablen ein welche zu dieser Zone gehören und kann in dieser Liste auch Haken setzen für Intern / Extern / immer (also nur Außenhaut bei Anwesenheit oder Vollschutz bzw immer für z.B. Rauchmelder)

Die Logik ist dann in der ‚Area‘-Instanz, welche ja über diese Liste weis, ob sie Melder mit ‚Intern‘ hat und dann eine Statusvariable zum schalten / visualisieren erzeugen muss.
Auf die IPS-Variablen in der Liste wird sich mit VM_Update registriert und somit werden Events alle Melder in der Instanz empfangen.
Somit kann auch eine Scharfschalteverhinderung ermöglicht werden, wenn z.B. ein Fenster offen ist.
Oder die Alarmmeldung für Extern / Intern sobald die ‚Area‘-Instanz scharf ist.

Das verschachteln von mehreren Bedienaktionen würde ich nicht über ein Modul lösen, sondern einfach durch ein Script in IPS welches dann alle Zonen-Instanzen scharf / intern / unscharf schaltet.

Noch mal eben zum eigentlichen Thema mit dem auslesen der Konfig von anderen Instanzen.
Warum platzierst du diese Eigenschaften nicht dort wo die wirklich benötigst ?
Also wenn dein Kontrollzentrum wissen muss welcher Melder was macht, dann stell es doch dort ein.
Mit den Listen sollte dies Problemlos möglich sein, wie ich es oben beschrieben habe.

Das hier hatte ich mal für jemanden mit IPS verbunden; den Link darf ich ja poste, ist ja Herstellerwebsite :wink:
MAP 5000-Familie
Allerdings in D nicht im freien Handel erhältlich; und richtet sich eher an Industrie und Gewerbekunden.

Michael

7

Hallo Michael,

danke für deine Ausführungen. Ja mit vielen „Funktionen“ wird es komplex, sollte aber machbar sein.

Bislang habe ich die Sensoren über ein Ereignis und einer Codeausführung „Alarm schlagen lassen“.

Man könnte es auch mit einem RegisterMessage und MessageSink machen… da überlege ich noch was für mich an sinnvollsten erscheint.

Gibt es eine Möglichkeit die registrierten Nachrichten irgendwo abzufragen, um zu überprüfen, welche alle registriert sind?

Wenn ich eine Instanz / Variable lösche, wird dann auch automatisch die zugehörige RegisterMessage gelöscht oder muss man vorher im Destroy ein UnregisterMessage machen?!

Habe in der Doku nichts dazu gefunden.

Gruß

Uli

8

Muss man alles selber machen.
Also selber merken, auch auf Delete registrieren und auch deregistrieren.
Beispiel:
IPSMySQLArchiv/module.php at fde006a1118a8056ecd6a1687773c6c5c8877dc8 · Nall-chan/IPSMySQLArchiv · GitHub

Achtung: $this->Vars ist ein InstanceBuffer ! Dort ist ein serialisiertes Array enthalten. Dient auch den alt neu Vergleich in ApplyChanges.
Michael

9

Danke für die Info.

Werden bei einem Neustart alle RegisterMessages neu geladen oder bleibt irgendwo im „Dunkeln“ etwas gespeichert.

D.h. wenn ich ein Modul / Instanz lösche, die ein RegisterMessage hatte, IPS neu starte, ist dann die ursprüngliche noch da? Vermutlich nicht…

@symcon: Wäre eine Funktion MS_GetRegisteredMessages($instanceID) nicht sinvoll, um die registrierten Nachrichten aufzulisten. Muss ja nicht eine Übersicht in der Kerninstanz sein oder wie die Timerliste.

Uli

Gesendet von iPad mit Tapatalk

10

Da davon nix in den Settings landet, ist alles weg nach einem Neustart.
Michael