Logs vorbereiten

Wolfgang Hochweller · 21 Juni 2019, 16:43:08

Gibt es Ansaetze, um Plots bei grossen Datensaetzen irgendwie 'vorzubereiten' ?

Beispiel :
Mein Stromzaehler liefert alle 2 sek 10 Werte, davon werden zwei in ein Logfile geschrieben;
macht also ueber den Tag eine Menge Eintraege.
Ein Plot oder ein Chart davon dauert ewig, ist halt doch nur ein Pi....

Vielleicht kann man beruecksichtigen, das alte Daten nie veraendert werden, es kommen immer nur neue dazu.

'event-on-change-reading' bringt hier auch nichts, die Daten des Zaehlers aendern sich staendig.

Im Moment faellt mir dazu nichts ein.

Wuehler · 21 Juni 2019, 16:51:46

Moin,

Würde ggf das Attribut event-aggregator helfen?

VG,
Dirk

amenomade · 21 Juni 2019, 20:07:53

Ich verstehe deine Ausage nicht

ZitatVielleicht kann man beruecksichtigen, das alte Daten nie veraendert werden, es kommen immer nur neue dazu.
... event-on-change-reading' bringt hier auch nichts, die Daten des Zaehlers aendern sich staendig.

Genau dafür ist event-on-change-reading da. Du willst nur geänderte Daten, aber es stört dich wenn die sich ändern??? Verstehe nicht

Wenn 2 Sek zu oft ist, kann man auch event-min-interval benutzen.

Wolfgang Hochweller · 21 Juni 2019, 22:48:29

Das hast du missverstanden.
Die Daten aendern sich dauernd, also bringt 'event-on-change-reading' nichts, ist dabei eher kontraprdpoduktiv.
Ich wollte darauf hinaus, dass man das Log ja eigentlich nicht immer vollstaendig neu durcharbeiten muss, sondern nur den Teil, der seit der letzten Ploterstellung neu dazugekommen ist, an den Daten, die schon mal geplottet wurden, aendert sich nichts mehr.
event-aggregator muss ich mir ansehen.
'event-min-interval' ist wahrscheinlich auch keine Loesung;
der Zaehler sendet regelmäßig drei Frames, einen alle 2 sek, einen alle 60 sek und einen jede Stunde.
Die beiden letzten darf ich dabei nicht uebersehen.

Wuehler · 25 Juni 2019, 08:10:21

Moin,

Dein edit des letzten Beitrags habe ich eben erst gesehen. Kann man die stündlichen Frames von denen die alle zwei Sekunden kommen unterscheiden?

Hollo · 25 Juni 2019, 09:17:33

Für den alle 2 Sekunden kannst Du trotzdem event-on-change-reading einsetzen; und zwar in Kombination mit einer erforderlichen "Änderungsgröße".
Damit dünnst Du das dann aus, hast aber weiterhin genug Werte.

ZitatSyntax

Das event-on-change-reading Attribut wird in der folgenden Weise spezifiziert:

attr <device> event-on-change-reading reading1[:threshold][,reading2[:threshold]...n]

Die zu berücksichtigenden Readings sind als durch Komma getrennte Werte anzugeben, können aber auch über reguläre Ausdrücke zusammengefasst werden.

Wolfgang Hochweller · 25 Juni 2019, 22:17:20

Danke, mit dem Ausduennen hast du sicher recht, ein Versuch kann sicher nicht schaden.
Die Verbrauchswerte sind sehr sprunghaft.
Grund dafuer sind zum einen die Solarzellen, die schon bei leichter Bewoelkung schnelle Aenderungen zeigen,
zum andern die Tatsache, dass bei uns alles mit Strom erledigt wird, Heizung, Warmwasser, Klima, etc.
Das Ganze dient zur Vorbereitung der Stromkostenkontrolle, da hier in naher Zukunft der Strompreis von Tageszeit und Momentanverbrauch bestimmt werden wird.

kadettilac89 · 26 Juni 2019, 09:01:41

Für das was du vorhast ist wahrscheinlich FHEM mit deinem Setup das Falsche bezogen auf deine Wünsche nach schnellen Zugriffszeiten.

- du erzeugst über 40000 Sätze pro Tag ... wahrscheinlich gibt deine SD-Karte bald auf da zu viele Schreibzugriffe hast, Größe der Files wächst
- du nutzt Logfiles statt DBLog
- diene Hardware ist ggf. zu schwach

Ansätze
1) teste mal im FHEMWEB das Attribut "SVGcache". Dann werden bereits erzeugte Plots zumindest zwischengespeichert
2) teste mal DBLog (z. B. in MySql-DB) statt Logfiles. Dann hast du die Werte zumindest in einer Datenbank, dürfte schon mal schneller sein
3) teste mal auf einer stärkeren Hardware, zum Beispiel in einer virtual machine oder eine schnellere SD-Karte
4) teste statt Plot in Fhem Grafana auf einer InfluxDB ... damit solltest du auch auf einem Raspberry akzeptable Antwortzeiten bekommen.

1-2 findest du in der Commandref und hier im Forum Threads

zu 4)
Influxdb aus Fhem befüllt
https://forum.fhem.de/index.php/topic,71551.0.html

Schau dir mal die Diskussion zwischen mir und Happyuser20 an. Der hat auch seine PV geloggt. Grafana auf MySql
https://forum.fhem.de/index.php/topic,77724.msg894163.html#msg894163

Edit. Wenn du nur einmal täglich eine Übersicht willst evtl. dieser Ansatz, per Mail zum Tageswechsel
https://forum.fhem.de/index.php?topic=77119.0

Wolfgang Hochweller · 26 Juni 2019, 10:33:03

Danke, das mit der SD-Karte ist ein Argument, weswegen ich sicher bald auf einen 'normalen' Linuxrechner umsteigen werde.
Ich habe es eine Zeit lang auch mal ueber einen USB-Stick probiert, aber mit wechselndem Erfolg; habe ich dann wieder eingestellt.

Vielleicht muss ich die Arbeit auch aufteilen, sprich, der Raspi im Sicherungskasten macht die ganze Arbeit, was Strom und Solar betrifft.
Der muss sowieso da sein, um die Werte des Zaehlers und Inverters auszulesen.
Falls dessen SD-Karte zu schnell versagt, stelle ich das auf Wlan oder Ethernet um.
Sonst hat der nicht viel zu tun, da kann er auch mal was arbeiten.

Nur die bearbeiteten Informationen bekommt das Hauptsystem dann zugespielt.

kadettilac89 · 26 Juni 2019, 10:58:24

sag vielleicht mal was du genau erreichen willst. wie stark aggregieren oder nach welcher logik. summe, mittelwert, ... was erhoffst du dir?

- statistics in fhem? verschiedene möglichkeiten
- dblog mit attribut redulcelog mit avg=day ... solltest dann stundenmittel erhalten

Hollo · 26 Juni 2019, 12:34:25

Zitat von: howi42 am 25 Juni 2019, 22:17:20
Danke, mit dem Ausduennen hast du sicher recht, ein Versuch kann sicher nicht schaden.
Die Verbrauchswerte sind sehr sprunghaft.
Grund dafuer sind zum einen die Solarzellen, die schon bei leichter Bewoelkung schnelle Aenderungen zeigen,
zum andern die Tatsache, dass bei uns alles mit Strom erledigt wird, Heizung, Warmwasser, Klima, etc.
Das Ganze dient zur Vorbereitung der Stromkostenkontrolle, da hier in naher Zukunft der Strompreis von Tageszeit und Momentanverbrauch bestimmt werden wird.

Ich komme nochmal darauf zurück...
die genannten Einflussfaktoren (sowohl Erzeugung als auch Verbrauch) stehen ja immer länger als 2 Sekunden an.

Insofern könntest Du testweise auch mal nur minütlich ins Log schreiben (Kombi aus höherem Threshold und min-intervall); das wäre ja schon Faktor 30 weniger.
Oder halt den Grenzwert für event-on-change entsprechend höher setzen.
Ob die gesamte PV nun gerade 10W mehr oder weniger erzeugt; macht ja insgesamt nicht so viel aus; 1W Verbrauch ebenso.

Einfach mal zum Testen des Unterschiedes.
Alternativ ein Zähler, der die Werte intern aggregiert und Du die aktuellen Stände alle 15 Min ausliest.
Ein kleineres Intervall machen die "smarten" m.W. auch nicht.

Wolfgang Hochweller · 26 Juni 2019, 14:14:21

Danke, habe das Logging jetzt mal auf 1/min bzw. groessere Aenderungen geaendert.
Morgen sehe ich den Effekt.

Wolfgang Hochweller · 04 Juli 2019, 15:15:30

Threshold hilft schon mal. Jetzt laesst sich auch ein Chartwidget
auf einem Android-Tablet mit passablen Antwortzeiten aufrufen

Wolfgang Hochweller · 07 Juli 2019, 11:22:55

Ich moechte noch ergaenzen, dass im Falle von Logs mit sehr vielen Eintraegen, gerne 50000 oder mehr, nicht der FHEM-Server ( in meinem Fall ein Pi 3) das Nadeloehr ist, sondern die Klienten.
Mit einem gar nicht mal so kraeftigen PC ueberhaupt kein Problem, mit einem State-of-the-Art Android Tablet kann das leicht zu groesseren
Wartezeiten fuehren.