[GELÖST] unknown IODev specified - Reihenfolgeproblem?

[KernSani]

Hallo zusammen,

beim Neustart von FHEM (shutdown restart/Raspberry PI reboot etc...) bekomme ich die Meldungen der Art

Code Auswählen Erweitern

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

[CoolTux]

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.

[Thorsten Pferdekaemper]

...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

[CoolTux]

Das ist ja das witzige. KernSani ist selber der Author.


Grüße

[Thorsten Pferdekaemper]

Das ist ja das witzige. KernSani ist selber der Author.

Warum steht in der maintainer-Datei dann mattwire?

[CoolTux]

Warum steht in der maintainer-Datei dann mattwire?

Beim IODev openMili handelt es sich um eine von mir modifizierte version von 30_MilightBridge

[KernSani]

Hier findest Du alles Wissenswerte dazu und den aktuellen Stand zum Thema.

Thanks CoolTux... Interessanter Thread Ich schau heute abend mal ob

der 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

[Thorsten Pferdekaemper]

Beim IODev openMili handelt es sich um eine von mir modifizierte version von 30_MilightBridge

Naja, das macht ihn ja noch nicht zum Modulautor. 

[CoolTux]

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.

[Thorsten Pferdekaemper]

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

[betateilchen]

*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.

[KernSani]

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   

[betateilchen]

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.