zum einen bleibt die Anzeige der InstanzID auf ‚Laden…‘ stehen, obwohl die Geräteinstanz erfolgreich angelegt wurde
zum anderen wird bei jeder Anlage einer Geräteinstanz ein zusätzlicher IO angelegt. In der angelegten Geräteinstanz ist dagegen der korrekte IO (mit dem auch der Konfigurator verbunden ist) eingetragen. Der zusätzliche IO steht dann auf fehlerhaft, da bei ihm die Verbindungsdaten fehlen.
Sowohl im Gerätemodul als auch im Konfigurator gibt es den gleichen
$this->RequireParent(Guid::CloudIO);
Hast du eine Idee, was die Ursache sein könnte? Ich scheine irgendetwas übersehen/vergessen zu haben.
Burkhard
Edit: Punkt zwei (Anlage eines fehlerhaften zusätzlichen IO) tritt nicht auf, wenn der IO auf inaktiv statt fehlerhaft gesetzt wird. Ist das so gewollt?
Die Anzeige bleibt auf „Laden…“ bis die Instanz korrekt nach Vorgabe konfiguriert ist. Wenn das nie passiert, dann bleibt der Konfigurator da hängen. Der typische Fehler, den ich schon ein paar mal beobachtet habe, sind unpassende Dateitypen. Das passiert, wenn das Modul beispielsweise eine Portnummer als String speichert, diese vom Konfigurator allerdings als Zahl angegeben ist. Die betroffene Eigenschaft kannst du auch ganz schnell finden, wenn du den Konfigurator neu lädst. Dann sollte die Instanz nämlich als falsch konfiguriert angezeigt werden. Überprüfe die also einfach und er zeigt an, was fehlerhaft ist.
Das Zurückbleiben eines fehlerhaften I/Os kann ich mir wiederum nicht seitens des Konfigurators erklären. Dieser sollte nämlich eigentlich aufräumen, wenn er Splitter oder I/Os austauscht. Kann es sein, dass hier im Gerät schon etwas schiefläuft und dies zwei I/Os erstellt? Kommt der Fehler auch wenn du die Instanz ohne Konfigurator erstellst?
Perfekt. Das war es. Ich hätte es alleine nie gefunden.
Das passiert leider nicht. Nach einem erneuten Laden war immer alles ok.
Ok. Das schränkt die Suche dann schon mal ein. Wenn ich ein Gerät erstelle, dann will er in der Tat einen zweiten I/O erstellen, obwohl es bereits einen passenden (nämlich den vom Konfigurator erstellten) gibt. Müsste er sich da nicht mit dem bestehenden verbinden? Was könnte ihm da fehlen?
Die Frage ist, was dein Gerät da genau macht. Vielleicht trage ich einfach bei wie es laufen sollte und du gleichst es mit der Realität ab:
Fall 1: create ist eine einzelne Konfiguration
Instanz wird erstellt und entsprechend der Vorgaben konfiguriert
Falls das Gerät mit dem I/O bzw. Splitter des Konfigurators kompatibel ist und nicht das einzige Kind seines I/O bzw. Splitter ist, wird es an den I/O bzw. Splitter des Konfigurators gehängt (Falls es das einzige Kind ist, geht der Konfigurator davon aus, dass ForceParent/RequireParent verwendet wurde und das Gerät seinen eigenen I/O bzw. Splitter braucht)
Fall 2: create als Kette
Instanz wird erstellt und entsprechend der Vorgaben konfiguriert
Falls die eigene Kette zur Konfiguration passt, alles gut
Falls die aktuelle Kette nicht passt und das Gerät das einzige an der Kette ist, wird diese umkonfiguriert bzw. im Fall von unpassenden Modulen werden neue angelegt und die alten gelöscht
Falls die Kette geteilt ist, darf sich die Instanz scheinbar ihren I/O bzw. Splitter teilen und schaut ob es eine passende existierende Kette gibt. Falls ja, hängt sie sich daran. Ansonsten wird analog zu Punkt 3 eine neue Kette erstellt.
Was ich mir noch vorstellen könnte: Dein Gerät erstellt einen I/O beim Erstellen mit der Standardkonfiguration. Wird danach die tatsächliche Konfiguration übernommen, benötigt das Gerät einen anderen I/O welchen es sich per RequireParent erstellt und sich von dem vorherigen löst. Dann geht der Konfigurator rüber, aber der vorherige I/O ist ja schon längst getrennt…
Fall zwei möchte ich mal gerade ausklammern, um es (für mich) nicht zu kompliziert zu machen. Ich habe nur Device, Konfigurator und IO Cloud.
Ein Device soll sowohl manuell als auch über den Konfigurator anlegbar sein. Damit auch gleich der IO mit angelegt wird, haben sowohl Device als auch Konfigurator den RequireParent im Create().
Soweit ich es verstehe muss der RequireParent vorhanden sein, damit eine Anlage bzw eine Verknüpfung mit einem IO geschieht. Ich habe es auch ohne probiert, aber dann wird kein IO angelegt oder verknüpft.
Den Punkt habe ich leider noch nicht ganz verstanden. Was bedeutet die Einschränkung
beim create des ersten Device ist ja bereits der Konfigurator ein Kind des IO und somit ist es nicht mehr das einzige Kind und somit sollte es an den I/O gehängt werden. Wird es aber nicht.
Auch im Fall, dass ich das Device manuell anlege, wird es nicht an den vorhandenen IO gehängt, sondern ein neuer angelegt.
Vielleicht erwarte ich auch zuviel. Sorry, dass ich so hartnäckig bin. Aber ich würde es gerne verstehen.
Ok, wenn es keine Kette gibt, dann sollte das eigentlich relativ einfach sein:
Ein Gerät wird erstellt und erstellt sich selbstständig per RequireParent einen neuen I/O
Die Konfiguration aus dem Konfigurator wird angewandt. Wird hierbei vielleicht noch ein I/O angelegt? Da sehe ich das Potential, dass etwas schiefläuft.
Der Konfigurator sieht, dass am I/O des Geräts nur das Gerät selbst hängt. Daher geht er (hier korrekt) davon aus, dass das Gerät einen eigenen I/O braucht und macht nichts weiter
Manche Geräte brauchen ja bekannterweise ihren eigenen I/O. Dafür gibt es ja RequireParent bzw. ForceParent. Jetzt kann der Konfigurator ja aber nicht in das Modul schauen und weiß nicht, welche Funktionen aufgerufen wurden. Daher verwendet der Konfigurator eine Approximation: Hat der I/O der neuen Instanz nur die Instanz an sich hängen, dann wurde dieser wahrscheinlich per RequireParent bzw. ForceParent erstellt und die Instanz braucht ihren eigenen I/O. Hängen an dem I/O neben der neu erstellten Instanz noch andere, so wurde wohl ConnectParent verwendet und die Instanz darf ggfs. an existierende I/Os angehängt werden.
Kannst ja sonst mal deinen Quellcode teilen, dann schaue ich da gerne mal rüber.
