[wiregate] - √ - 81.8AE32F000000_errors.rrd: Was passiert da?

[emax]

In /var/www/rrd finde ich das hier:

root@wiregate417:/var/www/rrd# ls -la
insgesamt 2140
drwxr-xr-x  2 root     root        4096  7. Aug 12:22 .
drwxr-xr-x 12 www-data www-data    4096 15. Jul 12:18 ..
-rw-rw-rw-  1 root     root     1017208  7. Aug 12:41 81.8AE32F000000_errors.rrd
-rw-rw-rw-  1 root     root      763016  7. Aug 12:41 eib_traffic.rrd
-rw-rw-rw-  1 root     root      382240  7. Aug 12:41 KgTreppeHelligkeit.rrd
root@wiregate417:/var/www/rrd#

Wie werte ich die ...errors.rrd aus?

Ich muss auch feststellen, dass meine testhalbe Helligkeitsaufzeichnung ihre Größe nicht verändert. Ist da was faul? Wenn ja, was?

Welche Logdateien sollte ich prüfen?

[Tru]

Wie werte ich die ...errors.rrd aus?

Schau mal unter unter RRDtool - RRDtool Documentation. Du kannst auf der CLI zum Beispiel mit rrdfetch die Daten auslesen oder mittels rrdgraph einen Graph erstellen.

Ich muss auch feststellen, dass meine testhalbe Helligkeitsaufzeichnung ihre Größe nicht verändert. Ist da was faul? Wenn ja, was?

Nein, da ist überhaupt nichts faul. Studier mal die Dokumentation zu RRD. Kurz: bei RRD handelt es sich um einen ganz anderen Typ von Datenbank als gewohnt. In RRD wird eine fest angelegte Zahl von Werten gespeichert. Diese Zahl wird bei der Erzeugung der Datenbank festgelegt (und die Werte auf unknown gesetzt). Bei jeder Datenspeicherung werden die Werte neu berechnet soweit nötig, typischerweise Durchschnittswerte für die einzelnen Zeitabschnitte.

Ein geniales Konzept zur graphischen Anzeige über einen typischen Zeitraum, weil (typischerweise) nur so viele Werte in der Datenbank gehalten werden wie zur Anzeige gebraucht werden, egal wie oft Daten geladen werden.

Gruss, Othmar

[makki]

Da werden - im optimalzustand - nur Nuller reingeschrieben
Auswerten: auf der Sensorseite neben dem Busmaster oder im Diagrammgenerator; aber das ist ein reines Problem/Diagnose-Werkzeug, sonst wirds halt nur aufgezeichnet damit man danach was zum nachsehen hat..

Makki

[emax]

Jetzt wird mir wieder was klarer. Da ich noch keinen 1Wire Sensor angeschlossen habe, war auch das Namensformat der errors.rrd für mich kein Hinweis. Jetzt sehe ich, dass das der Sensoradresse des Sensors entspricht, der in der Grundkonfiguration vorhanden ist.

Alles klar, vielen Dank!

[StefanW]

Hallo,

Jetzt sehe ich, dass das der Sensoradresse des Sensors entspricht, der in der Grundkonfiguration vorhanden ist.

Genau genommen ist das kein Sensor, sondern ein DS1420 Serial ID Chip. Ein solcher ist bei allen DS9490R 1-Wire Busmaster / USB Hostadaptern (der blaue) eingelötet.
Jeder 1-Wire Chip hat eine eigene Seriennummer, die aus der Family-ID, hier "81" und der eigentlichen Nummer besteht. Beim Serial ID Chip kann der 1-Wire Chip nur die SN herausgeben, er hat keine weitere Funktion. Auf diese Weise hat der Busmaster eine SN und es ist auch ein kleiner Test der 1-Wire-Busmaster Funktionalität, weil diese SN nicht gelesen werden könnte, wenn der Busmaster nicht funktioniert.

Anhand dieser Tabelle kann aus den Family-Codes der jeweilige Baustein abgelesen werden.

In den 1-Wire ID iButtons - so wie von uns für das digitale Schlüsselbrett angeboten - ist der gleiche Chip drin.

LG

Stefan

[emax]

Danke Stefan. Mühsam nährt sich das Eichhörnchen.

Es ist zu überlegen, ob wir nicht irgendwo mal eine zusammengefasste Wiregate Knowledge-Base aufbauen. Immerhin ist das ein ziemlich interdisziplinäres Projekt, und sich alle diese Dinge mit der Suchfunktion zusammen zu suchen ist aufwändig.

Aber vielleicht gibt es das ja schon, und ich weiß wieder mal nix davon ... :-o

[StefanW]

Es ist zu überlegen, ob wir nicht irgendwo mal eine zusammengefasste Wiregate Knowledge-Base aufbauen.

Gibt es bisher nicht. Nun diese Überlegung haben wir auch schon mehrfach angestellt, aber auf der anderen Seite, abgesehen von Entwicklern sind solche Details uninteressant für den Anwender.

Es ist ja genau der Punkt, den wir mit dem WireGate Multifunktionsgateway und unseren 1-Wire Produkten erreichen wollten, dass es GANZ EINFACH ist für den Anwender. Komplett vorinstalliert, einfach Sensoren und KNX anschließen (geht auch ohne KNX natürlich) ein paar GAs eintragen und fertig.

Darum schreiben wir auch keine 20 seitigen Dokumente (wie andere) mit welchen Tricks welche Reichweiten erziehlt werden können und auch sonst keine Informationen über weitere Details, weil wir gar nicht den Anschein erwecken wollen, als müsste jemand der sich für den Einsatz von 1-Wire interessiert, dies alles vorher gelesen haben.

Unsere Formel ist da einfach: Pro Busmaster 20 Sensoren (von Multisensoren nur 10) und 100 m Länge, Sterne und lange Abzweige sowie parallele Verlegung zu 230 V vermeiden. Das funktioniert einfach immer.

Auf den Multisensoren haben wir im Flash der Speicher bestimmte - übrigens individuelle - Informationen gespeichert die das Plug & Play erleichtern. Alle Sensoren auf einem Multisensor erscheinen im WireGate als zusammengehörig und die SN steht der einfacheren Zuordnung auf dem Aufkleber.

Insofern ist es gar nicht notwendig, diese Details zusammenzutragen damit die Anwender das lesen, denn sie sollen diese Details gar nicht benötigen.

Für einen Entwickler der programmieren möchte oder den Technik-Freak der ohnehin alles genau wissen will, ist das sicher was anderes. Aber der bekommt hier ja auch Auskunft oder sucht es sich zusammen.

Insofern fürchte ich, dass ein Super-1-Wire-Wiktionary auf unserer Webseite eher kontraproduktiv ist, weil wir eben nicht die Komplexität - die nur für den Entwickler interessant ist - sondern die besondere Einfachheit unseres 1-Wire Sensornetzwerkes darstellen wollen.

Anstecken - funktioniert - freuen - fertig.

Stefan

[emax]

Das kann ich nachvollziehen. Ein technisch orientiertes Nachschlagewerk wäre sicher auch nicht im Sinne eines "Don't scare the customer" Paradigmas.

Allerdings ist die Grenze zwischen Plug&Play Kunde und Techniker beim Wiregate vielleicht eher fließend. Tante Frieda schenkt Onkel Paule so was sicher nicht zu Weihnachten. Ich wage die Vermutung, dass die Wiregate Klientel aktuell noch sehr technophil besetzt ist.

Aber was solls. Wenn eine solche Sammlung mal schärfer ins Auge gefasst wird, dann bestünde ja die Möglichkeit, das (z.b.) auf SF-Net zu machen, und so ganz klar der Entwicklergemeinde und weniger der Konsumentenseite zu widmen.

[StefanW]

Ich wage die Vermutung, dass die Wiregate Klientel aktuell noch sehr technophil besetzt ist.

Das war Anfangs bei den Early Adaptors auch so, mittlerweile wird das vom Restaurantbesitzer der die Temperatur seiner Kühltruhen / Kühlräume damit - wegen der Aufzeichnungspflichten nach HAACP - genauso eingesetzt wie von fortschrittlicheren Elektroinstallationsbetrieben in Büro- und Hausinstallationen - und in 80% der Fälle ohne jegliche Supportfrage.

Das Forum und die Diskussionen hier vermitteln da ein verfälschtes Bild der Realität, weil es hier eher um die erweiterten Features geht.

Aber was solls. Wenn eine solche Sammlung mal schärfer ins Auge gefasst wird, dann bestünde ja die Möglichkeit, das (z.b.) auf SF-Net zu machen, und so ganz klar der Entwicklergemeinde und weniger der Konsumentenseite zu widmen.

Ja, das wäre eine gute Möglichkeit. Allerdings beziehen sich nach meiner Wahrnehmung die meisten Entwicklungen der Community rund um das Wiregate Multifunktionsgateway auf Anbindung von Funk-Modulen, berechnende Plugins, Visu, Logik und kaum auf 1-Wire an sich. Letzteres ist auch kaum nötig, weil das ja unsere Kernaufgabe ist bzw. es dafür eine separate Community (OWFS Mailinglist) gibt.

Eine Informationssammlung sollte sich nach meiner Wahrnehmung eher auf das WireGate Multifunktionsgateway und seine Komponenten / Plugins usw. beziehen und weniger auf den 1-Wire Bus.

Derzeit drehen sich unsere Prioritäten eher darauf, die akt. Entwicklungen produziert zu bekommen, das Thema Plugins besser zu skalieren usw.

Für ein Wiki fehlt uns ein wenig die Zeit im Moment, aber wer will, darf natürlich

LG

Stefan