- √ - RRD Files sind plattformabhängig

[greentux]

Glaub ich Dir sogar. Die haben aber keine CV und Co am laufen, sondern kommen mit dem WG selbst gut klar.
Es geht hier ja um Crossplattform.

[JuMi2006]

Also ich teste gerade rrdcached ...
Ich bin da begeistert und sehe das weder (in der Doku) irgendwelche Festplattenaktivitäten noch Last-Probleme (in Live).

Das läuft jetzt zwar von Pi zu Pi ... aber im Grunde je egal. Hier mal eines der längsten Plugins der Welt.

# return;
# rrdcached - alpha
# start rrdcached on remote for example: rrdcached -l 192.168.2.35:88
# GPL - JuMi2006 - https://knx-user-forum.de
# 2013-03-18


use Net::Telnet;
my ($value,$cmd,@rrds,$answer);

### Definitionen 
my $debug = 1;
my $rrd_server = '192.168.2.35';
my $rrd_port = '88';

# Eigenen Aufruf-Zyklus setzen
$plugin_info{$plugname.'_cycle'} = 240;

# RRDs
# rrd_name is path on REMOTE-System
push @rrds,{ga => "8/6/42", dpt => "9", rrd_name => "/var/www/rrd/eBus_mv_brine_in_temp.rrd"};
push @rrds,{ga => "8/6/41", dpt => "9", rrd_name => "/var/www/rrd/eBus_mv_brine_out_temp.rrd"};

### Definitionen Ende

### MAIN ### real long code

foreach my $rrd (@rrds){
$value = knx_read($rrd->{ga},0,$rrd->{dpt});
$cmd = "UPDATE ".$rrd->{rrd_name}." ".int(time()).":".$value;
send_rrd ($cmd);
}

sub send_rrd{
    my $cmd = shift;
    my $t = new Net::Telnet (Timeout => 3,
                    port => $rrd_port,
                    Prompt => '/\n/');
    $t->open($rrd_server);
    if ($debug){plugin_log($plugname,"Sende:$cmd")};
    $t->cmd($cmd)
    $t->close;
    eval { close $t; };undef $t;
}

[greentux]

Jetzt wäre es interessant, ob das tatsächlich das Problem:
32 -> 64 Bit
arm -> i386
löst...
Meinste das geht?
Falls ja, würde ich mir wünschen, das das WG demnächst im Webmin die Möglichkeit bietet, das remote wegzuschreiben.
In den Plugins nützt es ja nicht den ganzen 1wire Sensoren (oder wäre doppelt)...

[JuMi2006]

Man könnte das locker im wiregated einbauen. Plattformen sollten egal sein. Du übergibst dem rrdcached ein "UPDATE /pfad/zum/rrd/name.rrd timestamp:value"

Problem:
rrdcached kann keine rrds erstellen (zumindest schweigt sich die Doku dazu aus). Kann man zwar wiederum über ein Script lösen, wäre aber auch nicht so elegant.

EDIT: Mit "locker" meinte ich die Geschichte im wiregated.pl - das Webmin ist ne andere Baustelle.

[greentux]

1.5 kann create und anderes auch via rrdcached...
ist aber immer noch beta.

[JuMi2006]

och nee ... nicht schon wieder dpkg-buildpackage
So langsam kann ich rrdtool nicht mehr sehen ... wäre aber mal ein interessanter Versuch.

[greentux]

Bin ich dafür... aber dann auch für 32 und 64 Bit i386, damit man die rrd-Sammlung auf den "alten" 32 Bit Systemen los wird

[JuMi2006]

Für das WireGate und armhf/armel würde ich mich ja noch breitschlagen lassen ... aber nicht heute oder morgen. Dann auch gleich incl. fetchj patch.

Die anderen darfst Du gerne übernehmen . Die Build-Umgebung fürs rrdtool gleicht (gefühlt) der Hälfte eines offiziellen Debian-Repos.

P.S. + O.T:
Hutschiene wurde heute endlich mal etikettiert. Ich hoffe die morgen mal in die Post zu geben.
Des weiteren teste ich gerade einen aus der Firma geliehen billig RGB-Stripe. Sieht ganz gut aus, nur das WW fehlt irgendwie doch.

[greentux]

Mal wieder hochholend als Feature Request für die Unterstützung eines remote rrdcached. WG sollte diesen mit Daten versorgen können.

[makki]

Ehrlich, für was? Ein Leistungsfähiges (und Stromhungriges) anderes System kann sich die RRDs auch einfach direkt selber wegschreiben (?)

Makki

[greentux]

Und wie bekommt es die 1Wire Daten vom WG?
Per owserver Anfrage?
Ich hielte es zielführender, nicht gleich ganz unten anzusetzen, sondern in der Applikation.

[JuMi2006]

Das ist echt nett nur hab ich das Problem das mit 1.4x das graphen Faktor X (um keine angreifbare zahl zu liefern) langsamer ist..
Und das spielt bei ein paar dutzend Grafiken in meinem Haus durchaus eine Rolle, ob die Visu 3 oder 300 Sekunden zum laden braucht

Eher für mich als Erinnerungs- und Wiederfindungshilfe für das Erstellen von Grafiken

Erstellen einer Grafik:

time rrdtool graph graph-example1.png --start=-3h --end=now DEF:ds0=knxd_mem.rrd:value:AVERAGE LINE1:ds0#FF0000:knxd_mem.rrd

gerundete Werte (Ausreisser gibt es eher nach oben)
1.3.1: real 0.370 Sekunden
1.4.7: real 0.470 Sekunden

time rrdtool fetch knxd_mem.rrd AVERAGE -s-200h -r300

gerundete Werte (Ausreisser gibt es eher nach oben)
1.3.1: real 0.210 Sekunden
1.4.7: real 0.270 Sekunden

Zugegeben ist die 1.3.1 da klar im Vorteil.

Solange es für rrdtool-1.5 kein Release gibt lass ich es erstmal sein.
Da sind mir der Aufwand und die Ungewissheiten zu groß. Wie verhält sich ein "CREATE" beim rrdcached-> wird überschrieben, wer übernimmt das handling u.s.w..
Der Gedanke hinter dem rrdcached ist eigentlich gut, aber vielleicht gibt es wirklich mal plattformunabhängige RRDs, das kann eigentlich nur das Ziel sein.

[makki]

Nur eine Randnotiz: der CREATE spielt ja keine Rolle, das ist einmalig, ob das eine oder 100sek. dauert ist relativ wurscht..
Und der rrdached ist gut - auf Ultracores mit TB an RAM ja kein Thema, hamma aber ned

Das Problem ist AFAIK die grafik-library (zuletzt Pango glaub ich, 30% langsamer kommt in etwa hin), die halt unbrauchbar a***langsam ist; ich bin nicht bereit mir für dieselbe Grafik, keinen Millimeter höher/weiter/schöner/schneller ohne Not ne neue HW anzuschaffen, nur weils offenbar ineffizienter programmiert wurde - oder dolle 64Bits hat.
Der Weg der Wahl ist wie immer: KNX! da kommen die Werte, aufzeichnen, fertig, oder?

Makki

[JuMi2006]

Ergänzend:
Der rrdcached braucht weder Octacore noch TerraByte ... der läuft auch ganz unauffällig auf dem verpöhnten Pi.

Ansonsten sind mir die Grafiken egal, das macht doch die CV . Wenn ich sie doch mal woander brauche (drraw,graph.pl) würde ich auch ne Sekunde warten.

[greentux]

Ich hab auch nur nen Dualcore mit 4 GB... Und würde gern das WG weiterhin als das betreiben, was es kann, nämlich 1wire.

Jetzt weiss ich jedenfalls wie Makki sich fühlt, wenn er auf der owfs-Liste Ideen angefragt hatt und diese nicht ernst genommen werden...