DOIF global:"INITIALIZED" mag nicht mit KNX spielen?

[jw9]

Hallo,

Ich habe Definitionen in dieser Art:

Code Auswählen Erweitern

defmod Gartenlicht_Baeume KNX 1/1/120:dpt1.001:EinAus 1/4/120:dpt1.011:status:get
attr Gartenlicht_Baeume IODev KNXIF
attr Gartenlicht_Baeume alias Gartenlicht_Baeume
attr Gartenlicht_Baeume cmdIcon on:rc_GREEN off:rc_RED STS:rc_INFO@yellow
attr Gartenlicht_Baeume devStateIcon active:FS20.on:off inactive:FS20.off:on switching.*:hourglass:off
attr Gartenlicht_Baeume group Timer
attr Gartenlicht_Baeume room Timer
attr Gartenlicht_Baeume sortby 0
attr Gartenlicht_Baeume stateRegex /EinAus-set/switching-/ /EinAus-get//
attr Gartenlicht_Baeume webCmd on:off

setstate Gartenlicht_Baeume 2023-05-21 00:14:26 IODev KNXIF

und würde gerne beim Start von fhem den aktuellen Status vom Bus lesen um diese korrekt angezeigt zu bekommen:

Code Auswählen Erweitern

defmod di.Autostart DOIF ([global:"INITIALIZED"]) ( get Gartenlicht_Baeume status )
attr di.Autostart initialize init
attr di.Autostart room System

setstate di.Autostart cmd_2
setstate di.Autostart 2023-05-21 00:37:33 Device global
setstate di.Autostart 2023-05-21 00:14:23 cmd 2
setstate di.Autostart 2023-05-21 00:14:23 cmd_event global
setstate di.Autostart 2023-05-21 00:14:23 cmd_nr 2
setstate di.Autostart 2023-05-21 00:37:33 e_global_events UNDEFINED KNX_0503031 KNX 5/3/31:MODEL_NOT_DEFINED
setstate di.Autostart 2023-05-21 00:14:23 state cmd_2

Das gibt mir aber im Log folgende Fehlermeldung:

Code Auswählen Erweitern

2023.05.21 00:14:21 2: di.Autostart:  get Gartenlicht_Baeume status: KNX_Get (Gartenlicht_Baeume): invalid gadName: status

Gebe ich diesen Befehl von Hand in die Fhem-Kommandozeile ein, funktioniert es einwandfrei und es wird der aktuelle Zustand angezeigt.

Was stimmt hier nicht?

[erwin]

Hi jw9!

Was stimmt hier nicht?

In der cmd-ref zu KNX:

Code Auswählen Erweitern

When using KNX_scan or any 'set or get <device> ...' in a global:INITIALIZED notify, pls. ensure to have some delay in processing the cmd's by using fhem sleep.
Example:
defmod initialized_nf notify global:INITIALIZED sleep 10 quiet;; set KNX_date now;; set KNX_time now;; KNX_scan;;
This avoids sending requests while the KNX-Gateway has not finished its initial handshake-procedure with FHEM (the KNX-IO-device). Das Problem ist, dass bei global:initialized noch nicht alle definitionen verarbeitet sind, bzw. das GW noch nicht ready ist.
...In der nächsten Version vom KNXIO-Modul wird es einen zusätzlichen event geben:

Code Auswählen Erweitern

<KNXIO-Device>:INITIALIZED, dieser wird 30 sekunden nach global:INITALIZED UND das IO-Modul connected ist ausgelöst.
Damit braucht man kein sleep mehr! kommt demnächst 
l.g. erwin

[jw9]

Das Problem ist, dass bei global:initialized noch nicht alle definitionen verarbeitet sind, bzw. das GW noch nicht ready ist.

Hmmm, ja. Ist einsichtig. "initialized" ist ein dehnbarer Begriff.

dieser wird 30 sekunden nach global:INITALIZED UND das IO-Modul connected ist ausgelöst.

Wobei das dann aber keine feste Verzögerung sein sollte, sondern den tatsächlichen Ereignissen am IO-Modul folgen sollte. Zum Einen ist die Zeit ja nicht fix. Zum Anderen kann ja auch ohne fhem-neustart die KNX-Verbindung unterbrochen gewesen sein. Dann ist ja ebenfalls ein Zustandsabgleich erforderlich, sobald die Schnittstelle wieder hochgefahren ist.

Noch besser wäre es wenn bereits vom KNX-Modul intern ein Zustandsabgleich (KNX_scan?) immer dann erfolgt, sobald die Schnittstelle bereit ist. (also auch nach einer Schnittstellenstörung).
Gibt es Gründe das nicht zu tun? Man will ja eigentlich immer (sofern technisch möglich) einen abgeglichenen Zustand haben.

[jw9]

BTW:

Code Auswählen Erweitern

KNX_scan Function to be called from scripts or FHEM cmdline.
Selects all KNX-definitions (specified by the argument) that support a "get" from the device.
Was ist das Kriterium für KNX_scan an dem es feststellt ob es "support a get from the device"?

Wenn ich KNX_scan ohne Parameter aufrufe (also alle Geräte abfragen möchte) dann bekomme ich:

Code Auswählen Erweitern

2023.05.21 09:15:10 3: KNX_scan: 0 devices selected (regex= TYPE=KNX) / 0 devices with get / 0 "gets" executing...
Manuell abfragen kann ich die Geräte problemlos (dann halt jedes einzeln) und der aktualisierte Zustand wird auch angezeigt.

[erwin]

"global:initialized" ist ein dehnbarer Begriff.

stimmt. Konkret bedeutet das, das alle definitionen,Attribute,states,... vom config- und state-file eingelesen worden sind, aber nicht dass alle internen strukturen der devices/module bereits definiert sind und schon gar nicht, dass das IO-Device ready ("connected") ist.
Diese Problematik betrifft nicht nur KNX, sondern auch etliche andere Module, die zur initialisierung ihre Attributwerte brauchen, und damit erst nach global:initialised ihre definitionen komplettieren.
Die 30 sekunden sind ein worst case wert, wenn 30sekunden nach global:initialized das IO-device nicht ready ist, dann ist das ein anderes Problem! Ohne diesen Timer könnte ich nicht unterscheiden, ob es um einen FHEM-start oder um ein reconnect handelt.
Falls ich nur auf io-device:connected triggern würde, kann es (während FHEM-start) passieren, da das KNX-device noch nicht fertig initialisiert ist!
Es steht dir frei, nach jedem IO-device "connect" event einen Zustandsabgleich mittels notify auszulösen, generell einbauen will ich das nicht, eher würde ich die Ursache für disconnects suchen! Das wird vmtl. unmittelbar nach FHEM start schiefgehen, aber das hast du ja schon verstanden... ein sleep 1;;get .. wäre jedenfalls angebracht.
Re.: KNX_scan - es werden alle KNX-devices (definitionen) selektiert, die kein dptxx:set oder listenonly enthalten. Allerdings: wenn io-dev nicht "connected", wird übersprungen...., wenn MODELERR / disabled... ebenfalls. ob die KNX-Hardware antwortet ist eine andere Frage...
l.g.erwin

[erwin]

ich habe ein notify gebaut,das vmtl. deine Anforderungen erfüllen wird, allerdings erst mit der nächsten version v. KNXIO-Modul:

edit: code und Log gelöscht, da ab der KNXIO-Version v. 16.6.2023 obsolet

l.g.erwin

[jw9]

Die 30 sekunden sind ein worst case wert, wenn 30sekunden nach global:initialized das IO-device nicht ready ist, dann ist das ein anderes Problem! Ohne diesen Timer könnte ich nicht unterscheiden, ob es um einen FHEM-start oder um ein reconnect handelt.

Warum ẃill man das unterscheiden? fhem-start ist in diesem Zusammenhang vollkommen irrelevant.

Genau genommen ist ein Zustandsabgeleich GENAU nach einem connect erforderlich. Dabei ist es vollkommen irrelevant ob es der erste connect nach fhem-Start oder ein reconnect nach einer Unterbrechung/Störung ist. Ein Abgleich nach fhem-Start macht keinen Sinn solange noch kein Connect gekommen ist, denn diese Abfrage würde sowieso nur nach /dev/null gehen!

Das sagt Dir jetzt jemand, der seit 30 Jahren beruflich mit verschiedenen Bussystemen zu tun hat. Zwar nicht mit KNX, aber die Grundprinzipien sind überall gleich.

Falls ich nur auf io-device:connected triggern würde, kann es (während FHEM-start) passieren, da das KNX-device noch nicht fertig initialisiert ist!

Verstehe ich nicht.. Wieso schickt das io-device ein "connect" wenn es doch noch nicht einmal initialisiert ist?!?

Oh, dass fhem-start das flasche Kriterium ist hatte ich ja oben bereits erwähnt.

eher würde ich die Ursache für disconnects suchen!

Ummm...

Gründe für disconnects können vielfältig sein. Manche kann man tatsächlich lokalisieren und gezielt beheben. Generell ausschliessen kann man Störungen aber nicht. Ein stabiles System bekommt man nur dann wenn man Störungen auch sinnvoll behandelt. Dazu gehört auch, die jeweils richtigen Kriterien heranzuziehen.

Das wird vmtl. unmittelbar nach FHEM start schiefgehen, aber das hast du ja schon verstanden... ein sleep 1;;get .. wäre jedenfalls angebracht.

Warum das nach fhem-start schiefgeht habe ich oben dargelegt: fhem-start ist das flasche Kriterium.

BTW: Ein "sleep 1" reicht da nicht. In meinem Fall benötige ich schon ein "sleep 10". Und dann darf sonst nichts schiefgehen (zB Netzwerk-Probleme, oder KNX-Gateway gerade nicht erreichbar).

Warum? Weil fhem-start das falsche Kriterium ist. Das richtige Kriterium ist der (re-)connect. Dann braucht es auch keinen sleep.

Re.: KNX_scan - es werden alle KNX-devices (definitionen) selektiert, die kein dptxx:set oder listenonly enthalten. Allerdings: wenn io-dev nicht "connected", wird übersprungen...., wenn MODELERR / disabled... ebenfalls. ob die KNX-Hardware antwortet ist eine andere Frage...

Hmmm...

Anhand dieser Beschreibung erschliesst sich mir jetzt nicht unmittelbar, warum zB das Gerät aus dem Ausgangsbeitrag nicht selektiert wird. Das io-device _ist_ connected und manuelle sowie (zeitverzögerte) get/set funktionieren. Aber KNX_scan geht weder im notify noch manuell.

[erwin]

Warum ẃill man das unterscheiden? fhem-start ist in diesem Zusammenhang vollkommen irrelevant.

... iat es nicht! ich hatte geschrieben:

Falls ich nur auf io-device:connected triggern würde, kann es (während FHEM-start) passieren, da das KNX-device noch nicht fertig initialisiert ist!

Der feine Unterschied; KNXIO-device ready != KNX-device ready.... und damit ein set/get ... funktioniert muss beides vorhanden sein. Und genau das ist das Kriterium wo ich <KNXIOdevice>:INITIALIZED auslöse.
wobei es durchaus passieren kann, dass die KNX-devices vor dem IO-device mit ihrer initialisieren fertig sind, oder aber auch umgekehrt!
Das kann ich leider nicht beeinflussen, hängt u.a. auch mit der Reihenfolge in cfg-file ab...

re: KNX_scan - Frage: wenn du KNX_scan auf der fhem-cmdline eintippst - wie ist das resultat?
Alternativ

Code Auswählen Erweitern

{KNX_scan()} - Resultat?
und evtl.: KNX_scan ROOM=xxx oder KNX_scan <devicex> ?

PS: Deine Log-Zeile im Ausgangspost zeigt mir, dass dein FHEM nicht am aktuellen Stand ist.

[jw9]

Warum ẃill man das unterscheiden? fhem-start ist in diesem Zusammenhang vollkommen irrelevant.

... iat es nicht! ich hatte geschrieben:

Falls ich nur auf io-device:connected triggern würde, kann es (während FHEM-start) passieren, da das KNX-device noch nicht fertig initialisiert ist!

Der feine Unterschied; KNXIO-device ready != KNX-device ready.... und damit ein set/get ... funktioniert muss beides vorhanden sein. Und genau das ist das Kriterium wo ich <KNXIOdevice>:INITIALIZED auslöse.

Hmmm, ja. In der Tat hatte ich Dich an dieser Stelle falsch verstanden und unter "KNX-device" das "Gateway" im Hinterkopf.

Dennoch ist fhem-start das falsche Kriterium, auch dann wenn es mit einer Verzögerung versehen wird. Das korrekte Kriterium ist iodevice:connected. BTW: ein iodevice:disconnected kann auch getrost alles verwerfen was in irgendwelchen Puffern herumlungert (das nur nebenbei erwähnt).

wobei es durchaus passieren kann, dass die KNX-devices vor dem IO-device mit ihrer initialisieren fertig sind, oder aber auch umgekehrt!

Hmmm... Ich kenne fhem nur oberflächlich und kann an dieser Stelle nur spekulieren. Aber nach meinem Verständnis sollten beim Startup alle in der cfg eingetragenen devices initialisiert sein bevor ein global:INITIALIZED verschickt wird.

Was passiert denn mit einem CONNECTED (oder generell mit einem Event), das während dieser Initialisierungsphase verschickt wird? Wird dieses tatsächlich nur an die devices ausgeliefert, die zu diesem Zeitpunkt (zufälligerweise) schon bereit sind und der Rest geht leer aus?

Wenn das tatsächlich verloren gehen sollte, dann riecht das für mich doch sehr nach "broken by design". Das Event sollte entweder erst entgegen genommen werden wenn die Initialisierungsphase durch ist (der Sender muss dann ggf entsprechend blockiert werden) oder es muss zwischengespeichert und erst dann verschickt werden, wenn alle devices bereits sind.

re: KNX_scan - Frage: wenn du KNX_scan auf der fhem-cmdline eintippst - wie ist das resultat?
Alternativ

Code Auswählen Erweitern

{KNX_scan()} - Resultat?
und evtl.: KNX_scan ROOM=xxx oder KNX_scan <devicex> ?

Immer das gleiche: "0 Devices selected". Mit "manuell" meinte ich oben das Eintippen auf der fhem-cmdline.

PS: Deine Log-Zeile im Ausgangspost zeigt mir, dass dein FHEM nicht am aktuellen Stand ist.

Woran genau siehst Du das? Ich lasse täglich per cron ein Update und danach einen fhem-restart machen. Lediglich das TUL-Modul habe ich vom Update ausgenommen, weil es in der jetzigen Form vollkommen unbrauchbar ist und ich dabei bin es neu zu implementieren.

Leider hinterlässt der Update lediglich eine nichts-aussagende Zeile im Log. Hier 22 Stunden bevor der Log im Ausgangspost entstanden ist:

Code Auswählen Erweitern

2023.05.20 03:00:54 0: Server shutdown
2023.05.20 03:00:54 2: DbLog LogDB - stopping SubProcess PID >15708< ...
2023.05.20 03:00:54 2: DbLog LogDB - SubProcess PID >15708< stopped
2023.05.20 03:00:54 1: RMDIR: ./restoreDir/save/2023-05-17

Und diese Module wurden zuletzt aktualisiert.

Code Auswählen Erweitern

root@vdr2:/opt/fhem# ls --sort=time -la FHEM|head -10
insgesamt 38788
drwxr-xr-x 14 fhem dialout   36864 Mai 22 04:00 ..
-rw-r--r--  1 fhem dialout  160680 Mai 22 03:01 controls_fhem.txt
-rw-r--r--  1 fhem dialout  109736 Mai 22 03:01 50_SSChatBot.pm
-rw-------  1 fhem dialout  107886 Mai 21 03:00 10_KNX.pm
drwxr-xr-x  6 fhem dialout   28672 Mai 21 00:00 .
-rw-r--r--  1 fhem dialout   71615 Mai 19 03:00 98_WeekdayTimer.pm
-rw-r--r--  1 fhem dialout   56213 Mai 19 03:00 75_AutomowerConnectDevice.pm
-rw-r--r--  1 fhem dialout   69480 Mai 19 03:00 74_AutomowerConnect.pm
-rw-r--r--  1 fhem dialout  955155 Mai 18 03:00 93_DbRep.pm

Ich denke nicht, dass man viel aktueller sein kann..

[jw9]

wobei es durchaus passieren kann, dass die KNX-devices vor dem IO-device mit ihrer initialisieren fertig sind, oder aber auch umgekehrt!
Das kann ich leider nicht beeinflussen, hängt u.a. auch mit der Reihenfolge in cfg-file ab...

Hmmm... Also nach einem flüchtigen Blick in den Source von KNXTUL scheint mir das Problem eher in folgender Zeile zu liegen:

Code Auswählen Erweitern

--- FHEM/00_KNXTUL.pm~  2021-01-16 03:00:57.500001289 +0100
+++ FHEM/00_KNXTUL.pm   2023-05-22 12:39:40.410585860 +0200
@@ -148,7 +148,7 @@
                Log (1, "OpenDev: Cannot init KNXTUL-Device, ignoring it");
        }
 
-       DoTrigger($name, "CONNECTED") if($reopen);
+       DoTrigger($name, "CONNECTED");  #if($reopen);
        return $ret;
 }
 

00_KNXTUL.pm erzeugt beim ersten connect gar kein CONNECTED event! Das ist meines Erachtens grottenfalsch. (00_TUL.pm macht das genau so, aber das ist ja sowieso komplett kaputt und unbrauchbar).

[erwin]

Hi,
also grundsätzlich zum fhem start:
global:INITIALIZED bedeutet: alle cfg-files und save-files eingelesen UND das device global fertig initialisiert.
Etliche Module (so auch KNXIO, KNX) brauchen das als Voraussetzung um ihre internen Variablen zu initialisieren und machen das NACH global:INITALIZED. Daher ist z.b. das KNXIO-Modul und KNX_Modul zu diesem Zeitpunkt noch nicht fertig!

EVENTS werden grundsätzlich erst NACH global:INITALIZED durch fhem-core ausgelöst. Was das Modul mit dem event macht? Falls noch nicht fertig initialisiert, wirds einen Fehler geben...
Um den KNX-devices die Chance zu geben, fertig zu initialisieren, ignoriere ich (in dem code sample im vorletzen post) den connected-event während der ersten 30sec nach global:INITALIZED und ersetze ihn verzögert durch den KNXIO:INITIALIZED. Also von der Funktion her ident zum connected event, nur verzögert!

re TUL-Modul: würde empfehlen, wenn möglich auf das KNXIO Modul umzusteigen, das TUL Modul wurde seit 2017-12-15 nicht mehr upgedated.
Ähnliches gilt für KNXTUL-Modul!
... dein Argument war für mich die Motivation das KNXIO-Modul vor 2 Jahren komplett neu zu schreiben!
wg. update: sorry meine fehl-interpretation der log-msg!

re KNX_scan: hab ich noch nie in Kombination mit TUL- oder KNXTUL-Modul getestet....
update: KNX_scan geht mit TUL und KNXTUL definitiv nicht, weil es bei diesen Modulen kein reading state:connected gibt. Muss mir überlegen, ob ich das implementierfen will...., alternativ cmd-ref Hinweis dazu schreibe.