Reihenfolge der Definitionen in fhem.cfg bestimmt NICHT Reihenfolge beim Start?

[Pfriemler]

Ich bin verwirrt.
Bislang ging ich davon aus, dass die fhem.cfg linear von vorn nach hinten abgearbeitet wird. Das Forum ist voll von Hinweisen darüber, wie eine korrekte Reihenfolge viele Probleme lösen hilft, etwa wenn diverse Definitionen ein IO-Gerät benutzen, was noch gar nicht definiert ist.

Mit so einem Problem habe ich gerade mglw. auf anderer Front zu kämpfen. Dabei habe ich einmal die Reihenfolge des Öffnens meiner IO-Geräte mit den fhem.cfg Codezeilen verglichen. Auffallend ist, dass die Homematic-IO-Devices HMWLAN1 und HMUART fast quasi als letzte "in Gang kommen", während ein nachdefiniertes HMLAN1 am Ende der fhem.cfg viel früher initialisiert wird. Ich sehe absolut keinen Grund, warum ein auf dem GPIO des Raspberry steckendes IO weit nach den Netzwerkgeräten initialisiert wird.

Und: gibt es eine Möglichkeit, die Reihenfolge der Abarbeitung tatsächlich sinnvoll zu beeinflussen?

Code Auswählen Erweitern

2020.06.21 13:52:01 1: Including fhem.cfg
2020.06.21 13:52:01 3: telnetPort: port 7072 opened
2020.06.21 13:52:01 3: WEB: port 8083 opened (0029)
2020.06.21 13:52:01 3: WEBphone: port 8084 opened (0067)
2020.06.21 13:52:01 3: WEBtablet: port 8085 opened (0081)
2020.06.21 13:52:03 3: Opening EnOceanGW device ... (0138)
2020.06.21 13:52:03 3: Opening CUL1 device /dev/ttyACM0 (0162)
2020.06.21 13:52:03 3: myDuoFernStick device opened (0172)
2020.06.21 13:52:14 3: myKVPUDP: Opening multicast socket... (6251)
2020.06.21 13:52:17 3: WEBadmin: port 8088 opened (7197)
2020.06.21 13:52:20 3: Opening FritzboxAnrufe device 192.168.178.1:1012 (7855)
2020.06.21 13:52:20 3: CUL433 device opened (8054)
2020.06.21 13:52:23 3: WEBdev: port 8087 opened (9145)
2020.06.21 13:52:23 3: Opening JeeLink device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 (9202)
2020.06.21 13:52:24 3: Opening HMLAN1 device 192.168.178.109:1000 (9347)
2020.06.21 13:53:37 3: ESPEasy ESPBridge: Bridge v2.18 port [TCP:IPV4:8383] opened. (8181)
2020.06.21 13:53:37 3: HMUART device opened (0130)
2020.06.21 13:53:37 3: Opening HMWLAN1 device 192.168.178.154:23 (0122)
2020.06.21 13:53:37 3: Opening LCGW device 192.168.178.158:81 (0149)
2020.06.21 13:53:39 3: myBroker device opened (7167)
...
2020.06.21 13:53:39 0: Server started with 1075 defined entities (fhem.pl:22172/2020-06-12 perl:5.024001 os:linux user:fhem pid:6956)


[amenomade]

Da möchte ich gerne mitlesen. Leider keine Lösung für dich

[betateilchen]

Bislang ging ich davon aus, dass die fhem.cfg linear von vorn nach hinten abgearbeitet wird.

Das ist auch so. Aber wann ein aus der fhem.cfg heraus definiertes device anfängt zu leben und beispielsweise Attribute tatsächlich gesetzt werden, wird vom jeweils zugehörigen Modul (bzw. dessen Autor) bestimmt. Damit hat der FHEM-Startprozess selbst nichts mehr zu tun.

wie eine korrekte Reihenfolge viele Probleme lösen hilft, etwa wenn diverse Definitionen ein IO-Gerät benutzen, was noch gar nicht definiert ist.

Das sind aber meist veraltete Informationen. Inzwischen sollten die meisten Reihenfolgeprobleme softwareseitig gelöst sein. Falls das im Einzelfall nicht so ist, sollte der Modulautor informiert werden, damit er von Problemen erfährt und sich ggf. darum kümmert.

Und: gibt es eine Möglichkeit, die Reihenfolge der Abarbeitung tatsächlich sinnvoll zu beeinflussen?

Nein. Und das ist auch nicht schlimm, denn siehe oben: die Abarbeitung der fhem.cfg erfolgt exakt so, wie Du es Dir vorstellst - in der Reihenfolge, die in der Konfiguration steht. Aber das tatsächliche Verhalten eines Moduls bzw. device  hat damit nichts zu tun.