[wiregate] - √ - Fragen zu Wiregate Config

[xachsewag]

Hallo zusammen,
ich habe seit gestern mein Wiregate.

Das meiste ist ja wirklich selbsterklärend und hat auf anhieb funktioniert, trotzdem habe ich noch die ein oder andere Frage:

Im Bereich Sensoren / Werte knfigurieren

Hier gibt es 4 Felder für Zeilen für xxx-Schritt genaue Aufzeichnung.
Was genau bedeuten diese Werte dafür und was hat es mit den Schritten zu tun?
Bedeutet "Zyklus für Datenaufzeichnung RRD" die Anzahl der gespeicherten Werte für die Darstellung?
Mir gehts nicht darum das zu verändern, würde nur gerne wissen wofür die Funktionen stehen

Außerdem habe ich das Problem, dass das WG alle Telegramme über die 0.0.0 Versendet obwohl eine EIB Adresse eingegeben ist. Angebunden ist das WG über eine IPS/S2.1

Dank schonmal für die Hilfe

[makki]

Außerdem habe ich das Problem, dass das WG alle Telegramme über die 0.0.0 Versendet obwohl eine EIB Adresse eingegeben ist. Angebunden ist das WG über eine IPS/S2.1

Erstmal hierzu: die eingestellte EIB-Adresse gilt grob gesagt nur für ein lokales TP-UART und ist ansonsten wirkungslos.
Zum KNX hin zählt in dieser Konstellation die am IPS/S2.1 per ETS eingestellte PA, zur IP-Seite ist es immer 0.0.0;
Das ist eine (kosmetische) unschönheit, ist aber so Es ist halt nur "sowas ähnliches" wie ein IP-Router, keine Zertifizierung, keine 100%..

Im Bereich Sensoren / Werte knfigurieren

Hier gibt es 4 Felder für Zeilen für xxx-Schritt genaue Aufzeichnung.
Was genau bedeuten diese Werte dafür und was hat es mit den Schritten zu tun?
Bedeutet "Zyklus für Datenaufzeichnung RRD" die Anzahl der gespeicherten Werte für die Darstellung?

In kurz, damit kann man die Zeilen (rows) der RRA's (Round Robin Archive) verändern.

In länger, muss man dazu verstehen, wie das rrdtool funktioniert, hier, eine übersichtliche Einführung, etwas detailierter (beides in Deutsch)
- Die Anzahl der Zeilen im jew. RRA beeinflusst natürlich auch den benötigten Speicherplatz (Default: 382kB)

- Und ja, der Zyklus (step) hat damit zu tun, verändert man diesen, verändert sich auch die aufgezeichnete Datendichte/Länge.
-> Also mit Defaulteinstellung:
Archiv1 (2160x 5 Minuten=): für 180 Stunden werden die 5minütig gelesen Werte gespeichert usw.
Archiv4 (8760x 180x5 Minuten=): für 15 Jahre(!), Auflösung 15h
-> mit Zyklus 60 statt 300
Archiv1 (2160x 1 Minute=): für 36 Stunden werden die minütlich gelesen Werte gespeichert.
...
Archiv4 (8760x 36x1 Minute=): für 3 Jahre, Auflösung 3h

Jegliche Änderung daran greift aber nur für danach angelegte RRD's, sprich man muss den Sensor (bzw. das RRD) nach einer Änderung löschen.

Beschäftigen muss man sich damit aber natürlich nur wenn man will, die Defaultwerte sollten es für den Hausgebrauch tun

Makki

[xachsewag]

Hey, danke für die Antwort!

Also werde ich auch im ETS Monitor nur die 0.0.0 sehen.

Wie kann man sich die 4 unterschiedlichen Statistiken anzeigen lassen oder werden diese automatisch je nach Laufzeit dargestellt?

Gruß

[makki]

Beim erstellen der Grafiken wird - je nach gewähltem Zeitraum - automatisch die jew. höchste verfügbare Auflösung verwendet..

Makki

[xachsewag]

Wie oft wird eigentlich ein Sensor im 1Wire abgefragt?

Ist 26% Buslast bei 2 Sensoren eigentlich normal?

[makki]

So oft wie eingestellt (Global oder pro Sensor) bzw. wenn ein "Senden bei Änderung" eingestellt ist 1/4 des globalen Sendezyklus (also Default alle 75 sek.)
So ein Mittelwert zwischen reichlich vorhandene Resourcen schonen und responsezeit, meist sind Temperaturen ja jetzt nicht so wirklich im Millisekundebereich interessant (ist ja alles Green, mehr CPU kostet bösen Strom, der böses CO2 oder schlimmeres macht )

Die "Buslast" ist eher ein esotherischer Wert, wenn z.B. iButtons oder I/O's konfiguriert sind wird ständig deren Status gepollt und das geht schnell >90%, nichts bedenkliches..

Makki

[xachsewag]

OK dann bin ich beruhigt.

Die Zykluszeit der ersten beiden Sensoren liegt bei 290 Sekunden. Aber der Sensor wird öfters gelesen oder? Wenn ich die Webseite aktualisiere sehe ich ja schon früher den aktuellen Wert.

[makki]

Die Webseite (webmin) liest den Wert - unabhängig davon - live (deswegen ist es auch so langsam )

Zum testen/beobachten ist übrigens http://wiregateXXX:3001/uncached/28.xyz praktischer.

Makki

[xachsewag]

Sehr interessant! Danke. Dort stecken ja noch viele Infos drin

Der Homeserver läuft jetzt über das WG. Dieser sendet allerdings mit der ihm eingestellten PA und nicht mit 0.0.0

Gute Nacht.

[xachsewag]

Bin jetzt nochmal auf ein kleines Problem gestoßen:
Wenn ich ein Plugin öffne und den Plugin Namen ändern will und speichere, habe ich zusätzlich zu dem Aalten den gleichen Plugin unter dem neuen Namen in der Liste. Also dupliziert. (Sowohl mit IE als FireFox)

Wenn ich diesen dann lösche bleibt im unteren Teil (Plugin Debug-Infos) auch die Info des schon gelöschten Plugins.

Wie kann man einen Plugin umbenennen und wie bekommt man die Debug Infos von gelöschten wieder weg?
Gruß

[makki]

Das ist soweit plangemäss, damit man Plugins einfach kopieren kann. Das hängt sich immer nur am Namen des Plugins auf, hat Vor&Nachteile..

Wie kann man einen Plugin umbenennen und wie bekommt man die Debug Infos von gelöschten wieder weg?

In schön&einfach: garnicht*.
Ursprünglich gab es den Gedanken eine Garbage-collection zu machen, die alles was nicht mit vorhandenen Plugin-Namen beginnt in $plugin_info löscht aber nachdem ich ja kaum weiss wer da was&wie reingeschrieben hat, würde das vermutlich mehr Frust als Lust auslösen..

Makki

*: entweder in einem (anderen) Plugin händisch "delete $plugin_info{'ALTERNAME_cycle'};" usw. oder das komplette entsorgen: wiregated.pl beenden (per monit oder Webif, sonst startet es der monit gleich wieder) und /etc/wiregate/wiregate_plugin.db löschen.

[onkelm]

Hi,

kurze Frage:

ich hab jetzt mal getestet und man kann die Original CF Karte mit einem Imageprogramm auf eine andere CF Karte kopieren und mit Gpartet die Datenpartition vergrößern.

Wenn ich jetzt den Zyklus für Datenaufzeichnung entsprechend von 300 auf 30 ändere (64 GB CF)

entspricht das dann in etwa eine Verachtfachung der Datenaufzeichnung analog der Vergrößerung der CF Karte (16 Fache )?

Muß ich dann immer noch mit aktueller Firmware ( 1.4) die Sensoren löschen und hinzufügen damit das klappt ?

Oder geht das inzwischen so ?

Welche Einstellungen würdet Ihre entsprechend der Kartengröße vornehmen ?
Am liebsten als kleinstes alle Minute und dann halt so lange und viel entsprechend der 64 GB CF Karte.


Gruß OnkelM

[heckmannju]

Hi,
bei RRDs wird der Plattenplatz doch schon beim anlagen reserviert. Ich denke das Geld für die grössere CF Karte hättest du dir sparen können. die Zykluszeit kannst du runtersetzen aber hast du da keine angst das du dir deinen KNX Bus überflutest mit Temperaturen die sich eh nur alle halbe Stunden ändern.
VG
Jürgen

[onkelm]

Hi,
hmm ich dachte in der Zeit werden nur die RRDs geschrieben.
Aber du hast recht, ohne Wert in den Sensoren wäre das Fatal.
Dann müßte man also bei jeden Sensor eine eigene Zykluszeit setzen, die dann höher wäre um nicht den KNX Bus zu fluten. Also dort dann wieder 300.

Sehr guter Einwand, danke.
Mir ging es eigentlich nur um die Auflösung der RRD, gerade langfristig. Da ist mir halt 15 Stunden schon deutlich zu lange.
Deshalb die ganze Arie.

Wenn jemand da die idealen Tips hat - immer gerne.

Gruß OnkelM

[StefanW]

Diese Funktionalität, den Zyklus, die Aufzeichnungszeit, ggfls. die Verdichtung einer Wertaufzeichnung von Sensoren beliebig und auch fortlaufend ändern zu können sind häufig genannte und "alte" Anforderungen von Kunden.

So simpel das klingt, die Umsetzung ist es gar nicht. Den jeder Sensor hat dann seinen eigenen Fahrplan, die Aufzeichnung muss dann in ein flexibleres Datenbankformat erfolgen und trotzdem ausreichend komprimieren, damit das nicht platzt und dabei muss man immer aiuch noch das Flash schonen. Das Antwortverhalten soll dabei auch schnell sein.

Um einen Eindruck zu geben: Über einen Zeitraum von fünf Jahren kommt für einen simplen Wert der alle fünf Minuten weggeschrieben wird eine halbe Million Datensätze zusammen. Hieraus eine sekundenschnelle Antwort zu generieren ohne dass es sich um einen Hochleistungsserver handelt ist eine enorme Herausforderung. An so einem Feature kann man einen Entwickler mehrere Monate "forschen" lassen, wie man das Ressourcenschonend umsetzt.

Das RRD-Format ist ansich äußerst effizient. Es wurde auf - aus heutiger Sicht - sehr leistungsschwachen Servern geschaffen für die Aufzeichnung von tausenden Parametern. Dafür ist es gut, es skaliert erst ab ca. 10.0000 gleichzeitigen Quellen schlecht. Darum haben wir das auf dem WireGate auch verwendet. Der große Nachteil ist, dass es eben fix angelegt wird und nicht mehr geändert werden kann und die hohe Effizienz auch aus der hohen Verdichtung nach mehrereren Monaten kommt (was man auch anders anlegen könnte).

Wir haben diese Anforderungen

• Ein eigener Zyklus pro Aufgabe (nicht nur pro Sensor)
• Hocheffizientes Abspeichern in einer DB unter Schonung von Flash
• Ultraschnelles Auslesen
• Jederzeitige Änderbarkeit

im Nachfolgeprodukt Timberwolf Server umgesetzt. Das war anstrengender als es hier klingt, weil es im Detail sehr komplex ist, wenn man davon ausgeht, dass parallel gut zweihundert Sensoren mit fünfhundert Werten und bis achthundert Aufzeichnungen gemacht werden sollen.Jeder davon mit seinem eigenem Zyklus.

In ein paar Monaten bekommst Du das bei uns zu kaufen.

lg

Stefan