Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Nun, wiegesagt: es ist nur ein eine Zeile im rrdfetch(.sh) notwendig und vielleicht 3-5 Zeilen im diagram-plugin der CV. eine kleine Weiche um zischen fetchj (liefert ein array) und "xport --json" zu unterscheiden - ist alles GPL, es wird niemand davon abgehalten, es einfach umzusetzen
Makki
P.S: damals gabs das im RRDtool nicht, also war die wahl zwischen nichts und "geht" - ich hab das nicht gerne gepatched! Zwei Tage messen.. Also xport ging damals halt ganicht, weil fetch war das richtige (ich kenne das rrdtool seit es das gibt, also eher altes Jahrtausend..)
Hallo Makki,
ich hatte es ja schon gesagt, es soll sich hier keiner auf den Schlips getreten fühlen (was ich mir von Dir auch nicht vorstellen kann).
Du hast hier großes geleistet und beigetragen, ich sehe es auch so, ich möchte meine HW auch nicht ständig aufrüsten, nur weil jemand meint, er muß schlampig programmieren.
Ich finde es halt nur etwas unglücklich implantiert, aber nun ist es so und lässt sich nicht ändern.
Und noch meine 5ct dazu:
ich wollte das nie so, es war halt nur so das es keine akzeptable, performante Alternative gab und daher der JSON-Output des rrdtool vom CV-Team forciert wurde, um zeitnah eine Lösung zu erreichen.
(Viel) Später wurde es im rrdtool u.a. auf unsere Initiative hin - jedoch anders - implementiert..
Das rrdtool 1.3 lässt sich indeed z.B. unter Ubuntu 12.10 nicht mehr bauen, weil irgendein nutzloser Ruby1.9 vs 1.9.1-käse auf die Nase fällt
Nachdem das halbe packaging auch daraus besteht, Ruby- und Python-bindings mit Gewalt per Hand zu bauen wollte es mir auf die schnelle nicht gelingen, das da einfach mal rauszuwerfen.
Ist aber eh keine Lösung..
Ich hab mit 1.4.7 nochmal getestet, aufm core i7 spielts natürlich erwartungsgemäss keine Rolle, das "xport --json" wurde auch wohl nochmal geändert und liefert nun wirklich auch mal sinnvolle daten (keinen dump).. es ist langsamer aber erträglich und mir ja reichlich wurscht.
-> das beste wäre
1) im diagram-plugin eine Weiche einzubauen (das fetchj ist ein array, xport ein object, sieht halt nur komplett anders aus und entspricht nicht dem was flot erwartet, müsste man also vorher umwandeln)
2) den alten Quickhack soweit anzupassen, das es wie "xport --json" ausieht und im rrdfetch (.sh) zu unterscheiden
-> Kann gern jemand machen, steht bei mir aber nicht unter den Top100 auf der Prio-Liste
Was mich an dem ganzen am meisten ärgert ist das, dass man auf die alte Version 1.3.1 (die dann auch noch gefrickelt ist) für die CV angewiesen ist.
Und das ganze nur um einige ms. einzusparen.
Hat die neue Version Feature/behobene Bug/... das Du dringend brauchst?
Ein paar ms können auf die Dauer schon viele ms werden. Und auf schwacher Hardware um so schlimmer.
Wenn die Dir egal sind, dann schau noch mal im Forum, irgendwo gab's einen Thread wie man das auf der "verschwenderischen" Version aufsetzen kann.
Aber die CV war ja auch für das HW WireGate gedacht. Ich frage mich nur, ob alle ein WireGate benutzen, oder ich der einzige Super-Dau hier bin.
Weil scheinbar keiner ein Problem damit gehabt hat, das rrdtool 1.3.1 zu installieren, oder benutzen sonst alle die CV ohne Graphen?
Ich nutze das original WireGate - gerade um mich um solche Details nicht kümmern zu müssen. Da ist mir meine Zeit zu schade zu. Lieber bringe ich die CV weiter. Ich bin ja auch kein Administrator, eher noch Programmierer.
Die CV ist sicher nicht schlecht, sonst hätte ich mich damit auch nicht auseinandergesetzt, aber da liegen für den nicht Hardcore User doch noch zu viele Steine im Weg.
Der Nicht Hardcore-User verwendet ein fertiges System.
Wer sich selber eines aufsetzen will und kann, der bekommt bei Google und hier hoffentlich den ausreichenden Support dafür. Ein Selbstläufer wird das aber natürlich nicht sein - ohne grundlegendes Systemverständnis ist's halt immer steinig. Egal bei welcher Software.
Ein fehlendes gettext würde ich da unter der Kategorie Google einsortieren.
konnte ich aus dem WireGate repository die Files laden, aber viel weiter bin ich damit auch nicht gekommen.
Beim kompilieren ohne Parameter (./configure), fehlte zum Schluss noch das gettext tools.
Das bricht aber beim Installieren mit der aussagekräftigen Fehlermeldung "Abbruch" ab.
Ich glaube auch nicht, dass gettext unbedingt benötigt wird.
Für mich selber habe ich erst mal als unschöne Übergangslösung, das Image Widget genommen, da push ich alle 5 Minuten ein png rein, mit der aktuellen Version vom rrdtool.
Was mich an dem ganzen am meisten ärgert ist das, dass man auf die alte Version 1.3.1 (die dann auch noch gefrickelt ist) für die CV angewiesen ist.
Und das ganze nur um einige ms. einzusparen.
Wenn einige meinen, sie benötigen 40-50 Graphen in ihrer Visu, dann sollen sie sich doch bitte eine Leitwarte wie im AKN in ihren Keller bauen.
Die benötigte Rechenleistung dafür, die bekommt man beim Max-Planck-Institut zum mieten, ja die machen das.
Aber die CV war ja auch für das HW WireGate gedacht. Ich frage mich nur, ob alle ein WireGate benutzen, oder ich der einzige Super-Dau hier bin.
Weil scheinbar keiner ein Problem damit gehabt hat, das rrdtool 1.3.1 zu installieren, oder benutzen sonst alle die CV ohne Graphen?
Die CV ist sicher nicht schlecht, sonst hätte ich mich damit auch nicht auseinandergesetzt, aber da liegen für den nicht Hardcore User doch noch zu viele Steine im Weg.
Es soll sich auch keiner auf den Schlips getreten fühlen.
Ob ich das noch weiterverfolge, weiß ich nicht. Bei Smarthome.py, tut sich nun ja auch was ganz interessantes.
So, das waren meine 5 Cent.
Wer mich noch unterstützen möchte, oder eine Idee hat, dann geht es hier weiter.
Nicht dass ich zu faul wäre zum suchen, aber wenn ich irgendwann nicht mehr weiter weiß, dann muss ich halt fragen.
Könnte mir das einer vielleicht mal vorkauen, ich komme da echt nicht weiter.
Ich habe da halt noch nicht so die großen Linux Kenntnisse.
Und wenn es hier in diesem Forum nicht passt, dann möge man mir bitte sagen wo ich es sonst posten soll.
ACHTUNG und schonmal sorry!
Das rrdtool ist gepatched (ich möchte es keinen Fork nennen, weil das ist&war nie die absicht)
Aber es muss rrdfetch (.sh) geben und fetchj im rrdtool
-> Kann man in/aus /etc/apt/sources.list
Code:
# WireGate repository
deb http://repo.wiregate.de/wiregate wiregate-0.1 main
deb-src http://repo.wiregate.de/wiregate wiregate-0.1 main
holen und bauen (geht unter lenny, squeeze, wheezy und auch allen ubuntus plug&play!..)
Das Problem ist, das das aktuelle rrdtool mit der libcairo (oder wie auch immer der übeltäter heisst) Faktor 4-10(!) langsamer ist - und das kann ich nicht brauchen, das ist indiskutabel!
Es gibt Leute, die kaufen sich wenn die Software ineffzienter wird einfach 8 statt 4 Kerne und stecken 8 statt 2 GB RAM rein, diesem schwachsinnigen Prinzip mag ich aber nicht folgen Und das kann&will ich auch keinem Kunden mit vorh. HW erklären..
Das neue rrdtool hat allerdings einen (Faktor 5-20 langsameren, falschen [dump statt fetch]!) JSON-output, wo man nur das script anpassen müsste - finde ich aber auch inakzeptabel, weil meine Prio ist nunmal die CV, nicht die grösstmögliche ineffizienz des rrdtools wegen der Verwendung schlechter Libs
bei mir funktioniert das Diagram_Inline Plugin nicht, da steht immer nur loading.
Ich habe mir hier auch schon alle Threads angesehen, aber nur rausgefunden dass, das rrd-file unter var/www/rrd liegen soll, das liegt da auch.
Und wenn ich bei label einen Text eingebe, meldet mir Check_Config immer, config visu_config is NOT valid XML.
Ohne Text bei label ist alles OK nur steht immer loading.
Als OS ist Debian Wheezy im Einsatz, CV ist Release 0.6.2 und RRDTool ist V 1.4.3
Und ja, Daten werden in das rrd-file geschrieben. Ist vielleicht das RRDToll nicht die richtige Version?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
.
Einen Kommentar schreiben: