FHEM (Perl) läuft mit 100% CPU Last bei Neuinstallation?

[nicor2k]

Hallo! Ich habe folgendes Problem - wollte einen 2. Raspberry Pi mit FHEM installieren und habe alles so gemacht wie hier (und auf meinem seit jetzt fast einem Jahr mit FHEM laufenden Pi...)
http://www.computerhilfen.de/info/schnell-anleitung-fhem-auf-einem-raspberry-pi-installieren.html

Also SD Karte formatiert, Noobs aufgespielt, Raspbian installiert, dann Perl geladen und FHEM. Das hat auch wunderbar geklappt, konnte direkt mit dem Browser darauf zugreifen. Nach einem Neustart des Rechners läuft Perl aber plötzlich mit 100% CPU Last (wenn ich den Befehl "top" eingebe), der Browser versucht zwar noch, sich mit dem Rechner zu verbinden, es kommt aber keine Seite. Habe das ganze an einem 2. Raspberry probiert mit einer ebenfalls neuen SD Karte, wieder formatiert, installiert etc. Bis zum Neustart funktioniert alles problemlos, danach läuft auch da FHEM mit 100% und liefert keine Webseite mehr aus.

Update: Auch auf dem neuen Raspberry Pi 4 machte FHEM / Perl bei mir Probleme und kam auch wieder auf immerhin über 55% CPU Last. Interessanterweise lief dann auch MPD (für die Audio-Ausgaben von FHEM bei mir zuständig) mit über 60%. Einen Trick gibt es aber: Wenn ich den Start von FHEM mit einem "sleep 5" um 5 Sekunden verzögere, läuft alles normal und Perl und MPD haben wieder eine einstellige CPU-Auslastung - jetzt auf mehreren Raspberry Pis getestet. Wie das aussehen muss, habe ich hier als Screenshot für Euch: https://www.computerhilfen.de/hilfen-64-426312-0.html

[rudolfkoenig]

Ich hoer das zum ersten mal.
Ich wuerde FHEM abschiessen, in fhem.cfg "attr global verbose 5" setzen, FHEM neu starten, und danach das logfile pruefen.

[nicor2k]

Im "normalen" Log-file (ohne verbose 5) ist nichts ungewöhnliches zu erkennen, ist ja auch noch fast leer, da frisch installiert...

Mit einem "kill PROZESSID" oder "killall perl" komme ich nicht weiter, der Prozess lässt sich anscheinend nicht beenden (kommt aber keine Fehlermeldung). Kann ich das "verbose 5" einfach über die Konsole in die fhem.cfg schreiben und dann neustarten?


Kann es sein, dass auf dem alten (funktionierenden) RasPi eine ältere Raspbian Version mit älterem Perl läuft als auf dem neuen? Kann ich erst später prüfen - aber kann es an so etwas liegen?

[nicor2k]

Komischerweise läuft es jetzt, nachdem der Rechner die Nacht über aus war...
Perl ist im Moment in der Top-Liste gar nicht mehr zu sehen...

Aber: Die installierten Perl-Versionen sind tatsächlich unterschiedlich: Perl 5.14.2 auf dem Rechner, der seit langem läuft und Perl 5.20.2 auf dem neuen Rechner...

Ich werde das mal weiter beobachten


edit:

Leider zu früh gefreut, nach kurzer Zeit ist der Server-Load wieder auf 100.0% gestiegen und die Seite wird im Browser wieder nicht geöffnet

[Wernieman]

Also die Perl-Version würde ich jetzt erst mal nicht als Ursache erkennen. habe hier auch eine 5.20.2 laufen, allerdings x86

Hast Du Zusätzliche Perl-Module aus Nichtpacketquellen installiert?

[Starkstrombastler]

Hallo,

ich habe seit heute ein ähnliches Problem.
Nache dem Update des Ubuntu läuft perl mit 99% Systemlast. Ich kann es auch nicht via kill abschießen.
Meine fhem-Startseite ist nicht erreichbar. 

Wie kann ich den Rechner starten, ohne perl zu starten? Ich würde dann alle Schritte manuell ausführen.

[nicor2k]

Ich habe mich an die oben verlinkte FHEM Anleitung gehalten - und auf 2 anderen PIs mit dem älteren Wheezy lief es problemlos. Ob es an Perl liegt, weiß ich nicht, dass war nur eine Vermutung, weil es für FHEM ja dringend nötig ist und eine andere Version.

Ich habe das Problem gelöst, indem ich alles platt gemacht habe und Raspbian mit Wheezy installiert. Jetzt geht es

[r0br0ck]

Hallo,

kann das nur bestätigen. Hatte mit Jesie auch 100% CPU Last auf einem RPI2.
Nach dem flashen von Wheezy läuft wieder alles.

LG

[MarioR]

Hallo Zusammen,
gibt es inzwischen eine Lösung für dieses Problem ? Oder muss ich downgraden auf Wheezy ?

Ich muss demnächst mein FHEM von der Fritzbox werfen (also update einspielen), sonst funktioniert angeblich mein Internetzugang nicht mehr.
Auf dem RaspberryPi habe ich nach dem Booten 100% CPU durch Perl, wenn ich den den Prozess kille und FHEM neustarte scheint alles normal zu laufen.

[Wernieman]

Wie startest Du denn fhem automatisch?

[MarioR]

Hallo,
jetzt kommt leider mein (noch) nicht vorhandenes Wissen auf dem RaspberryPi, auf der Fritzbox hat ja immer alles einfach funktioniert.

Auf dem Raspberry

gibt es in

etc/init.d/

fhem


Das ist wohl der Autostart ?

[Wernieman]

Wenn es ein Debian basiertes Linux ist kannst probieren:

Code Auswählen Erweitern

update-rc.d fhm remove

Damit wird erstmal fhem aus dem Autostart rausgenommen.
Anschließend kannst Du probieren, ob ein manueller Start funktioniert, also in der Console:

Code Auswählen Erweitern

/etc/init.d/fhem start

Bitte prüfe dabei parallel (z.B. in einem 2. Fenster) die CPU-Auslastung (am besten mit "top")

[MarioR]

Wenn ich es aus dem Autostart rausnehme und mit /etc/init.d/fhem start von Hand starte läuft es.
In top ist dabei nichts auffällig.

[MarioR]

Scheint ein Timing-Problem zu sein ?!
Ich habe jetzt in /etc/init.d/fhem

nach
        echo "Starting fhem..."
folgendes eingefügt
        sleep 20s

Jetzt bleibt er beim booten nicht mehr hängen und perl taucht in top nicht mehr auf.

[Wernieman]

Alternativ kannst Du probieren, die "Dependencies" zu ändern,

also folgende Zeile anpassen:

Code Auswählen Erweitern

# Required-Start:       $local_fs $remote_fs
# Required-Stop:        $local_fs $remote_fs


z.B. könntest Du probieren, es nach dem Netzwerk starten zu lassen

Alternativ, es per "/etc/rc.local" zu starten, habe es bei mir so gelöst.

[Darkman]

Ahoi,

das Problem liegt meinen Erkenntnissen nach am Zeit per ntp setzen. Das steht auch glaub irgendwo in der Doku das man sicherstellen soll, das die Zeit VOR dem Start von fhem stimmt. Im normalfall wird aber wohl die Zeit "etwas" nach fhem korrekt gesetzt, dadurch dreht der Perl Prozess durch.

Der fuer mich sauberste Fix war das Startscript von fhem anzupassen und ins required-start noch $ntp mit rein zu nehmen. Damit wird sichergestellt das fhem erst nach dem NTP gestartet wird und das Problem war weg.

HTH,
Sven

[MarioR]

Hallo,
ich habe jetzt $ntp bei required-start hinzugefügt, und meinen sleep auf 2 runtergesetzt.
Ich dachte ich hätte das schonmal ausprobiert und fhem hat dann nicht mehr gestartet.
So scheint es im Moment auf jeden Fall zu funktionieren.

Irgendwas muss ich mir noch bei meinen Tests zerschossen haben, meinen Pi erreiche ich jetzt nur noch über die IP-Adresse. Aber das ist jetzt wohl ne andere Baustelle.
(EDIT: Komisch Jetzt doch....)

Vielen Dank und Viele Grüße,
Mario

[Otto123]

Irgendwas muss ich mir noch bei meinen Tests zerschossen haben, meinen Pi erreiche ich jetzt nur noch über die IP-Adresse. Aber das ist jetzt wohl ne andere Baustelle.
(EDIT: Komisch Jetzt doch....)

Hast Du ne Fritzbox? Bei mir ist es so, dass die FB nach einem Neustart(der FB) die Raspberry's nicht per DNS auflöst. Erst wenn die Raspberry's neu gestartet wurden oder eben nach einiger Zeit. Obwohl in der Liste der Netzwerkgeräte alle Geräte als "grün" stehen.

Gruß Otto

[MarioR]

Ja ist ne Fritzbox, wurde aber nicht neu gestartet. Jetzt funktioiert es aber, ohne das ich noch etwas geändert habe.
Etwas dubios der Pi, mit FHEM auf der Fritzbox hatte ich nie Probleme.

[Otto123]

Ist quasi Off Topic:
Mir ist in der Vergangenheit aufgefallen, dass immer mal wenn ich was am Pi "gemacht" habe der anschließend eine Weile nicht per Name erreichbar war. Manchmal half name.fritz.box irgendwann ging es mal wieder.

Fakt ist aber, der DNS Server für intern ist die FB. Und Geräte wie "Android" machen DNS lookup.

Als ich jetzt meine FB durch ein Recovery (ich wollte die Alte Meldung von ehemals FHEM/Telnet auf der FB verschwinden lassen)  neu gestartet habe und ein Pi eine neue Adresse bekommen hat (warum auch immer) war der Stundenlang vom Android per Name nicht erreichbar. Vom Windows ging alles. nslookup brachte das Problem zu Tage, der war quasi nur im DNS nicht registriert. Neustart vom Pi hat geholfen...

Gruß Otto

[Wernieman]

Wenn Ihr schon 24/7 einen Pi laufen lasst, könnt Ihr auch einen DNS-Server aufsetzen, dann habt Ihr genau die Probleme nicht ;o)

Und noch etwas: Server sollten eine Feste IP zugeordnet bekommen, dann kann sich diese nicht Ändern

[MarioR]

Feste IP habe ich eingestellt, im Moment schmiert der Pi ständig ab. Keine Ahnung warum.
Meine Frau meint dazu: "hol Dir ne 2. Fritzbox, da hat ja alles funktioniert".
Über Nacht lief der Pi jetzt durch, kommt mir alles sehr unstabil vor.

[Otto123]

Also instabile PIs gibt es bei mir nicht. Ist mir noch nie abgeschmiert.

@Werniemann Da hast Du voll Recht und DHCP gleich mit!

Gesundes neues Jahr
Otto

[nicor2k]

Das mit dem Zeit-Server könnte hinkommen (dachte aber, ich hätte die Zeit immer direkt richtig gesetzt...)
Hier hat Thomas jedenfalls ein Word-Arround, dass man vor FHEM ein "sleep 10" in die /etc/init.d/fhem setzen soll, das soll helfen (habe aber noch nicht probiert, noch läuft Weezy sehr stabil)...

[Wernieman]

Es gibt auch die Möglichkeit, FHEM erst NACH ntp zu starten .... gibt irgentwo im Forum dazu eine Doku

[Otto123]

Mein Verständnis bisher war:
- ntp sorgt für die aktuelle Zeit während des Betriebes.
- fake-hwclock sorgt dafür, das nach dem Start nicht vor dem Shutdown ist.

Damit gibt es doch nur einen Stillstand während dem Neustart oder einer Betriebspause. Außer Tritt dürfte dabei nichts kommen.

Ansonsten müsste man im fhem.service Script im Abschnitt [Unit] nach After= festlegen das fhem erst nach ntp startet.

Ich habe bloss keine Ahnung wo fhem.service eigentlich liegt.

Gruß Otto

[Wernieman]

Wie bei allem mit systemd arbeitenden Ditris:

Code Auswählen Erweitern

/etc/systemd/system/

[Otto123]

Nur das da bei mir keine liegt 
Aber ich habe die Erklärung gefunden wo sie liegt wenn es gar keine gibt 
FHEM legt ja von selbst keine an. Sondern implementiert den /etc/init.d "Mechanismus"

Oder liege ich da falsch?

[Wernieman]

Jep .. was als "fall back" auch normalerweise genutzt wird

[Otto123]

Wieder was gelernt! 

[MarioR]

Also instabile PIs gibt es bei mir nicht. Ist mir noch nie abgeschmiert.

@Werniemann Da hast Du voll Recht und DHCP gleich mit!

Gesundes neues Jahr
Otto

Lag wohl am Wlan. Der PI war nicht mehr erreichbar, und ich dachte er wär abgeschmirt. Seit er am LAN hängt ist er stabil.

[ext23]

Hallo,

ich möchte kein neues Thema öffnen aber ich habe auf meinem Server auch zwischen 90 und 100% last des perl Prozesses. Apptime verrät mir aber nichts womit ich was anfangen könnte. Hat noch jemand eine Idee wie ich raus bekomme woran das liegt? Die Maschine sollte eigentlich so performant sein, dass das nicht passiert. Also ich nutze ein RPi oder sowas...

/Daniel

[rudolfkoenig]

"attr global verbose 5" setzen, und log beobachten.

[ext23]

OK, habe ich auch schon geschaut, es kommt eine ganze Menge (Jeelink und SPSPM und so) aber ehrlich gesagt nicht in der Menge, dass ich sagen würde es sollte auch nur annähernd 1% CPU Last verursachen.

Ich werde es weiter beobachten, bzw. nach und nach mal die interface deaktivieren...

/Daniel

[ext23]

Also ich finde nichts, ich bin echt überfragt.

Werden bei Apptime nur Module gezeigt in denen bestimmte Bedingungen erfüllt sind oder alle, also auch die unsauber programmieren? Ich meine es sind keine 100% auf Anschlag, aber nahe dran, also irgend etwas scheint da tierisch zu ackern. Bei einem Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz finde ich das ein wenig viel für FHEM.

Oder würdest du hier was auffälliges sehen:

Code Auswählen Erweitern

                                name             function    max  count    total  average maxDly
                            PanStick      panStamp_Define   4567      1     4567  4567.00      0 HASH(PanStick); PanStick panStamp /dev/PanStamp@38400
                                KODI           XBMC_Ready   3000 13889258    59988     0.00      0 HASH(KODI)
                           RFXTRX433           TRX_Define   2857      1     2857  2857.00      0 HASH(RFXTRX433); RFXTRX433 TRX /dev/RFXTRX433@38400
                             MP00202       OWX_ASYNC_Read   2422  12741   102441     8.04      0 HASH(MP00202)
            Notify_Schluessel_Daniel          notify_Exec   2245      2     2267  1133.50      0 HASH(Notify_Schluessel_Daniel); HASH(fl_iButton_blau)
                          az_OW_LCD1            OWLCD_Get   2213      1     2213  2213.00      0 HASH(az_OW_LCD1); az_OW_LCD1; gpio
                           wifiled01     WifiLight_Define   1008      1     1008  1008.00      0 HASH(wifiled01); wifiled01 WifiLight RGBW LD382A:192.168.0.91
                             JeeLink       JeeLink_Define   1006      1     1006  1006.00      0 HASH(JeeLink); JeeLink JeeLink /dev/JeeLink@57600
                             JeeNode       JeeLink_Define   1006      1     1006  1006.00      0 HASH(JeeNode); JeeNode JeeLink /dev/JeeNode@57600
                    Steckdose_Server         SISPM_Define    901      1      901   901.00      0 HASH(Steckdose_Server); Steckdose_Server SISPM /usr/local/bin/sispmctl
                         tmr-at_Exec      HASH(0x5a697a0)    810      4     3240   810.00      4 HASH(Timer_1Wire_ba_Temp_Steuereinheit)
               ba_Temp_Steuereinheit       ECMDDevice_Set    807     13     3228   248.31      0 HASH(ba_Temp_Steuereinheit); ba_Temp_Steuereinheit; messen
                             MP00202     OWX_ASYNC_Notify    717     17      717    42.18      0 HASH(MP00202); HASH(global)
                          PushNotify  PushNotifier_Define    520      1      520   520.00      0 HASH(PushNotify); PushNotify PushNotifier EV468E7DBV468E7DV75BBV46BV466C3VEFTBFTFBFB net.homeip.itse ext23 gen6iNWG9bY .*
        WEBtablet_192.168.0.15_41103              FW_Read    323      1      323   323.00      0 HASH(WEBtablet_192.168.0.15_41103)
                            Twilight      Twilight_Define    295      1      295   295.00      0 HASH(Twilight); Twilight Twilight 52.539094 13.603869 3 638242
                         Callmonitor FB_CALLMONITOR_Notify    244   1722      244     0.14      0 HASH(Callmonitor); HASH(global)
                        DMXUniverse1    DMX4ALLUSB_Define    206      1      206   206.00      0 HASH(DMXUniverse1); DMXUniverse1 DMX4ALLUSB /dev/DMX@38400
                                 WEB              FW_Read    184     17      766    45.06      0 HASH(WEB)
              tmr-OWX_ASYNC_RunTasks     HASH(0x10f2fd70)    174   1581    42613    26.95   3225 HASH(MP00202)
                                CUL1           CUL_Define    143      1      143   143.00      0 HASH(CUL1); CUL1 CUL /dev/ttyACM0 1234

Das avg ist recht hoch mhhh, aber bei allen. Oder spinnt hier eventuell mein USB Bus.

/Daniel

[justme1968]

ist es wirklich der haupt fhem prozess oder irgend ein child? beim mit spinnt manchmal der sonos prozess mit 100% cpu. 

du kannst dich mit strace -p <pid> an den prozess hängen und schauen was er gerade macht.

gruss
   andre

[ext23]

Hi,

naja ich denke es ist der Hauptprozess, also Perl. Der läuft aber auch nur jeweils auf einer der 4 Kerne die meine CPU hat.

strace liefert ein haufen Zeilen aller:
select(176, [5 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 29 30 54 55 71 72 73 95 146 153 155 171], NULL, NULL, {1, 353556}) = 1 (in [21], left {1, 353550})
select(176, [5 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 29 30 54 55 71 72 73 95 146 153 155 171], NULL, NULL, {1, 353451}) = 1 (in [21], left {1, 353444})
select(176, [5 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 29 30 54 55 71 72 73 95 146 153 155 171], NULL, NULL, {1, 353339}) = 1 (in [21], left {1, 353333})
select(176, [5 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 29 30 54 55 71 72 73 95 146 153 155 171], NULL, NULL, {1, 353231}) = 1 (in [21], left {1, 353225})


Das ist der Prozess:
fhem      9966 80.8 11.6 603656 456920 ?       S    10:34 474:05 perl fhem.pl fhem.cfg

top:
  PID BENUTZER  PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
9966 fhem      20   0  604008 457308   5344 R  82,5 11,7 474:47.50 perl

Ich kann da kein Unterprozess erkennen auch nicht im Baum.

Gruß
Daniel

[justme1968]

über /proc/<pid>/fd solltest du  sehen wozu der filedescriptor 21 gehört der das select aufwachen lässt.

gruss
  andre

[justme1968]

irgendwo gibt es einen thread bei dem es auch um zu viel last beim lesen von einem usb device ging. kann aber sein das das nur in einer vm war. da gibt es auch einen patch vorschlag der zumindest dort geholfen hat.

[ext23]

Mhh das ist mein DMX Adapter, und das Modul habe ich selber geschrieben Heißt ich habe da irgendwo Misst gebaut in meinem Modul.

/Daniel

[ext23]

Ich hab jetzt mal ein paar Debug logs in meine Module eingebaut. Auffällig ist nur, dass die read Funktion Device Modul ständig aufgerufen wird. Die ist aber leer bei mir, ich nutze das nicht da der DMX Controller von sich aus keine Infos sendet sondern nur auf Anfragen antwortet. Kann das mein Problem sein?

Es heißt ja "called from the global loop, when the select for hash->{FD} reports data" Jetzt ist nur die Frage warum da Daten reported werden... Sonst dürfte er die Funktion ja gar nicht aufrufen wenn ich das richtig verstanden habe.

/Daniel

[rudolfkoenig]

Jetzt ist nur die Frage warum da Daten reported werden

Vmtl. weil FD in selectlist eingetragen ist.
Hast du die Datei mit DevIO geoeffnet? Dann passiert das automatisch.

[ext23]

Vmtl. weil FD in selectlist eingetragen ist.
Hast du die Datei mit DevIO geoeffnet? Dann passiert das automatisch.

Ich nutze DevIO ja. Heißt also das ist normal und vermutlich nicht Ursache für mein Verhalten.

[rudolfkoenig]

Heißt also das ist normal und vermutlich nicht Ursache für mein Verhalten.

Aeh:
- Wenn man DevIO nutzt, ist normal, dass man nicht pollt, sondern ReadFn aufgerufen wird, wenn das zentrale select() feststellt, dass was zum Lesen gibt.
- Wenn das Geraet unaufgefordert Daten schickt, oder das Modul beim Pollen nicht alle Daten "weggelesen" hat, und ReadFn nichts tut, dann tritt genau das o.g. Verhalten auf: ReadFn wird in einer Endlosschleife aufgerufen.

Wenn du DevIO verwenden willst, und auf Pollen bestehst, dann solltest du

delete($selectlist{"$name.$dev");
  delete($readyfnlist{"$name.$dev");

nach DevIo_OpenDev aufrufen.

[ext23]

wenn das zentrale select() feststellt, dass was zum Lesen gibt.

Naja das macht es dann vermutlich, nur gibt es nichts zum Lesen weil, bzw. wenn dann die Antwort, aber die sollte ja eigentlich irgend wann mal "weggelesen" sein, ist nur 1 Byte was da als Antwort im UART Buffer liegt.

- Wenn das Geraet unaufgefordert Daten schickt, oder das Modul beim Pollen nicht alle Daten "weggelesen" hat, und ReadFn nichts tut, dann tritt genau das o.g. Verhalten auf: ReadFn wird in einer Endlosschleife aufgerufen.

Wenn du DevIO verwenden willst, und auf Pollen bestehst, dann solltest du nach DevIo_OpenDev aufrufen.

Naja Pollen möchte ich gerade nichts, also die Antwort vom DMX Controller interessiert mich garnicht um es mal krass zu sagen. Aber danke, ich schau mir das mal an was du schreibst. Ansonsten baue ich in die Lesefunktion noch was ein, das der Buffer leergelesen wird oder so. Aber jetzt habe ich zumindest verstanden was das Problem ist. Das ist mir nie aufgefallen das ich da misst drin habe. Schade das AppTime sowas nicht anzeigt. Ich versuche das zu ändern und werde berichten.

/Daniel

[ext23]

So ich hab ein

$buf = DevIo_TimeoutRead($hash, 0.1);

in die Read Funktion gepackt und schon sieht das ganze besser aus. Jetzt wird die Funktion nicht mehr aufgerufen, da war also noch irgend was im Buffer. Danke.

Endlich wird der Server wieder ruhiger und 10 Watt weniger verbraucht er auch

/Daniel

[rudolfkoenig]

die Antwort vom DMX Controller interessiert mich garnicht um es mal krass zu sagen

Aah. So geht es nicht, man muss hoeflich bleiben, und dem anderen auch zuhoeren.

Wenn du vom select aufgerufen wirst, reicht ein DevIo_SimpleRead, dass select sich meldet, ohne dass was zu lesen waere, habe ich noch nicht erlebt. Ok, Ausnahme: das Geraet wurde entfernt, aber DevIo_SimpleRead behandelt das auch.

[ext23]

Naja macht alles Sinn ja, hatte ich halt nicht aufm Schirm gehabt beim programmieren. Ich war froh, dass mein Modul macht es es soll Ich war fest der Meinung das ich nach dem Senden an den Controller danach den Puffer leere wo die "unnütze" Antwort drin steht, war aber ein Trugschluss.

/Daniel

[wange2]

Hi MarioR,
dein Tip mit sleep(10) hat mir geholfen. Gerade fhem 5.9 auf raspi 4 und debian installiert.
100% cpu von user fhem mit perl.
Bei meiner installation habe ich in /etc/init.d allerdings kein fhem script gefunden. Dafür aber einen Definitionsfile in /etc/systemd/system. Da konnte man das sleep nicht einbauen.
Nun habe ich das Statement sleep(20); direkt in das Script /opt/fhem/fhem.pl ganz an den Anfang nach den Definitionen eingefügt. Nun läuft das prima nach Neustart.

[Otto123]

Nun habe ich das Statement sleep(20); direkt in das Script /opt/fhem/fhem.pl ganz an den Anfang nach den Definitionen eingefügt. Nun läuft das prima nach Neustart.

Das tut man nicht

Besser so: https://forum.fhem.de/index.php?topic=104132.0

Und etwas Linux Prosa lesen hilft auch

Gruß Otto