Stoffsammlung: FHEM-Start - normaler Ablauf, Tricks und Tipps, Expertenmodi usw.

[Beta-User]

Hallo zusammen,

jüngst hat martinp876 im Zusammenhang mit der Initialisierung von CUL_HM einen ziermlich interessanten Beitrag gepostet:

Die Inits und Zuordnung der IOs  - besser das IO mit der Adresse des Device zu provisionieren - startet bei mir definitiv nach dem initDone.
Das InitDone kommt, wenn der Kernal das "fhem.save" ausgeführt hat. Danach passiert system-bedingt m.W. nichts mehr.
CUL_HM startet dann nach einem Timer den UpdateConfig bei welchem - wie gesagt - die Attribute und Readings kontrolliert werden. Also alles, was mir eingefallen ist. Hier werden bspw auch Systematische Updates realisiert (wie bspw die Umstellung der ModelId welche es u.a. erlaubt, die Model-ID zu überschreiben)
Und erst hierbei wird (habe ich gerade getestet) das IO initialisiert.
Erst danach ist CUL_HM wirklich funktional.

Parallel starte ich mein UserConfigUpdate in welchem ich alles setze, was ICH in MEINER Installation konsequent sehen will. Dabei ist mir egal, ob das Attribut schon gesetzt ist, ich setze es noch einmal.  Funktionert dann, wenn man sich eine Systematik vorstellen kann.
somit erstelle ich ein c_User.cfg (alle meine Setup-Files sind im setup directory)

Code Auswählen Erweitern

define userCfg notify global:INITIALIZED include setup/c_User.cfg

Im File steht dann bspw

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert                  12_templOnly
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual autoReadReg             5_readMissing
attr TYPE=CUL_HM                                           event-on-change-reading .*
deleteattr TYPE=CUL_HM:FILTER=DEF=........    expert
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert
deleteattr TYPE=CUL_HM:FILTER=DEF=........    autoReadReg
deleteattr TYPE=CUL_HM:FILTER=subType=virtual autoReadReg


aber auch

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=model=HM-TC-IT-WM-W-EU       group   heatDevice
attr TYPE=CUL_HM:FILTER=DEF=......01:FILTER=model=HM-TC-IT-WM-W-EU     group   temperatur
attr TYPE=CUL_HM:FILTER=DEF=......02:FILTER=model=HM-TC-IT-WM-W-EU     group   heatCtrl
attr TYPE=CUL_HM:FILTER=DEF=......0[37]:FILTER=model=HM-TC-IT-WM-W-EU  group   heatSupport


sowie logsettings

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=......                                 DbLogInclude powerOn,Activity,battery.*,motor.*,level
attr TYPE=CUL_HM:FILTER=DEF=........                               DbLogInclude motor,tempSum,temperature,level


Musste ich einmal loswerden. M.E. eine coole Methode, attribute Methodisch zu setzen und auch neue Devices in die Systematic einzubinden.

In dem Thread spielen noch ein paar andere Aspekte eine Rolle, u.a. wird da das (heute meist nicht mehr existente) "Reihenfolgethema" etwas näher beleuchtet.
Die von martinp876 hier auszugsweise geteilte "Nachkonfiguration" hat allerdings m.E. mindestens den "Nachteil", dass ggf. "rote Fragezeichen" generiert werden, ohne dass wirklich eine Änderung erfolgt ist (was ich persönlich eben als Nachteil solchen empfinde), außerdem ist das mit "include" etwas aus der Mode gekommen, insbesondere, wenn man - wie ich - configDB nutzt.

Die automatisierte "Nachkonfiguration" von neuen Devices sehe ich tendenziell auch eher auf der Ebene eines "defined|modified"-Events.

Kurz: Es gibt da vermutlich nicht "die Lösung" für alle Aspekte, aber wenn eben jemand spezielle Nachinitialisierungsroutinen benötigt, kann dies eine interessante Methode sein.

Daher an dieser hierfür ggf. etwas besser geeigneten Stelle nochmal meine Fragen dazu:

Eine OT-Frage zu dem Ding mit der nachgelagerten setup/c_User.cfg:

Mein bisheriges Bestreben war es eher, Änderungen der cfg im laufenden Betrieb zu vermeiden und v.a. auch auf "auto-save"-Anweisungen zu verzichten, von daher hätte ich das eher als "attrTemplate"-Satz für den Fall der Neudefinition bzw. Änderung eines (Satzes von) Devices angesehen oder wenigstens FILTER verwendet, um das nur dort zu setzen, wo es nicht sowieso schon der Fall ist (kann sein, dass Rudi das zwischenzeitlich im Hintergrund sowieso abfängt).

Wie handhabt ihr denn das?
Ich für mich finde das Prinzip einer statischen cfg übersichtlicher und mag auch diese "disable-by-Attribut"-Geschichten usw., die zu Änderungen der cfg führen nicht besonders. Aber evtl. habt ihr da andere Erfahrungen usw.?
Wäre ggf. interessant, das mal etwas zusammenzutragen, kann dann aber auch gerne ein gesonderter Thread werden...

Mittelfristig könnte man das ja irgendwie zusammentragen und thematisch mit den Artikeln "https://wiki.fhem.de/wiki/Konfiguration" und "https://wiki.fhem.de/wiki/Fhem.pl" verzahnen... (darf gerne auch jemand anderes übernehmen ).