Über wie viel GB in welchem Zeitraum und Anzahl von Datenpunkten reden wir da?
Möchte Influx als Vergleich mal noch reinwerfen:
2 Jahre, ca. 120 Datenpunkte: ca. 300MB
Moderator: Co-Administratoren
Über wie viel GB in welchem Zeitraum und Anzahl von Datenpunkten reden wir da?
Haengt das nicht extrem stark davon ab, welches Detaillevel an Daten man wie lange behaelt, so dass da je nach Config ganz unterschiedliche Datenmengen bei identischen Datenquellen entstehen?
Was meinst du mit Detaillevel?
Ich hab gerade mal nachgeschaut und mit erschrecken Festgestellt, ich muss ausmisten
Das meinte ich, diese Retention kann man nach meinem sehr rudimentaeren Wissen doch sehr flexibel definieren, also nicht nur “2 Jahre dreiminuetliche Datenpunkte halten”, sondern auch umso staerker ausduennen bzw Originaldaten durch Aggregate ueber laengere Zeitintervalle ersetzen, je aelter ein Zeitreihenstueck ist.
Sollte man nicht tun, das Erschrecken ist einem sicher, ging mir juengst ebenso.
Hey Baxxy und Ewald,FUEL4EP hat geschrieben: ↑20.06.2021, 15:49Hi Tom,
Die Standardgrafiken vom CCU-Historian werden auf dem Rechner, auf dem der CCU-Historian läuft, als Bild erzeugt und sind daher nicht interaktiv.
Die Interaktivität ist unter Extras->H2-HighChart gegeben. HighChart 'saugt' sich zuerst alle Daten ins RAM, das dauert ein wenig. Danach ist die Anzeige schneller und vor allem interaktiv bedienbar. HighCharts ist hier beschrieben.
Sowohl der Standard CCU Historian als auch HighChart erlauben es Lesezeichen z.B. auf einem iPAD für einen Graphen zu erstellen. Damit ist die Darstellung einer Messgröße sehr einfach.
Code: Alles auswählen
// Zum Freischalten der Web-Links zu den Beispiel-Web-Seiten, die Kommentarzeichen (//) vor folgenden
// zwei Zeilen entfernen:
webServer.menuLinks.link1.text='H2-HighChart'
webServer.menuLinks.link1.address='/custom/h2-highchart/H2-HighChart.gy'
// webServer.menuLinks.link2.text='Beispiel 1 - Vorjahresvergleich'
// webServer.menuLinks.link2.address='/custom/example1.gy'
Zwei Wassermelder sind inzwischen aufgetaucht, von den HM-LC-Sw1-FM auch welche, aber nur die die inzwischen geschaltet wurden, die anderen immer noch nicht.TomMajor hat geschrieben: ↑20.06.2021, 15:303. "Entdeckungszeit" der BidCos-RF Geräte finde ich extrem seltsam. Am Anfang waren nur die Sys.Variablen da, 1h später ein paar BidCos-RF Geräte, aber längst nicht alle.
Kommt mir irgendwie so vor als wenn ein BidCos-RF Gerät nur zum Historian hinzugefügt wird wenn es gerade gesendet hat (+ die historian.metaCycle Zeit die bei mir auf 30min steht).
Aber was ist mit den Geräten die sich nur 1x pro Tag in der Zentrale melden, wenn überhaupt?
Z.B. die HM-LC-SW1-FM, oder die Wassermelder, da habe ich noch keinen einzigen meiner Geräte in der Historian Datenpunktliste, und das nach 4 Stunden. Bei ioBroker waren bei Einrichtung alle Geräte mehr oder weniger sofort da, das ist zumindest meine Erinnerung.
Es sollte doch möglich sein, sofort alle BidCos-RF über die API zu bekommen, auch wenn sie gerade nicht senden?
Hey Jerome,jp112sdl hat geschrieben: ↑20.06.2021, 19:03Was meinst du mit Detaillevel?
Ein einzelner Datenpunkt liefert doch immer einen einzelnen Wert, z.B. ein TH-Sensor alle 2-3 min. 2 Datenpunkte (Temp+Feuchte).
Und die fliegen in die DB mit einer Retention von 2 Jahren.
Nun mag es "kleine" Wertetypen (boolean) geben und "große" Wertetypen (long int).
Keine Ahnung, wie Influx das macht mit der Speicherallokierung oder gar Deduplizierung.
Die ist ja extra darauf ausgelegt (Zeitreihenmetriken zu sammeln).
ioBroker insgesamt ist natürlich viel mehr als eine Betriebsdatenerfassung. Wer noch andere Module von ioBroker z.B. für die Automatisierung oder Anbindung von Fremdsystemen nutzt, sollte natürlich auch dann die dortige Historisierung von Werten verwenden. Allerdings ist die Installation und Wartung einer ioBroker-Installation nicht zu vernachlässigen. Gerade wenn es mit der Betriebsdatenerfassung richtig losgehen soll, ist die Installation, Konfiguration und Pflege einer separaten Datenbank notwendig. Dann landet man schnell auf der Kommandozeile und bei irgendwelchen SQL-Befehlen. Damit kommen viele Anwender gut klar oder haben die Zeit sich damit zu beschäftigen. Diese sind auch nicht die primäre Zielgruppe vom CCU-Historian.Ich habe den ioBroker im Betrieb, eigentlich nur für die Diagramme (weil die HM internen zu beschränkt sind), aber der Broker kostet auch immer zusätzlichen Aufwand in HW und Pflege/Updates. Ich überlege mal den Historian zu probieren und den Broker mittelfristig loszuwerden, mein Ziel ist immer wenn möglich KISS sowie ein robustes System mit möglichst wenig Pflegeaufwand.
Ja, CCU3 ist richtig. Ich werde noch das Handbuch dort anpassen.mein bislang einziger Kritikpunkt im Handbuch, auf RaspberryMatic mit Funkmodul wird nicht direkt eingegangen bzgl. devices.device1.type, ich habe dort CCU3 anstatt CUSTOM_CCU eingetragen, etwas Zweifel bleibt aber, aber ich denke CCU3 ist richtig.
Das war eine Design-Entscheidung: Historien zu Datenpunkten werden erst angelegt, wenn sich der Datenpunkt tatsächlich das erste Mal meldet/ändert. In der CCU existiert ein Mehrfaches an Datenpunkten, die nicht relevant sind. In der Regel melden sich alle HomeMatic-Geräte einmal am Tag, wodurch dann auch alle Datenpunkte nach einem Tag bekannt sind. Die Anzeigenamen, Räume und Gewerke werden dann alle paar Stunden erkundet."Entdeckungszeit" der BidCos-RF Geräte finde ich extrem seltsam. Am Anfang waren nur die Sys.Variablen da, 1h später ein paar BidCos-RF Geräte, aber längst nicht alle.
Für die Standard-Trend-Darstellung im CCU-Historian wird ein PNG-Bild gerendert und zum Web-Browser geschickt. Dadurch sind die o.g. Features nicht möglich. Allerdings existiert auch das Plug-In "H2-HighCharts" für den CCU-Historian, das seit einigen Versionen immer mitgeliefert wird. Es ist im Menü unter Extras zu finden.5. zur Diagramm Feineinstellung sind in ioBroker/Flot definitiv mehr Möglichkeiten als im Historian enthalten.
6. Anzeige der x-y/Zeit-Wert Daten beim Mouse-Over über einem Punkt im Diagramm, siehe Bild im Anhang. Scheint es beim Historian nicht zu geben? Nutze ich sehr gern bei ioBroker/Flot, ist schon fast ein Killerkriterium für mich das nicht mehr zu haben.
Eigentlich spielt die Größe der Datenbank bei heutigen Speichermedien eher eine kleinere Rolle, allerdings kann hier der CCU-Historian gegenüber InfluxDB punkten. Beispielsweise können Zeitreihen mit dem Swinging-Door-Algorithmus im CCU-Historian stark verdichtet werden, ohne dass Charakteristika der Trend-Kurve wie bei einer Mittelwertberechnung verloren gehen. Aus den Rohdaten werden geschickt Einträge verworfen, die keinen nennenswerten Beitrag zur Kurve liefern. Beispiel: 10 Jahre, ca. 790 Datenpunkte (alle von allen Geräten): ca. 535 MBMöchte Influx als Vergleich mal noch reinwerfen:
2 Jahre, ca. 120 Datenpunkte: ca. 300MB
Code: Alles auswählen
webServer.menuLinks.link1.text='Beispiel 1 - Vorjahresvergleich'
webServer.menuLinks.link1.address='/custom/example1.html'
Bist du sicher das dies für die BidCos-RF Geräte gilt? ich persönlich würde alle DP der HM Geräte sofort dem user auflisten (pro Channel 0/1 usw. aus-/einklappbar), das gibt die API her denk ich und ioBroker macht es so.Mathias hat geschrieben: ↑21.06.2021, 20:15Das war eine Design-Entscheidung: Historien zu Datenpunkten werden erst angelegt, wenn sich der Datenpunkt tatsächlich das erste Mal meldet/ändert. In der CCU existiert ein Mehrfaches an Datenpunkten, die nicht relevant sind. In der Regel melden sich alle HomeMatic-Geräte einmal am Tag, wodurch dann auch alle Datenpunkte nach einem Tag bekannt sind. Die Anzeigenamen, Räume und Gewerke werden dann alle paar Stunden erkundet.