Wird beim zweistufigen Modulkonzept beim Starten von FHEM zuerst das IO Device und dann die Client-Devices definiert bzw. wird das beim Speichern in der entsprechenden Reihenfolge in fhem.cfg geschrieben?
Wenn Du die entsprechenden Prefix verwendest dann ja.
73 IODev
74 das Device Modul
Nur als Beispiel
Welches Präfix meinst Du? Oder richtet sich die Reihenfolge der Speicherung nach dem Internal NR?
Nach der Zahl vor dem Modulnamen
Sorry bin kurz angebunden, sonst wurde ich mehr schreiben
@zap: die Reihenfolge des Speicherns in fhem.cfg ist identisch mit der Reihenfolge des Definierns, bzw. die beim Einlesen der Konfiguration.
Wenn man ein Clientdevice ohne IOdevice definirt, dann kommt normalerweise im Logfile die Meldung "No I/O device found for ...". Das passiert, wenn man fhem.cfg (ohne darueber nachzudenken) selbst umbaut, oder IOdevice entfernt bzw. ersetzt.
Es gibt z.Zt. keine elegante Moeglichkeit, die Reihenfolge von spaeter hinzugefuegten IOdevice (beim Ersetzen) zu aendern, ausser fhem.cfg direkt zu editieren..
@CoolTux: dieser Praefix ist inzwischen beinahe nutzlos: es bestimmt die Reihenfolge in der Dispatch Funktion den Client-Modulen die Rohdaten vom IODev zu praesentieren. Damit kann z.Bsp. das USF1000 Modul FS20 Signale "entfuehren".
Guten Morgen Rudi,
Dann lag ich ja total daneben. Danke für die korrekte Info.
@Zap
Sorry für die falsche Info. Da lag ich voll daneben.
Grüße
Danke Euch für die Antworten. Ich werde meine Client Module dahingehend anpassen, dass sie im Define nicht einfach davon ausgehen, dass das IO Device schon definiert ist bzw. im Zweifel eine entsprechende Fehlermeldung werfen.
Ich stecke jetzt in der FHEM Entwicklung bzw. fhem.pl nicht so tief drin. Aber grundsätzlich weiß doch jedes IO Modul, welche Client-Module zu ihm gehören und wenn man eine lauffähige Konfiguration in FHEM aktiv hat, sollte entsprechend auch in jedem Client-Modul das IODev gesetzt sein. Auf dieser Grundlage könnte man doch beim Speichern der Config dafür sorgen, dass dies in der richtigen Reihenfolge in fhem.cfg geschrieben wird, oder? Passiert das aktuell schon so?
Man darf mich gerne hauen wenn ich mich irre, aber so wie ich das verstanden habe und auch entwickelt habe muß der Modulauthor selber für die Logik sorgen was das wissen und erkennen an geht.
$hash->{Clients} = ":NUKIDevice:";
Dies sorgt dafür das das physisches Modul weiß welche logischen Module ihm zugeordnet sind.
Das ist korrekt. Ich habe das ganze zweistufige Modulkonzept vor einiger Zeit im Wiki mal ausführlich dokumentiert: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module
Gruß
Markus
ZitatMan darf mich gerne hauen wenn ich mich irre,
Nicht hauen, hoechstens korrigieren :)
$hash->{Match} in der logischen Modulbeschreibung (nicht Instanz $hash!) wird verwendet, um in Dispatch eine vom physischen Geraet gemeldete Nachricht dem zustaendigen logischen Modul zuzuordnen (man denke an CUL vs FS20/FHT/CUL_EM/CUL_WS/etc). Das geht natuerlich nur mit geladenen logischen Modulen, d.h. wenn ein "define XXX FS20 ..." usw. vorher durchgefuehrt wurde.
$hash->{Clients} in der physischen Modulbeschreibung wird verwendet, falls kein bereits geladenes logisches Modul sich fuer die gemeldeten Daten zustaendig fuehlt, um ein autoload durchzufuehren. Normalerweise fuehrt das Interpretieren dieser Nachricht im gerade geladenen logischen Modul zu einem "UNDEFINED XXX FS20 ..." Event, was ueblicherweise via autocreate mit dem Anlegen einer logischen Instanz (define XXX FS20 ...) endet.
Der Artikel von Markus ist aber viel detaillierter...
Zitat von: zap am 18 Dezember 2016, 11:53:00
Danke Euch für die Antworten. Ich werde meine Client Module dahingehend anpassen, dass sie im Define nicht einfach davon ausgehen, dass das IO Device schon definiert ist bzw. im Zweifel eine entsprechende Fehlermeldung werfen.
Ich stecke jetzt in der FHEM Entwicklung bzw. fhem.pl nicht so tief drin. Aber grundsätzlich weiß doch jedes IO Modul, welche Client-Module zu ihm gehören und wenn man eine lauffähige Konfiguration in FHEM aktiv hat, sollte entsprechend auch in jedem Client-Modul das IODev gesetzt sein. Auf dieser Grundlage könnte man doch beim Speichern der Config dafür sorgen, dass dies in der richtigen Reihenfolge in fhem.cfg geschrieben wird, oder? Passiert das aktuell schon so?
Ich würde dir empfehlen jeglichen Versuch von Kommunikation mit dem IO-Device in der Define-Funktion nur dann vorzunehmen, wenn FHEM bereits initialisiert/gestartet ist ($init_done == 1). Während der Initialiserungsphase sollte man keine IO-Operationen via IO-Device machen. Im Falle das FHEM sich gerade initialisiert ($init_done == 0) sollte man in der NotifyFn auf das global-Event INITIALIZED bzw. REREADCFG lauschen. Details dazu im Wiki zur DefineFn: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Define
Gruß
Markus
Zitat von: rudolfkoenig am 17 Dezember 2016, 09:51:08
Es gibt z.Zt. keine elegante Moeglichkeit, die Reihenfolge von spaeter hinzugefuegten IOdevice (beim Ersetzen) zu aendern, ausser fhem.cfg direkt zu editieren..
Deshalb hatte ich schon vor langer Zeit vorgeschlagen, in den Modulen, die IOdevices erzeugen, dafür zu sorgen, dass ein IOdevice als solches "erkennbar" ist, beispielsweise durch ein entsprechendes Internal. Dann könnte man beim Speichern der fhem Konfiguration automatisiert dafür sorgen, dass IOdevices möglichst früh gespeichert werden.
Ist nicht die Existenz von $hash->{clients} genau dieses Flag? Ok, gibt es natürlich nur, wenn es auch Client Module gibt. Allerdings ist auch nur dann wichtig, dass ein IO Device frühzeitig definiert wird.
Also könnte man beim Speichern zunächst mal alle Devices speichern, die o.g. Internal gesetzt haben.
es sind keine zusätzlichen flags nötig.
man müsste vor dem speichern nur alle devices durch gehen und an hand des IODev internals jeweils alle devices die zu einem iodev gehören zusammen suchen und dann jeweils zuerst das iodev und alle zugehörigen devices speichern und dann mit dem nächsten iodev weiter machen. und danach den ganze rest.
Zitat von: betateilchen am 18 Dezember 2016, 13:47:32
Deshalb hatte ich schon vor langer Zeit vorgeschlagen
... genau den Thread habe ich aus (bei mir) aktuellem Anlass vor ein paar Tagen ausgegraben (https://forum.fhem.de/index.php/topic,21023.msg538538.html#msg538538) :-[
Zitat von: justme1968 am 18 Dezember 2016, 18:38:09
man müsste vor dem speichern nur alle devices durch gehen und an hand des IODev internals jeweils alle devices die zu einem iodev gehören zusammen suchen und dann jeweils zuerst das iodev und alle zugehörigen devices speichern und dann mit dem nächsten iodev weiter machen. und danach den ganze rest.
Hatte ich seinerzeit schon genau so probiert, aber das hat nicht zuverlässig funktioniert (warum, weiss ich nicht mehr genau).
Genau deshalb kam damals die Idee mit der "Selbstkennzeichnung" von IOdevices.
man muss auf jeden fall von den aktuell bei den clients eingetragenen iodev aus gehen und diese jeweils gruppiert mit den zugehörigen clients abspeichern.
wenn man umgekehrt nur von den generell möglichen clients eines iodev aus geht bringt man installationen durcheinander die mehrte gleiche iodevs haben und die clients nicht im
define fest eingetragen sind. das ist die große mehrheit. fs20, it und auch hm ohne vccu.
aus diesem grund kann man auch nicht einfach alle iodevs zusammen an den anfang sortieren.
vielleicht fällt dir noch ein was damals nicht funktioniert hat.
Ich habe mir jetzt eine Funktion gebaut, die mir drei Ergebnisse liefert:
Ein array mit allen in Clients gefundenen IODevs
2016.12.18 20:25:48.007 1: DEBUG>$VAR1 = [
'hmuart'
];
Einen hash1 mit devicename und zugehörigem IODev
2016.12.18 20:25:48.009 1: DEBUG>$VAR1 = {
'sz_Bett_links' => 'hmuart',
'ez_Sensor' => 'hmuart',
'wz_RT' => 'hmuart',
'az_Ventilator' => 'hmuart',
'az_RT' => 'hmuart',
'Melder_Klingel' => 'hmuart',
...
Einen hash2 mit allen devices ohne IODev
2016.12.18 20:25:48.016 1: DEBUG>$VAR1 = {
'PegelHH' => 'noiodev',
'sz_RT_ClimaTeam' => 'noiodev',
'Gruppe_F' => 'noiodev',
...
Als nächstes muss ich mir eine Logik bauen, um einzelne devices zu speichern.
Dann ein loop über das erstgenannte Array und in dieser Schleife
- zuerst das IODev sichern
- alle Geräte aus hash1 sichern, die dieses IODev verwenden.
Im letzten Schritt alle Geräte ohne IODev aus hash2 sichern.
Soweit richtig gedacht?
Da fhem.pl inzwischen das IODev Attribut automatisch setzt in AssignIoPort (bis auf CUL_WS), ist vermutlich die Reihenfolge der IODevs beim Schreiben egal. Ich habe trotzdem noch Respekt vom automatisches Umsortieren, die Kommentare werden sinnlos, vmtl. gibt es auch andere Nebeneffekte, die erst in ein paar Wochen auftauchen.
Ich wuensche mir, dass wir vorher die Problemfaelle klar beschreiben, und nicht nur ein eingebildetes Problem loesen. Der TE hat nur eine Frage gestellt, und kein Problem beschrieben.
probleme:
- anwender tauscht ein iodev gegen ein neues aus. d.h. das neue wird ganz normal per define angelegt, alle IODev attribute von hand umgesetzt, das alte gelöscht und getestet -> erst mal läuft alles. aber beim nächsten neustart gibt es ein problem.
@betateilchen: durch das zusammen suchen über die hashes wird die reihenfolge komplett umgeschmissen.
wie wäre folgendes:
- hash1 wie oben vorgeschlagen erzeugen
- die schleife bleibt wie bisher mit folgenden änderungen:
- wenn das aktuelle device (als iodev) in hash1 enthalten ist -> aus hash1 löschen
- wenn das aktuelle device ein iodev hat das in hash1 enthalten ist -> zuerst das iodev sichern, dann das device
damit würde die reihenfolge im grossen und ganzen beibehalten, nur die ios werden jeweils vor das erste device sortiert das sie verwenden falls die reihenfolge nicht passt.
@Rudi: keine Sorge. Es geht mir mehr um die Machbarkeit selbst, weil mich das Thema schon lange ärgert. Die fhem Welt besteht nämlich nicht nur aus fhem.cfg ;)
@Andre: danke für die Hinweise. Werde ich mal überlegen.
Hi,
gibt es zu dem Thema inzwischen eigentlich neue Erkenntnisse? Es scheint doch das ein oder andere Problemchen zu geben, wenn z.B. ein IO-Device ausgetauscht werden soll.
Ich bin mir nicht ganz sicher, ob das Problem grundsätzlich nur für IO-Devices auftritt, oder auch für andere Devices, die irgend eine "Basis" voraussetzen. Ich habe jetzt grad das Beispiel nicht im Kopf, aber ich glaube, das war irgendwas mit PRESENCE.
Gruß,
Thorsten
Ich empfehle:
- der ModulAutor soll erst dann IOWrite verwenden, wenn die Initialisierung abgeschlossen ist. Das kann man mit notify auf global:INITIALIZED oder mit InternalTimer(1, ...) erreichen. Dann werden die per Attribut gesetzten IODevs auch beruecksichtigt.
- der Benutzer soll nach Austausch des IODevs die IODev Attribute anpassen, z.Bsp. mit "attr IODev=CUL_alt IODev CUL_neu"
Hi,
danke für die rasend schnelle Antwort. Das bedeutet, dass die Modulautoren das Problem lösen sollen und man keine Annahmen über die Reihenfolge der Gerätedefinition machen sollte. Dann muss ich das auch mal für HM-Wired reparieren...
Gruß,
Thorsten
Zitat von: rudolfkoenig am 14 Februar 2017, 14:05:25
- der Benutzer soll nach Austausch des IODevs die IODev Attribute anpassen, z.Bsp. mit "attr IODev=CUL_alt IODev CUL_neu"
denn dann werden die Geräte neu durchnummeriert, sodass die "versorgten" Geräte eine höhere Nummer bekommen als das neu angelegte IODev selbst.
Allerdings ist mir noch nicht ganz klar, warum ich inzwischen {NR} Werte weit im 5-stelligen Bereich in meinem System habe. Irgendwie scheint es mir, als würden die Geräte viel zu oft neu durchnummeriert.
Zitatdenn dann werden die Geräte neu durchnummeriert
Stimmt, kann aber nicht mehr begruenden, wieso. Ich finde, diese Umnummerierung sollte entfernt werden.
Die automatische Zuordnung finde ich sinnvoll, damit der Benutzer nicht verpflichtet ist, das explizit zu tun. Das logische Modul darf aber nicht vor der Zuweisung der Attribute das IODev verwenden, da eine automatische Zuordnung nicht immer richtig ist.
Zitat von: rudolfkoenig am 14 Februar 2017, 14:37:05
Stimmt, kann aber nicht mehr begruenden, wieso.
Weil beim Speichern der Konfiguration die Geräte nach Nummern aufsteigend sortiert und (ohne die Nummer) gespeichert werden.
Durch die Umnummerierung wird weitgehend sichergestellt, dass beim FHEM Start kein Gerät vor seinem zugehörigen IODev definiert wird.
Zitat von: rudolfkoenig am 14 Februar 2017, 14:37:05
Ich finde, diese Umnummerierung sollte entfernt werden.
Ich auch. Wobei mir ja grundsätzlich egal ist, ob meine 350 Geräte von 1-350 oder von 1-27934 durchnummeriert sind. Es war mir nur aufgefallen, dass ich seit einiger Zeit sehr hohe Nummern im System habe.
Habe die Umnummerierung entfernt.
Hi,
ich bin jetzt soweit, das Problem für HM485 anzugehen. Meine Devices haben auch das Attribut IODev, aber fhem.pl liefert mir diese Meldung, wenn das IODev vorher noch nicht definiert ist:
configfile: HBW_Sen_Key_12_HBW7296279: unknown IODev hm485 specified
Das Attribut wird dann nicht gesetzt. D.h. ich habe dann auch keine echte Chance, mit den IOWrites zu warten, da mir das IODev komplett verloren geht. Ein AssignIoPort ist auch nicht viel besser, da das natürlich auch kein gültiges Device bekommt:
No I/O device found for HBW_Sen_Key_12_HBW7296279
Ich könnte jetzt natürlich mein IODev in einem anderen Attribut oder einem Internal parken und dann später AssignIoPort aufrufen, aber das ist nicht wirklich schön.
Wie ist das denn jetzt gedacht?
Gruß,
Thorsten
Zitatfhem.pl liefert mir diese Meldung, wenn das IODev vorher noch nicht definiert ist:
Ich gehe davon aus, dass dein fhem.pl nicht aktuell ist. Siehe auch https://forum.fhem.de/index.php/topic,69591.msg611353.html#msg611353
Bei mir liefert folgende Reihenfolge keinen Fehler beim starten:
define FS20 FS20 1234 56
attr FS20 IODev CUL
define CUL CUL none 0000
Zitat von: rudolfkoenig am 02 April 2017, 08:38:55
Ich gehe davon aus, dass dein fhem.pl nicht aktuell ist.
Ah ja, da hast Du Recht. Das ganze ist auf meiner Entwicklungsbox und ich habe updates vermieden, da das auch meine Änderungen kaputt machen würde. Da muss ich wohl meinen Entwicklungsprozess etwas nachbessern.
Was mir noch nicht ganz klar ist:
Momentan wird im define bei mir noch direkt AssignIoPort aufgerufen. Das müsste dann verzögert stattfinden (InternalTimer) oder? ...oder braucht man das dann gar nicht mehr?
Gruß,
Thorsten
ZitatDas müsste dann verzögert stattfinden (InternalTimer) oder? ...oder braucht man das dann gar nicht mehr?
Nein, braucht man nicht, da dafuer eine Sonderfunktion gibt: falls waehrend der Initialisierung IODev fehlt, dann wird in AssignIoPort bzw. "attr XX IODev" IODevMissing gesetzt, und nach dem Einlesen von fhem.cfg wird fuer alle solche Geraete nochmal die Zuweisung versucht.
Nur falls du mit dem Geraet direkt im DefineFn kommunizieren willst, musst du es verzoegern.
Hi,
ich habe das jetzt mal ausprobiert, aber folgendes Szenario macht Probleme: Es gibt zwei IO-Devices, nennen wir sie mal A und B. Jetzt gibt es ein Device (D), welches IO-Device B benutzt. Dummerweise wird aber A vor D angelegt und B erst danach. Dann ordnet AssignIoPort erst einmal das IO-Device A zu, da das schon vorhanden ist und theoretisch passt. Danach kommt dann "attr D IODev B", wodurch "mein" Kram versucht IO-Device B zu verwenden, aber irgendwie funkt trotzdem noch A dazwischen. Das geht schief.
So ganz verstehe ich noch nicht, warum das nicht klappt, aber vielleicht hat sonst jemand noch eine Idee.
Gruß,
Thorsten
ZitatDanach kommt dann "attr D IODev B", wodurch "mein" Kram versucht IO-Device B zu verwenden, aber irgendwie funkt trotzdem noch A dazwischen. Das geht schief.
Kannst du bitte das genauer beschreiben? Vlt mit eine "verbose 5" Log?
IODev dient eigentlich nur zum Schreiben, beim Lesen wird es nicht beruecksichtigt.
Zitat von: rudolfkoenig am 04 April 2017, 07:32:34Kannst du bitte das genauer beschreiben? Vlt mit eine "verbose 5" Log?
Ich werde mir das selbst nochmal genauer ansehen müssen. Ich dachte nur, dass vor mir auch schon jemand ähnliche Effekte hatte. Es kann aber gut sein, dass das alles sehr spezifisch für HM-Wired ist.
Ich werde dann von meinen Ergebnissen berichten.
Gruß,
Thorsten
Könnte man nicht einfach alle Zeilen die in der cfg einen Fehler beim einlesen verursachen zwischenspeichern und dann erneut einlesen nachdem die cfg das erste mal vollständig eingelesen wurde?
Zitat von: igami am 04 April 2017, 09:46:56
Könnte man nicht einfach alle Zeilen die in der cfg einen Fehler beim einlesen verursachen zwischenspeichern und dann erneut einlesen nachdem die cfg das erste mal vollständig eingelesen wurde?
Es wird ja formal kein Fehler verursacht. Woher soll FHEM den wissen, dass da in meinem Modul was falsch läuft?
Nein, meiner Meinung nach ist die einzig vernünftige Lösung die, dass die Reihenfolge der Device-Definitionen keine Rolle spielen darf.
Gruß,
Thorsten
Zitatdie Reihenfolge der Device-Definitionen keine Rolle spielen darf.
_Wenn_ ein logisches Geraet beim Definieren aus der fhem.cfg ueber das zugeordnete IODev kommunizieren will,
_dann_ muss diese Kommunikation per notify oder InternalTimer auf spaeter (nach Beenden der Initialisierung) verschoben werden.
Mir ist noch nicht klar, warum so eine Kommunikation notwendig ist, ich wuerde versuchen sowas zu vermeiden.
Schliesslich wird das bei jedem fhem Neustart oder rereadcfg ausgefuehrt.
Zitat von: rudolfkoenig am 04 April 2017, 11:56:02
_Wenn_ ein logisches Geraet beim Definieren aus der fhem.cfg ueber das zugeordnete IODev kommunizieren will,
_dann_ muss diese Kommunikation per notify oder InternalTimer auf spaeter (nach Beenden der Initialisierung) verschoben werden.
Das ist klar.
Zitat
Mir ist noch nicht klar, warum so eine Kommunikation notwendig ist, ich wuerde versuchen sowas zu vermeiden.
Vielleicht nicht 100% notwendig, aber es passiert halt momentan so in meinem Modul, zumindest wenn nach dem AssignIoPort ein Device zugeordnet ist. Blöderweise kann das halt erst einmal ein falsches IODevice sein.
Notwendig ist eine Kommunikation mehr oder weniger direkt nach dem define, da bei HM-Wired der Gerätetyp und die Einstellungen aus dem Gerät gelesen werden. Das ist zumindest beim ersten define notwendig, später wenn es aus der fhem.cfg geht könnte man das umgehen.
Um das ganze aber sinnvoll umzubauen würde ich aber zuerst komplett verstehen, was da momentan (nicht) funktioniert. Ich denke aber, dass ich das selbst rausfinden werde.
Zitat
Schliesslich wird das bei jedem fhem Neustart oder rereadcfg ausgefuehrt.
Das ist ja nicht so schlimm. Mein Haupt-FHEM hatte die letzten 239 Tage keinen Neustart oder rereadcfg. Selbst wenn man jeden Tag einen Neustart machen würde, wäre das Einlesen der Gerätekonfiguration kein Problem.
Gruß,
Thorsten
ZitatSelbst wenn man jeden Tag einen Neustart machen würde, wäre das Einlesen der Gerätekonfiguration kein Problem.
Das mag sein, aber es gibt Leute, die in FHEMWEB, Edit-Files die notifiy, at, usw. aendern und debuggen, und deswegen staendig ein rereadcfg ausfuehren. It es auch kein Problem, wenn rereadcfg alle 10 Sekunden kommt?
Zitat von: rudolfkoenig am 04 April 2017, 14:10:48It es auch kein Problem, wenn rereadcfg alle 10 Sekunden kommt?
Nein, das ware wahrscheinlich kein Problem. Dann wird das Lesen der Konfiguration vorzeitig abgebrochen und neu gestartet. Außerdem kann man es auch komplett abschalten.
Gruß,
Thorsten
So, jetzt habe ich das ganze nochmal betrachtet.
Die Probleme kamen vor Allem daher, weil ich Depp für die beiden IODevices denselben USB-Port verwendet habe. Das ging dann natürlich ein bisschen durcheinander.
Also tatsächlich gab es kein Problem, wenn AssignIoPort aufgerufen wird bevor das IODev-Attribut gesetzt wird. Allerdings hat AssignIoPort zuerst das falsche IO-Device zugeordnet. Wenn das Attribut nicht gesetzt ist, dann sucht es halt irgendeins. Kurz danach wird dann zwar das richtige über das Attribut gesetzt, aber trotzdem gefällt mir das nicht. Ich habe deshalb jetzt doch AssignIoPort verzögert.
Eine Ausnahme ist, wenn das IO-Device direkt im define steht, da es dann sofort an AssignIoPort übergeben wird und es dann auch richtig behandelt wird.
Gruß,
Thorsten