FHEM Forum

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

"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?

Attribute zu FHEMWEB: wie sind plotEmbed und plotfork gesetzt?

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

Desktop = Pfui...

ansonsten mußt do doch nicht nach "everything", um zur Detailansicht von (vermutlich) "WEB" zu gelangen...

ich werfe mal noch das "initialUSBcheck" ins Rennen --> https://wiki.fhem.de/wiki/Raspberry_Pi#Empfohlener_Patch

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.

"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.

Thema Wiki: https://wiki.fhem.de/wiki/Raspberry_Pi
ist eigentlich recht eindeutig.

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?

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...).

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?

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.

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.

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 (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...]

Falls das Problem immer noch tw. exisitiert, greife ich mal den Beginn des Threads auf

Zitatda 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.

In den Anfängen des OBIS-Moduls hatten wir ein riesen Performance-Problem mit pushenden Zählern. Du könntest das device mal vorübergehend aus der config nehmen, um das device als Verursacher zu bestätigen oder auszuschließen.
Grüße Markus

Zitat von: KölnSolar am 17 Dezember 2020, 19:28:34
Falls das Problem immer noch tw. exisitiert, greife ich mal den Beginn des Threads aufIn den Anfängen des OBIS-Moduls hatten wir ein riesen Performance-Problem mit pushenden Zählern. Du könntest das device mal vorübergehend aus der config nehmen, um das device als Verursacher zu bestätigen oder auszuschließen.
Grüße Markus

Das kann ich gerne mal machen.
Wie stelle ich das am zweckmäßigsten an?
In der fhem.cfg die Zeile
define ED300L OBIS /dev/ttyUSB0@9600,8,N,1 SML
mit einem # kommentieren?

Zitat[.. könntest du https://forum.fhem.de/index.php/topic,116424.0.html anpinnen?...]

Gemacht. Betreff sollte man aber jetzt aendern.

ZitatIst es jetzt geschickter, die state-Events mitzuschneiden (und den Rest nicht), oder besser die Einzelwerte?

Etwas vereinfacht skaliert der Aufwand im FileLog mit Anzahl der vorhandenen (d.h. ungefilterten) Spalten(!) im fraglichen Bereich.
Der Aufwand im SVG skaliert mit Anzahl der anzuzeigenden Werte.

D.h. optimal ist ein separates FileLog pro Linie, was nur die Wertspalte enthaelt, zusaetzlich zum Zeitstempel und Geraet. Die naechstbeste Loesung ist alle benoetigten Werte auf einer Zeile zu haben, moeglichst ohne ueberfluessige Spalten. Bevor ich aber mit solchen Umbauten anfange, wuerde ich die Haeufigkeit der geschriebenen Daten minimieren (brauche ich wirklich fuer jede Minute Daten?), und nur das speichern, was ich auch anzeigen will.


Ich habe jetzt in fhem.pl die Variable $numCPUs gefuellt (nur fuer Linux, sonst ist es 1), und fuer Mehrprozessorsysteme in 01_FHEMWEB.pm die Voreinstellung fuer plotEmbed auf 2 gesetzt. Damit werden die SVGs vom Hauptprozess entkoppelt und parallel berechnet.

Zitatmit einem # kommentieren?

bloß nicht. Dann kriegen wir Schläge  ;D

In der Detailansicht des devices kannst Du unten auf "Raw definition" klicken. Den kompletten Inhalt des sich öffnenden Fensters irgendwohin kopieren. Dann oberhalb des Fensters auf "delete this device" klicken und es ist weg. Dann kannst Du prüfen, ob sich die performance verändert hat.
Schließlich klickst Du auf das + Zeichen links oben u. kopierst den Inhalt wieder zurück in das Fenster. "Execute" klicken und das zähler-device ist wieder da.

"Raw definition" finde ich, aber ein "+" und "Execute" habe ich nicht. Wo müsste ich das finden?

Ah, hab's gefunden, scheint nur im "f18" - Theme enthalten zu sein.

Also, das vorübergehende Löschen des OBIS-device hat leider nichts an der performance geändert.
Ich hatte ja auch den IR-Kopf schonmal vom USB-Port abgezogen und dies hatte auch keine Änderung bewirkt.

Zitat
Ich hatte ja auch den IR-Kopf schonmal vom USB-Port abgezogen und dies hatte auch keine Änderung bewirkt.

Das war eine Alternative.  :)
Dann musst Du es allgemeiner herausfinden. Hier (https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche) findest Du Tips zu top, minimalconfig..... Wenn FHEM als Bösewicht ausgemacht ist, kannst Du auch mal das Modul freezemon ausprobieren. Bei mir ist das dauerhaft installiert.
Viel Erfolg
Markus