Problem mit SendDataToParent bei Modul-Update

[Bayaro]

Abend!

Ich schon wieder

Habe in meinem aktuellen Modul ein Problem beim Modul-Update festgestellt...
...während das Modul-Update läuft funktioniert der I/O nicht, aber leider werden beim Modul-Update erst die Device-Instanzen aktualisiert, welche ein ApplyChanges ausführen und dabei Daten an den I/O loswerden wollen und da auch eine sinnvolle Antwort erwarten/brauchen - was aber nicht funktioniert, weil der I/O ja nicht bereit ist.

Jetzt dachte ich, dass ich ganz schlau einfach eine kleine while-Schleife einbaue...aber war nichts Denn während er in der while-Schleife hängt, macht er im Hintergrund wohl nicht mit dem Update vom I/O weiter.
Log-Ausgabe zeigt mir dann an, dass er erst von Device-Instanz 1 seine 4 Wiederholungen erfolglos macht und auf Fehler geht, dann von Device-Instanz 2 die 4 Wiederholungen versucht und auf Fehler geht - danach aktualisiert sich der I/O - und dann funktionieren die Device-Instanzen auch wieder.
Aber beim ApplyChanges der Device-Instanzen werden z.B.Variablenprofile mit den Daten vom Cloud-Server (die der I/O liefern soll) aktualisiert usw - was aber dann beim Modul-Update in die Hose geht

Wie könnte ich das Problem lösen? Die Reihenfolge wie die Instanzen aktualisiert werden sollen einzustellen wäre toll, aber das ist wohl nicht möglich. Oder werden die nach dem Alphabet aktualisiert? Dann wäre eine unschöne aber mögliche Lösung den den Ordner "_Device" in "_ZDevice" zu ändern?!

EDIT: Das der I/O beim Modul-Update nicht funktioniert verstehe ich ja noch, aber müsste der I/O dann als Status nicht was anderes als 102 haben? Ich prüfe aber direkt vor dem SendDataToParent, ob der I/O den Status 102 hat und da kommt das Modul noch erfolgreich drüber und danach schlägt SendDataToParent mit einem FALSE fehl

Vielen Dank im Voraus und Grüße,
Chris

[paresy]

Kannst du mal ein Mini Beispiel machen, dass den Fehler zeigt? Der I/O wird ja nicht aktualisiert und sollte sollte der auch beim Update problemlos laufen. Was für einen I/O hast du denn in Benutzung?

paresy

[Bayaro]

Hmmm...eher schwer :-\

Den IO habe ich selbst geschrieben und der wird im Modul mitgeliefert - deshalb wird er beim Modul-Update auch aktualisiert.
Im IO kann man Zugangsdaten für einen Cloud-Server eintragen und der IO hält dann die Verbindung mit dem Cloud-Server und alle Geräte-Instanzen reden über den IO mit dem Cloud-Server.

Was mir eben noch aufgefallen ist - ein paar Sekunden nach dem Update schickt die IO Instanz an die Device-Instanzen ein Status 102. Was für mich eigentlich bedeutet, dass der IO keinen 102 hatte beim Update - was ich auch erwarten würde. Aber meine Prüfung kurz vor dem SendDataToParent vom IO sagt auch 102. Vmtl ist das alles in einem sehr engen Zeitfenster und geht deshalb in die Hose

Schönen Abend und Grüße,
Chris

[Nall-chan]

Nein das ist korrekt. Die Annahme daß der Status vorher anders war ist falsch.
Er sendet ein 102 beim Applychanges, da du ja vermutlich einen SetStatus 102 dort setzt. Dabei ist es egal welchen Status die Instanz vorher hatte (inkl. 102).
Das ist dann die Meldung (an z.b. registrierte Childs) das er jetzt betriebsbereit ist und z.b. deine Childs ihre Aktualisierung starten können.
Der Status ist immer eine Aktualisierung, keine Änderung.
Michael

[Bayaro]

@ Nall-chan: Stimmt...ich setze im ApplyChanges vom IO ein 102, wenn alles ok ist - das geht dann natürlich an die Childs.

Ich könnte als Lösung für mein Problem beim MessageSink vom IO mit 102 in der Geräte-Instanz ein ApplyChanges auslösen, allerdings wären das dann beim Update 2 x ApplyChanges in der Geräte-Instanz. Einmal beim Update von der Geräte-Instanz selbst und ein paar Sekunden später dann nochmal, wenn der IO sein 102 an die Geräte-Intanzen schickt...hmmmm...
Was besseres fällt mir aktuell nicht ein :-\

Leider ist die Kommunikation vom Modul mit dem Cloud-Server relativ komplex (ich brauche verschiedene API-Abfragen um beim ApplyChanges Variablen-Profile zu setzen/aktualisieren und um noch einige andere Dinge anzustellen).

Einen Buffer mit Timestamp machen, der ein ApplyChanges innerhalb von X Sekunden "blockt" (zur "Entprellung") finde ich eher doof, weil dann der User nicht schnell Sachen in der Geräte-Instanz umstellen könnte.

Mal eine Nacht drüber schlafen... Gn8
-Chris-