[WireGate-Plugin] Grafiken erstellen (Datenarchiv)

[makki]

Beispiel für die Erstellung von Wertarchiven für Grafiken

# Demo-Plugin Grafiken in RRD speichern
# V1.0 2010-03-19

# Eigenen Aufruf-Zyklus auf 300 Sekunden (Default globales RRD-Intervall) setzen
$plugin_info{$plugname.'_cycle'} = $wg_config{''}{'rrd_interval'};

# Luftfeuchte Bad

# Einen Wert der Luftfeuchte von der Gruppenadresse 5/2/79 in einem rrd speichern
# Luftfeuchte_Bad ist ein beliebiger Text; keine Umlaute oder Sonderzeichen (/\: etc)
# und einmalig!
# Dann wird die Funktion knx_read mit der Gruppenadresse aufgerufen, 
# hier max. 300 sek alt
# sonst wird ein Lesetelegramm abgesetzt und die Antwort abgewartet
# DPT5 = 1 Byte 0-100%, zwei Möglichkeiten:
# DPT angeben wie unten oder Gruppenadressen aus der ETS importieren, dann kann der Datentyp entfallen
update_rrd("Luftfeuchte_Bad","",knx_read("5/2/79",300,5));  # Gruppenadresse, maxAlter, DPT

# Beispiel für Temperaturwert (DPT9/EIS5) von "externem" Sensor
update_rrd("Temp_Kueche","",knx_read("3/1/46",300,9));

# Abgerufen können die Grafiken durch Modifikation der Grafik-URL eines vorhandenen 
# 1-Wire Sensors werden: z.B. 28.0D22CB010000_temp.rrd im letzten Beispiel durch
# Temp_Kueche.rrd ersetzen. Gross/Kleinschreibung beachten!

# Wenn etwas im Plugin-Log stehen soll, kommentarzeichen # entfernen
# Ideal auch zur Debug-Ausgabe
#return "Graphen wurden aktualisiert"; 
#Sonst 0 = Alles Ok, kein Logeintrag
return 0;

[marlan99]

Wahnsinn !!

auf diese beiden Plug-Ins habe ich gewartet. Eingefügt und funktioniert.

Yippie !!

[makki]

Ich bin doch mit dem "Erklärungs-Posting" noch garnicht fertig

Makki

[marlan99]

Tja du dokumentierst den Code zu gut ;-)

und die paar Zeilen waren einfach zu verlockend auch gleich auszuprobieren.
Grafik mit externen Sensoren ist integriert und läuft, der PI regler bin ich am testen. Hab ja auch noch einen Bug irgendwo in meiner 1-Wire verkabelung (gemäss separatem Thread).

Gruss
Marcel

[Chris M.]

Schön ist, dass ich in einem Plugin gleich mehrere Werte verwursten kann.

Kann ich nun dieses Plugin an mehrere Adressen (nämlich allen zu loggenden) anmelden und dafür sorgen, dass nur der jeweils geschickte Wert aufgezeichnet wird? (Wie?)

Ich glaube, das wäre eine Erweiterung, die auch andere interessiert...

PS: Würde es nicht Sinn machen, alle KNX-Botschaften pauschal mit RRD zu loggen? (Oder wird das dann zu groß?)

[makki]

Kann ich nun dieses Plugin an mehrere Adressen (nämlich allen zu loggenden) anmelden und dafür sorgen, dass nur der jeweils geschickte Wert aufgezeichnet wird? (Wie?)

Hier wird ja nicht an Gruppenadressen "angemeldet" (siehe andere Plugins, $plugin_subscribe, das geht für beliebig viele..) sondern nur zyklisch alle 300s aufgerufen.
Das tut es in dem Fall auch am besten, denn ein Update unter 300s bringt bei der voreingestellten Auflösung des RRDs eh nichts.
Die Werte werden entweder zyklisch auf den KNX geschrieben oder dann aktuell per Lesetelegramm angefordert, wenn Alter im eibd-Cache (hier 300 sek) grösser ist.

Aber auch das subscriben wäre möglich, natürlich auch mehrerer, wenn man da einen konkreten Anwendungsfall hat oder sieht! Ich freue mich über Anregungen, updates oder neue Code-Schnipsel

PS: Würde es nicht Sinn machen, alle KNX-Botschaften pauschal mit RRD zu loggen? (Oder wird das dann zu groß?)

Kurz rechnen: 400 GA (bei mir) x 372kB = ~150 MB; 1,8GB frei: geht
Halte ich Standardmässig zwar für leicht übertrieben aber nun, dafür sind die Plugins gemacht, auch das kann man tun (vielleicht in 20/50er-Päckchen aufteilen)

(Wenn man die Daten jetzt nicht Standardmässig 15 Jahre(!) verdichtet aufhebt liesse sich das grössenmässig sogar noch deutlich optimieren..)

Makki

[ThorstenGehrig]

Hi
Die Werte die ich speichern will kann ich vermutlich nicht lesen - wenn ich richtig informiertt bin wirft die wärmepumpe die konfigurierten Werte regelmäßig auf den Bus.
Klappt das dann trotzdem mit dem Knx_Read oder muss ich das anders machen...?
Da mein WG auf der Baustelle steht ist try&error unpraktisch...

Gruß
Thorsten

[makki]

Das sollte kein Problem sein, bzw ist es IMHO sowieso besser - weil erheblich schneller und weniger Buslast - die Werte aus dem Cache zu nehmen und die Geräte passend zyklisch senden zu lassen.

Ergo
knx_read("z/y/x",<MAXALTER>,<DPT>)
also z.B. für einen DPT9/EIS5-Wert
knx_read("z/y/x",3600,"9")

Dann wird nur vom Bus gelesen (sendet Lesetelegramm auf die GA und wartet auf Antwort), falls der Wert der Gruppenadresse nicht innerhalb der letzten Stunde (3600 Sek.) auf dem Bus "aufgetaucht" ist (egal ob als Write oder Read->Response)
Ausser nach einem Restart (des eibd), da ist der Cache natürlich erstmal leer, deswegen sollten die Gruppenadressen natürlich trotzdem auch zusätzlich lesbar sein (Lesen-Flag in der ETS gesetzt).

Makki

[greentux]

Problem ist, das hier die globalen RRD Settings nicht genutzt werden. Die RRDs werden mithin also mit den defaults angelegt.
Das müsste im wiregated.pl geändert werden. Alternativ kann man den "Sensor" KNX auch in die owsensors.conf eintragen, was vermutlich aber anderswo Ärger macht.

[emax]

Es sind ja nur ein paar Zeilen, trotzdem: Ist das die neueste Version? Nicht das mir da irgendeine Genialtät entgeht ;-)

Im SVN-Tree auf meinem Rechner finde ich das jedenfalls nicht.

[makki]

Ja und Nein; Danke für den Hinweis:
War nicht im SVN, nachgeholt..
Sollte sich was ändern nehme ich das dann aus dem ersten Post raus, aktuell ist also immer SVN (die Idee mit SVN entstand erst später..)

Makki

[greentux]

Frage: Für das dann neuangelegte rrd pro Wert werden die Daten genommen, die auf der Webmin Sensors Seite ganz unten eingetragen sind?
Ich habe dort ein paar Anpassungen vorgenommen und möchte, das auch die KNX Werte mit gleicher Auflösung gespeichert werden.

[greentux]

Weiterhin hätte ich gern COUNTER statt GAUGE... der Aufruf im wiregated.pl gibts ja irgendwie her. Nur wie korrespondiert das mit dem Plugin hier?

[makki]

Da ist glatt ein bisschen der Käfer drin: Für neue Sensoren, werden im Webif hartcodierte Werte eingesetzt (aber letztlich nicht verwendet bevor gespeichert), nicht das globale als Default.

Nachdem der wiregated.pl bis dahin aber das RRD schon neu angelegt hat stimmts dann trotzdem: für neue Sensoren gilt dort der globale als Default. Die Anzeige im Webif über die RRA's stimmt dann nicht mit der Realität überein.
Wird geändert, zusätzlich fiel mir gerade gerade ein "Info" Button als sinnvoll ein, wo man einfach nachsehen kann (analog rrdtool info nur in hübsch&Verständlich )

COUNTER (bzw. alles andere wie DERIVE usw auch) geht, muss man update_rrd nur beim anlegen als 4. Parameter mitgeben. Beim späteren befüllen spielt das keine Rolle..

Bei "komplexen" RRD's kann es sich aber auch definitiv einfacher gestalten, gleich das anlegen im Plugin einmalig selbst zu machen; es gibt ja noch mehr: min/max, interval (step, der wichtigste Parameter, der sagt was die Reihen für eine Zeiteinheit haben, da wird bei neuen immer der globale genommen usw... )

Das ganze rrdtool zu abstrahieren soll eigentlich garnicht Ziel sein, geht auch kaum, wenn man bestimmte Sonderwünsche hat kopiert man sich zum erstellen des RRD's das (RRDs::create(..) einfach aus wiregated.pl. Das ist auch schon dokumentiert

Makki

[greentux]

Ok, verstanden. Es gibt doch aber nur eine Funktion, die rrd_update heißt oder? Vermutlich legt die an, wenns noch nicht da ist? So habe ich das Plugin verstanden.
Oder kann ich irgendwie das rrd auch extra anlegen?