Diskussion Daten loggen, ccu-historian, ioBroker

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

jp112sdl
Beiträge: 9148
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 555 Mal
Danksagung erhalten: 1278 Mal
Kontaktdaten:

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von jp112sdl » 20.06.2021, 17:50

Hoppla hat geschrieben:
20.06.2021, 17:39
sonst wird die Datenbank zum Monster.
Ü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

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

HMSteve
Beiträge: 261
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 7 Mal
Danksagung erhalten: 43 Mal

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von HMSteve » 20.06.2021, 18:52

jp112sdl hat geschrieben:
20.06.2021, 17:50
Möchte Influx als Vergleich mal noch reinwerfen:
2 Jahre, ca. 120 Datenpunkte: ca. 300MB
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?

Viele Gruesse,
Stephan

jp112sdl
Beiträge: 9148
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 555 Mal
Danksagung erhalten: 1278 Mal
Kontaktdaten:

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von jp112sdl » 20.06.2021, 19:03

HMSteve hat geschrieben:
20.06.2021, 18:52
welches Detaillevel an Daten man wie lange behaelt,
Was 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).

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

Benutzeravatar
Hoppla
Beiträge: 281
Registriert: 29.12.2018, 19:39
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leipzsch
Hat sich bedankt: 24 Mal
Danksagung erhalten: 8 Mal

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von Hoppla » 20.06.2021, 19:11

jp112sdl hat geschrieben:
20.06.2021, 17:50

Ü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
Ich hab gerade mal nachgeschaut und mit erschrecken Festgestellt, ich muss ausmisten ;-)

650 Datenpunkte mit 2,5 Gbyte.
Da sind Sensoren dabei, die alle Minuten loggen ...

HMSteve
Beiträge: 261
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 7 Mal
Danksagung erhalten: 43 Mal

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von HMSteve » 20.06.2021, 21:05

jp112sdl hat geschrieben:
20.06.2021, 19:03
Und die fliegen in die DB mit einer Retention von 2 Jahren.
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.
Ich waere bspw. ziemlich veraergert, wenn Wetterwerte wie Tagesextrema ueberhaupt geloescht wuerden.

Viele Gruesse,
Stephan

HMSteve
Beiträge: 261
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 7 Mal
Danksagung erhalten: 43 Mal

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von HMSteve » 20.06.2021, 21:08

Hoppla hat geschrieben:
20.06.2021, 19:11
Ich hab gerade mal nachgeschaut...
Sollte man nicht tun, das Erschrecken ist einem sicher, ging mir juengst ebenso. :lol:
Vielleicht doch ein Argument fuer InfluxDB, wenn man es clever aufsetzt, waere aber wieder eine neue Technik, in die man sich reindenken muss...

Viele Gruesse,
Stephan

TomMajor
Beiträge: 1537
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 143 Mal
Danksagung erhalten: 311 Mal
Kontaktdaten:

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von TomMajor » 20.06.2021, 23:54

FUEL4EP hat geschrieben:
20.06.2021, 15:49
Hi 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.
Hey Baxxy und Ewald,

den HighChart Kommentar hatte ich aus dem Augenwinkel im Sample Config gesehen, ich kannte aber HighChart nicht und konnte mit dem Kommentar im Sample Config nichts anfangen, deswegen erst mal links liegen gelassen:

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'
ich schau mir den HighChart noch mal an.

TomMajor hat geschrieben:
20.06.2021, 15:30
3. "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?
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.
Das ist m.E. nicht gut gelöst im Historian, zumal zu dem Thema nicht viel im Handbuch steht. Die Frage kam auch schon häufiger hier im Historian Bereich des Forums wo denn die Geräte sind.
Alle in der CCU vorhandenen BidCos-RF Geräte beim ersten Start aus der API auslesen wäre der saubere Weg imho, so scheint es ioBroker zu machen.

jp112sdl hat geschrieben:
20.06.2021, 19:03
Was 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).
Hey Jerome,
der Historian treibt da einigen Aufwand um eben nicht jeden einzelnen Wert eines jeden Datenpunktes mit seinem Änderungsintervall in die Datenbank zu nehmen sondern das zu reduzieren, Stichworte Delta Kompression, Swinging-Door Kompression usw.
https://github.com/mdzio/ccu-historian/ ... isierungen
Influx wird das ähnlich machen und vermutlich auch irgendwo einstellbar.
Viele Grüße,
Tom

Mathias
Beiträge: 1333
Registriert: 03.11.2010, 10:25
System: CCU
Wohnort: Aachen
Hat sich bedankt: 15 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von Mathias » 21.06.2021, 20:15

Dann will ich auch noch als Entwickler vom CCU-Historian einige der genannten Punkte aufgreifen:
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.
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.

Der CCU-Historian will eine State-Of-The-Art Betriebsdatenerfassung, die intern komplex ist, möglichst einfach verpackt dem Anwender anbieten. Alles (CCU-Anbindung, Koppler, Datenbank, Web-Server, ...) befindet sich in einem Installationspaket und wird bei jeder Version gemeinsam ausgeliefert. Auch die Konfiguration der Historisierung von einzelnen Datenpunkten erfolgt über die Web-UI mit wenigen Klicks. Bei InfluxDB muss man sich in die Sprache InfluxQL einarbeiten um z.B. die Retention-Policy zu konfigurieren. Sicherlich muss man sich auch um den CCU-Historian etwas mehr kümmern, wenn man viele Daten über einen langen Zeitraum aufzeichnen will. Dann sollten schon separate Hardware und eine SSD eingesetzt werden.
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.
Ja, CCU3 ist richtig. Ich werde noch das Handbuch dort anpassen.
"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.
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.
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.
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.

Beispiel:
Zwischenablage03.png
Möchte Influx als Vergleich mal noch reinwerfen:
2 Jahre, ca. 120 Datenpunkte: ca. 300MB
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 MB

Die Konfiguration der Messwertvorverarbeitung erfordert natürlich Zeit, aber dies unterstützt der CCU-Historian mit der Möglichkeit einer Massenkonfigurationen von Datenpunkten oder auch der Ausführung von Konfigurationsskripten, die im Wiki zu finden sind.

Viele Grüße
Mathias

TomMajor
Beiträge: 1537
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 143 Mal
Danksagung erhalten: 311 Mal
Kontaktdaten:

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von TomMajor » 22.06.2021, 01:06

Hi Mathias,

zunächst einmal vielen Dank und großen Respekt für deine Arbeit am CCU-Historian und das lange Dranbleiben und Supporten eines solchen Projektes.

Ganz genau, aus Überlegungen den ioBroker wegen Wartungsaufwand und Komplexität (da ich wie geschrieben eigentlich nur die Visualisierung benötige) ggf. loszuwerden bin ich zur Evaluierung bei deinem Projekt gelandet und meine bisherige Einschätzung hatte ich ja oben geschrieben.

HighChart mit Mouse-Over probiere ich auf jeden Fall noch aus.

Ich würde empfehlen noch folgende Punkte ins Handbuch aufzunehmen um die (bereits minimale) Verwirrung für einen Neueinsteiger CCU-Historian weiter zu minimieren (ich hatte bereits überlegt dir eine issue dafür aufzumachen)

- device type CCU3 für eine RM mit einem RPI-RF-MOD oder HM-MOD-RPI-PCB Funkmodul (von dir schon vorgemerkt)

- Datenpunkte von BidCos-RF Geräten sind im Historian erst zu sehen, wenn sich der Datenpunkt tatsächlich das erste Mal meldet/ändert - das erwartet man nicht dass am Anfang keine Geräte da sind und fragt sich sofort ob was mit der Konfiguration nicht stimmt.

- Möglichkeit des alternativen Diagramms mit Mouse-Over / HighChart,
das es sowas überhaupt gibt und man dies mit z.B.

Code: Alles auswählen

webServer.menuLinks.link1.text='Beispiel 1 - Vorjahresvergleich'
webServer.menuLinks.link1.address='/custom/example1.html'
bekommen würde kommt imho nirgends zum Ausdruck. ich hatte es in der Config zunächst deaktiviert weil ich aufgrund des Kommentars glaubte das brauche ich nicht.

"möglichst einfach verpackt dem Anwender anbieten." ist dir auf jeden Fall gelungen :)

Bleibt in meinem konkreten Fall noch die Performance Sache und der Test von HighChart. Ich vergleiche auf jeden Fall den HighChart noch mal mit dem ioBroker.
Mathias hat geschrieben:
21.06.2021, 20:15
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.
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.

Im Broker muss man dafür die DP zum Loggen einmalig markieren was ich auch besser finde als alle default mitzuloggen (ich weiß man kann das mit defaultDisabled ändern, aber dann verschwinden wohl auch Infos über den DP wie Namen so dass es schwer wird den später wieder zu finden).

Das Konzept von ioBroker ist in diesem Punkt imho perfekt - alle DP sofort listen mit allen Infos zu diesen, aber der user muss die gewünschten DP zum Loggen 1x markieren - just my 2ct.
In der Regel lasse ich den Channel 0 zugeklappt, klappe den Channel 1 auf und markiere dort die Values die ich brauche.
Viele Grüße,
Tom

Mathias
Beiträge: 1333
Registriert: 03.11.2010, 10:25
System: CCU
Wohnort: Aachen
Hat sich bedankt: 15 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

Re: Diskussion Daten loggen, ccu-historian, ioBroker

Beitrag von Mathias » 22.06.2021, 18:51

Ich habe mal alle oben angemerkten Punkte mit in das Handbuch aufgenommen. Danke an Tom.

Am Anfang direkt eine komplette Liste der Datenpunkte anzubieten, ist vielleicht eine sinnvolle Sache. Ich werde mir das mal überlegen.

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“