Autor Thema: Fragen zum AssignIOPort  (Gelesen 282 mal)

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3496
Fragen zum AssignIOPort
« am: 14 Mai 2020, 17:07:01 »
In meinen beiden geerbten Modulen wird jeweils in der sub Define auch AssignIOPort($hash) aufgerufen. Bisher habe ich wenig Gedanken daran verschwendet warum, ala wird schon richtig sein denn wir brauchen ja später ein IODev. Da ich z.Z. einen Fehler suche habe ich das beim 10_MAX.pm Modul mal auskommentiert und war doch etwas überrascht das nach einem Restart noch alles lief. Wenn ich das nun richtig sehe/lese wird AssignIOPort eh von fhem.pl beim Start aufgerufen wenn das Device ein Attribut IODev hat. D.h. ein eigener Aufruf ist unnötig ? zumindest würde das erklären warum ein grep AssignIOPort *.pm so wenig andere Module zeigt.

Beim 14_CUL_MAX.pm kann das vernutlich im Define auch entfallen, mit einer Ausnahme :
Da ich das Modul umgebaut habe das es mit mehr als einem CUL als IODev arbeiten kann rufe ich zum Wechseln des aktuellen CULs AssignIOPort auf.
Allerdings nicht nur mit dem $hash sondern auch dem zweiten Parameter proposed und der ist dann vorbesetzt mit dem neuen "Wunsch" CUL Device.
Wenn ich hier die sub wieder richtig lese, ist das lediglich ein Wunsch, d.h. schlägt dieser Versuch fehl greif wieder das eigenliche IODev unter dem Attribut.

Habe ich das soweit richtig verstanden ? Bzw. hat jemand eine mögliche Erklärung dafür warum M.Gehre das damals mit ins Define gepackt hat ? 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22328
Antw:Fragen zum AssignIOPort
« Antwort #1 am: 14 Mai 2020, 18:12:07 »
Zitat
D.h. ein eigener Aufruf ist unnötig ?
Nicht, wenn man nach define direkt loslegen will, ohne FHEM-Restart.
Der Code in fhem.pl ist eher fuer fahrlaessige fhem.cfg Editierer drin.

Zitat
Wenn ich hier die sub wieder richtig lese, ist das lediglich ein Wunsch, d.h. schlägt dieser Versuch fehl greif wieder das eigenliche IODev unter dem Attribut.
So sehe ich das auch.

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3496
Antw:Fragen zum AssignIOPort
« Antwort #2 am: 14 Mai 2020, 19:59:04 »
Nicht, wenn man nach define direkt loslegen will, ohne FHEM-Restart.
hmm....  z.b. wenn das Device mit autocreate gerade erzeugt wurde ? Aber dann fehlt doch auch das Attribut IODev noch ?

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22328
Antw:Fragen zum AssignIOPort
« Antwort #3 am: 15 Mai 2020, 09:40:23 »
Zitat
z.b. wenn das Device mit autocreate gerade erzeugt wurde ?
Oder wenn man das define ueber telnet oder FHEMWEB selbst eingegeben hat, das soll es auch noch geben.

Zitat
Aber dann fehlt doch auch das Attribut IODev noch ?
Das Attribut IODev ist nur dann relevant, wenn es mehr als eine Moeglichkeit gibt, das IODev Internal zu setzen, d.h. es ist eine Moeglichkeit fuer den Benutzer, AssignIOPort zu ueberschreiben.

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3496
Antw:Fragen zum AssignIOPort
« Antwort #4 am: 15 Mai 2020, 11:35:59 »
THX Rudi, ich glaube ich habe nun eine Lösung die alle in Frage kommenden Möglichkeiten abdeckt.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher