[geklärt] Verzögerung durch ActionDetector o.a. beim FHEM-Start?

[Pfriemler]

Hmlan wird nicht von culhm verwaltet, nur genutzt.

Stimmt, mein Fehler. HMLAN hat ein eigenes Modul 00_HMLAN.pm

Eine nicht vorhandene cul hatte auf das timeout des ethernet für einige sekunden aktiv gewartet. Lege mich nicht auf die genauen zeiten fest.
Es ist also, insbesondere bei nicht antworten, gerne ein timeout problem der Treiber.

Dass es eine temporäre Blockade gibt, wenn das Gerät initialisiert werden soll, aber nicht antwortet, ist ja ok.
Idiotisch ist, wenn ein als dummy attributiertes Gerät trotzdem zu erreichen versucht wird.

Hmlan sollte auch erst nach initdone starten, wäre sinnvoll.

Kein Widerspruch.

Zu den hmios: culhm meldet die Adressen der devices beim gewählten io an. Das ist bei einigen typen extrem wichtig.
Beim ersten init wird (unsichtbar) die gesamte config des device kontrolliert. Das natürlich nur einmal nach restart.

Sicher? Du sprachst davon, dass Du solche Dinge nach dem initdone getimt hast. Ist denn initdone nicht gleichbedeutend mit der Melder "Server started ..."? Die ersten HMUARTLGW-inits laufen doch aber davor und scheinen besonders zeitfressend zu sein, jetzt ist es immerhin deutlich besser.

Das abfabgen des 2. Durchlauf kann ich bei Gelegenheit suchen. Lohnt sich aber kaum.

Nein, der zweite Durchlauf stört ja nicht bei <1s.

Das zuweisen des io geht schnell. Es kommt auch im betrieb vor, einzeln, wenn das io für ein device geändert werden muss.

Habe ich schon öfter gesehen als "added peer"-Meldungen beim Sniffen. Schien mir aber was anderes als diese HMUARTLGW-inits zu sein...

und zuletzt:

Mir scheint, dass alle deine Devices bei einem io angemeldet werden.

Nein, das scheint nur so. Tatsächlich werden zwar >90% beim HMUART angemeldet, aber eben auch einige an meinem HMWLAN1. Deren Meldungen sind der Kürzung im Zitat zum Opfer gefallen.

[martinp876]

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.

[Pfriemler]

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.

ah ... mein Fehler. "Server started with" kommt demnach deutlich später. Die Provisionierung, wie Du es nennst, kommt bei mir natürlich auch erst nach fhem.save.

CUL_HM startet dann nach einem Timer den UpdateConfig .... Umstellung der ModelId ... erst hierbei wird (habe ich gerade getestet) das IO initialisiert.

Was für mich immer noch nicht die Frage klärt, warum die Provisionierung zweimal erfolgt, einmal vor und einmal nach der Initialisierung des IO. In meinem beschränkten Systemverständnis ergibt es absolut keinen Sinn, ein Gerät mit Daten zu versorgen, welches noch gar nicht initialisiert wurde. Ob das Zeit frisst oder nicht, sei einmal dahingestellt. Wenn es so ist, dass die 10 inits, die mein System hier vor der IO-Initialisierung schafft, gar nicht durch die Inits selbst verzögert sind, sondern nur nebenbei anfallen, während andere, wesentlich intensivere Prozesse im Hintergrund laufen (Dein UpdateConfig?), dann könnte man ja damit leben. Vielleicht ist es ja auch so, dass nicht das IO, sondern das steuernde Modul HMUARTLGW mit Daten versorgt wird.
Ich kann mir jedenfalls keinen Reim drauf machen. Im Log sieht man zwei Init-Kaskaden, von denen die vor dem IO-Init eben deutlich sichtbar langsamer abläuft.

Parallel starte ich mein UserConfigUpdate in welchem ich alles setze, was ICH in MEINER Installation konsequent sehen will.

In der Tat eine coole Sache, aber das würde mir vieles Feintuning zerschroten, z.B. in Bezug auf Eventauslösungen bei Änderung oder Update von Readings. Da ist bei mir schon lange nicht mehr überall event-on-change-reading .* angesagt.

Aber für ein Testsystem würde ich es definitiv immer so machen.

[Beta-User]

Hallo zusammen,

neben vielem Altbekannten sind hier auch ein paar sehr aufschlussreiche Infos drin, die mMn. irgendwie noch zu einer strukturierten Einführung in CUL_HM gehören sollten.

Da ich eh' grade dabei bin (ja, langsamer wie gedacht, aber noch dabei...), die Einsteigerdoku/"das pdf" zu überarbeiten:
Würde es nicht Sinn machen, ein paar Praxistipps, das (von vielen ignorierte) Thema VCCU usw. in den "Anhang" einzuarbeiten und diesen dann separat hier anzupinnen und/oder im Wiki zu verlinken?



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

[martinp876]

Ein separater thread könnte schon sinn machen.
Es gibt kein "richtiges" Vorgehen,  klar. 
Für mich unterscheide ich operationale Attribute, Gruppierungen  und debug. Ok, log auch noch.
Wenn ich an der Kiste arbeite ändere ich häufig etwas. Exeter, debug Level, Tests zum nachstellen von Problemen,.....
Einige Fixpunkte will ich immer haben. Wenn ich ein neues device einrichten werden nach reboot Gruppen und Räume zugewiesen, webcmd, loggings für die Datenbank.
Das file löst auch Kommandos aus welche ich zu startup machen will. So wird das zeilendisplay initialisiert.  Man könnte einen conficcheck machen,....
Aus meiner Sicht sollte das (so ein) file beschrieben  werden und standardmäßig angelegt sein. Der User kann es leer lassen. Ich hatte etwas gebraucht, die Methode zu finden als ich anfänglich ein eigenes kommando aus myutils starten wollte.
Was in jedem Fall angenehm ist: ich kann mich auf das korrekte vorhanden sein einiger Attribute verlassen.

[Beta-User]

Ein separater thread könnte schon sinn machen.

...habe mal hier angefangen: https://forum.fhem.de/index.php/topic,112539.msg1068736.html#msg1068736