FHEM website lädt extrem langsam

Begonnen von BerndHST, 17 Dezember 2020, 15:35:26

Vorheriges Thema - Nächstes Thema

BerndHST

Hallo zusammen,

da ich einen neuem Stromzähler bekommen habe, habe ich auf einem zweiten raspberry ein nagelneues fhem aufgesetzt, um den IR-Kopf zum Auslesen der Zählerwerte (mit OBIS) zu testen. Dies funktioniert soweit nun alles, allerdings lädt FHEM extrem langsam, manchmal dauert es mehrere Minuten (sic!) bis die Seite "everything" geladen wird.
Ein Netzwerkproblem schließe ich mal aus, da der raspberry auf ssh problemlos zu erreichen ist und auch ping-Aufrufe in weniger als 10ms beantwortet werden.
Allzuviel hat er auch nicht zu leisten, es werden 1x pro Minute etwa 8 Werte in einem txt-log gespeichert. Daraus werden 2 SVG-Plots erstellt.
Auf dem zweiten, älteren raspberry laufen wesentlich mehr Plots (Heizung, Wasser, etc.) und die kommen wesentlich zügiger, obwohl es noch ein uralter Raspberry1 ist.

Ich habe mal das closeConn - attribut gesetzt, aber das hat nichts gebracht.
Wie komme ich dem Problem auf die Schliche, bzw. kann ich den Fehler eingrenzen?
Wäre es denkbar, das eine defekte SD-Karte als Ursache in Frage kommt?

Bernd

Christoph Morrison

"Der Raspberry" ist genau welches Modell?
Was für ein Betriebssystem für den Raspberry nutzt du?
Läuft sonst noch irgendwas auf der Maschine?
Hast du eine alte SD-Karte genommen? Welcher Hersteller? Welches Modell?
Wie ist der IR-Kopf angeschlossen?

Beta-User

Attribute zu FHEMWEB: wie sind plotEmbed und plotfork gesetzt?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

BerndHST

Hallo,

zunächst mal zu den ersten Fragen:
Raspberry 2b
aktuelles Sytem, von der offiz. Raspberry-Seite, "Raspberry Pi OS with desktop"
auf der Raspberry läuft sonst nichts mehr
SD Karte ist eine 8GB noName, die lief aber bisher problemlos in einem anderen Raspi
Der IR-Kopf ist über USB angeschlossen, hatte ihn auch mal abgezogen aber das hat auch keine Änderung gebracht

zu plotEmbed und plotfork kann ich leider nix sagen, komme gerade gar nicht an fhem ran, da er wieder endlos lange lädt. Ich starte die Kiste mal über SSH komplett neu

Beta-User

Desktop = Pfui...

ansonsten mußt do doch nicht nach "everything", um zur Detailansicht von (vermutlich) "WEB" zu gelangen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Frank_Huber


BerndHST

initialUSBcheck habe ich schon direkt am Anfang mal abgestellt

"Desktop = pfui" , ok, die Raspberry-Seite sieht nun komplett anders aus, als ich es kenne und irgendwo wurde mal Desktop für fhem empfohlen. Welches System würdet Ihr denn als fhem-Basis empfehlen?

Ich muß nicht nach everything, aber "WEB" wurde bei mir links nicht aufgelistet, wenn ich das richtig in Erinnerung habe.

Allerdings lädt fhem jetzt wie es aussieht überhaupt nicht mehr .....
Kann ich die conf und meine logdateien irgendwie retten und dann ein neues (anderes?) System (auf anderer SD-Karte) aufsetzen? Irgendwie scheint ja mächtig der Wurm drin zu stecken.

Beta-User

"irgendwo" war vermutlich irgendein Video eines "Oberschlaubergers", der nicht wußte, wie man ssh buchstabiert. Beschäftigt uns hier immer wieder, das Thema, im Wiki steht ziemlich deutlich: headless! (Wie auch immer das grade heißen mag, früher nannte es sich "lite", und zu Pi habe ich meine Meinung; für diesen Zweck hier dürfte er ok sein, wenn auch etwas "overdone"...)

Ansonsten kommt man über "list WEB" (in der Kommandozeile schon irgendwohin, wo man entweder sieht, dass die beiden Einstellungen ok sind, oder eben klicken kann, um auf die Detailseite zu gelangen. Ansonsten gäbe es auch noch die Option, das "detail="-Ziel direkt im Browser als URL einzugeben ;) .

"Retten" geht bestimmt, am einfachsten vermutlich mit einer Linux-Maschine und passendem Kartenleser.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Frank_Huber


BerndHST

Ich komme gerade wieder ran ....

Wenn ich "unlisted" wähle, kommt die Seite recht fix. Evtl. liegts ja doch an den plots.

plotembed und plotfork sind garnicht gesetzt.
Wie sollten sie sein?

Beta-User

Zitat von: BerndHST am 17 Dezember 2020, 16:33:12
Wie sollten sie sein?
Die commandref hilft nicht weiter?

(die defaults dürften das Problem sein...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

BerndHST

Aaah, mit plotembed=1 lädt die Seite wenigstens wieder fix und jetzt sieht man auch, daß es der zweite SVG-Plot ist, der so ewig braucht.
Da ist eigentlich nix besonderes drin, außer ein delta-d für tägliche Verbrauchswerte. Brauchen die sooo lange?

Beta-User

Na ja, FileLog ist nicht unbedingt besonders effizient, wenn die Dateien entsprechend groß sind. Würde mal mit kleineren Zeiträumen und "kleben" ins Rennen gehen und dann mal schauen, wie sich das entwickelt. Ansonsten gäbe es noch "statistics" oder die diversen "Counter"-Module, die entsprechende Summary-Datenpunkte schreiben können.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rudolfkoenig

FileLog ist relativ schnell, solange in der Datei nur/hautpsaechlich das vorhanden ist, was man sehen will.
Wenn FileLog fuer eine SVG-Linie viele Zeilen oder Spalten innerhalb des gesuchten Bereiches ignorieren muss, dann wird es ineffizient.

Beta-User

Etwas OT, aber evtl. magst du das ja vertiefen bzw. bei der Gelegenheit etwas erläutern:
Klar ist, wenn in der File nur ein einziges Reading als Event mitgeschnitten wird, dann ist es ziemlich schnell.
Jetzt gibt es Module, die bauen z.B. ein "state"-Reading/Event, das sowohl temperature wie humidity enthält, und daneben noch jeweils triggernde Einzelreadings.

Ist es jetzt geschickter, die state-Events mitzuschneiden (und den Rest nicht), oder besser die Einzelwerte?
Und wie ist es, wenn es dann 4 oder 5 Bausteinchen sind?

Klar dürfte sein, dass man nicht alles drei braucht...

[noch mehr OT: könntest du https://forum.fhem.de/index.php/topic,116424.0.html anpinnen? martinp876 scheint irgendwie grad viel anderes um die Ohren zu haben und/oder hat es bisher übersehen...]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors