FHEM - Entwicklung > FHEM Development

IODev Handling durch device

<< < (2/17) > >>

noansi:
Hallo Zusammen,


--- Zitat ---Soweit ich sehe, wird hier verzweifelt versucht ein Attribut fuer etwas zu missbrauchen, was eigentlich Reading sein sollte.
--- Ende Zitat ---
Darüber habe ich auch schon nachgedacht und denke auch, dass es eigentlich ein guter Weg wäre den Zustand auch über den Restart für alle IO Zuordnungen zu sichern. Da es bei CUL_HM_assignIO schnell gehen muss allerdings mit Sparvariante ohne Zeitstempelaktualisierung.

Zunächst ging es aber um den Fix des Problems, dass das Setzen des Attributes im laufenden Betrieb nicht zu vollwertiger Umstellung auf das gewünschte neue IO führt. Damit eine notwendige Behandlung des Attributs durch das CUL_HM Modul, um die Funktion zu erreichen. Und dabei das kleine Hinderniss der unerwünschten Meldungen.
Daraus haben sich die weiteren Fragestellungen ergeben, dass auch das Setzen beim FHEM Start bisher nicht sauber funktioniert hat.
Das vor dem Zielkonflikt, die Änderungsvorschläge nicht zu umfangreich und abweichend vom bisherigen Stand werden zu lassen. Schließlich besteht der Wunsch, dass sie vom Maintainer zumindest funktional auch übernommen werden.

Die Multi-IO Unterstützung von CUL_HM gepaart mit schnellen Antworttiminganforderung und aktiven IOs stellt etwas andere Anforderungen, als es das Framework derzeit für die IO Zurodnung bietet. Ich hoffe, das ist schon etwas klarer geworden.

Von daher sind meine Fragestellungen
- Wurde es nicht bedacht, in der vorgeschlagenen Art das Attribut allein durch das nutzende Modul behandeln zu lassen?
- Gibt es noch andere Anwendungen in FHEM bezüglich IODev, die von mehr Flexibilität bei Attribut IODev profitieren würden? Es sich somit lohnen würde meine Patchanfrage besser direkt etwas umfangreicher anzugehen, statt des vorgeschlagenen sparsamen Flickwerks?
- Würde es mal noch andere Attribute geben, die eine Sonderbehandlung in fhem.pl erfordern und die gleichfalls von der Lösung betroffen wären, respektive davon profitieren könnten?
- Habe ich eine andere Möglichkeit zur einfachen Lösung unter Nutzung von IODev übersehen, so dass mein Patchvorschlag überhaupt nicht notwendig wird?
- Habe ich Nebenwirkungen auf andere Module durch den Patchvorschlag übersehen (z.B. ist mir der Trigger am Ende erst später aufgefallen, womit Save Config anfangs kein rotes '?' bekam)?
- Oder gibt es im Gegenteil eher einen Konsens dieses spezielle Attribut durch das Framework alleine in der Sonderform verwalten zu lassen? Dann verwerfe ich den ganzen Patchvorschlag bezüglich IODev besser und suche andere Wege.


--- Zitat ---Attribut ist das, was der Benutzer setzt. Reading ist das, was das Modul setzt, wenn es gepsiechert werden soll.
--- Ende Zitat ---
Das habe ich verstanden. autosave hat die Grenzen aber aufgeweicht. Ebenso die globale Datenhaltung mit direktem Zugriff (anfangs mit wenig bis keinen Zugriffsmethoden, richtig?), die den "Missbrauch" sehr verführerisch gemacht hat, aber auch performant im Vergleich zu Methodenzugriff.

--- Zitat ---das ist aber keine Begruendung es weiter zu treiben, eher im Gegenteil
--- Ende Zitat ---
Dem stimme ich zu. autosave ist bei mir übrigens aus.


--- Zitat ---Ich verstehe schon, dass ein Umbau auf Reading mehr Arbeit bedeutet, ich faende es aber toll, wenn nicht bei jedem Problem sofort eine Ausnahme vom beabsichtigten Architektur gemacht wird.
--- Ende Zitat ---
Nicht die Mehrarbeit ist das Problem, sondern den Kompromiss für den Zielkonflikt zu finden.


--- Zitat ---Bei CUL_HM ist das Phänomen ziemlich verbreitet, eventuelle Uservorgaben auch schon mal zu "überstimmen"
--- Ende Zitat ---
Ist auch durchaus sinnvoll, um historische Einstellung automatisch auf aktuellen Stand umzustellen und auch um offensichtliche Einstellfehler zu korrigieren. Macht dem User das ohnehin schon kompilzierte Einstell-Leben einfacher.


--- Zitat ---Das Problem ist, dass die Info vorhanden sein "muss", was schiefgeht, wenn es (noch) keine Readings gibt (ok, da kann man dann defaults setzen, die aber falsch/kontraproduktiv sein könnten)
--- Ende Zitat ---
Im Grunde ist das auch die Begründung für die Sonderbehandlung des IODev Attributs, da die config die Reihenfolge der Definitionen nicht vorschreibt/schreiben möchte -> Verlagerung des Setzens ans Ende der Initialisierung, wenn alle IOs definiert sein sollten.
Da kommt mein IODev Änderungsvorschlag in CUL_HM beim FHEM Init nicht dran, weshalb etwas Disziplin bei der Ordnung in der config für volle Funktionalität erforderlich ist.

Damit wäre es eigentlich besser, einem Modul die Möglichkeit zu geben, eine Funktion bereit zu stellen, die zu diesem Zeitpunkt modulspezifische IO Zuweisung durchführt.
Beispielsweise eine $modulhash->{FinalizeInitFn}, die mit Leben gefüllt werden kann, wenn es benötigt wird. Fehlt sie, werden die FHEM default Aktionen ausgeführt bzw. FHEM default Werte gesetzt. Damit auch offen für andere Problemlösungen.

Gruß, Ansgar.

CoolTux:

--- Zitat ---- Gibt es noch andere Anwendungen in FHEM bezüglich IODev, die von mehr Flexibilität bei Attribut IODev profitieren würden? Es sich somit lohnen würde meine Patchanfrage besser direkt etwas umfangreicher anzugehen, statt des vorgeschlagenen sparsamen Flickwerks?

--- Ende Zitat ---

Die Max Modulreihe würde davon profitieren. Ich weiß das Wzut daran mal gearbeitet hatte, habe aber keine Ahnung wie weit er damit gekommen ist.


Grüße
Marko

Beta-User:

--- Zitat von: noansi am 24 April 2021, 00:06:13 ---Von daher sind meine Fragestellungen
- Wurde es nicht bedacht, in der vorgeschlagenen Art das Attribut allein durch das nutzende Modul behandeln zu lassen?

--- Ende Zitat ---
Na ja, nach meiner Erfahrung in MySensors kann es zu Situationen kommen, dass einfach das falsche IO verwendet wird, wenn man sich bei autocreate etc. nicht aktiv kümmert. Weiß nicht, inwieweit das jeweils bei anderen zweistufigen Modulen bedacht wurde bzw. ob es da wegen anderer Matching-(Parse-) Strukturen dieses Problem überhaupt in der Form gab/gibt.

Spätestens dann muss der User eingreifen, ähnliches gilt, wenn er Nodes oder IO's anders platziert. Kann ich bei MySensors bei späteren Änderungen vermutlich nicht automatisiert feststellen (oder nur mit sehr hohem Aufwand), bei der initialen Festlegung ist es seit einiger Zeit gefixt.


--- Zitat ---- Oder gibt es im Gegenteil eher einen Konsens dieses spezielle Attribut durch das Framework alleine in der Sonderform verwalten zu lassen?

--- Ende Zitat ---
Aus obigen Grund: Dagegen!
gilt 1:1 auch so z.B. für MQTT2_DEVICE; da kann sich das IO auch schon mal ändern, wenn der User die zugrundeliegende Infrastruktur umbaut.


--- Zitat ---Das habe ich verstanden. autosave hat die Grenzen aber aufgeweicht.

--- Ende Zitat ---
autosave ist mAn. zwischenzeitlich (wieder?) allgemein verpönt.

Ansonsten war das mit dem Hinweis, dass CUL_HM Attributinhalte schreibt ausdrücklich keine wirkliche Kritik! Ich fand es aus Usersicht befremdlich, aus heutiger Sicht ist es klar, dass man als Developer keine andere Option hat.
Der Kritikpunkt beschränkt sich daher lediglich auf den, dass das zugrundeliegende framework den Grundsatz "Attribute gehören dem User" durchbricht. Muss man halt an der einen oder anderen Stelle wissen und akzeptieren, that's all.

rudolfkoenig:
Ich rate weiter, da ich immer noch keine Ursachenbeschreibung gehoert habe: CUL_HM hat Probleme in Multi-Controller Setups, fuer Geraete wie Fernbedienungen, die herumgetragen werden, und deswegen jeweils von unterschiedlichen Controller angesprochen werden sollten. An sowas habe ich bei der Einfuehrung von IODev sicher nicht gedacht.

Ein Schritt zurueck:
- das IODev Internal wird in IOWrite verwendet, den "offiziellen" Weg der Kommunikation vom logischen Modul (wie CUL_HM) zu physischen (wie CUL).
- das FHEM Framework hilft mit AssignIoPort und weiteren Code, um ein passendes IODev zu finden, der Benutzer kann das mit dem IODev Attribut ueberschreiben.
- etwas ungeschickt ist, dass AssignIoPort das IODev Attribut auch setzt. Das ist notwendig wenn mehr als ein physisches Modul das Geraet theoretisch bedienen koennte, aber nur einer es richtig kann.

Attribute gehoeren dem Benutzer, die sind auch nicht dafuer ausgelegt, dauernd vom Modul geaendert zu werden, das ist die Domaene der Reading.

Vorschlag:
- AssignIoPort setzt statt den IODev Attribut ein IODev Reading
- setstate (der fuer das Setzen der Readings beim Initialisieren zustaendig ist), wird analog zu attr IODev speziell behandeln, und das IODev Reading setzen.
- wenn ein Modul IODev aendert, dann soll es auch das Reading setzen (z.Bsp. mit AssignIoPort).
- der Benutzer kann alles mit dem IODev Attribut ueberschreiben, das ist im Normalfall aber nicht notwendig.
Mir ist noch unklar, wie die Uebergangsphase funktionieren soll, stichwort Kompatibilitaet. Eine Loesung waere dem Benutzer mitzuteilen, im Problemfall bitte das alte IODev Attribut zu loeschen.


--- Zitat ---Damit wäre es eigentlich besser, einem Modul die Möglichkeit zu geben, eine Funktion bereit zu stellen, die zu diesem Zeitpunkt modulspezifische IO Zuweisung durchführt.

--- Ende Zitat ---
Ich koennte zwar ein FinalizeInitFn inbauen, aber es gibt bereits zwei Loesungen fuer dieses Problem:
- NotifyFn auf global:INITIALIZED
- im InitializeFn ein InternalTimer mit 0 als Timeout starten. Diese Variante ist deutlich billiger und einfacher als die NotifyFn Variante.



--- Zitat ---Ich fand es aus Usersicht befremdlich, aus heutiger Sicht ist es klar, dass man als Developer keine andere Option hat.
--- Ende Zitat ---
Dann muss man halt an Optionen arbeiten.
Z.Bsp. indem der Modulautor im Modul- oder Instanz-Hash ein defaultAttr pflegt, was AttrVal() zurueckliefert, falls kein Attribut gesetzt ist.

noansi:
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.


--- Zitat ---- NotifyFn auf global:INITIALIZED
- im InitializeFn ein InternalTimer mit 0 als Timeout starten. Diese Variante ist deutlich billiger und einfacher als die NotifyFn Variante.
--- Ende Zitat ---
- 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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln