FHEM reagiert manchmal verzögert

[Gear]

Moin,
mir ist seit einiger Zeit aufgefallen, dass gelegentlich einfach zwischen Aktion und Ausführung eine Zeitverzögerung >5sec  auftritt.
Nach langem suchen passiert das z. B. beim Spritpreis einholen, wenn meine Strommesser ihre Daten senden und diese ausgewertet werden (99er File) oder vergleichbar.

Kann man die Dinge irgendwie auslagern, so dass FHEM nicht blockiert wird?
Oder zwei FHEM Instanzen auf einem Pi laufen?

Beste Grüße und Danke
Gear

[dieter114]

Hallo Gear,

ich habe an einem Pi gut 30 1-Wire über USB sowie unglaublich viel Berechnungen im Hintergrund laufen.
Dazu konnen 3 CUL`s, Wetterauswertungen und nun auch noch umfangreiches TabletUI.
Alles lief einwandfrei bis ich auf die "Tolle" Idee kam auch noch über lan-ping alle angeschlossenen Einheiten auf Funktion und Existenz zu überprüfen.
Danach konnte ich "Kaffekochen" gehen nach einem Befehl.
Lösung: Alle Dinge, die übers Netz irgendwelche Abfragen laufen lassen, die du nicht selber im Timing beeinflussen kannst, in einen anderen Pi auslagern.
Ob das mit einer zweiten Instanz geht weis ich nicht.
Mein System läuft nun auf einem Pi4 als "Hauptinstanz" dazu ein Pi2 für die Poolsteuerung im Sommer
und ein alter Pi1, der genau diese Abfragen mit lan-ping usw. macht.
Über fhem2fhem alles zusammengeschlossen und die Performance stimmt wieder.
Die Systemlast von fhem2fhem ist minimal, man mus nur erst einmal verstanden haben wie das funktioniert.(Wiki!)

Gruß Wolfdieter

[Otto123]

Hi,

Spritpreis - klingt nach attr global dnsServer

dnsServer
Enthält die IP Adresse des DNS Servers. Die von bestimmten Modulen (oder eigenen Code) aufgerufene HttpUtils_NonblockingGet wird auch bei der DNS Auflösung nicht mehr blockieren, falls dieses Attribut gesetzt ist, da es in diesem Fall FHEM eigene Routinen aufgerufen werden. Sonst werden die OS-eigenen, blockierenden Routinen inet_aton bzw gethostbyname aufgerufen.

Den 99 er Code müsstest Du auf Blocking Content untersuchen.

Ansonsten kann ich anstatt FHEM2FHEM auch mqtt empfehlen.

Gruß Otto

[Gear]

@Otto
Ich habe in deinem Blog was gefunden zu mehreren Instanzen. ^^
> Werde ich am WE mal testen!
>> Wie ist es am Sinnigsten die FHEM Instanzen zu verkuppeln? MQTT? FHEM2FHEM? oder doch anders?

Naja, ich habe 7 Tasmota Stromzähler und 4 ESP-Easy, das erstellt eben Statistiken und schreibt die Daten in die Datenbank, an und für sich ist die Durchlaufzeit nicht seh lange, aber wenn es im 60sec Takt kommt, dann blockiert das schon.
> Aktuell läuft es auf 15min und das hatte das Problem gelöst.

Ich nutze Ping nicht, da es FHEM zum Teil blockiert hat, nutze dafür WOL.

Zu"attr global dnsServer", soll ich das aktivieren?

Danke!
Ich melde mich nochmal, wenn ich es getestet habe.

[dieter114]

Hi,

Spritpreis - klingt nach attr global dnsServerDen 99 er Code müsstest Du auf Blocking Content untersuchen.

Ansonsten kann ich anstatt FHEM2FHEM auch mqtt empfehlen.

Gruß Otto

Hallo Otto,
wie kann man eigentlich sein System auf Blocking-Content untersuchen?
Mein Problem ist ein RPi4. Das System bootet von der SD und läuft dann in einer SSD am USB3.
Alles ist "sauschnell" aber total Instabil.
Das Debian Buster läuft zu jeder Zeit stabil durch, also kann ich Hardwareprobleme mit der SSD ausschließen.
Fhem Blockiert offensichtlich, nur ich finde keinen Grund dafür.
Auf einem RPI3 mit 32GB SD läuft alles absolut stabil - nur leider recht langsam.
Gruß Wolfdieter

[KernSani]

Was Otto oben meinte sind deine Routinen in der 99_myUtils. Wenn du z.B. OS-Befehle oder http-Abfragen ausführst, blockert dein System bis die Ergebnisse da sind.
Generell kann man mit dem freezemon blockierende Prozesse aufspüren.
Grüße,
Oli


Kurz, weil mobil

[Otto123]

wie kann man eigentlich sein System auf Blocking-Content untersuchen?

Hallo Wolfdieter,

wie Kernsani gesagt hat freezemon ... Ansonsten meinte ich: wirklich reinschauen in die eigenen Routinen ob dort etwas ausgeführt wird, was im Zweifel lange dauern kann.
Du kannst auch Dein FHEM mit bestimmten Befehlssequenzen von "außen" befeuern und schauen wie lange es dauert oder was passiert. Wie man das machen kann, habe ich hier mit beschrieben.

Gruß Otto

[dieter114]

Danke Otto,
das hab ich soweit verstanden aber:
Warum treten die Probleme nur beim Pi4 auf?
Die gleiche Software (SD Karte getauscht) geht auf dem Pi3 ohne jegliche Probleme.
Gruß Wolfdieter

[Otto123]

Das verstehe ich nicht. Selbst wenn etwas blockiert, könnte die Blockade ja bestenfalls auf dem Pi4 kürzer dauern weil es schneller geht.

Das klingt eher danach, als ob auf dem Pi4 was schief läuft. Ich habe keine Idee was. Es klingt ja danach, dass etwas auftritt weil es jetzt schneller geht. Klar auch das kann sein, plötzlich überholen sich Dinge die früher scheinbar nebeneinander herliefen.
Kannst Du nur suchen, ob Du einen Verursacher findest.

[dieter114]

Nochmal danke
Genau an dem Punkt bin ich auch angekommen.
Habe mein Hauptsystem wieder auf den alten PI3 gebracht.
Nun läuft es  - aber halt etwas langsamer - dafür stabil!
Es muss doch irgendwelche Logs im Debian geben, die irgendwie aufzeichnen was da wo und wie läuft.
Solche Probleme sind doch bei komplexen Systemen an der Tagesordnung.
Ich verstehe nur zu wenig vom Linux, sonst hätte ich zumindest einen Ansatz.
Sicher: Ein Teil nach dem Anderen Zuschalten und Beobachten.
Nur welcher (noch) berufstätige Mensch hat die Zeit dafür.
Gruß Wolfdieter

[claudio-fhem]

Der Raspi 4 ist nicht einfach ein schnellerer 3er, sondern hat ein komplett anderes Bus System und noch einige offene Baustellen. Da wurde so einiges (gerade auf der Softwareseite) quick and dirty zusammengewurstelt. Der Brexit? Oder brauchten sie schnell eine neue Einnahmequelle? Wer weiss...

Ich wäre mit dem 4er noch zurückhaltend. Und an einer anderen Stelle schonmal beschreiben: Wenn man einen 4er mit Netzteil, USB-Hub, Kühlung/Gehäuse zusammenrechnet, ist man schnell bei einem günsitgen miniITX Board mit Gehäuse, da läuft dann auch jedes ordentliche OS, nicht nur die ARM-Sachen...

[Wernieman]

Es ist kein Unix, sondern ein FHEM-Problem, entsprechend kannst Du in den unix-Logfiles /var/log/*) bestimmt wenig finden.

Du musst dann schon mit FHEM Bordmitteln (freezmon o.Ä.) auf Fehlersuche gehen ...

[KölnSolar]

Da es in einem anderen Fred auch mal wieder das freeze-Thema gab, und sowohl hier als auch da 1W im Spiel ist: Die machen grundsätzlich Probleme. Zugriffszeit je Lesezyklus ca. 1s/device. Bei Nutzung mit GPIO4 existiert eine inoffizielle Version von mir, die das Problem löst. Scheinbar(anderer Fred) ist das selbe Problem aber bei OWTHERM auch vorhanden.

Grüße Markus
PS: Letztendlich hilft nur dem eigenen System auf den Grund gehen: freezemon u. apptime sind da sehr gute Helfer. Kostet halt Zeit......

[Wernieman]

Oder eben 1W per "eigener Hardware" anbinden .... gibt doch genug Lösungen?