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 …
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
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…
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.
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.
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?
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?!