[gelöst] global:INITIALIZED zu früh seit Update heute?

[DeeSPe]

Genau. Stand schon seit 2 Jahren auf der Todo... 
Jetzt hatte ich mal einen Grund das anzupacken (allerdings hab ich von einer Grundsatzdiskussion nichts mitbekommen...).

Na gut dass das jetzt zur Sprache kommt.

Wir hatten hier doch in den letzten Wochen die Grundsatzdiskussion, dass bestimmte Module erst nach bestimmten Kriterien starten dürfen, um von ihrer Reihenfolge innerhalb der Konfigurationsdaten unabhängig zu werden.

Genau deshalb dachte ich man wäre "safe" bei INITIALIZED!
Bisher tut das Ändern der NTFY_ORDER ihren Dienst. Es sind aber leider erstmal längerfristige Tests nötig.

Ich setzte das Thema mal auf gelöst, damit Rudi wieder "in Ruhe schlafen" kann.
Danke mal wieder für Deine Unterstützung Rudi!

wenn mehrere module die voneinander abhängig sind auf global:INITIALIZED warten haben wir ein problem da die reihenfolge dieser module untereinander nicht definiert bzw. alphabetisch ist.

im prinzip kann man seine eigene notify order ändern, das funktioniert aber nur wenn es zwischen diesen modulen regeln gibt und nicht jeder für sich versucht möglichst weit hinten zu sein.

vielleicht wäre es besser wenn es eine art modul spezifisches initialized event gäbe um diese abhängigkeit zu entkoppeln.

Bleibt nur die Frage offen wie man das "Problem" längerfristig angehen könnte...

Danke an alle.

Gruß
Dan

P.S. Wenn es der allgemeinen Problematik hilft darf hier natürlich gern weiter darüber diskutiert werden.

EDIT: P.P.S. Hier sieht man mal wieder wie wertvoll eine aktive Entwickler Community ist.

[Thorsten Pferdekaemper]

@Thorsten Pferdekaemper: das geht nicht. weil es auf eine definierte reihenfolge ankommt funktioniert eine einfache verzögerung nicht da damit die reihenfolge zufällig (bzw. alphabetisch vom modul namen) abhängt.

Ja, ist klar... Ich hab's mir jetzt nochmal genauer angeschaut und es lief ja sowieso schon in einem notify. Da ist natürlich die InternalTimer-Lösung Schwachsinn. (Ich beleidige damit nur mich selbst, bevor jetzt die Popcorn-Party losgeht.)
Da wäre dann tatsächlich ein Modul-spezifisches Event notwendig. Da aber FHEM selbst (also fhem.pl) nicht wissen kann, inwiefern welches Modul welche Verzögerungs-Technik verwendet, kann das wirklich nur jedes Modul selbst machen. Ich kann mir da nichts generisches vorstellen. Höchstens vielleicht eine Regel, wie das Event aussehen sollte.
Gruß,
   Thorsten

[justme1968]

genau. eine regel wie das event ausschauen sollte.

[rudolfkoenig]

genau. eine regel wie das event ausschauen sollte.

Vorschlag: wenn ein Modul seine Konfiguration per global:INITIALIZED oder InternalTimer beendet, dann muss es ein Event "global:<MODUL> INITIALIZED" oder "global:<DEVICE> INITIALIZED" generieren, dann kann man sich an diese Events haengen. Weiterhin ungeloest: warten bis alle fertig sind.

[betateilchen]

und vor allem, wann ein solcher event erfolgen soll...

• in xxx_Initialize() macht es wenig Sinn, weil das initialize() alleine noch lange nix mit den devices zu tun hat
• in xxx_Define() macht es auch wenig Sinn, weil das Modul ja gar nicht weiß, wieviele Geräte während des Ladens der FHEM-Konfiguration insgesamt angelegt werden müssen. Ein event macht erst dann Sinn, wenn das letzte Gerät definieirt ist.
• und  auch dann wird es schwierig, weil manche Geräte, die per Netzwerk-Discovery gefunden werden müssen, ziemlich lange brauchen.

Es müsste also nach dem globalen $init_done (bzw. global:INITIALIZED) jedes Modul entsprechend prüfen, ob es mit seiner eigenen Initialisierung fertig ist und erst danach seine eigene Fertigmeldung erzeugen.

Ob man das Ganze über ein event steuern sollte - ich bin mir nicht sicher.

Code Auswählen Erweitern


$modules{<modulName>}{initdone}=1


als Fertigmeldung wäre vielleicht eine Alternative, die irgendwie ausgewertet werden könnte (und müsste).

[Loredo]

Genau deshalb dachte ich man wäre "safe" bei INITIALIZED!

Jetzt, wo es "alle" anfangen zu nutzen, eben dann nicht mehr so pauschal, wenn man sich darauf verlässt, dass ein bestimmtes Modul fertig initialisiert ist.
Ich werde mal noch einen DoTrigger() in die Module selbst einbauen, so dass diese selbst nach Erledigung das globale Event nochmals mit dem Zusatz des Devicenamens rausschicken. Dann kann man auch explizit darauf triggern, unabhängig von NotifyOrderPrefix.

Code Auswählen Erweitern


$modules{<modulName>}{initdone}=1


Im %modules Hash ist es nicht richtig aufgehoben, da gibt es auch schon LOADED. Da du aber auf Device-Ebene benachrichtigt werden willst, gehört es ins Device Hash.
Ich werde $hash->{.READY}=1 setzen.

[justme1968]

@rudi: ja. das finde ich gut.

braucht man ein 'alle fertig' ?

je nach definition gibt es das vielleicht sogar garnicht. es können ja auch zur laufzeit beliebig devices dazu kommen.

so lange man richtig auf die events reagiert wäre das ja auch kein problem.

@betateilchen: das wann ist einfach. wenn das modul meint es ist fertig. ob das nach dem start aus NotifyFn kommt oder zur laufzeit aus DefFn oder irgendwann später wenn ein neues device dazu kommt hängt vom modul ab.


ich glaube der knackpunkt ist: das event ist eigentlich kein INITIALIZED sondern ein CONFIG_CHANGED. d.h. es wird nicht nur beim start ein mal erzeugt sondern immer dann wenn sich intern etwas geändert hat und abhängige module benachrichtig werden. also z.b. auch zur laufzeit wenn RESIDENTS zur laufzeit ein neues ROOMATE device inkludiert.

ob ein device überhaupt so ein event erzeugt hängt auch davon ab ob es überhaupt ein abhängiges device gibt. wenn also jemand kommt und sagt 'es wäre schön wenn device xy so ein event erzeugt damit ich mich dran hängen kann'.

[betateilchen]

Im %modules Hash ist es nicht richtig aufgehoben, da gibt es auch schon LOADED. Da du aber auf Device-Ebene benachrichtigt werden willst, gehört es ins Device Hash.
Ich werde $hash->{.READY}=1 setzen.

Und woher weiß ein "abhängiges" Modul dann, dass alle devices vom TYPE=<module> angelegt sind?

[Loredo]

Und woher weiß ein "abhängiges" Modul dann, dass alle devices vom TYPE=<module> angelegt sind?

Gegenfrage: Woher soll das mein Modul wissen?

[DeeSPe]

ich glaube der knackpunkt ist: das event ist eigentlich kein INITIALIZED sondern ein CONFIG_CHANGED. d.h. es wird nicht nur beim start ein mal erzeugt sondern immer dann wenn sich intern etwas geändert hat und abhängige module benachrichtig werden. also z.b. auch zur laufzeit wenn RESIDENTS zur laufzeit ein neues ROOMATE device inkludiert.

ob ein device überhaupt so ein event erzeugt hängt auch davon ab ob es überhaupt ein abhängiges device gibt. wenn also jemand kommt und sagt 'es wäre schön wenn device xy so ein event erzeugt damit ich mich dran hängen kann'.

Genau das ist der Punkt warum es in meinem Modul "set <name> updateInternalsForce" gibt. Wenn sich ein überwachter TYPE erweitert/verringert dann muss eben genau das ausgeführt werden damit die Device aktualisiert werden ohne Neustart.

Ich fand auch keinen Weg das zu automatisieren, ausser einer zeitgesteuerten Funktion.

Gruß
Dan

[Loredo]

Ich habe für RESIDENTS+ROOMMATE+GUEST jetzt eingecheckt:


1. Event "INITIALIZED devicename", nachdem das Device sich intern fertig initialisiert hat
2. Event "MODIFIED devicename", nachdem das Device eine interne Änderung durchgeführt hat


$hash->{'.READY'} wird intern verwendet und steht während des Initialisierens solange auf 0, bis diese erstmalig abgeschlossen wurde.

[Loredo]

Ich fand auch keinen Weg das zu automatisieren, ausser einer zeitgesteuerten Funktion.

Da wäre eine Kooperation ja sinnvoll gewesen. Kann es mir nicht verkneifen nochmals darauf hinzuweisen, dass du auf meine Bitte sich abzustimmen damals nicht reagiert hast. 

[DeeSPe]

Da wäre eine Kooperation ja sinnvoll gewesen. Kann es mir nicht verkneifen nochmals darauf hinzuweisen, dass du auf meine Bitte sich abzustimmen damals nicht reagiert hast. 

Ach schön, hatte nur auf Deinen erneuten Hinweis gewartet. Danke dass Du meine Erwartung erfüllt hast!
Das hat ja nun aber wirklich nichts speziell mit Deinem Modul zu tun. HOMEMODE überwacht noch andere Devices bei denen es mir so ähnlich gehen könnte, ROOMMATE RESIDENTS ist nun aber mal das initial nötige Device. Wenn ich z.B. einen Zwischenstecker gleichen Specs dazu nehme, gibt es bisher auch keine Möglichkeit zur Laufzeit automatisch darauf zu reagieren.

Ich schaue mir mal an was Du da gemacht hast Julian.
Vielleicht klappt es ja doch noch mit einer Abstimmung.

Gruß
Dan

[betateilchen]

1. Event "INITIALIZED devicename", nachdem das Device sich intern fertig initialisiert hat
2. Event "MODIFIED devicename", nachdem das Device eine interne Änderung durchgeführt hat

mit oder ohne Modulbezug im event? (ich gebe zu, aus Bequemlichkeit habe ich jetzt nicht in die Moduldatei geschaut)

Da Deine drei Module nicht die einzigen in FHEM sind, sollte man irgendwie unterscheiden können, woher ein event kommt.

Deshalb fände ich

Code Auswählen Erweitern

RESIDENTS:INITIALIZED <deviceName>

sinnvoller als nur

Code Auswählen Erweitern

INITIALIZED <deviceName>

[Loredo]

mit oder ohne Modulbezug im event? (ich gebe zu, aus Bequemlichkeit habe ich jetzt nicht in die Moduldatei geschaut)

Ohne, denn es geht rein um die einzelne Device-Instanz selbst. Warum brauche ich da den Modulnamen davor?
Wir reden hier ja ohnehin davon, dass per NOTIFYDEV eingeschränkt wird, welche Events ich erhalte, oder nicht?

------

Mit einem weiteren Patch habe ich jetzt ein weiteres Event eingebaut, welches tatsächlich dann triggert, wenn alle Devices des Moduls fertig initialisiert wurden:

Code Auswählen Erweitern


<TYPE> INITIALIZED


Das entspricht Rudis Vorschlag dafür.
Dieses Event löst schließlich nochmals je Device das zuvor eingebaute Event aus in dem Format:

Code Auswählen Erweitern


INITIALIZED <device>


Diese Events werden nach einem rereadcfg entsprechend wiederholt.

Wenn ein einzelnes Device zur Laufzeit geändert wird, erzeugt es das Event CONFIG_CHANGED:

Code Auswählen Erweitern


CONFIG_CHANGED <device>


Ich hatte zunächst gedacht, dass man hier auch "MODIFIED <device>" schicken könnte, wollte es aber dann während der Laufzeit doch unterscheidbar haben.