RegisterMessage - übergeordnete I/O Instanz

Hallo.

ich finde es leider nicht in der Doku, oder ich bin blind.
Ich würde gerne in dem Modul reagieren, wenn die übergeordnete I/O Instanz auf inaktiv gesetzt wird.
Ist das möglich? Was musst ich mit RegisterMessage registrieren und wie werte ich das am besten aus?

Hintergrund: Jede Nacht verliert der MQTT Client die Verbindung zum Broker, wenn ich nun eine Funktion „auto reconnect“ einbaue, könnte ich dies im Modul abfangen und neu verbinden. Also wenn die I/O Instanz auf inaktiv springt, könnte ich über das Modul einen reconnect anstoßen. (Um sicherzustellen, dass der reconnect gewollt ist, würde ich natürlich eine Checkbox, für einen automatischen Reconnect, im Konfigurationsformular hinzufügen!)

Grüße,
Kai

Den reconnect macht IPS für dich, alle 60 Sekunden wenn der IO in Fehler geht.
Musst du gar nichts machen.
Im Gegenteil, wenn du dann am IO selber noch den auf deaktiv / aktiv setzt bekommst du das auch als Event und hast eine Endlosschleife.

Also den IO gar nicht beeinflussen.
Und dann schön hier auf IM_CHANGESTATUS horchen.
Dabei nicht FM_DISCONNECT und FM_CONNECT vergessen, sonst funktioniert es nicht mehr sobald der User einen anderen IO auswählt.
Beispiel: IPSBVIP/BVIPTraits.php at 4fe2331973a0017c3bac2cd0c5b449cf76841d3e · Nall-chan/IPSBVIP · GitHub

Und hier wird dann reagiert wenn er aktiv/inaktiv wurde:

Michael

Hallo Michael,

danke für die Antwort.
Ah das hört sich gut an, und sobald der I/O wieder aktiv ist kann ich die Authentifizierung von MQTT durchführen und der Client müsste wieder verbunden sein.
Das versuche ich! Vielen Dank!

Grüße,
Kai

Da musst da etwas mehr umbauen.
Aktuell nimmst du ja Einfluss:
IPS-KS-MQTT/module.php at cc1d169f5d82f9d50d25b886f8539ee9b9a0416a · Schnittcher/IPS-KS-MQTT · GitHub
Und sogar wenn man versucht den IO per Hand zu deaktivieren, aktiviert dein Modul ihn einfach wieder:
IPS-KS-MQTT/module.php at cc1d169f5d82f9d50d25b886f8539ee9b9a0416a · Schnittcher/IPS-KS-MQTT · GitHub

Damit die Gegenseite auch mitbekommt dass die Verbindung neu aufgebaut werden muss, ist es leider nötig etwas Einfluss auf den IO zu nehmen. Bei meinem verlinkten Splitter wird nur im Applychanges meiner Instanz auch einmalig der IO mit Applychanges befeuert um die TCP-Verbindung neu aufzubauen.
Dadurch wird auf jeden Fall IM_STATUSCHANGE gefeuert und der baut dann die Verbindung auf Protokollebene neu auf (TCP steht dann ja bereits).

Damit entfällt auch die ‚Open‘ Eigenschaft im Splitter.
Weil ob die Instanz nun verbunden wird oder nicht, wird allein durch den Haken im IO gesteuert.

Vereinfacht es etwas, wenn man nicht mehrere ‚Open‘ oder ‚Aktiv‘ Eigenschaften in der Kette von Instanzen hat :wink:

Michael

Edit:
@paresy:
Kann der ClientSocket nicht auch bitte ein Feld im Datenaustausch bekommen, um einen ‚Neustart‘ der TCP Verbindung zu erzwingen?
Dann kann das IPS_ApplyChanges($IO) entfallen :slight_smile:

Danke Michael.
Das Modul stammt ja nicht von mir, ich habe es nur erweitert.
Dann werde ich mir das mal anschauen. Wenn ich es richtig verstanden habe, sollte es ja nicht so schwer sein. :smiley:

Grüße,
Kai

Gesendet von iPhone mit Tapatalk

Hallo Michael,

ich baue gerade ein Modul, wo ich per Telnet auf ein Gerät zugreifen will. Daher habe ich ein Device und einen Client Socket als I/O. Den Splitter habe ich jetzt erstmal nicht verwendet.

Wenn ich die Telnet Verbindung aufbaue, muss ich mich einmal Authentifizieren, ansonsten geht der Client Socket nach 60 Sekunden in einen Fehler. IPS versucht dann wieder zu verbinden.

Meine Idee, auf den Status des Client Socket per MessageSink horchen und dann das Login ausführen.

Wenn ich mir oben die Bespiele ansehe, müsste ich ja ganz nah dran sein. Richtig?

Uli

Antworte mir mal selber :smiley:

Bin am Ziel… funktioniert… muss jetzt nur einmal gucken, wie komplex ich das machen mit FM_CONNECT und FM_DISCONNECT.

Uli