IPS 5.5 und HasActiveParent()

Hallo,

ich habe gestern auf 5.5 aktualisiert (IP-Symcon 5.5, Ubuntu, 27.11.2020, 6a6cc96dfcca), hat alles prima geklappt, Problem habe ich nur folgendes:

ich habe mein Dyson-Modul, das hat als Parent den MQTTClient (von KaiS) und dies benutzt ja wiederum die Client-Socket.

Alle Verbindungen sind i.O., Daten fliesen in beide Richtungen …

Ich benutze seit längeren HasActiveParent in meinen Module um zu prüfen, ob es einen funktionsfähigen Parent gibt.

Nun, $this->HasActiveParent() in DysonDevice-Modul liefert jetzt immer false zurück, obwohl wie gesagt, die Kette in Ordnung ist, keine Markierung bei den Instanzen und dieKommunikation stattfindet.

Ein IPS-Reboot brachte keine Änderung.

Vor dem Update (also mit 5.4) lief das seit Monaten ohne Mucken. Und in meinen anderen Modulen funktioniert die gleiche Abfrage weiterhin einwandfrei …

Hat sich da was geändert?

Danke & Gruß
demel

War es nicht so, dass es jetzt den Client auch von Symcon gibt?

Uli

Gesendet von iPhone mit Tapatalk

ja, soll es geben. Aber eigentlich ist meine Frage, warum in diesem Fall HasActiveParent() (nach dem Update) nicht mehr funktioniert

demel

Magst du mal prüfen, ob alle Modul in der Kette korrekt auf IS_ACTIVE (102) stehen?

paresy

hi,

ja, steht alles auf IS_ACTIVE

gruß
demel

Denn nur darauf prüfen wir. Git Blame sagt auch, dass wir daran nichts geändert haben seit Monaten.

paresy

Hallo paresy,

ich hatte nur nach einem Icon in der Status-Spalte geschaut, und da dort nichts stand … sorry.
Nun habe ich den Status explizit mit GetInstance() abgefragt und siehe da, der MQTTClient von KaiS bleibt im Status 101 (IS_CREATING) stehen.

Ich habe rasch nachgeschaut, da wird in dem Modul im ApplyChanges() gar kein SetStatus(IS_ACTIVE) aufgerufen.

In dem Child (DysonDevice) habe ich ein GetConfigurationForParent(), das im MQTTClient alle Felder auf ReadOnly setzt; das hatte ich testhalber mal geändert und getestet indem ich eine Änderung durchgeführt und gespeichert habe. Also ist das nicht das Problem.

ich frage mich
a) ob das so ok ist, das im ApplyChanges() kein SetStatus() gemacht wird?
b) ob sich hier vielleicht was geändert hat (z.B. etwas im parent::ApplyChanges() ), denn in 5.4 hat das keine Probleme gemacht

Gruß
demel

Hallo demel,

ich stelle exakt das selbe Verhalten nach dem Update auf 5.5 zwischen den MQTT Client von KaiS und meinem Roomba Modul fest.
Erstmal Danke für den Tipp - der MQTT Client bleibt bei mir auch im 101 Status hängen - aber ich habe keine Ahnung warum.

Natürlich kann ich nach dem MQTTConnect() im Modul den Status via SetStatus() auf 102 setzen (und das klappt dann auch), jedoch verstehe ich nicht warum das notwendig ist.
In meinem Modul springt der Status automatisch auf 102 - ohne das ich irgendwo SetStatus() aufrufe.

Bist Du hier weiter gekommen?

Einzige Idee: Kann es sein, dass der Funktionsprefix MQTTC identisch zu dem des neuen integrierten Moduls ist? Kommt es hier vielleicht zu einem Konflikt?
Vielleicht komme ich morgen mal dazu dies auszuprobieren.

Ich habe auch schon überlegt auf den nun integrierten MQTT Client zu wechseln, jedoch scheint dieser aktuell noch nicht das Protokoll 3.1.1 zu unterstützen oder zumindest kann ich aktuell keine ClientId setzen - ohne dies lehnt der iRobot Roomba leider die Verbindung ab…

Über jede Idee/Tipp bin ich dankbar :wink:

Grüße
TiTan

Hallo,

nein, wirklich weitergekommen bin ich nicht. Ich hatte KaiS angeschrieben, ob es einen besonderen Grund gibt, warum er kein IS_Active setzt, aber noch keine Antwort bekommen.
Einstweilen habe ich in seinem Modul das SetStatus() eingebaut, damit ist es wieder in Ordnjng.

Ich habe noch keine Zeit gehabt, ein weitere IPS-Testsystem mit 5.4 aufzubauen, um ganz sicher nachweisen zu können, das sich das Verhalten mit 5.5 geändert hat.

Von paresy habe ich auch noch nichts mehr gehört.

gruß
demel

Hallo,

Kai hat sich gerade gemeldet, ich habe einen PR erstellt, der in ApplyChanges() ein SetSTatus(IS_ACTIVE) macht, das hat bei mir geholfen. Kai wird den sicherlich bald übernehmen und eine neu Version im Modul-Store einreichen.

Gruß
demel

Sorry für die späte Antwort. Ich habe mir das Problem noch einmal angesehen und wir haben zur 5.5 tatsächlich am Status einiges umgebaut. Was aber passieren sollte: Sofern nach dem ApplyChanges der Status immer noch auf IS_CREATING steht, stellt der Kernel diesen automatisch auf IS_ACTIVE (Das ist auch das 5.4 und älter Verhalten).

Ich habe aktuell im Code auch nicht sehen könnten, warum bei Kai’s Modul dies nicht passiert. Er setzt den Status ja auf nichts anderes zwischendurch. (Ausnahme wäre, dass ApplyChanges nicht sauber durchgeht und mit einer Meldung abbricht)

Könnt ihr einmal dies hier laufen lassen, ob noch weitere Instanzen bei euch betroffen sind?


foreach(IPS_GetInstanceList() as $id) {
    $i = IPS_GetInstance($id);
    echo $id . " > " . $i['InstanceStatus'] . PHP_EOL;
}

paresy

Habe auch einige Shellys im Einsatz. Den Code etwas umgebaut:

foreach(IPS_GetInstanceList() as $id) {
    $i = IPS_GetInstance($id);
    echo $i['ModuleInfo']['ModuleName'].": ".$id . " > " . $i['InstanceStatus'] . PHP_EOL;
}  

Symcon Version: IP-Symcon 5.5, Windows x64, 08.11.2020, 2ec4065585af - Shelly Modul 4.3.1

Dummy Module: 38436 > 102
Client Socket: 59451 > 102
ShellyConfigurator: 44964 > 102
Connect Control: 34331 > 104
Skin Control: 25002 > 102
Store Control: 28110 > 102
ISDN: 30978 > 105
DenonSplitterTelnet: 46176 > 102
Archive Control: 25738 > 102
WebServer: 14899 > 102
Dummy Module: 22288 > 102
Serial Port: 21410 > 102
ShellyDimmer: 52222 > 102
DenonAVRTelnet: 28610 > 102
Client Socket: 58816 > 104
Event Control: 19720 > 102
Notification Control: 18841 > 102
Dummy Module: 18020 > 102
MQTT Server Device: 42425 > 102
Server Socket: 50888 > 102
Util Control: 12645 > 102
WebFront Visualization: 11708 > 102
Module Control: 54980 > 102
ShellyDimmer: 29068 > 102
DenonAVRTelnet: 14981 > 102
ShellyPlug: 26161 > 102
DNSSD Control: 57090 > 102
MQTT Server Configurator: 24425 > 102
SSDP Control: 29430 > 102
Calendar Control: 59604 > 102
ShellyDimmer: 37988 > 102
Location Control: 35135 > 102
WebHook Control: 29075 > 102
WebOAuth Control: 41306 > 102
MQTT Server: 54940 > 102
DenonAVRTelnet: 24351 > 102
MQTT Server: 52934 > 102
Client Socket: 21289 > 102
Tasmota: 36043 > 102
Dummy Module: 35184 > 102
Cutter: 52794 > 102
Register Variable: 45735 > 102
TasmotaConfigurator: 12889 > 102
MQTT Server Configurator: 47479 > 102
Server Socket: 19919 > 102
MQTT Server Device: 40085 > 102

Sieht soweit aber gut aus - da klebt nichts auf dem problematischen 101er Status.

paresy

Hallo,

beim mit steht alles auf 102 - im MQTTClient-Modul hatte ich eingebaut, das er ein SetStatus() im ApplyChanges() macht.

demel

Hallo Zusammen,

bei meinem ersten Versuch standen nun auch alle Instanzen auf 102. Habe dann aber mal getestet ob es ggf. mit dem Prefix MQTTC zusammen hängt und entsprechend den Patch nochmal „ausgebaut“ sowie das Prefix geändert.
Ergebnis: Nein daran lags nicht.

Aber: Dazu musste ich Symcon neu starten - bzw. hab ich gleich den ganzen Server durch gestartet und siehe da -> Nach dem Neustart steht neben dem MQTT Client auch eine Sonos Instanz auf 101…
Es handelt sich dabei um eine Geräte Instanz von GitHub - tkugelberg/SymconSonos: Sonos PHP Module for IP-Symcon.
Interessant dabei ist, dass es hiervon mehrere gibt (2 Stück) und nur eine von beiden hängt nach dem Neustart in 101!?

@paresy in der ApplyChanges kann ich im MQTT Modul nichts finden was wirklich durch externe Faktoren „Fehlschlagen“ kann… aber wie verhält es sich mit der MessageSink? Das MQTT Modul startet dort den Verbindungaufbau im MQTT Protokoll und das könnte ja durchaus fehlschlagen wenn es beim Start noch irgendwo im Netz klemmt…
Das Sonos Modul hat wiederum keine MessageSink aber in der ApplyChanges ist einiges an „Verbindungsaufbau“ drin was wohl durchaus fehlschlagen könnte?!

Sollte sowas in einen try… catch…?

Grüße TiTan