Hallo zusammen,
beim Neustart von FHEM (shutdown restart/Raspberry PI reboot etc...) bekomme ich die Meldungen der Art
EG_Licht: unknown IODev openMili specified
Das IODev Attribut verschwindet dann tatsächlich, nach ändern der DEF (ohne was zu ändern) ist es wieder da und funktioniert problemlos.
Grundsätzlich würde ich annehmen, dass es sich um ein Reihenfolgeproblem handelt, das ich in der fhem.cfg einfach beheben könnte - wie mache ich so etwas in der configDB?
Generelle Frage: Beim IODev openMili handelt es sich um eine von mir modifizierte version von 30_MilightBridge - Gibt es irgendeinen Trick dem Modul beizubringen, welche Devices von ihm abhängig sind (das "Clients" internal wird korrekt gesetzt).
Danke,
Oli
Bitte schön
https://forum.fhem.de/index.php/topic,62653.0.html
Hier findest Du alles Wissenswerte dazu und den aktuellen Stand zum Thema.
...oder kurz: Der Maintainer des betroffenen Moduls sollte das beheben. D.h. diesen Thread in den passenden Forenbereich verschieben und den Maintainer darauf aufmerksam machen.
Gruß,
Thorsten
Das ist ja das witzige. KernSani ist selber der Author.
Grüße
Zitat von: CoolTux am 06 März 2017, 17:16:47
Das ist ja das witzige. KernSani ist selber der Author.
Warum steht in der maintainer-Datei dann mattwire?
Zitat von: Thorsten Pferdekaemper am 06 März 2017, 17:21:24
Warum steht in der maintainer-Datei dann mattwire?
Zitat von: KernSani am 06 März 2017, 17:01:24
Beim IODev openMili handelt es sich um eine von mir modifizierte version von 30_MilightBridge
ZitatHier findest Du alles Wissenswerte dazu und den aktuellen Stand zum Thema.
Thanks CoolTux... Interessanter Thread ;-) Ich schau heute abend mal ob
Zitatder Benutzer soll nach Austausch des IODevs die IODev Attribute anpassen, z.Bsp. mit "attr IODev=CUL_alt IODev CUL_neu"
hilft... Eigentlich habe ich das ja schon gemacht... (könnte aber sein, dass ich das IODev danach nochmal gelöscht und defined habe)
Grüße,
Oli
Zitat
Beim IODev openMili handelt es sich um eine von mir modifizierte version von 30_MilightBridge
Naja, das macht ihn ja noch nicht zum Modulautor.
Zitat von: Thorsten Pferdekaemper am 06 März 2017, 18:07:08
Naja, das macht ihn ja noch nicht zum Modulautor.
Kann sein. Aber als Autor von MilightBridge würde ich da abwinken. Weißt ja nicht wie groß die Modifikation ist.
Zitat von: CoolTux am 06 März 2017, 18:18:54
Kann sein. Aber als Autor von MilightBridge würde ich da abwinken. Weißt ja nicht wie groß die Modifikation ist.
Wir können ja wetten: Wetten dass das Problem auch in der originalen Version auftritt? (Ich habe nicht nachgeschaut.)
...wobei soweit ich weiß das Milight-Modul eh obsolet ist und nur noch WifiLight weiterentwickelt wird.
Gruß,
Thorsten
*gähn*
Solche Thread-Titel nerven mich maßlos. Denn auch diesmal ist die configDB einmal mehr nicht die Ursache eines Problems. Aber es ist ja so einfach, den "Schwarzen Peter" einfach weiterzugeben...
Spaß macht das nicht.
Und eine Anfängerfrage ist das übrigens auch nicht.
Vielen Dank für die Hilfe - Das Reihenfolge-Problem ließ sich mit attr lösen :-) Jetzt habe ich offensichtlich noch ein Problem, dass bereits während der Initialisierung geschrieben wird, aber das sollte ich dank o.g. link auch in den Griff bekommen.
@Thorsten: In diesem Fall würde ich eher mich selbst als Modulautor sehen ;-) Und so wie ich den von Cooltux verlinkten Thread verstehe hat der original-Autor da auch nix falsch gemacht.
@betateilchen: Die configDB ist nicht Ursache des Problems, da stimme ich zu. Für die Lösungssuche war es aber durchaus relevant, da ich in der fhem.cfg manuell die Reihenfolge ändern kann, mir dies in der configDB aber nicht bekannt ist (daher auch Anfängerfrage)
Grüße,
Oli
Zitat von: KernSani am 06 März 2017, 20:07:45
da ich in der fhem.cfg manuell die Reihenfolge ändern kann, mir dies in der configDB aber nicht bekannt ist (daher auch Anfängerfrage)
nochmal: DAS ist keine Anfängerfrage.