Autor Thema: IODev Handling durch device  (Gelesen 1266 mal)

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1108
Antw:IODev Handling durch device
« Antwort #15 am: 27 April 2021, 20:55:42 »
Hallo Rudolf,

Zitat
Ich fuerchte da musst Du weiter ausholen, oder an die passende Stelle verweisen, da meine Erinnerung mich im Stich gelassen hat.
Das hat gar nichts mit Dir zu tun, sondern kam im IOgrp/IODev Zusammenhang im Homematic Forum wegen unterschiedlichen Werten zwischen Reading IODev und Attribut IODev.
Wenn man das Attribut IODev nicht anbietet, darf man aus dem Code raus auch sinnvollerweise nur das Internal setzen, sonst gibt es nach einem Save Config die "Strafe" beim nächsten FHEM Start in Form von Fehlermeldungen.
Und es soll ja auch Menschen geben, die sich den diesbezüglichen fhem.pl Code noch nicht angesehen haben, die Funktionen aber dennoch benutzen wollen. ;-)

Mit dem Weglassen des Angebots des Attributs IODev habe ich auch noch ein gedankliches Problem.
Wie schon geschrieben, gibt es Szenarien für einige oder auch alle HM devices, die das Attribut IODev benötigen.
Allerdings ist das beim CUL_HM Modul erst nach der kompletten Verarbeitung der Config klar, weil erst dann alle devices,
- somit auch die optionale VCCU als IO Verwaltungsinstanz, definiert sind
und
- erst dann der jeweilige HM device Typ und Subtyp via Attribut bekannt sind. Und damit auch ein eventueller Bedarf nach Attribut IODev.
D.h. alle Nutzer, die eine Konfiguration nur auf Basis von IODev fahren, bekämen nach einem Update erst mal ihre funktionsfähige IO Konfiguration unterm Hintern weggerissen. Wenn ich es auf den ersten Blick richtig sehe auch ohne die Möglichkeit einer automatischen Umschreibung von Attribut alt auf Attribut neu auf Basis des Frameworks.
Aus Kompatibilitätsgründen ist der Weg des kompletten Weglassen des Angebots wenig empfehlenswert.

Es bliebe noch die nicht ganz saubere Möglichkeit, das Attribut für die Initilisierungphase zu zu lassen und danach für ein neues Setzen zu entziehen, um eine Umschreibung einzubauen. Danach kann AssignIoPort genutzt werden, um nur das Internal IODev zu setzen, falls beim Umschreiben kein IO zugewiesen wurde, wie ich gesehen habe.

Zitat
allerdings ist FinalizeInitFn prinzipiell auch nicht anders.
Wenn FinalizeInitFn nicht zweckgebunden definiert wird oder missbraucht wird, klar. Ein fehlendes $init_done=1 sorgt aber auch für Einschränkungen.

$init_done erst später zu setzen, z.B. wenn global INITIALIZED verarbeitet ist, würde vermutlich zu erheblichen Kompatibilitätsproblemen zu bestehenden Modulen führen.

Äquivalenz ließe sich vermutlich mit einem neuen beispielsweise global PREINITIALIZED vor INITIALIZED erreichen, wenn sich in DoTrigger und abhängigen Funktionen nicht noch ein verstecktes $init_done!=1 Problem auftut.

In's Timerhandling dafür noch eine Sonderbehandlung einzubauen fände ich deplatziert. Und kommt ohnehin erst nach dem INITIALIZED, damit auch im Ablauf nicht mehr sinnvoll.

Ich habe auch nicht generell NotifyFn und InternalTimer als Initialiserungsmöglichkeit nach dem FHEM Start kritisiert. Allerdings hast Du die finish_init() Funktion ja (rein auf das IODev Problem bezogen) auch nicht grundlos nicht via InternalTimer aufgerufen, sondern direkt im Init Ablauf, eben weil zu dem Zeitpunkt noch nichts anderes läuft, alles definiert ist und Du rechtzeitig IOs zuweisen wolltest.

Zitat
Nein, aber das ist kein Argument fuer ein Framework-Umbau, sondern eher eins fuer CUL_ReadAnswer bzw. CUL_DoInit Umbau.
Du bist nicht allein mit dem CUL Modul. Das wird auch in anderen IO-Modulen so gemacht. Ich müßte mich da mit TSCUL kompatibel auch vor dem "ersten Stein Werfer" in Deckung bringen.  ;)

Gruß, Ansgar.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23974
Antw:IODev Handling durch device
« Antwort #16 am: 28 April 2021, 18:56:59 »
Ich habe jetzt AssignIoDev umgebaut, damit es statt Attribut ein Reading setzt, wie oben beschrieben.

Zitat
Allerdings hast Du die finish_init() Funktion ja (rein auf das IODev Problem bezogen) auch nicht grundlos nicht via InternalTimer aufgerufen, sondern direkt im Init Ablauf
Das hat damit wenig zu tun, sondern damit, dass der Aufruf ueber InternalTimer aufwendiger waere.

Ich kann (wenn immer noch gewuenscht) ein FinalizeInitFn Aufruf einbauen, bitte bestaetigen.
Am liebsten waere es mir in der aktuellen finish_init(), die macht ja bereits eine Schleife ueber alle Geraete.

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1108
Antw:IODev Handling durch device
« Antwort #17 am: 28 April 2021, 22:11:43 »
Hallo Rudolf,

vielen Dank für die Änderungen.
Ich schau erst mal, ob ich damit alle Probleme erschlagen kann. Ist ja doch deutlich umfangreicher geworden, als ursprünglich auch nur ansatzweise angedacht.  :)

Gruß, Ansgar.

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1176
Antw:IODev Handling durch device
« Antwort #18 am: 02 Mai 2021, 13:57:51 »
Ich habe jetzt AssignIoDev umgebaut, damit es statt Attribut ein Reading setzt, wie oben beschrieben.
Das hat damit wenig zu tun, sondern damit, dass der Aufruf ueber InternalTimer aufwendiger waere.

Ich kann (wenn immer noch gewuenscht) ein FinalizeInitFn Aufruf einbauen, bitte bestaetigen.
Am liebsten waere es mir in der aktuellen finish_init(), die macht ja bereits eine Schleife ueber alle Geraete.
Ich nehme an, die Änderungen wurden in der Routine AssignIoPort vorgenommen.

Für eine Installation mit mehreren EnOcean-Transceivern ist es notwendig, statisch festzulegen, welcher dieser Transceiver als Sender verwendet wird. Diese Festlegung erfolgt nach wie vor - sowie ich das verstehe - über das Attribut IODev. Welche Routine das Attribut IODev auswertet und das Internal IODev entsprechend nachzieht, ist mir noch nicht klar.

Da das Attribut von AssignIoPort das Attribut IODev nicht mehr versorgt wird, ist diese statische Zuordnung nicht mehr gewährleistet.
Wird dies noch angepasst oder muss das Attribut IODev im EnOcean-Modul nun nach dem Aufruf von AssignIoPort beim Anlernen von Devices entsprechend beschrieben werden?

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1108
Antw:IODev Handling durch device
« Antwort #19 am: 02 Mai 2021, 15:03:14 »
Hallo Klaus, hallo Rudolf,

Zitat
Ich nehme an, die Änderungen wurden in der Routine AssignIoPort vorgenommen.
Nicht nur, siehe https://svn.fhem.de/trac/changeset/24351/.
CommandAttr ist zusätzlich ebenso angepasst, wie CommandSetstate.

Dabei geht es darum, die Zuweisung des IOs an das Ende des Inits zu legen (wie bisher auch), damit die IO devices auch definiert, sind, die über Attribut oder Reading beim Init gesetzt werden.

In AssignIoPort wird nur noch das Reading IODev gesetzt. Bei Save Config werden die Readings in der fhem.save gespeichert und beim nächsten Start von fhem daraus wieder gelesen.

Das Attribut IODev wird weder angetastet noch seiner Wirkung beraubt. Sprich, wird es gesetzt, dann wird das IO auch daraus eingestell (was bedeutet, dass das Internal IODev darauf eingestellt wird). Dabei wird auch das Reading IODev gleich gesetzt.
Ist das Attribut nicht gesetzt, dann wird das Reading IODev genutzt, um das IO daraus einzustellen. Also die neue Methode.
Sprich das Attribut kann dann auch gelöscht werden, ohne dass sich was an der IO Zuordnung ändert, so denn das Reading gespeichert wurde. Das Attribut wird aber nicht automatisch gelöscht.

D.h. bei autocreate wird es jetzt vermutlich interessant für Dich. Da wird nicht das IODev Attribut gesetzt, sondern nur das Reading IODev.
Wenn Du das Attribut noch unbedingt setzen möchtest, dann könntest Du es im Undefined Trigger mitgeben, so da bekannt, denke ich.

Sinnvoll ist das, wenn der Modulcode geändert wird und man beim Testen Fehler einbaut, so dass das Modul beim Start nicht mehr
geladen wird. Somit die devices nicht mehr definiert werden und damit das Reading IODev nicht gesetzt wird und somit beim nächsten FHEM Start nach Korrektur des Fehlers das Reading weg ist und eventuell ein anderes IO zugewiesen wird, wenn kein Attribut IODev in der config vorhanden ist.

Gruß, Ansgar.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23974
Antw:IODev Handling durch device
« Antwort #20 am: 02 Mai 2021, 20:16:20 »
Wenn man im Modul auf das Vorhandensein des IODev Attributes prueft, dann kann das zu Problemen fuehren.
Ich bin der Meinung, dass das nicht notwendig ist, das Modul soll (wenn ueberhaupt!) nur das IODev Internal anfassen.
Eigentlich sollte die Kommunikation zwischen den beiden Modulen ueber IOWrite() bzw Dispatch laufen.