Moin,
ich wundere mich etwas, dass das vor mir noch keiner so gemacht. Aber da es mich eh gejuckt hat:
https://github.com/solexx/fhem-munin-plugins
Das ist eine Reihe von Plugins für Munin, die einen lokal laufenden FHEM-Server (bald auch mal konfigurierbar ...) abfragen und für eine Menge Readings automatisch Graphen basteln. Vorteil gegenüber dem, was ich bisher so gesehen (oder selbst gemacht) habe:
- Kein Parsen von Logfiles!
- Keine Namenskonvention oder Konfiguration der vorhandenen Geräte notwendig. Die Plugins suchen per list-Befehl Geräte mit passenden Readings (temperature, humidity, brightness ...) einfach selbst.
- Neu angelernte Geräte werden automatisch angezeigt.
Der größte Nachteil ist wohl, dass die Labels auch automatisch generiert werden (aus dem Namen der Geräte in FHEM) und man nicht immer genau die Kurven in einem Graphen hat, die man sich wünscht. Dafür gibt es aber mit Bordmitteln von Munin Abhilfe, siehe Link oben. Wie das konkret aussehen kann:
http://jigsaw.home.well-adjusted.de/munin/fhem_auto-day.html
http://jigsaw.home.well-adjusted.de/munin/home.well-adjusted.de/FHEM/index.html
Was ich nicht weiß ist, inwiefern das Ganze spezifisch für HomeMatic ist. Ich habe keine anderen Geräte und weiß nicht, ob die Readings überall gleich heißen. Ein paar Details wie das Ausfiltern von doppelt gemeldeten Temperaturen (Heizkörperthermostat gepeert an Wandthermostat, verschiedene Kanäle an einem Device, die den gleichen Wert melden) funktionieren aber ziemlich sicher nur richtig mit HomeMatic.
Ich werd wohl auch noch ein Wildcard-Plugin schreiben, mit dem man ein beliebiges Attribut rendern lassen kann. Das dürfte viele weitere einfache Fälle abdecken.
Gruß,
Jochen.
Wobei doch munin auch Werte parst .... nur eben intern.
Was meinst Du? Beziehst Du Dich darauf, dass ich betone, keine Logfiles zu parsen? -Der Unterschied dürfte in der Geschwindigkeit signifikant sein, natürlich abhängig von der Logfile-Größe. Ich bekomme von FHEM in fast allen Fällen direkt Zahlen zurückgeliefert und übergebe die Munin. Was gibt es da noch zu Parsen?
Richtig performanceoptimiert ist das alles natürlich auch nicht. Ich könnte an vielen Stellen die Werte für alle Geräte auf einmal per list anfragen. Stattdessen frage ich FHEM für jedes Gerät einzeln. Tut aber auch nicht furchbar weh, die Plugins laufen auf meinem kleinen Server (Atom D510) in deutlich unter einer Sekunde durch, auch für mehr als zehn Geräte.
Gruß,
Jochen
Doch ..... Ich mach das schon seit längerem .... Allerdings mit Cacti.
Mann sollte jedoch nicht vergessen das bei beiden Systemen die Daten zyklisch von externen Systemen gepollt werden. FHEM jedoch schreibt die Daten event-basiert.
Konkret heisst das wenn du einen Türsensor erfassen möchtest und die Aktivität unterhalb deiner Zykluszeit ist wirst du ihn nicht erfassen können.
Daher eignet sich Munin/Cacti/... Nur in solchen Fällen wo eine zeitkritische Erfassung nicht gegeben ist.
Auch monit/Cacti etc. schreiben intern "Logfiles", d.h. legen die Daten ab. Es werden dann diese Daten ausgewertet ... und da ich ein Freund von "keep it simple" bin,
Zitat von: Wernieman am 12 Januar 2016, 08:58:14
Auch monit/Cacti etc. schreiben intern "Logfiles", d.h. legen die Daten ab. Es werden dann diese Daten ausgewertet ... und da ich ein Freund von "keep it simple" bin,
Nun ja ... Logfiles würde ich das nicht nennen ... beide verwenden RRD.
Das ist wenn es um das Parsen geht deutlich einfacher und ressourcensparender.
Abgesehen davon verdichtet RRD automatisch ... was FHEM ja gar nicht macht.
Zitat von: AxelSchweiss am 12 Januar 2016, 08:44:26
Doch ..... Ich mach das schon seit längerem .... Allerdings mit Cacti.
Und, wo ist der Code? ;-)
ZitatMann sollte jedoch nicht vergessen das bei beiden Systemen die Daten zyklisch von externen Systemen gepollt werden. FHEM jedoch schreibt die Daten event-basiert.
Konkret heisst das wenn du einen Türsensor erfassen möchtest und die Aktivität unterhalb deiner Zykluszeit ist wirst du ihn nicht erfassen können.
Daher eignet sich Munin/Cacti/... Nur in solchen Fällen wo eine zeitkritische Erfassung nicht gegeben ist.
Jein. Ich habe das für den Bewegungsmelder so gelöst, dass ich die Anzahl der Events im Auswertungsintervall plotte. Verloren geht da nichts, außer wahrscheinlich beim Überlauf.
Für mich ist Munin allerdings sowieso im Wesentlichen dafür interessant, Veränderungen über längere Zeit zu sehen. Gerade beim Wetter finde ich das gut. Und in den Tagesgrafiken sieht man schön, wie träge die Heizung ist bzw. wie langsam oder schnell ein Raum auskühlt.
Zitat von: Jochen am 12 Januar 2016, 11:39:37
Und, wo ist der Code? ;-)
Es geht doch nichts über eine höfliche Bitte :-)
Ich werde das wahrscheinlich ins Wiki legen .... sobald ich meine FrickelWare etwas überarbeitet habe und mich dafür nicht mehr schämen muss.
Zitat von: Jochen am 12 Januar 2016, 11:39:37
Für mich ist Munin allerdings sowieso im Wesentlichen dafür interessant, Veränderungen über längere Zeit zu sehen. Gerade beim Wetter finde ich das gut. Und in den Tagesgrafiken sieht man schön, wie träge die Heizung ist bzw. wie langsam oder schnell ein Raum auskühlt.
Hast du da eine Wetterstation? Wie hast du das dann gemacht.
Weil wenn ich mir hier nur alle 5 Minuten die Werte hole fallen die ganzen Spitzen und Böen unter den Tisch.
Zitat von: AxelSchweiss am 12 Januar 2016, 12:19:05
Es geht doch nichts über eine höfliche Bitte :-)
Ich werde das wahrscheinlich ins Wiki legen .... sobald ich meine FrickelWare etwas überarbeitet habe und mich dafür nicht mehr schämen muss.
Kein Stress. Ich hatte auch nur "zufällig" mal Zeit und Lust, meine historisch gewachsenen Plugins releasefähig neu zu bauen.
Zitat von: AxelSchweiss am 12 Januar 2016, 12:19:05Hast du da eine Wetterstation? Wie hast du das dann gemacht.
Weil wenn ich mir hier nur alle 5 Minuten die Werte hole fallen die ganzen Spitzen und Böen unter den Tisch.
Ich habe nur Luftfeuchte und Temperatur, da gibt es keine relevanten Spitzen. Aber ja, das ist natürlich auch eine Einschränkung von diesem Ansatz. Für Munin habe ich während der Implementierung zufällig das hier gesehen, aber noch nicht ausprobiert:
http://guide.munin-monitoring.org/en/latest/plugin/supersampling.html
Um das ähnlich effizient wie die aktuellen Werte zu ermitteln, müsste FHEM mir aber auch historische Daten liefern können.
Für die Wetterstation und ihre zeitkritischen und massigen Daten habe ich vor in DBLog zu loggen.
Cacti wird dann auf diese DB (MySQL) alle 5 Minuten zugreifen und sich den kleinsten, größten und mittleren Wert dieses Intervalls holen.
(Eventuell mach ich noch die Standardabweichung mit rein)
Das gibt dann drei Kurven in einem Diagramm.
Mal sehen ob das dann eine Aussage hat oder ob das Bild dann zu verwaschen wird.
Zitat von: AxelSchweiss am 13 Januar 2016, 14:30:58
Für die Wetterstation und ihre zeitkritischen und massigen Daten habe ich vor in DBLog zu loggen.
Cacti wird dann auf diese DB (MySQL) alle 5 Minuten zugreifen und sich den kleinsten, größten und mittleren Wert dieses Intervalls holen.
(Eventuell mach ich noch die Standardabweichung mit rein)
Das gibt dann drei Kurven in einem Diagramm.
Mal sehen ob das dann eine Aussage hat oder ob das Bild dann zu verwaschen wird.
Kann ich mir gut vorstellen, dass das ok aussieht. Die Frage ist dann, wie man über größere Zeiträume aggregiert. RRDtool würde Dir für die Min/Max-Werten wieder einen Durchschnitt berechnen, das klingt nicht sinnvoll. Sinnvollerweise müsstest Du selbst für größere Zeiträume jeweils die absoluten Min/Max-Werte nehmen. Das wird nur nicht ohne Vorberechnung (wie RRDtool es macht) ordentlich performen. Da ist dann wieder Bastelarbeit.
Alles muss man selbst machen!
Die Aggregation kann man bei RRDtoll ja quasi auch ausschalten.
Die Frage ist nur wie lange will ich die Einzelwerte aufbewahren.
Aus MySQL werd ich sie nach ein bis zwei Tagen löschen.
Das Cacti läuft bei mir auch auf einem anderen Server wie FHEM. Da reicht die Performance auf jeden Fall.
Ich versuche seit 2 Tagen, die munin-Plaugins zum Laufen zu bekommen, leider erfolglos.
fhem_auto_status läuft, die anderen Plugins bringen im Update-Log den Fehler
Missing required attribute 'label' for data source
Die Data Source ist je Script unterschiedlich.
Hat sich da was geändert? Was muss ich wo anpassen, damit die munin-Scripts wieder laufen? Gibt es andere Möglichkeiten, solche Status-Graphen anzuzeigen?
Danke!
Hi,
Autor hier. Verstehe ich es richtig, dass die Plugins bei Dir bisher gar nicht funktioniert haben? Aktuelle Version von GitHub?
Die Fehlermeldung irritiert mich. Das Label der Geräte in Munin wird aus dem Device bzw. (in einigen Fällen) dem Alias gebildet. Mindestens der Devicename sollte ja immer da sein.
Schick mir gerne mehr von dem Log und vielleicht zu einem Deiner Geräte Detailinfos aus FHEM.
Gruß,
Jochen.
Hallo Jochen,
besten Dank!
Kann es sein, dass sich die Scripts daran verschlucken, dass meine Devices einen oder mehrere Punkte enthalten?
Im update Log finde ich Hinweise auf sowas...
Missing required attribute 'label' for data source 'Thermo' in service fhem_auto_battery
Die entsprechenden Geräte heissen 'Thermo.3', 'Thermo.5' und so weiter.
Missing required attribute 'label' for data source 'WallPIR' in service fhem_auto_brightness
Hier heisst das Gerät 'WallPIR.1'.
Danach kommt im Log dann jeweils so etwas:
Service fhem_auto_battery on MuninMonitor/127.0.0.1:4949 returned no data for label Thermo
Service fhem_auto_brightness on MuninMonitor/127.0.0.1:4949 returned no data for label WallPIR
Was müsste ich ändern (am Besten in den Scripts und nicht in meinen Device-Bezeichnungen), damit es funktioniert?
Besten Dank,
Stefan
Ja, Punkte in den Gerätenamen sind für Munin ein Problem, wenn das Plugin nicht vorsorgt. Hast Du die letzte Version von GitHub? Ich habe dazu gerade kürzlich einen Patch bekommen. Damit müsste das gehen. Habe es aber nicht selbst getestet.
Hi - danke für den Tip!
Ich habe mir gerade die letzte Version von GitHub geholt und kompiliert (make, make install). War davor dir 2.0.37 (aus dem Ubuntu Repository), und sollte ja jetzt eigentlich die 2.0.43 sein. Allerdings meldet munin auf der Webseite nach wie vor 2.0.37.
Auch die frisch kompilierte Version von munin-node (in node/sbin des Build-Verzeichnisses) meldet beim Start mit -v 2.0.37.
Ich bleib' da mal dran...kann ja nicht sein. :o
Wie müsste das Plugin denn vorsorgen, damit Punkt im Gerätenamen munin nicht aus dem Tritt bringen?
Das Plugin 'Desired Temperatures' liefert die Gerätenamen mit Punkten einwandfrei an munin, 'Brightness' dagegen zeigt nur zwei Geräte mit 'No .label provided' an (beide mit Punkt definiert).
Nochmal Danke,
Stefan
EDIT:
Ok, ich habe was gefunden.
In den Plugins, die die Devices mit Punkt richtig melden, finde ich
devname="$(echo "$device" | tr '[.]' '_')"
echo "${devname}.label ${device}"
statt
echo "${device}.label ${device}"
Ich habe dieses Replace in alle anderen Plugins eingebaut und devname statt device (hoffentlich) an allen Stellen richtig ersetzt.
Schau'n wir mal, noch läuft die Erzeugung der Graphs.
Ja, sorry, ich meinte auch die neueste Version meiner Plugins von GitHub, nicht von Munin. Aber Du hast die richtige Stelle gefunden. War wie gesagt ein mir zugeschickter Patch und ich hatte nicht geprüft, ob das alle Stellen korrekt behandelt.
Ich flick das mal nach. Danke für den Hinweis.
Gruß,
Jochen.