Wie Temperaturdaten über GA in eine RRD schreiben

[Michixx]

Hallo Leute,

ich benötige mal Eure Unterstützung.
Ich suche jetzt schon seit zwei Tagen in allen möglichen Quellen nach einer Lösung, aber ich finde da irgendwie nicht den richtigen Ansatz, oder ich verstehe es nicht.
Eibd, CV und linknx sind installiert, allerdings habe ich mich mit linknx noch nicht auseinander gesetzt. OS ist Debian Wheezy auf einem Raspberry.

Das RRDtool habe ich installiert, nur mir ist echt unklar wie ich jetzt die Temperaturdaten von der GA 1/0/9 in die Datenbank schreiben kann.
Die Daten sollen hinterher mit der CometVisu und dem Diagramm-Plugin angezeigt werden.

Das erstellen der Datenbank funktioniert auch.

#!/bin/bash
rrdtool create database.rrd --start N --step 300 \
DS:temp:GAUGE:600:U:U \
RRA:AVERAGE:0.5:1:12 \
RRA:AVERAGE:0.5:1:288 \
RRA:AVERAGE:0.5:12:168 \
RRA:AVERAGE:0.5:12:720 \
RRA:AVERAGE:0.5:288:365

Und hier der update database Script:

#!/bin/bash
cd /home/thomas/rrdtool
# Read temperature from sensor
tempread=`cat /home/owfs/10.4F7494010800/temperature` 
temp=`echo $tempread | cut -c -4`
# Update database
rrdtool update database.rrd N:$temp
# Create graphs
rrdtool graph temp_h.png --start -1h DEF:temp=database.rrd:temp:AVERAGE LINE1:temp#0000FF:"Temperature [deg C]"
rrdtool graph temp_d.png --start -1d DEF:temp=database.rrd:temp:AVERAGE LINE1:temp#0000FF:"Temperature [deg C]"
rrdtool graph temp_w.png --start -1w DEF:temp=database.rrd:temp:AVERAGE LINE1:temp#0000FF:"Temperature [deg C]"
rrdtool graph temp_m.png --start -1m DEF:temp=database.rrd:temp:AVERAGE LINE1:temp#0000FF:"Temperature [deg C]"
rrdtool graph temp_y.png --start -1y DEF:temp=database.rrd:temp:AVERAGE LINE1:temp#0000FF:"Temperature [deg C]"
#0000FF means blue trace color in the graphs.

Das ist ein Beispiel was ich im Netzt gefunden habe, was so auch scheinbar funktioniert.

Wie kann ich nun der Variable tempread=`cat /home/ den Wert aus der GA 1/0/9 zuweisen?
Oder habe ich da grundsätzlich einen Gedankenfehler?.

Viele Grüße
Michael

[Chris M.]

Das ist kein CometVisu Thema - dort werden nur bestehende RRDs angezeigt...

Im WireGate Forum wurde gerade eben ein Thread gelöst, der auch genau das machen wollte: https://knx-user-forum.de/forum/supp...wiregate/24844

Am einfachsten machst Du es wie dort per WireGate-Plugin.

[Michixx]

Das ist kein CometVisu Thema - dort werden nur bestehende RRDs angezeigt...

Das ist mir schon klar, nur hier gibt es scheinbar die meisten User die damit umgehen.

Im WireGate Forum wurde gerade eben ein Thread gelöst, der auch genau das machen wollte: https://knx-user-forum.de/forum/supportforen/wiregate/24844

Am einfachsten machst Du es wie dort per WireGate-Plugin.

Habe ich doch geschrieben:
Ich suche jetzt schon seit zwei Tagen in allen möglichen Quellen nach einer Lösung, aber ich finde da irgendwie nicht den richtigen Ansatz, oder ich verstehe es nicht.
Und dieser Thread ist mir bekannt, habe aber kein WireGate.
Aber lass mal nach.

Gruß
Michi

[Chris M.]

Du brauchst halt einen Deamon der auf die KNX Gas hört und beim eintreffen eines Paketes eine Aktion auslöst.

Notfalls halt nur per cron z.B. alle 5 Minuten ausführen lassen und den letzten Wert aus dem eibd-Cache lesen - nicht sonderlich smart, da nicht Event gesteuert, aber für kontinuierliches wie eine Temperatur durchaus geeignet.

Eibd-Befehl wäre hier der groupchacheread.

Übersetzten des rohen Hex-Wertes in vernüntige Zahl bleibt dem geneigten Leser als Übung überlassen

[Bodo]

Hoi

Deshalb hab' ich auch ein WG, weil ich da in einem Plugin eine Zeile eintrage und fertig.

$plugin_info{$plugname.'_cycle'} = $wg_config{''}{'rrd_interval'};

# Plugin liest Wert von KNX und legt ihn im RRD ab
update_rrd("egalwas","",knx_read("12/0/0",0,1));

Musst halt den wiregated daemon nachbauen...

[Tqm]

@ Michixx

läuft´s nun bei Dir am Raspberry Pi?
(wenn ich das richtig verstehe ist das einfach ein Perl Script welches man über einen Cron-Job regelmäßig ausführen muss ...)

[Michixx]

Ja,

das habe ich ganz einfach mit linknx und einem Bash-Skript gelöst, ist völlig easy.

Wie genau, das werde ich heute Nachmittag hier nachliefern.

PS: Hier nun wie ich es gelöst habe.

Der Temperaturwert wird nur bei Änderung der Temperatur in die Datenbank geschrieben

<objects>
    <object id="Wohnzimmer_Temperature" gad="1/0/9" type="9.xxx" flags="cwu" init="persist" log="true">Wohnzimmer_Temperature</object>
</objects>
 
<rule id="Wohnzimmer_TEMP_LOG">
   <condition type="object" id="Wohnzimmer_Temperature" trigger="true" />
   <actionlist type="if-true">
       <action type="shell-cmd" cmd="/home/rrdtool/update_database_wz.sh"/>
   </actionlist>
</rule>

linknk ruft dann das Bash-Skript "update_database_wz.sh" auf und schreibt die Werte in die Datenbank

#!/bin/bash
cd /home/rrdtool
# Read temperature from sensor
 
tempread=`cat /var/lib/linknx/Wohnzimmer_Temperature` 
temp=`echo $tempread | cut -c -4`
# Update database
rrdtool update database_wz.rrd N:$temp

Gruß
Michael

[Tqm]

@Michael

Besten Dank - funktioniert einwandfrei

[makki]

Nur der Vollständigkeit halber: bei Werten aus dem WG ist das nicht nötig und bei "fremden" ganz einfach via Plugin:
SourceForge.net Repository - [openautomation] Contents of /wiregate/plugin/generic/rrd_graph.pl

Makki

[lobo]

Hallo,

Michixxs Lösung hat den Charme, dass die Werte direkt beim Senden auf den Bus auch als RRDs geschrieben werden (also quasi KNX-like eventgetriggert).

Das PL im Wiregate (funktioniert sehr gut - habe ich auch derzeit im Einsatz) speichert nur den letzten gesendeten Wert. Damit könnten ggf. wichtige Zwischenwerte verloren gehen.

Ich denke, es gibt gute Gründe, das Eine oder Andere zu verwenden (je nach Anforderung).

Viele Grüße,

Stefan

[JuMi2006]

Ein paar Anmerkungen noch dazu .. weils eben dazugehört

Michixxs Lösung hat den Charme, dass die Werte direkt beim Senden auf den Bus auch als RRDs geschrieben werden (also quasi KNX-like eventgetriggert).

Kling erstmal ganz nett aber nur teilweise wirklich sinnvoll. Kommt nämlich über den im RRD angegeben "heartbeat" kein Telegramm rein so wird dieser step als verloren und mit NaN beschrieben.

Das PL im Wiregate (funktioniert sehr gut - habe ich auch derzeit im Einsatz) speichert nur den letzten gesendeten Wert. Damit könnten ggf. wichtige Zwischenwerte verloren gehen.

Damit ist aber sichergestellt dass das RRD überhaupt korrekt befüllt wird.
Zwischenwerte nimmt das rrdtool aber eh nicht auf ... dort ist irgendwo beim anlegen eines RRDs ein "step" definiert worden. Kommen innerhalb dieses steps mehrere Werte rein bildet rrdtool da ganz einfach nen Mittelwert.

Ich denke, es gibt gute Gründe, das Eine oder Andere zu verwenden (je nach Anforderung).

Sicherlich! Wobei man auf 2 Sachen achten sollte:

Alles was innerhalb des im RRD definierten "step" reinkommt wird einfach auf einen Mittelwert vereinfacht. Dieser wird dann zum Zeitpunkt x als Datenpunkt/Zeile im RRD geschrieben.

Man muss schon dafür Sorge tragen dass überhaupt ein Wert innerhalb von "heartbeat" geschrieben wird. Sonst gibt es da einfach eine Lücke.

Grüße

[Michixx]

Man muss schon dafür Sorge tragen dass überhaupt ein Wert innerhalb von "heartbeat" geschrieben wird. Sonst gibt es da einfach eine Lücke.

Das ist mir am Anfang auch aufgefallen und deshalb muß man den Wert halt entsprechend hoch ansetzen.
Und es ist für mich auch erst einmal nur eine Zwischenlösung, mit der kann ich aber sehr gut leben.
Im Anhang kann man es auch sehen, es sind keine Lücken vorhanden.

[lobo]

Mirko, zunächst mal danke für den Hinweis. Ich habe das noch nicht weiter verfolgt, da ich mich gerade so ein wenig in die aktuelle SVN der CV einarbeite.

Ich hätte 2 konkrete Anwendungsfälle, wo ich gerne möglichst exakte Infos haben würde:

1. Defekt eines Temperaturfühlers:
An meinem BJ Raumpanel rauscht der Temperaturfühler leider erheblich. Der sendet auch gerne mal alle paar Sekunden einen neuen Wert. Im Mittel stimmts - daher habe ich mich nicht näher damit beschäftigt, aber wenn hätte ich gerne im Anschluß auch gesehen, ob es besser geworden ist.

2. Exaktes Monitoring der Beschattung:
"Schaaaatz, warum ist gestern die Jalousie nicht hochgegangen - es war doch schon eine Zeit lang bewölkt". Dieser Fragestellung kann ich nur nachgehen, wenn ich wirklich gut zeitaufgelöste Infos bekomme (über die Jalousien, die Aussenhelligkeit, Azimut, Elevation, Innentemperatur bzw. Stellgröße der Heizung). Das mache ich derzeit im Zweifelsfall sehr umständlich über die Logging-Dateien (log="true" in Linknx). Das Format ist nur so schrottig, dass ich lage brauche, bis ich alles zusammen habe.

Das Meiste könnte man hier IMHO zumindest über ein zyklisches Senden abfangen - oder? Was passiert denn, wenn der Wert nicht mehr gültig ist? Beispiel: Nach mehreren Tagen geht die Schattierung eines Fensters auf "1"?

Viele Grüße,

Stefan

[JuMi2006]

@lobo:

Da hilft es eigentlich nur die RRD manuell zu erstellen und im entsprechend kurzen Zyklus zu füllen.
Da hilft es dann aber nur sich durch die Doku vom rrdtool zu kämpfen...zu testen...anzupassen.
Für so ein Event getriggertes Monitoring ist rrdtool eigentlich weniger geeignet. Ein paar Klartext-Logs (Linknx -> shell/Perl/php-Script) sind da eher zielführender wenn es um temporäre Probleme geht.

RRDtool - rrdcreate

RRDtool - RRDtool Documentation

[lobo]

Ein paar Klartext-Logs (Linknx -> shell/Perl/php-Script) sind da eher zielführender wenn es um temporäre Probleme geht.

Wahrscheinlich hast Du recht ... das Beste wäre es, über einen Cron-Job ein mal am Tag die wichtigsten Daten in eine CSV-Datei so zu konvertieren, dass man damit auch was anfangen kann.

Viele Grüße,

Stefan