Modifikationen an eibd und rrdtool upstream?

[Chris M.]

Was ich mir wünschen würde, wäre mehrere RRDs gleichzeitig abfragen zu können. Das würde eine sehr saubere Lösung für https://github.com/CometVisu/CometVisu/issues/244 ermöglichen mit minimaler Request-Anzahl erlauben.

Egal wie man es löst, wichtig ist, dass des rasend schnell ist. (Ich glaube das war damals mit ein Grund für die Implementierung des Patches)

[MGK]

ich würde es aber auch für eine WIRKLICH gute Idee halten das Diagramm-Widget auf die RRD-Standard xml-xport umstellen! Es stehen ja eh einige Änderungen/rebuild an, würde das nicht Sinn machen?

was hat das wiregate für eine Version von RRDtool derzeit, kann das xml xport?

das script auf der Doku-Seite läuft grundsätzlich (hatte das noch etwas korrigiert), dauert aber recht lange und kann nur mitt RRD files mit nur einer Datenquelle umgehen... ich habe das für 2/3 mal erweitert, baue das noch um für beliebig viele und poste ich mal in der Doku.

Gruss,
Michael

[peuter]

Also mit OpenHAB kannst du auch die eingebaute rrd-persistenzschicht nutzen und dessen Daten in der CV darstellen

[Brn]

Hallo,

ich bin vom CV wiki auf diese Seite gekommen und wollte mal nachfragen, ob nun - knapp 3 Jahre später - die hier aufgeführte Anleitung: http://www.cometvisu.org/wiki/CometV...ion/RRDtool/en .... noch immer der einzige Weg ist, CV mit Graphen zu versorgen. Bei mir soll CometVisu auf einem Raspberry Pi laufen, der ebenfalls noch openhab beherbergt. Also der fällt dann eher unter die Kategorie "nicht so leistungsstark".

Die auf der Wiki-Seite dargestellte Lösung erscheint mir eher wie ein Workaround, weniger als eine Angestrebte Installationsanleitung.

Und: kann man rddtool auch nachschieben? Oder sollte das am best


Danke und viele Grüße.


//Edit: würde vielleicht einfach die Installation vom Raspbian Paket php5-rrd ausreichen?

[henfri]

Hallo,

na, mich interessiert auch nicht die Größe ;-)
Sondern ob der Status eines Schalters sofort übernommen wird, wenn du ihn via KNX Taster drückst&co.

Also die Echtzeitfähigkeit. Das ist ja unabhängig vom Umfang der Visu.

Gruß,
Hendrik

[greentux]

Ich mache eher nur überschaubare Sachen, also keine fancy Männerviso. Bei mir gibts ne Seite mit Klimadaten im Haus, ne Seite mit ein paar Szenen, eine mit dem Wetter und das wars derzeit auch schon.
Komischerweise reicht das allen...

[henfri]

Hehe. Das kenn ich (beides).

Wie verhält sich denn die SmartVisu im Vergleich zur CV. Ich bin noch nicht so weit. Ich las vor einiger Zeit, dass die Geschwindigkeit (polling) schlechter sei.
Hast du schon Erfahrung? Ich glaube, da hat sich einiges getan, oder?

Gruß,
Hendrik

[greentux]

Leider nein. Der Garten fordert seinen Tribut. Ausserdem bin ich schon zur Hälfte zur sh.py gewechselt...

[henfri]

Hallo Greentux,

gibt es dazu schon was neues?

Gruß,
Hendrik

[henfri]

Super, das freut mich. Ich bin gespannt!

[greentux]

henfri, ich glaube wir haben das jetzt. ich versuche mich da zu kümmern.
allerdings muss ich dazu im büro sein
dann wäre zu klären was einfacher ist.
xport oder ein fetch / fetchj proxy, sprache.

[henfri]

Hallo,

ich wollte hierzu gerade einen Bug auf machen, damit dies nicht verloren geht.
Aber SF mag nicht und sagt: xsrf-attempt detected.

Vielleicht kann jemand anders es eintragen:

Currently it is not at all easy to setup the backend for CV.

It seems, that a patched eibd and rrdtool are needed. 
But in fact this is not the case: Just some tools using eibd (eibread-cgi and eibwrite-cgi) are needed. Also, not a hand-selected version of rrdtool is neccessary, when just using the latest version, but accepting a lower performance. See:https://knx-user-forum.de/cometvisu/24165-modifikationen-eibd-und-rrdtool-upstream-new-post.html

I would suggest providing the needed files:
eibread-cgi.c
eibwrite-cgi.c
Makefiles/configure.sh

as well as the rrdfetch-script (I think it is).

Maybe together with a simple install-script (maybe asking for the path of the cgi-bin and then creating the links)

Greetings,
Hendrik

Gruß,
Hendrik

[greentux]

Vl. geht ja schon mehr als gedacht.
Makki Du sagst, Dein eibd-client Paket könnte alles.

Wenn ich aber ein "apt-get source eibd-clients" mache, bekomme ich auch nur wieder das gesamte bcusdk geliefert. Wenns da jetzt einen "./configure --cv-clients-only" gäbe, wäre die Welt schon fast in Ordnung. Ggf. gibts das ja und ich sehe es nur nicht.
Vl. kannst Du da etwas Lich reinbringen.

[ctr]

eibd-clients geht echt einfacher, mein Packerl lässt sich von OpenWRT über Dreambox bis Ubuntu 12.10/64 Warnungs-frei bauen (und entspricht v0.0.5, ich hab das absichtlich darunter gehalten, damit es keine Konflikte gibt!).. Wenn mans lieber gern auf die harte Tour mit Makefile-patchen hat, ok, kann man das .changes nehmen
...

Natürlich kann man das hinbiegen aber - mal böse gesagt - mich bezahlt niemand für, also soll sich doch bitte jemand drum kümmern, dem daran liegt, das [...]

Ist ja schon richtig dass Du nicht dafür bezahlt wirst, dass die CV auf anderen Plattformen läuft, aber es ist nicht im Sinne von OpenSource (auch nicht Debian-konform) wenn man sowas mal eben reinpatched "weil es einfacher ist" und damit anderen quasi mutwillig das Leben schwerer macht. Natürlich "geht" es auch mit dem vorhandenen Material, aber eben nicht so wie es gedacht ist... Du beschwerst Du Dich doch selbst auch über Gefrickel bei anderen oder wenn ihnen Deine Prioritäten (z.B. Performance) nicht so wichtig sind, setzt Dich aber selbst über Standards hinweg, das passt nicht so richtig zusammen.

Versteh mich nicht falsch, dass ist als konstruktiver Vorschlag (speziell eibread/eibwrite innerhalb des eibd-clients Pakets) gemeint, die Kritik gilt nur für die Art und Weise des Umgangs damit.

Gruß,
Christian

[henfri]

Hallo,

die CV funktioniert jetzt soweit, hinsichtlich der Kommunikation mit dem Bus bei mir.
[ACHTUNG]Aber es geht ja nicht um mich![/ACHTUNG]

Ich möchte, dass es für den geneigten User einfach ist, die CV zu installieren. Und das ist es NICHT.

eibd-clients geht echt einfacher, mein Packerl lässt sich von OpenWRT über Dreambox bis Ubuntu 12.10/64 Warnungs-frei bauen (und entspricht v0.0.5, ich hab das absichtlich darunter gehalten, damit es keine Konflikte gibt!).. Wenn mans lieber gern auf die harte Tour mit Makefile-patchen hat, ok, kann man das .changes nehmen

Wunderbar. Wäre es dann nicht sinnvoll, den für die CV nötigen Teil davon bei der CV mitzuliefern? Einmal als Quelltext mit Build-Instruktionen, einmal als x86-Deb (weil vorhanden), meinetwegen auch als amd-64-Deb und schlieslich als deb-src.
Damit dürften doch wirlich 90% der User es recht einfach haben.

Beim rrdtool ists wesentlich komplizierter.. Aber jetzt mal ehrlich, mir liegt nunmal primär an der Performance&Funktion in der CV, ebenso wie "Upstream" das wurscht ist, ist es mir wurscht ob das mit Fedora 199.77 perfekt ist
Natürlich kann man das hinbiegen aber - mal böse gesagt - mich bezahlt niemand für, also soll sich doch bitte jemand drum kümmern, dem daran liegt, das es unter Susie 17 mit rrdtool 1.4 und libcairo geht (der overhead ist da wurscht, ist eh Faktor 10+) - und einfach nen Wrapper oder nen patch für fetchj schreiben (das sind keine 5 Zeilen unterschied!), fertig, oder?

Aber das ist doch nicht nachhaltig.
Wir predigen doch immer, dass alles was mit dem Bus zusammenhängt auch in 30 Jahren noch laufen soll. Sollen wir also 30 Jahre lang rrdtool backporten?

Da muss es doch eine bessere Lösung geben.

Gruß,
Hendrik