IODev Handling durch device

Begonnen von noansi, 22 April 2021, 19:16:57

Vorheriges Thema - Nächstes Thema

martinp876

Ich sehe nicht, dass sich nichts ändert. Auf die Schnelle verstehe ich es nicht und sehe keine Dokumentation, was da geschehen soll in Bezug auf IODev.
Es gibt weiter ein Attr IODev, Reading IODev und Internal IODev

IsIoDummy() : welche funktion hat das?
IOWrite(): hier wird das Internal IODev genutzt.
=> das Internal ist also das operationell relevante Datum

fhem_setIoDev(): diese Funktion ist zu nutzen, um das IO zusetzen. Bedient werden das Internal und das Reading.
=> interessant: sollte man ein "falsches" device setzen wird das Internal "IODevMissing" gesetzt.
=> existiert das Attr IODev  und passt es nicht zum "Wunsch" wird die Aktion abgebrochen (hä?)
=> wenn alles klappt wird das Reading gesetzt und das Internal gelöscht

Ich vermute, fhem_setIoDev() sol genutzt werden, das IO zu aktivieren. Ich muss nun aber erst das Arrtibut löschen oder es passend zu setzen. Ehrlich, was ist der Hintergrund hierzu?

Erwartet hätte ich, dass wenn ich "val" nicht sende, ein IO gesucht wird. Dann wäre es eine wirklich funktionale Methode.
Ich hätte mir gewünscht:
- wenn !init_done => merken und bei/mit/nach init_done aufräumen
- wenn init_done weise das IO zu gemäß: 1) wunsche(val), 2) best-effort (entsprechend AssignIOPort)
- return könnte das IO device sein.

AssignIoPort: hier reden wir nun von einem "port", und nicht mehr von einem "Device" - ist aber wohl identisch - ok.
  Prio 1 ist das Attribut, prio2 das Reading. Wirklich sauber ist es nicht implementiert. Wenn das Attribut auf ein disabled device zeigt wird ein potentiell mögliches Reading nicht berücksichtigt.


Warum wird hier nicht aufgeräumt und eine klare Linie verfolgt? Definitionen sind hilfreich - insbesondere wenn sie auch niedergeschrieben werden! Ich haben einige Abfragen zu "Clients" gefunden - aber bei mir keine Implementierung  gesehen. Doku ebensowenig.


IODev handling - wie ich es sehe
1) capabilites: Clients soll wohl in irgend einer Form die Möglichkeiten abbilden, bspw welche IOs ein Device nutzen könnte. Das wäre cool, aber nicht hinreichend. Zum einen haben wir schlechte und gut IOs. Eine CUL kann HM unterstützen, aber sehr schlecht. tscul ist hier angesagt. Wie also soll das funktionieren, wo kann ich es lesen?
2) possible: das finde ich garnicht - CUL_HM hat etwas implementiert. Man hat mehrere IOs und diese werden den Devices zugewiesen (Stichwirt vccu) - nach Prio, settings werden geprüft, bereitschaft wird geprüft. So etwas könnte man zentral machen... gibt nichts.

3) wunsch Realisierung (meine Meinung)
Attribut IODev ist Anwender Initial Value. Wenn es gesetzt wird, wird es geprüft und, wenn möglich aktiv gesetzt. Weiter ist es default wenn kein "Wunsch" geäussert wird. Operationell ist das Reading relevant, was mit den Internal identisch sein MUSS (warum man das auch immer 2-mal braucht - sollte aufgeräumt werden)

AssignIoPort ist als methode nur kernal-intern notwendig

fhem_setIoDev() Ablauf
IO-wunsch wird auf funktionalität geprüft (vorhanden/enabled<>dummy/aktiv<>error<>temporary inactive) . Aktionen müssen definiert werden.
wenn Io-Wunsch gültig und es mit den current (Internal) identisch => do nothing
wenn Io-Wunsch gültig und änderung zu current (Internal) setze IO in reading und internal
wenn Io-Wunsch ungültig prüfe current. Wenn gültig => do nothing
wenn Io-Wunsch ungültig prüfe current. Wenn ungültig prüfe Attribut. Wenn gültig => setze IO auf Attribut
wenn Io-Wunsch ungültig prüfe current. Wenn ungültig prüfe Attribut. Wenn ungültig suche Optionen. Wenn gültige Option gefunden, setze diese. Wenn keine gefunden wurde disbale IO. Setze current auf "not available".

=> im Reading kann ich dann immer sehen -und nachverfolgen - welches IO gesetzt ist und auch wenn keines zu verfügung steht.

Das ist eine Umwidmung der Semantic von attr IODev - und m.E. eine klare definition: ein initial value.





rudolfkoenig

ZitatIch sehe nicht, dass sich nichts ändert.
Woran siehst Du das?

ZitatIsIoDummy() : welche funktion hat das?
Prueft, ob das IO-Device dummy ist, um zu wissen, ob das Senden eine Auswirkung haben wird. Wird bisher von drei uralten EM*.pm Modulen verwendet, damit bei get sofort eine Fehlermeldung zurueckgeliefert wird. Kann ich gerne entfernen, es verwirrt offensichtlich.

Zitatfhem_setIoDev(): diese Funktion ist zu nutzen, um das IO zusetzen. Bedient werden das Internal und das Reading.
Ich weiss nicht, von wem diese Nachricht stammt, von mir nicht. Sie ist eine fhem.pl Hilfsroutine.

Wie geschrieben: Weder fuer den Modulautor, noch fuer den Benutzer soll sich was aendern.
Es sei denn, man macht als Modulautor komische Sachen, wie AssignIoPort aufrufen, und erwarten, dass ein Attribut gesetzt wird.

Ich verstehe, dass man schlechte Laune hat, und den Aerger auf dem Erstbesten auslassen will, fuehrt aber in diesem Fall nicht weit..
Falls man mir ein konkretes Problem schildert, dann werde ich versuchen eine Loesung zu finden.

noansi

Hallo Martin, hallo Rudolf,

ZitatReading relevant, was mit den Internal identisch sein MUSS (warum man das auch immer 2-mal braucht - sollte aufgeräumt werden)
Das neue Reading wird gebraucht, da es beim fhem Neustart gespeichert wird und ermöglicht, das letzte vor dem Neustart genutzte IO wieder einzustellen.

Für ein z.B. VCCU Autoassign eine sinnvolle Methode, da sich über einen Neustart die Umgebungsbedingung (Stichwort RSSI basierte IO Zuweisung) in der Regel nicht großartig ändern und "intelligente" IOs mit gleicher Einstellung ihrer zugewiesen Clienten weiter arbeiten können.

Für das Attribut ist das Speichern eine Option und stellt den vorherigen Stand daher nur optional wieder ein.

Für die Verarbeitungsgeschwindigkeit und Kompatibilität zu bestehendem Code ist das Internal weiterhin sinnvoll.


Aus meiner Sicht ist das Reading derzeit eine nutzbare Hilfskrücke, damit bei einem fhem Neustart die gleiche Einstellung durch fhem.pl wieder eingestellt wird, wie sie zuvor im IO eingestellt war (so denn der User das Attribut IODev gelöscht hat!).

Eigentlich wollte ich nur den im IO gespeicherten Zustand wiederherstellen (,der ja eigentlich durch vorherige Wahl von Attributeinstellungen durch den User mehr oder minder direkt zustande gekommen ist), bevor fhem IO Empfangsdaten zu verarbeiten beginnt, aber schon alle HM devices und HM IOs definiert sind.


ZitatIODev handling - wie ich es sehe
...
Nebenbei habe ich mir andere CUL sendend nutzende Module um ein Attribut 'IODevList' erweitert, um bei Ausfall des ursprünglich via IODev gesetzten IOs eine (funktechnisch, empirisch) nutzbare automatische Ersatz-IO Wahl zu ermöglichen. Damit wird bei IO Ausfall das erste verfügbare IO aus dieser IODevList eingestellt.
Die von fhem.pl bereit gestellten Möglichkeiten haben dazu nicht gereicht, da AssignIoPort in automatischer Form nur Modulkompatibilität nutzt, aber die funktechnische Erreichbarkeit damit nicht abgedeckt wird. Ging in den Fällen auch nur nach Liste, weil die entsprechenden Clientgeräte keine Rückmeldung geben und damit kein RSSI als Entscheidungshilfe verfügbar ist. Würde es eine Qualitätsinformation, wie RSSI, geben, dann hätte ich die auch mit genutzt.
Die gedankliche Anregung dazu war CUL_HM mit VCCU IOList.

Das wäre ein Anregung zur Erweiterung von AssignIoPort (oder eine alternative Funktion). Einmal eine IO Liste zu nutzender IOs (inklusive des VorzugsIOs) und dann ein Standardinternal/-reading /-helper (z.B. ein Internal IOq_<IOName>), dass das anfordernde device bereit stellen kann, um die "Qualität" eines nutzbaren IOs im Vergleich zu anderen IOs anzugeben. Zusätzlich müssten IOs auf standardisiertem Wege ihre tatsächliche Nutzbarkeit bekannt geben können.
Derzeit ist es ein Abenteuer, die zu ermitteln, wenn mehrere unterschiedliche IOs (unterschiedliche Module) nutzbar sind.

Gruß, Ansgar.

martinp876

Hallo Ansgar,
ZitatDas neue Reading wird gebraucht, da es beim fhem Neustart gespeichert
sehe ich nicht so.
Wenn das io statisch eingestellt wird ist es statisch. Punkt. Das muss das Reading nichts speichern, was wiederhergestellt werden müsste.
Wenn das IO dynamisch vergeben wird kann die Ermittlung nach einem Neustart gestartet werden. Das muss funktionieren.
Man kann es auch in einem Reading speichern - nötig darf es nicht sein.

ZitatFür das Attribut ist das Speichern eine Option und stellt den vorherigen Stand daher nur optional wieder ein.
Das ist Sache von Rudi, es festzulegen. Das sollte bei CUL_HM und dessen IOs nicht anders ein als bei allen anderen.

Die aktuelle Implementierung und die von Rudi bereitgestellten Methoden/Funktionen sind nicht schlüssig. Ich kann über Assignments ein IO einstellen, aber nur wenn es kein Attribut gibt. By all means... wie soll man das nutzen? Indem du in CUL_HM readings manuell und unter Umgehung aller Kernal-methoden setzt? Wozu dann die Kernal-methoden?

ZitatEigentlich wollte ich nur den im IO gespeicherten Zustand ....aber schon alle HM devices und HM IOs definiert sind.
Es macht Sinn, nach dem Init "aufzuräumen". Es gibt einige Consitancy-checks welche nach dem einlesen aller *.cfg und aller Readings ausgeführt werden müssen. Das muss eigentlich JEDES Modul machen. CUL_HM macht das schon geraume Zeit - eine Funktion nach "KernelInit" triggern und dann Attribute und zuordnungen prüfen, bearbeiten, ggf updaten oder löschen. Du kennst die Funktion und ich würde sie bei jedem Modul fordern, welches Abkängigkeiten prüfen muss.

Was also sind meine Probleme:
1) wenn man ein Reading betreibt, sollte es den üblichen Methoden und verhalten unterliegen. Also die Kernel Methoden nutzen und die Notifcation unterstützen.
2) die Kernel methode muss genutzt werden können zum IO setzen. Kann sie nicht, da das Attribut Prio1 hat und nicht angepasst wird. Entweder setze ich das Attribut vorher oder ich lösche es.
3) Für CUL_HM gelten dann 3 Regeln
3a) für devices welche kein "auto-IO" eingestellt haben wird das Attribut genutzt. Period.
3b) für devices welche eine vccu nutzen (auto-IO) wird das Attribut IODev gelöscht. Das IO wird durch die VCCU und deren Methoden geregelt
=> IOgrp löscht IODev!
3c) bei Devices ohne IOgrp und ohne IODev suchen sich ein Device gemäß den aktuellen Regeln (Assign-IO oder beim pairen das Device, welches es meldet.

Die Funktion fhem_setIoDev ist dann nutzbar. Bei "statischen IOs" beim Setzen des Attribut, bei dynamischen bei jeder Änderung.

wirklich sinnvoll wäre es, wenn der Kernel solche Verhalten implementiert so dass es einheitlich im System ist. Also bei fhem_setIoDev alle 3 Attribute setzen. Wie kann man annehmen dass der Programmierer ein "gewünschtes" IO aussucht welches eigentlich nicht  gültig ist. Das ist doch ein internes Interface, keine User-Methode!!!




noansi

#34
Hallo Martin,

ZitatWenn das IO dynamisch vergeben wird kann die Ermittlung nach einem Neustart gestartet werden. Das muss funktionieren.
Man kann es auch in einem Reading speichern - nötig darf es nicht sein.
Ja, wenn das Attribut IODev und jetzt auch das Reading IODev entfernt sind, somit die IO Assignment Mechanismen fhem.pl nicht angesprochen werden.
Weiterhin darf dem User dann das Attribut IODev nicht mehr angeboten werden, denn damit setzt er wieder die Funktionen von fhem.pl in Gang, ohne das die IOs selbst was davon mitbekommen.
Auch darf beim Autoassign nicht mehr auf AssignIOPort als "letzten Rettungversuch" zurück gegriffen werden. Die Funktion ist auch zu langsam, um falls sie zufällig ein funktechnisch sinnvolles IO gewählt hat, noch rechtzeitg senden zu können.

Außerdem darf kein IO vorzeitg geparste Daten in die Parse Funktion schieben und damit über die Verarbeitung/Eventverarbeitung eventuell IO-Aktonen anstoßen, die ihreseits wieder ein Assignment erfordern/anstoßen, bevor die Wiederherstellung abgeschlossen ist.

ZitatIch kann über Assignments ein IO einstellen, aber nur wenn es kein Attribut gibt. By all means... wie soll man das nutzen? Indem du in CUL_HM readings manuell und unter Umgehung aller Kernal-methoden setzt? Wozu dann die Kernal-methoden?
Die Umgehung der Kernel-methoden dient der Geschwindigkeit, da beim Autoassign vor dem Senden trödeln sicher nicht die beste Beschäftigung der CPU ist.

Es ist Rudolfs Vorgabe (und ich habe auch entsprechende Uservorstellung in anderem Zusammenhang gelesen), das ein gesetztes Attribut als Userwille Vorang hat. Sich damit auch das einstellt, was der User sich da vorgestellt hat. Wenn er die Blockade nicht duch das Löschen des (angebotenen) Attributs aufhebt, soll es eben nicht automatisch funktionieren.

Wenn der User gleichzeitig Attribute für die Automatik setzt, dann wir es mit dieser "Regel" spannend (bisher ist das ja Nomalzustand).
Will er IODev starr oder will er IOgrp Automatik? Oder hat er nur nicht begriffen, wofür was wie gut ist (was nach allem Lesen im Forum die wahrscheinlich zutreffende Variante ist).

Zitat1) wenn man ein Reading betreibt, sollte es den üblichen Methoden und verhalten unterliegen. Also die Kernel Methoden nutzen und die Notifcation unterstützen.
Muss nicht, denn Readings kann man auch unter Nutzung der Kernel Methoden setzen, ohne dass Events ausgelöst werden. Das legt der Programmierer fest.
Allerdings wird ja noch mehr dabei gemacht, z.B. Datum/Uhrzeit des Readings setzen. In diesem Fall nicht wirklich von Interesse.
Würde es Events auslösen käme sicher jemand auf die Idee, dass es doch ganz toll wäre, das zu loggen oder noch anderes damit anzustellen.

Zitat3b) für devices welche eine vccu nutzen (auto-IO) wird das Attribut IODev gelöscht. Das IO wird durch die VCCU und deren Methoden geregelt
=> IOgrp löscht IODev!
Jeah. Attribut und Reading?! Und auch aus der Attributsliste?! :) Automatisch und nur geschützt durch entsprechende Hinweise in der Attributs Commandref?  :)
Ich hoffe, das geht hier durch den "TÜV", denn automatisches Löschen ist ja zunächst wiederum ein Eingriff in den User Willen. Und speichern muss er die so gänderte Config auch noch. Sonst nimmt das Drama mit dem nächsten Neustart wieder seinen Lauf.

Und wie bei den virtuellen devices? Eigentlich IODev richtig, aber es gibt noch Möglichkeiten, den RSSI von Zieldevices anzuzapfen, sofern gepeered.

ZitatDie Funktion fhem_setIoDev ist dann nutzbar.
Achtung, nur dann, wenn Rudolf sie zu einer Kernel Methode umdefiniert!
Derzeit ist sie nur eine interne Hilfsfunktion und kann sich ändern, auch im Verhalten/Umfang.

Gruß, Ansgar.

martinp876

Mein Vorgehen:
Ich werden anhand der Vorgaben des Kernel (Dokumentation = code) eine Implementierung finden. Ich denke Rudi hat Zeit bis Ende der Woche. Wenn es so bleibt wie es ist bin ich unzufrieden, aber der Kernel entscheidet. Punkt.

Meine Gedanken:
Die Implementierung von Rudi hat mich massiv enttäuscht. Es gibt nun 3 (DREI) stellen an denen das IODev abgelegt wird. Und man kann sich aussuchen, wo man es abholt. Das ist Bastelei - sorry.
Die Methoden prüfen aus meiner Sicht auf seltsame Weise die Daten. Hier fehlt ganz klar der rote Faden eines Architekten. In der SW prüft man nicht in jeder Prozedur alles - die Verantwortung liegt schon bei dem Entsprechenden Anwender. Also sind erst einmal Anwenderklassen der Funktionen zu definieren.
1) User: Alles was der User ausführen darf sollte sehr genau auf sinnhaltigkeit geparst werden
2) Anwenderentwickler: es wird noch grob geprüft - die Verantwortung steigt gewalting. Hier geht es um Funktionen/Methoden, welche ein User bswp in User-readings o.ä nutzt
3) Moduleentwickler: haben ganz klar eine große Verantwortung, die kernel methoden korrekt aufzurufen. Der Kernel muss sicherstellen, dass es nicht zum Absturz kommt - mehr eigentlich nicht.
4) kernel: nun, der code wird geprüft - intern ist wenig zu prüfen

Beispiel: fhem_setIoDev prüft ob das IO definiert ist. kann man - aber das ist nicht komplett. Wird es auch geprüft, wenn das IO gelöscht oder umbenannt wird? Wird das löschen verhindert oder die IO vergabe neu verhandelt?
Aber gut - ist eben unvollständig.

Jetzt wird beim Setzen des Readings durch den User IODev fhem_setIoDev ausgeführt - aber nur wenn das Attribut entsprechend steht. Da fehlen mir schon die Worte - ehrlich.

Es könnte so einfach sein - einfach lassen, wie es war.

Performance ist mir unklar.
Warum ist InternalVal(<dev>,"IODev","") schneller als AttrVal(<dev>,"IODev","") oder ReadingsVal(<dev>,"IODev","")
ok, direktzugriff. dann ,
warum ist $dev{<dev>}{IODev} schneller als $attr{<dev>}{IODev} oder  $dev{<dev>}{READINGS}{IODev}{val}
=> rechtfertigt das die Duplizierung des Parameters - im anwendersichtbaren Bereich? Dann sollte ich noch weitere Attribute dahin duplizieren.
==> ich bin nicht einverstanden.

Wiederherstellen nach reboot:
Bisher habe ich das Attribut IODev ungesetzt - voll automatisch. Das geht - aber es wird nur über einen restart gesichert, wenn man ein save macht. Na und? Der Mechanismus zur Errechnung des IO muss robust sein. Nach reboot wird es errechnet - fertig. Es kann sein, dass ein andere der mögliche IOs gewählt wird. Das muss übrigens funktionieren - und wird sich schnell wieder einrenken.
Wenn man es retten will - dann mache ich das dich nicht so.
Ich würde, wenn es für mich notwendig ist, ein Reading ".IODev" anlegen (unsichtbar). Der Anwender muss es nicht merken. Auch keine Implementierung im Kernel. Es gibt auch kein notify,... es wird nur die Speicheroption genutzt. Ich muss noch nicht einmal die Zeit setzen...
Nach reboot im "cleanup after boot" wird dann das Reading mit den Attributen abgeglichen. Einmalig. Wenn das Reading einen sinnvollen und gültigen Wert enthält wird er gesetzt. Ansonsten wird das Reading ignoriert. DAS IST KEINE KERNEL FUNKTION!

ZitatDie Umgehung der Kernal-methoden dient der Geschwindigkeit, da beim Autoassign vor dem Senden trödeln sicher nicht die beste Beschäftigung der CPU ist.
schlecht. Kernel funktionen sind nicht zum umgehen da. Wenn du kernal support willst, nutze ihn. wenn nicht, fordere ihn nicht. Es wird so viel Zeit für notifies verbraucht - wie oft änderst du das IODev? Das ist nicht relevant hier zeit zu sparen. Addiere einmal die Zeiten!!!

ZitatEs ist Rudolfs Vorgabe (und ich habe auch entsprechende Uservorstellung in anderem Zusammenhang gelesen), das ein gesetztes Attribut als Userwille Vorang hat
Dem stimme ich nicht zu und kann es nicht einhalten. Es gibt attribute welche ich (schon lange) automatisch setze, da sie sich aus Sachzwängen ergeben. Rudi hatte die Sereinnummer als Attribut in CUL_HM definiert - der User darf diese nicht setzen.
Ich habe "interne Attribtute" in CUL_HM definiert (model-id) welche der User nicht mit legalen Mitteln ändern kann. Braucht er es biete ich eine Methode an, es zu überschreiben.
=> hier kann ich wirklich nicht zustimmen.
=> wenn ein User das Attribut IOgrp setzt KANN das Attribut IODev nicht mehr von ihm verwaltet werden.
=> Rudis vorgaben ist tendentiell korrekt - hat aber klare Grenzen. In diesem Fall stelle ich dem Anwender klare Fallen... was sollte das helfen - und wem?  no go!


ZitatMuss nicht, denn Readings kann man auch unter Nutzung der Kernal Methoden setzen
ich weiss, was man kann. Mir fehlt dennoch die klare Linie, wenn ich es bei jeden Reading anders mache. Nogo.

ZitatUnd auch aus der Attributsliste?!
habe ich nicht gesagt, geht auch nicht. Löschen ist, das gesetzte Attribut löschen - ein Setzen verhindern.
Attributlisten kann man leider nicht je device sondern nur je Modul setzen. Daher haben wir unangenehm lange Attributlisten. Leider.


ZitatAchtung, nur dann, wenn Rudolf sie zu einer Kernal Methode umdefiniert!
Derzeit ist sie nur eine interne Hilfsfunktion und kann sich ändern, auch im Verhalten/Umfang.
na hoffentlich!
Ich bin für löschen!
Wenn sie blebt sollte es zwingend eine kernalmethode werden - schliesslich wird hier das Verhalten definiert welches nur hier dokumentiert ist.

rudolfkoenig

Ihr schreibt ja Romane. Ich habe alles gelesen, hoffentlich auch alle Punkte behalten, die angesprochen wurden.

Zu der IODev "Theorie":
- das IODev Internal wird nur vom IOWrite() verwendet, diese Funktion sollte das alleinige Interface von einem logischen Modul zum physischen sein. Die andere Richtung ist Dispatch.
- das IODev Internal wird durch AssignIoPort() vom logischen Modul gesetzt, dabei kann man einen Vorschlag unterbreiten. Dieser Wert wird fuer den Neustart in einem Reading mit dem gleichen Namen gespeichert, da die automatische Zuordnung bei mehreren physischen Geraeten sich aendern kann.
- der Benutzer hat die Moeglichkeit, die automatische Zuordnung durch ein Attribut mit dem Namen IODev zu beeinflussen.

Was sich geaendert hat: IODev wird in AssignIoPort nicht im Attribut, sondern im Reading gespeichert. Sollte weder fuer den Modulentwickler (der ja nur AssignIoPort, IOWrite und Dispatch verwendet), noch fuer den Anwender eine Aenderung bedeuten.

Ein Attribut gehoert aus Prinzip dem Benutzer. Dass ich selbst Fehler mache, soll nicht als Ausrede verwendet werden, sondern als Grund zum Aendern, wie hier gerade. Manchmal landet ein Datum im Attribut, weil ich am Anfang der Modulprogrammierung nicht weiss, ob das vom Benutzer geaendert werden soll. Wenn man spaeter sicher ist, kann man das aendern.

Der Programmierer kann nicht absehen, wie sein Programm verwendet wird (FHEM ist das beste Beispiel dafuer), deswegen soll der Wille des Benutzers respektiert werden. Wenn ich als Benutzer einen Fehler mache (d.h. ich setzte den Attribut falsch), dann muss ich mit den Konsequenzen leben. Keiner zwingt mich, den Attribut zu setzen.


Zu den einzelnen Punkten:
ZitatDas wäre ein Anregung zur Erweiterung von AssignIoPort (oder eine alternative Funktion).
Theoretisch muesste vor dem Senden jedes Ausgabegeraet geprueft werden, auf welchem Wege das aktuelle Ziel am besten erreichbar ist. Koennen die Ausgabegeraete das zuverlaessig? Gibt es einen tatsaechlichen Bedarf dafuer, oder ist das eine akademische Diskussion? Ich will mich nicht wehren, aber z.Zt. bin ich noch nicht ueberzeugt, dass es den Aufwand wert ist, da es die Sache fuer viele Beteiligte (Programmierer und Endanwender) verkompliziert.

ZitatWas also sind meine Probleme: [...]
1) und 3) habe ich nicht als Problem verstanden, sondern als Luft abassen.
2) kann ich nicht nachvollziehen, bzw. wenn es ein Problem ist, dass der "ahnungslose" Benutzer die Vorgaben der Programmierers ueberschreiben kann, und damit womoeglich das Programm unbenutzbar macht, dann ist das mAn kein Problem, sondern Absicht.

ZitatEs gibt nun 3 (DREI) stellen an denen das IODev abgelegt wird. Und man kann sich aussuchen, wo man es abholt.
Der erste Satz ist richtig, der Zweite nicht: man "holt" IODev nicht ab, man verwendet IOWrite.
Ein logisches Modul sollte keine Kenntnisse ueber die drunterligende IODevs haben, diese haben die gleiche Funktionen anzubieten, oder (wenn sie es nicht koennen), zu ignorieren. Sonst kann man nicht ohne Weiteres ein neues physisches Modul hinzufuegen, oder Hilfsmodule wie CUL_RFR oder FHEM2FHEM implementieren. Wenn man die Schnittstellen aufgibt, dann kann man auch alles in einem Modul implementieren.

ZitatIch habe "interne Attribtute" in CUL_HM definiert (model-id) welche der User nicht mit legalen Mitteln ändern kann. Braucht er es biete ich eine Methode an, es zu überschreiben.
Das kann man so machen, bedeutet aber eine Abweichung vom normal, und man darf sich nicht wundern, wenn das Modul zunehmend weniger zum Rest passt.

ZitatAttributlisten kann man leider nicht je device sondern nur je Modul setzen.
Das ist nicht richtig: wenn $defs{NAME}{.AttrList} definiert ist, dann wird sie anstatt $modules{TYPE}{AttrList} verwendet.
Diese Moeglichkeit ist jetzt etwas ueber drei Jahre alt.

herrmannj

Ehrlich gesagt finde ich das ebenfalls suboptimal. Die Logik ist total quer und vor allem die kruecke dafür ein Reading zu erzeugen ist daneben. Drei Mal io (Attribut, internal, Reading), völliger Unsinn. Wenn hier als Einzelschicksal das benötigt wird, dann speichert das doch bitte im KV Store und gebt fhem die Möglichkeit das der dev das unabhängig vom Attribut per Funktion aus seinem Modul explizit setzen kann.

noansi

#38
Hallo Rudolf,

ZitatDamit wird bei IO Ausfall das erste verfügbare IO aus dieser IODevList eingestellt.
ZitatGibt es einen tatsaechlichen Bedarf dafuer
Für die Funktion "Ersatz-IO" ja. Es ist schon beruhigend, wenn ein IO Ausfall nicht gleich einen Totalzusammbruch im System bedeuted.
Bei HM Nutzern ist dieses Einsatzgebiet häufiger zu sehen. Vermutlich auch, weil es geht.

Zitat, oder ist das eine akademische Diskussion?
Nun, Du hast das IODev Reading eingeführt, warum also nicht weiter denken?
- Wenn ein IO Ausfall per Event signalisiert wird, kann über Eventverarbeitung auch was auf Userebene gemacht werden. Die zu sendende Information ist dann aber meist verloren.
- Lösbar natürlich auf Modulebene. In dem Fall geht es zunächst um eine Ersatz Liste mit Userdefinierter Prorität, also Reihenfolge in der Liste. Damit ist dann auch eine ggf. notwendige IO  Vorbereitung erschlagbar.
Würdest Du was ins Kernel integrieren,
- würdest Du auf den IODev Attributskonflikt stoßen. Sprich, die Frage klären müssen, ob es sinnvoll ist ein gesetztes Attribut automatisch zu übergehen, wenn der User via anderem Attribut Automatik festgelegt hat. (Der Fehler des nicht Löschens des Automatikhemmers fällt nach Murphy sicher in eine Abwesenheitsphase).
- versuchen, eine standardisierten Weg für IO Ausfallsignalisierung zu etablieren

Für eine Funktion "bestes IO wählen" ist die Frage, in wieweit die IO Eignung über einen Qualitätswert ausreichend gut abbildbar ist.
Auf Modulebene vermutlich geeigneter lösbar. Der Qualitätswert wäre ohnehin schon auf Mudulebene geeignet bereit zu stellen. Das ist nicht mehr weit weg auch das IO zuzuweisen.

Gruß, Ansgar.

martinp876

Hallo Rudi,

Ich für meinen Teil sehe hier - neben dem eigentlichen Problem - architektonische und semantische Probleme. Ich kann das leider nicht in einem Satz ausdrücken - und wundere mich eigentlich, dass ich das überhaupt darlegen muss.

IOWrite ist der einzige nutzer des IO. Warum das nun nicht mehr aus den Attribut kommen soll ist mir unklar.

Ich bin nicht einverstanden, was du implementiert hast. Das ist sehr eingeschränkt und auch sehr fragwürdig.  AssignIoPort() kann ich gerne zum Setzen des IO nutzen.
Dein AssignIoPort ist aber schwach! Es mag hienreichend sein für einfache Anwendungen. CUL_HM bietet eine Möglichkeit für automatische Ersatzschaltungen von IOs. AssignIoPort bietet nur das Setzen und macht prüfungen welche ich sowieso schon mache(n muss).
AssignIoPort setzt nur das System-interface. Das IO wird nicht vorgereitet - was bei HM notwendig ist.
Faktisch bietet mir AssginIoPort fast keinen Service, ist recht aufwendig für den geringen benefit,... aber gut - ich bin für Standards und werden es endsprchend nutzen. AssingIoPort prüft nicht die Auslastung, den Zustand(overload), den rssi.

"Attribute welcher der Anwender setzt sind beizubehalten". Sehe ich eigenltich auch so. Aber der Anwender muss nicht alle Attribute setzen - und kann das bei CUL_HM auch nicht (mit User-Methoden!). Es gibt attribute welche CUL_HM gehören. Die meinsten habe ich verriegelt  - eventuell könnte ich stringenter sein. IODev darf der Anwender setzen - wenn er nicht den Auto-Mode IOgrp gewählt hat. Das ist schlüssig - der Anwender wird IODev nicht mehr ändern können und somit kann ich seine Entscheidung auch nicht überschreiben.
Zitat
der Benutzer hat die Moeglichkeit, die automatische Zuordnung durch ein Attribut mit dem Namen IODev zu beeinflussen.
Die Aussage ist quatsch. Der User - in deiner Implementierung hat die Möglichkeit jede Automatik abzuschalten. Ehrlich - CUL_HM ist hier meilen weiter! Der User kann bestimmte IOs zulassen, automatik einschalten, preferd-IOs definieren. Alles wie ich meine schlank und effizient. AssingIoPort ist hier eigentlich hinderlich.

In deiner Implementierung kann der User das IO über setReading setzen. Das ist schlicht eine Kathastrophe. Das geht ja garnicht. Das IO wird geändert -aber CUL_HM bekommt es nicht mit. Das IO wird nicht eingerichtet -geht also nur bedingt.

ZitatEin Attribut gehoert aus Prinzip dem Benutzer.
widerspruch.  Warum? Wenn der User es nicht setzen kann - un dich das verhindere  - gehört es mir. Punkt. Bedenke das einmal in deiner Philosophie - das ist schlüssig und wird seit Jahren in CUL_HM erfolgreich praktiziert. Die User sind zufrieden (zumindest traut sich keiner etwas zu sagen).

ZitatDass ich selbst Fehler mache...
ich jedenfalls rede nicht von coding fehlern - ich mache selbst genug. Ich reden von Grundsatzentscheidungen.

ZitatTheoretisch muesste vor dem Senden jedes Ausgabegeraet geprueft werden, auf welchem Wege das aktuelle Ziel am besten erreichbar ist. Koennen die Ausgabegeraete das zuverlaessig?
falsche Frage. Nicht das Ausgabegerät entscheidet, sondern die "vccu". Ich müsste schon wieder weiter ausholen... für CUL_HM (und für jedes Multi-Entity modul) fehlt die "modul Instanz" welche das Modul koordiniert. In CUL_HM habe ich einst den ActionDetector erstellt, dann das externe hmInfo und nun noch die "vccu" als interne, aber doch übergreifenden Entity. Das alles gehört eigentlich in die "modul-übergreifend-koordinierende Entity" - etwas was fhem schmerzlich vermissen lässt, weil das Desing strict flat sein soll.
Die vccu definiert zulässige IOs. Die IOs melden ihren Zustand - oder besser man kann ihn abfragen. Die Modul-Instanz entschiedet dann, welches IO am besten geeignet ist. Ist seit jahren am laufen. Der User kann - je Device (kanäle können das natürlich nicht - auch ein Hierarchiestufe welche FHEM eigentlich nicht kennt) die Automatik einschalten/prefered listen einrichten,...

ZitatGibt es einen tatsaechlichen Bedarf dafuer, oder ist das eine akademische Diskussion?
aber hallo!!! wo kommst du her? Mehr als natürlich. Ein Anwender von homematik kann mehrere IOs haben. Zur Redundanz, für Erreichbarkeit,... Ein IO kann überlastet sein (nach Funk-Vorscrift darf ein IO nur eine bestimmte Dauer je Stunden aktiv funken - eine Regelung über welche du dich mit deinen CULs hinwegsetzt). Und wenn ein IO keine "credits" mehr hat kann ich evtl ein andere nutzen (ohne Gesetzesbruch). Es gibt hand-helds welche sich bewegen. Auch das kann die vccu bedienen - automatisch

ZitatIch will mich nicht wehren, aber z.Zt. bin ich noch nicht ueberzeugt, dass es den Aufwand wert ist, da es die Sache fuer viele Beteiligte (Programmierer und Endanwender) verkompliziert.
Leider hast du dich nicht gewehrt. Die ursprüngliche Implementierung was nahezu perfekt. Nun ist es (sorry) ein Chaos aus meiner Sicht.
Ersatzschaltung ist essentiell. Ich sehe nicht, wie der kernel das machen sollte. das Modul sollte entscheiden, wie das zu machen ist. Übrigens sind dynamische IOs auch bei bluetooth in Presence ein Thema.
=> aus meiner Sicht solle der kernel sich auf sein Kerngeschäft beschränken. Die Alternative ist, es richtig zu machen. Dann ist aber deutlich mehr zu machen. Und ob das bei FHEM und dem Zoo am Module und Entwicklern durchsetzbar ist überlasse ich dir.


Zitat1) und 3) habe ich nicht als Problem verstanden, sondern als Luft abassen.
Ich lasse nicht wirklich Luft ab - ich engargiere mich um etwas zu retten. Luft ablassen ist etwas anders bei mir :)
1) ist mit sicherheit ein Problem, insbesonderen deine User-Implementierung. Bitte ersatzlos löschen. Dringend.
3) der Automode hat nichts mit Luft ablassen zu tun. Das ist Realität und funktional. Wenn eine User einen Automode einstellt hat er die Kontrolle über Attr IODev an mich abgegeben. Ok, mein strategischer Fehler - ich sollte ihm das kalr machen, indem ich ihm das setzen von diesem Zeitpunkt an verbiete oder zumindest einschränke. Das werde ich nun auch tun.

Zu 2) habe ich eine andere Ansicht. Ein Nutzer will das System sicher nutzen. Man sollte ihn for Fehlern bewaren (was auch du an einigen Stellen schon tust). User sind zu schützen.  Hacker und Freaks haben in fhem jede möglichkeit und können alles überschreiben. sowieso - das System ist offen.
Aus meiner Erfahrung wissen nur (sehr!) wenigen nutzer, was wirklich zu machen ist, ein homematik IO umzuschalten. Müsse sie auch nicht, macht der Modulentwickler.

ZitatDas ist nicht richtig: wenn $defs{NAME}{.AttrList} definiert ist, dann wird sie anstatt $modules{TYPE}{AttrList} verwendet.
Diese Moeglichkeit ist jetzt etwas ueber drei Jahre alt.
sehr!  cool. Habe ich nicht meit bekommen - und werden das nnun intensiv nutzen, im aufzuräumen.

Resumee: so wie es ist wird es typisch funktionieren. Ein Anwender wird wohl kaum die Methode setReading IODev nutzen (zum Glück). Schon das macht setReading zu einem Steuer-element - bei dem nun wirklich alles fehlt. Sollte es genutzt werden geht es bein CUL_HM schief. Sollte es nicht genutzt werden ist es sinnlos.
Mit fehlt hier das wie bei Attributen übliche
- user-interface
- auswahl-liste
- Modul-option eines Konsistenz-checks
- Modul-support das IO einzurichten
Hoffentlich nutzt es keiner

martinp876

Hallo Ansgar,
IO Ersatzschaltungen sind NOTWENDIG, realität und werden von mir nicht diskutiert. Sie sind gefordert und Anwender hatten sich eh gewundert, warum das nicht standard ist. Allein die Frage, ob man es braucht ist seltsam. Rein die Art der Implementierung kann diskutiert werden.

rudolfkoenig

ZitatSprich, die Frage klären müssen, ob es sinnvoll ist ein gesetztes Attribut automatisch zu übergehen, wenn der User via anderem Attribut Automatik festgelegt hat. (Der Fehler des nicht Löschens des Automatikhemmers fällt nach Murphy sicher in eine Abwesenheitsphase).
Ich habe nichts dagegen, wenn jemand das Denken dem Programm ueberlaesst, werde aber allergisch, wenn die Maschine meine Wuensche ignoriert. Wenn ich Fehler mache, dann sind das meine Fehler, daran kann ich was aendern. Wenn das Programm meine Wuensche ignoriert, dann brauche ich ein anderes Programm. Es bleibt euch frei, Attribute zu ignorieren, das ist aber nicht mehr FHEM, wie ich das fuer mich haben will.

ZitatAuf Modulebene vermutlich geeigneter lösbar. Der Qualitätswert wäre ohnehin schon auf Mudulebene geeignet bereit zu stellen. Das ist nicht mehr weit weg auch das IO zuzuweisen.
Sehe ich auch so, und ich weiss nicht, warum hier so ein Theater darum gemacht wird. Man muss weder AssignIoPort aufrufen, noch ein IODev Attribut anbieten, es reicht, wenn man das IODev Internal setzt, und sich auf IOWrite/Dispatch fuer die Kommunikation beschraenkt: die Schnittstelle ist damit weiterhin gewahrt, und man kann die IO-Module austauschen oder die IO-Kette erweitern.

noansi

Hallo Rudolf,

Zitatwerde aber allergisch, wenn die Maschine meine Wuensche ignoriert
Dein Standpunkt ist verstanden.
Die Implementierung mit Reading passt auch besser dazu, denn das Attribut manuell zu löschen ist auch ein User-Wunsch. Trotzdem bekommt man ein möglicherweise ungeeignetes IO beim nächsten Neustart "aufgezwungen", nur weil das IODev Attribut in der Attributliste des Moduls steht.  ;)
Eine Art Plug&Play. Für den Anfang mit fhem auch hilfreich. Von daher auch nicht wirklich zu kritisieren.

In der alten Attributsimplementierung hätte IODev bei Fehlen auch direkt mit einer Liste aller in Frage kommender IOs gefüllt werden können, mit Prio für das erste in der Liste. Dann hätte der User eine Lösch- oder Umsortierliste vorgefertigt bekommen. Und Martin schon eine IO Liste als mögliche Basis zum Attribut IOList bei der VCCU. (die VCCU benötigt aber auch noch ein eigenes IO, von daher hat IOList noch seine Berechtigung)

Wenn man nur mit diesem einen Attribut IODev die IO-Wahl kontrolliert ist Dein Kontroll-Standpunkt auch richtig.
Und auch CUL_HM kennt Fälle, wo eine automatische Wahl des IOs nicht möglich ist. Das betrifft virtuelle HM devices, die nur Broadcasts senden. Da muss der User ein IODev festlegen, so dass die Wunschempfänger den Broadcast auch empfangen können.
Auch wenn er die Automatik nicht wünscht, dann muss er ein jeweils passendes IODev setzen können.
Das vom Kernal angebotene IODev Attribut hat somit auch seine grundsätzliche Anwendungsberechtigung. Und wenn der User es nur so fahren will, muss er nicht umdenken, wenn er das gleiche Attribut nutzen kann.

Will er Automatik, dann sind mehr Einstellungen richtig zu wählen, VCCU einrichten und mit IOList versehen, HM devices mit IOgrp versehen, darüber wird dann auch eine Liste von VorzugsIOs angegeben.
Das Dogma, dass das Attribut IODev nicht Modulseitig anzutasten ist, sondern zwingend den vorgegebenen Wert einzustellen ist, wird nun hinderlich. Um den neuen Userwunsch zu respektieren, darf es nicht da sein. Damit wäre es in gleicher Logik sinnvoll, das Attribut mit der Umstellung automatisch zu löschen, denn sonst gehorscht das System dem User auch nicht! Ein Dilemma!
Ist es gelöscht, kommt auch keine Verwirrung bezüglich "falscher" Einstellung des IOs auf.
In der geänderten Automatik-Einstellung ist das Vorzugs-IO die Stelle, an der nun zur Wahl eines Wunsch-IO umzustellem ist. Die Dir vorschwebende Kontrollmöglichkeit ist also vorhanden, nun aber an anderer Stelle.
Von daher sollte das IODev Attribut dann bei Automatikwahl auch nicht mehr angeboten werden.

ZitatAssignIoPort setzt nur das System-interface. Das IO wird nicht vorgereitet - was bei HM notwendig ist.
Ja, da fehlt eine Moduleingriffsmöglichkeit, auch zum Verhindern in Automatikeinstellung. Nicht nur für HM.

Gruß, Ansgar.

martinp876

Hallo Rudi,

ich gehe nicht konform mit deiner Einstellung zu Attributen. Am Ende wiederspricht deine Implementierung deinen Aussagen. Sinnvoll ist es eh nicht.

Aber zurück: User Einstellungen sind zu beachten und haben Hoheit. So gut es eben geht. Daher:
vom User gesetzte Attribute haben Prio
   - das ist eine wichtige Richtlinie
   - das ist KEIN Dogma
   => User Attribute werden, wenn möglich, beachtet.

Ich habe auch "system Attribute". Diese lasse ich den User nicht ändern - hier kann er also auch keine Einstellungen (legal) vornehmen.

Aber zu fhem. Wie ich gestern gelernt haben kann man Attribute Entity-spezifisch definieren. Das ist wirklich prima und ich bin mal wieder etwas spät. Aber damit definierst du selbst, dass das vorhanden sein von Attributen volatil ist - und natürlich auch dessen Inhalt. Die Attribute ändern sich also, je nach dem, as mit der Entity passiert (sonst macht es ja keinen Sinn!!!). Um das ganze Konsistent zu halten muss (MUSS) der ordentliche Modul-programmierer aufräumen, kontrollieren,.... Ändert sich also der Zustand und es kommt eine Attribut-option hinzu und wird diese von User gesetzt hat der User seinen Wunsch geäußert. Attr <entity> OptAttr1 = OptAttrValXXX. Nun ändert sich die Entity, die Attribut-Optionen lassen hier OptAttr1 nicht mehr zu. Was machst du?
1) Ich lasse das Attribut stehen - ist ungültig, unzulässig, aber egal Der User wollte es so. Beim Reboot löscht es der kernel - oder?
2) ich lasse das Umstellen der Entity nicht zu so lange Attribute existieren, welche nach der Umstellung nicht mehr zulässig wären
3) ich lasse die Umstellung der Entity zu und bringen die Attribute auf Stand. Maximal schonend um die Richtlinie einzuhalten - logisch.

Welchen Tot wirst du sterben?
Für mich gibt es nur eine Lösung das ist 3). Alles andere destabilisiert das System. Der User kann möglicherweise garnicht übersehen, was er tut. Ich als Anwender von Modulen anderer Entickler wünsche mir dringend! dass diese die Standart Konfiguration auf Stand halten und ebenso initialisieren. Leider ist das nicht immer der Fall und ich muss mich sogar mit tirvialen Einstellungen rumschlagen und einarbeiten um einen Schalter zu bedienen. Weil der Programmierer den Default nicht automatisch anbietet.

Wie sieht es nun mit IODev aus. Einst hatte ich das Problem, dass ein IO Automatismus notwendig wurde. Die Semantik sit gewachsen und unterliegt der Methodik: Wähle einen IO Controller (vccu) und legen eine mögliche prio liste fest. => <vccu>:[<prefIO1>[,<prefIO2>[,<prefIO3>,...]]]
Es wäre nun cool gewesen, wenn der Anwender das in attr IODev hinterlegen hätte können. Aber die Semantic des Attributs forderte genau ein IO.
Daher habe ich ein IOgrp eingeführt mit welcher der Anwender (aktiv!) den Wunsch äussert, IOs nach (seinen!) Regeln automatisch gesetzt werden. Natürlich kann ich im Sagen - nun ja, lieben User, hättest du mal besser attr IODev gelöscht, dann würde auch IOgrp funktionieren. Obendrein hat fhem.pl aber ein attr IODev gefordert. Dead-lock.

Hier sollte man eben kein Dogma anwenden (auch wenn es schwer fällt) sondern den kurzen Dienstweg gehen und nach der "Richtlinen methode" vorgehen.
=> User wüchscht IO Automatik => Attr IODev wird vom Modul übernommen, IOgrp gehört dem User
Modul-Attribtute sind vom User nicht mehr Änderbar (muss ich an dieser Stelle noch realisieren)

De-Fakto ist es nicht sinnvoll möglich, dem User die uneingeschränkte Hoheit über Attribute zu geben. Bestmöglich, ja. Uneingeschränkt, nein!
Ich kann gerne noch Warnungen ausgeben, wenn ich eingreife - in User Attribute. Modul-Attribute gehören mir, die hat der User nie gesetzt und kann es auch nicht.


martinp876

Noch mal für Rudi,
über den Umgang mit Attributen habe ich nun referriert und zumindest versucht klar zu machen, dass es (nahezu) unauflösbare Konflikt beim Umgang mit dem "Userwillen" gibt,welche das Userinterface, macht man es richtig - SEHR umständlich macht. Rudi hat keine Stellung bezogen, auch gut.

Nun einmal zu AssignIoPort. Keine Diskussion, ob es nun ein Port oder ein Device ist - oder nur ein IO. Und ALLE meine kommentare sollen weder persönlich noch irgendwie reines gemecker sein. Ich habe ein paar Erfahrungen und CUL_HM hat Anforderungen. Ich hoffe, die Anmerkungen werden als Anregung verstanden, als solche reviewed und evtl sogar angenommen.
Also AssignIO:
Rudis konzept ist gut - aus der Ferne betrachtet. Funktions-Entitys (also bspw ein CUL_HM Aktor) - ich kürze einmal "FE" ab - welche ein IO benötigen kommnizieren - objektorientierter Ansatz - über die Zentrale (fhem.pl) miteinander. Dabei werden alle möglichen FM mit den passenden IOs verbunden. Cool .

Nun, tritt man näher funtioniert es vorne und hinten nicht - und auch nicht in der Mitte. Es funktionsfähig zu machen wäre ein erheblicher Eingriff!! Möglich, ja. Gewünscht?

Vorne: Die IO Auswahl.
Um ein IO zu proglamieren muss man prüfen
- ist es ein IO
- unterützt es das Modul (CUL_HM)
- ist es konfiguriert auf das Modul - oder schon von konträren Module allokiert
- ist es enabled
=> nun haben wir eine Liste möglicher IOs nach statischen Kriterien
- ist das IO auf die Addresse geprägt, welche das FM benötigt?
=> IO config check
- Ist das IO erreichbar
- besteht ein Oberload zustand
- besteht ein sonstiger Error
=> nun sind die dynamischen Zustände der IOs eingegrenzt
- ist das FM in reichweite
- welches IO hat den besten Empfang?
=> nun sind die FM berücksichtigt.
- sind wir gerade am abarbeiten eines Auftrags? Kein Umschalten des IOs mitten im "job"
=> der Operational-state der FM/IO beziehung ist berücksichtigt
- hat der User präferenzen, umschaltungen einzuschränken oder priorisieren?
=> der User-wille

Alles aus der obigen Liste ist notwendig
==> AssignIo bietet hier so gut wie nichts. Wäre auch schwer, klar. Besser, das Modul macht dies
==> wäre SEHR schön, wenn die internen Schnittstellen standartisert würden. Hier habe ich aber wenig Hoffnung, in endlicher Zeit irgendetwas zu erreichen.  Ich erinnere daran, dass Rudi schon verhindert hat, dass der homematic mode von der CUL hinreichend unterstützt werden kann. Daher hat Ansgar das Modul TSCUL ins rennen schicken müssen. leider.


Hinten:
Ist ein IO vorne ausgesucht muss es hinten eingerichtet werden. Bei einer Änderung der IO<>FM Zuordnung muss das FM aus dem alten IO gestrichen werden und im neuen IO zugewiesen werden.
==> AssignIo bietet hier wiedrum nichts.


Und die Mitte: Performance
AssignIo ist als statische Zuordnung erdacht. Dabei ist Performance ein kleines Problem. Da wir aber dynamische Zurordnungen machen ist Performance bei der Prüfung ein erhebliches Thema. Ein Paradigmen-shift wäre hier notwendig. CUL_HM versucht Prüfungen auf die Konfigurationsebenen zu heben und die operationelle Ebene (welche performance-relevant ist) von allem zu entlasten, was hier sinnvoll vermieden werden kann.


Wie also geht es, wenn doch nichts passt? nun, CUL_HM prüft das IO (leider  kein einheitliches Interface - sehr schade) und das FM sowieso. Der User kann seine Wünsche doch recht detailliert in einem einzigen Attribut artikulieren.
Um dem System genüge zu tun wird AssignIo befriedigt. Beitragen tut AssignIo eigentlich nichts, bietet ja nichts. Eigentlich behindert es in diesem Zustand nur.


So lange AssignIo Anforderungen nicht beachtet - oder sogar unterstützt - bleibt CUL_HM gar nichts anderes übrig, es faktisch zu umgehen und formal zu befriedigen.


Schaue ich mir den Code in fhem.pl im IO umfeld an komme ich schon zum nächsten Thema. init_done wird schon vor finish_init() gesetzt. Ok, der Trigger kommt erst danach, was bei rereadCfg in einer andern Reihenfolge passiert. Hier wird leider auch der Trigger REREADCFG ausgelöst, bevor init_done gesetzt ist.
Neue Frage: wie ist "init_done" definiert? hart? Ich würde erwarten, dass init_done dann gesetzt wird, wenn der kernel init erledigt hat. Final. Danach erwarte ich einen Trigger
welchen die Module nutzen können (und müssen!) um die Konfiguration zu prüfen. Ach da gibt es auch noch ein reread_active. Sollte so etwas nicht zusammen mit init_done schon beim ersten booten initialisiert werden? Wäre sauber.

Wie gesagt, ich warte bis zum Wochenende. Und noch einmal - das sind Anregungen - kritik am Code (weniger - Rudi ist hier deutlich besser als ich!!) und der Architektur (deutlich mehr) - aber alles hoffentlich konstruktiv.
CUL_HM wird auch in Zukunft den kernel befriedigen. Sollte der Kernal hilfreich sein wird diese Hilfe entgegen genommen - gerne.