[Frage] Wie Devices beim "save config" sortieren?

[betateilchen]

Grundsätzliche Frage zur Diskussion:

Würde es nicht Sinn machen, bei einem "save config" automatisiert eine gewisse Reihenfolge einzuhalten?

• alles unter global
• alle Devices, die I/O Operationen ausführen
• alle anderen Devices

Auf das Thema gekommen bin ich durch diesen Thread und den darin gegebenen, durchaus nachvollziehbaren Hinweis.

http://forum.fhem.de/index.php/topic,20959.0.html

[justme1968]

das löst das problem glaube ich nur zum teil. wenn plötzliche alle IODevs vorne stehen und es mehr als ein passendes gibt ist es dann nämlich auch falsch.

ich denke es wäre besser den mechanismus generell umzustellen und das IODev das beim autocreate als 'passend' gefunden wird immer ins attr IODev eintragen und speichern. (in verbindung mit dem $proposed parater verwende ich das schon für die HUEDevices und bin gerade dabei die jeelink module drauf umzustellen. das funktioniert sehr gut und zuverlässig vorhersehbar.)

dann würde es grundsätzlich keine überraschungen mehr geben weil beim neustart etwas nicht mehr passt. die zuordnung wäre fest und hängt nicht mehr von irgend einer reihenfolge ab.

[betateilchen]

Aber würde das nicht voraussetzen, dass jedes Modul dann im Bedarfsfall so lange warten und den Verbindungsaufbau verzögern/wiederholen muss, bis das IO-Device dann wirklich existiert? Soweit ich gesehen habe, gibt es durchaus Module, die das nicht tun.

[justme1968]

wenn das IODev im define noch nicht vorhanden ist funktioniert das assignIodev nicht wirklich. das sollte auch jetzt schon probleme machen.

wenn es vorhanden ist wird er zustand beim anlegen festgeschrieben sofern es der anwender nicht überschreibt.

das sollte im fast allen fällen genau so gut sein wie es die automatische auswahl jetzt ist mit dem zusätzlichen vorteil das es konsistent erhalten bleibt so lange der anwender es nicht explizit ändert.

es sollte also in meinem fall schlechter sein als es jetzt ist und in fast allen fällen die jetzt proble machen deutlich besser.

[betateilchen]

wenn das IODev im define noch nicht vorhanden ist funktioniert das assignIodev nicht wirklich.

Aber genau das ist doch der Hintergrund meiner Fragestellung...

[justme1968]

ich meine dann funktioniert es auch jetzt schon nicht wirklich.

wenn du meinst das durch das nach vorne sortieren beim nächsten starten dann die automatische zuordnung funktioniert stimmt das vermutlich. dann wäre das noch vorne sortieren aller devices die Clients bzw MatchList gesetzt haben auch in verbindung mit dem festen zuweisen sinnvoll.

[betateilchen]

ich meine dann funktioniert es auch jetzt schon nicht wirklich.

So langsam kommst Du dahinter, worum es mir geht

[justme1968]

das ändert aber nichts daran das mein vorschlag genau so sinnvoll ist

[betateilchen]

Das habe ich nie bestritten - in Kombination können diese beiden Maßnahmen eine erhebliche Stabilisierung bringen.

[rudolfkoenig]

erhebliche Stabilisierung

Das klingt schlimmer als es ist, da mAn die Probleme selten auftauchen.

Bei der aktuellen Implementation gibt es ein Problem dann, wenn ein Benutzer sein FS20 vor dem CUL definiert, oder spaeter das CUL entfernt, und z.Bsp. ein neues CUNO anlegt. In diesem Fall schreien beim Anlegen alle FS20-Geraete "No I/O device found". Das IODev Attribut loest das eigentliche Problem, aber nicht die Fehlermeldung im Log, dies kann man  z.Zt. nur durch verlegen des IODevs nach vorne machen. Dies ist bei fhem.cfg relativ einfach, bei der configDB vmtl. aufwendiger.

@beteteilchen: Dein Vorschlag wuerde dieses Problem loesen, im folgenden Fall aber Verwirrung stiften: man hat das Erdgeschoss mit CUL+FS20 abgedeckt, nun geht es mit CUNO+FS20 im dritten Stock weiter. Ploetzlich versucht FHEM alle nicht explizit zugeordnete FS20 im Erdgeschoss ueber das CUNO im dritten Stock zu erreichen. Dieser Fall funktioniert aktuell ohne Probleme, IODev Attribut braucht man auch nicht unbedigt.

Z.Zt gefaellt mir ein auf justme1968's Idee basierende Loesung am besten: AssignIoPort setzt das Attribut falls IODev vorhanden, warnt im Fehlerfall aber nur falls !$init_done. Fuer diesen Zweck gibt es eine Schleife nach dem Initalisieren.

[betateilchen]

Du hast recht, es klingt schlimmer als es ist.

@beteteilchen: Dein Vorschlag wuerde dieses Problem loesen, im folgenden Fall aber Verwirrung stiften:

Z.Zt gefaellt mir ein auf justme1968's Idee basierende Loesung

Ja, andres Idee mit AssignIoPort finde ich auch sehr gut - deshalb ja auch meine Bemerkung, dass die Kombination aus Sortieren + AssignIoPort wohl die beste Lösung wäre. Da dürfte eigentlich auch der von Dir beschriebene Fall keine Verwirrung mehr stiften.

Dies ist bei fhem.cfg relativ einfach, bei der configDB vmtl. aufwendiger.

Nachdem ich eine Nacht über das ganze Thema geschlafen habe, stellt sich mir die Frage, ob das Problem derzeit ohnehin nicht nur dann auftreten kann, wenn der Benutzer die Einträge in der fhem.cfg von Hand vornimmt und nicht über das Frontend.

Denn:

• Beim "save config" wird die laufende Installation aus dem Speicher weggeschrieben. Man sollte davon ausgehen können, dass diese Konfiguration so funktioniert, wie der Anwender es gerne möchte
• Das Wegschreiben der define erfolgt derzeit numerisch sortiert nach der Reihenfolge der in der aktuellen Konfiguration angelegten define. Es kann also (für mein Verständnis: normalerweise) kein Client-Device VOR seinem zugehörigen IO-Device angelegt sein. Ausnahme: der beschriebene Sonderfall.
• Der beschriebene Sonderfall "mehrere passende IO Devices für das gleiche Client-Device" würde also nur dann zu Problemen führen, wenn die Zuordnung des IO am Client erst nachträglich geändert wird, z.B. weil ein zweites IO Device in Betrieb genommen wird.
• Der beschriebene Sonderfall ließe sich auch bei Verwendung von configDB durch AssignIoPort und korrektes Verhalten des Client-Device (warten bis $init_done) abfangen.

Dieses geforderte "nützliche" Client-Verhalten sollte dann aber irgendwann als wichtiger Entwicklungshinweis /-richtlinie publiziert werden, damit das in die hardwareabhängigen Module auch so eingebaut wird. Damit hätte man wieder einen tatsächlichen Grund weniger, die fhem.cfg "von Hand" ändern (Umstellen der Reihenfolge) zu müssen.

[rudolfkoenig]

Hab den Vorschlag eingecheckt.
@Betateilchen: ein Problem kann weiterhin auftauchen, falls jemand das IODevice entfernt (delete CUL_0).

[betateilchen]

ja. Aber Dummheit muss und sollte bestraft werden... 

[betateilchen]

Hab den Vorschlag eingecheckt.

Damit scheint es irgendwelche Probleme zu geben:

http://forum.fhem.de/index.php/topic,21176.0.html

[rudolfkoenig]

Danke fuer den Hinweis, da ist noch mehr im Argen, z.Bsp. verhaelt sich CUL_WS beim gesetzten IODev Attribut anders, als ohne, siehe http://forum.fhem.de/index.php?topic=21205.new#new 
Das ist ein Hack, um Empfang der CUL_WS per 868MHz und 433MHZ parallel zu ermoeglichen, ich habe dafuer eine Ausnahme eingebaut.  Auch das HM Problem sollte jetzt umschifft sein, obwohl ich die Ursache nicht verstehe. Die Fixes stehen ab sofort per update zu Verfuegung.