Hallo Zusammen,
erst mal Danke für die Beiträge bisher und Deinen Vorschlag, Rudolf.
Zusätzlich ist zu Unterscheiden zwischen FHEM Init und dem laufenden Betrieb.
Initphase:Noch einen Schritt zurück.
Bei einem Neustart von FHEM (kann auch der harte ohne vorheriges shutdown sein) existiert eine IO Zuordnung.
Die IOs waren aktiv vorbereitet und "kennen" ihre devices auf die sie mit eigenen Automatismen antworten sollen (d.h. nicht nur sende- sondern auch empfangsrelevant) und tun dies auch weiter, wenn ihnen nichts anderes gesagt wird.
Das Attribut IODev kann zu der Zuordnung passen oder auch nicht mehr.
Die auf den IOs ist aber in der Regel die aktuell günstigere und soll möglichst beibehalten werden können. Das ist Modulabhängig und ggf. auch abhängig davon, ob das IO seinen Zuweisungszustand auch wieder zur Verfügung stellen kann.
Damit ist der attr IODev Wert in der FHEM Init Phase zu setzen oder auch anders zu setzen oder auch gar nicht. Wird es gesetzt, dann müssen alle IOs des Multi-IO-Verbundes entspechend gesetzt bzw. zurück gesetzt werden.
Ohne Ordnung in der config kann dies nur nach der kompletten Verarbeitung der config korrekt erfolgen.
Das Framework setzt derzeit sowohl das Attribut IODev, als auch das Internal IODev entweder nach Config-Attribut IODev oder entsprechend einem gefundenen kompatiblen IO.
Im Szenario ist die vom Framework gewählte Einstellung in der Regel daher falsch und die IOs nicht korrekt eingestellt, da das Framework auch diese Einstell-Funktionalität nicht bieten kann.
Bei einem harten Neustart wäre auch ein Reading IODev in der Regel falsch. Bei regulärem Neustart wäre der letzte Zustand vor einem nomalen Restart wieder nutzbar.
- NotifyFn auf global:INITIALIZED
- im InitializeFn ein InternalTimer mit 0 als Timeout starten. Diese Variante ist deutlich billiger und einfacher als die NotifyFn Variante.
- Haben beide den Nachteil, dass $init_done bereits gesetzt ist. Alle Funktionen sehen ein initialisiertes FHEM.
- Geht an/funktioniert für alle defnierten devices (so weit jeweils genutzt). Diese wiederum können einen set ausführen. Dieser set kann auf eines der devices abgesetzt werden, die eines der falsch vorbereiteten IOs nutzen, bevor deren INITIALIZED oder Init Timer durchlaufen ist.
- ReadAnswer Funktionen der IOs können bereits Empfangsdaten bekommen, die geparst und Dispatched werden und ggf. Antworten generieren, die wiederum auf die falsch vorbereiteten IOs treffen können.
Die NotifyFn Variante wird genutzt. Und leidet unter dem $init_done=1 und dass Internal IODev bereits u.U. falsch gesetzt ist. Eventuell kann man aber hier ansetzen und ein modulspezifisches init_done statt dem globalen noch nutzen.
Laufender Betrieb FHEM:Wenn der User das Attribut IODev setzt, dann soll das Modul das Setzen des Internals IODev überschreiben und die IOs entsprechend einstellen können.
Denn wenn das Attribut IOgrp gesetzt ist und die Verwaltungsinstanz (bei CUL_HM eine VCCU) aktiv ist, dann ist automatische Zuweisung aktiv. Ggf. muss dann von der Verwaltungsinstanz ein Ausweich IO gewählt werden können. IODev habe ich für meinen Vorschlag in dem Fall nur als temporären Vorzugsvorschlag gewählt, weil damit eine Umschaltung darauf möglich ist (nicht muss) und es zu Testzwecken nützlich ist.
Das Widerspricht natürlich Deiner Vorstellung von IODev Userkontrolle.
Auf jedenfall darf das Framework nicht das Internal IODev falsch einstellen, schon gar nicht, ohne die Verbund-IOs richtig umzustellen und das ist bisher der Fall, wenn der User das Attribut im laufenden Betrieb setzt (nur das gerade aktive kann ohne Probleme gesetzt werden), denn das Attribut wird im aktuellen Modul-Code gar nicht behandelt.
Außerdem gibt es im Homematic Forum auch haufenweise User Unverständniss zur Nutzung der Attribute. Wenn IOgrp gesetzt ist und die Verwaltungsinstanz aktiv und zuständig ist, dann ist IODev nun mal nicht mehr Master bei der Zuweisung, sondern nur noch ein Notnagel.
Bei IOgrp kann man auch VorzugsIOs setzen, die bei Nutzbarkeit bevorzugt gewählt werden.
Konsequent wäre dann sogar eigentlich User setzt IODev, aber -> Attribut IOgrp VorzugsIO wird gewählt -> VCCU Attribut IOList IO wird gewählt -> Attribut IODev IO wird gewählt -> Framework AssignIO Zuweisung findet noch ein passendes IO zur Wahl, welches nutzbar ist (operabel meldet).
IOgrp alleine ist auch kein Indikator für die IODev Priorität, denn wenn die Verwaltungsinstanz nicht aktiv ist (z.B. gar nicht definiert), dann ist wieder IODev der Master und IOgrp bedeutungslos.
D.h. das Framework könnte das Internal IODev setzen, dann das Reading IODev mit Trigger und den Trigger müsste das Modul verarbeiten um die Internal Umstellung auf einen funktionalen Zustand einzustellen, wobei ihm aber gerade die Information entzogen wurde, welches IO gerade eigentlich aktiv war (und darf dabei aber nicht auf die Idee kommen CommandAttr zu nutzen um das IODev Attribut selbst zu setzen).
Gruß, Ansgar.
PS: Bezüglich Userverständnis muss ich sicherlich noch eine Prüfung auf einen geeigneten IO Typ einbauen, damit nicht irgendwas als IO gewählt wird.
