Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[apollon77]

Die History Adapter speichern immer alles. Werte auslassen geht nur wenn sie nicht geändert waren dann per „nur Änderungen loggen“.

[ManfredH]

Wozu gibt es dann bei den History-Adaptern überhaupt die Option "Nach Intervall aufzeichen"?? Irgendjemand muß sich dabei ja was gedacht haben. :(

Find ich jetzt ziemlich blöd, weil mir diese vielen Werte die DB zumüllen :(

[apollon77]

Wo steht „nach Intervall aufzeichnen?“

Es gibt einzig die Option wenn man nur Änderungen aufzeichnet das gleiche Werte nach einem gewissen Intervall dennoch nochmals geloggt werden.

Warum müllen dir die Werte die Datenbank zu? Was bringt es dir unvollständige Daten in der Datenbank zu haben ?

[ManfredH]

@apollon77:

Es gibt einzig die Option wenn man nur Änderungen aufzeichnet das gleiche Werte nach einem gewissen Intervall dennoch nochmals geloggt werden. ` Aha, da liegt also mein Verständnisproblem. Da hab ich den Text in der Eingabemaske wohl fehl-interpretiert :( . Danke für die Aufklärung!

> Warum müllen dir die Werte die Datenbank zu? Was bringt es dir unvollständige Daten in der Datenbank zu haben ? Weil ich die meisten Werte nicht alle 2-3 Minuten (Sendezyklus HomeMatic) brauche. Die Außentemperatur z.B. interessiert mich nur stündlich (was will ich da mit Werten alle paar Minuten? Bin ja kein Meterologe ;) ) und dadurch, daß ich das Logging-Intervall nicht bestimmen kann, hab ich allein bei diesem Sensor die 20- bis 30-fache Datenmenge. Auf's Jahr gerechnet ist das viel Holz (statt 365 x 24 = 8760 dann 262300 Datensätze) :( . Dto. Innentemperatur, Stromverbrauch u.v.m.. Und wenn man dann (wie ich) z.B. die Verbrauchsdaten (Strom, Gas) zusammen mit den Außentemperaturen mehrere Jahre lang speichern will (>= 10 Jahre) dann explodiert da vermutlich die DB :(

Hintergrund meines Loggings ist, daß ich beim Energieverbrauch Einsparungspotentiale ausfindig machen möchte. Das bisherige Logging (CUxD) hat mir z.B. schon die Erkenntnis gebracht, daß die Warmwasser-Schwerkraftzirkulation (in Betrieb seit 1978) mind. 3500 kWh im Jahr kostet (Stromverbrauch im Vergleich dazu derzeit 2500 kWh pro Jahr!). Oder daß nach der Dachsanierung die Innentemperatur während der Nachtabsenkung nur sehr wenig abfällt und ich die statt um 22 Uhr schon 2 Stunden früher beginnen lassen kann.

Im Prinzip hätte mir das Logging von CUxD ja gereicht, aber bei der neuen Heizung lassen sich interessante Betriebsparameter auslesen, an die ich nur mit ioBroker und dem Viessmann-Adapter dran komme. Die möchte ich auch loggen, mir die Werte/Trends anschauen und dann an der einen oder anderen Stellschraube drehen.

Wie groß ist denn die Chance, daß so eine Option (Logging-Intervall einstellen) realisiert wird? Wäre das ein sehr großer Aufwand?

[paul53]

@ManfredH:

Wie groß ist denn die Chance, daß so eine Option (Logging-Intervall einstellen) realisiert wird? `
Wohl eher gering, da anscheinend nur Du Bedarf dafür hast. Mögliche Lösung: Zusätzliche(r) Datenpunkt(e) für History, die ihren Wert nur jede Stunde ändern.

const idSrc = '...'; // ID der Original-Datenpunktes
const idDst = '...'; // ID des Datenpunktes für History (SQL)

schedule('0 * * * *', function() { // jede volle Stunde
   setState(idDst, getState(idSrc).val, true);
});

[apollon77]

Was meinst DU mit CuxD Logging? Wenn Du da logging einschaltest loggt der auch jeden Wert in einem CSV-File :-)

Was für eine DB wolltest Du denn nehmen? An sich sind zahlen etwas sehr kurzes beim Speichern :-) Ich glaube du überschätzt die Datenmengen …

Aber ja, der Weg den Paul53 vorgeschlagen hat ist hier der sinnvollste und einfachste.

[ManfredH]

@paul53:

Mögliche Lösung: Zusätzliche(r) Datenpunkt(e) für History, die ihren Wert nur jede Stunde ändern. Ok - das war der entscheidende Hinweis - danke! Hätte ich eigentlich auch selbst drauf kommen können, nachdem ich die Tagessummen für Strom und Gas eh schon so behandle :/ . Kann man in HM ja recht einfach abfackeln mit der Zeitsteuerung. Muß man halt "nur" nochmal ein paar Systemvariable dafür definieren. > ````
const idSrc = '...'; // ID der Original-Datenpunktes
const idDst = '...'; // ID des Datenpunktes für History (SQL)

schedule('0 * * * *', function() { // jede volle Stunde
setState(idDst, getState(idSrc).val, true);
});
```` `
Das wiederum versteh ich jetzt nicht :(

[ManfredH]

@apollon77:

Was meinst DU mit CuxD Logging? Wenn Du da logging einschaltest loggt der auch jeden Wert in einem CSV-File :-) `
Ja, aber die Werte stehen dann tageweise in jeweils <u>einer Datei</u>. Sprich die Dateigröße ist recht übersichtlich, während sich in einer DB halt alle Werte in (mehr oder weniger) einer einzigen Tabelle tummeln. Keine Ahnung, was mySQL da schafft :(

> Was für eine DB wolltest Du denn nehmen? An sich sind zahlen etwas sehr kurzes beim Speichern :-) Ich glaube du überschätzt die Datenmengen …
mySQL. Es geht auch nicht um die Zeit zum Speichern, sondern um die Anzahl der Records (siehe Berechnungsbeispiel oben). Zumal die halt praktisch alle in einer einzigen Tabelle stehen :( . Allein bei den Außentemperaturen eine Viertelmillion pro Jahr. Macht in 10 Jahren 2,5 Mio. Dazu dann noch den Energieverbrauch in der gleichen Größenordnung. Summa summarum roundabout 1 Mio Records pro Jahr. Irgendwann machte jede DB mal die Grätsche …

> Aber ja, der Weg den Paul53 vorgeschlagen hat ist hier der sinnvollste und einfachste. Der einfachste sicher. Ob auch der sinnvollste weiß ich nicht. Ich für meinen Teil fände es schon sinnvoll, bei einer History-Funktion die Zahl der zu speichernden Datensätze einschränken zu können. Vor allem für Langezeit-Speicherung/-Analysen. Stichwort "Aggregation" usw.. Aber das ist immer die Sichtweise des Anwenders. Andere haben halt andere Präferenzen. Wobei ich mich schwer tue, über den Tellerrand zu schauen und diese zu sehen :(

[Stabilostick]

Große Anzahl von Records in einer Tabelle -> Dafür sind Datenbanken da. Noch ein sinnvoller Index darauf und gut ists.

DIe Tabellen für die eigentliche Datenhaltung werden wie folgt in MySQL angelegt:

"CREATE TABLE ts_number  (id INTEGER, ts BIGINT, val REAL, ack BIT, _from INTEGER, q INTEGER);"
"CREATE TABLE ts_string  (id INTEGER, ts BIGINT, val TEXT, ack BIT, _from INTEGER, q INTEGER);"
"CREATE TABLE ts_bool    (id INTEGER, ts BIGINT, val BIT,  ack BIT, _from INTEGER, q INTEGER);"

Macht

für Zahlen        integer 4bytes + bigint 8bytes + real 8bytes + bit 1byte + integer 4bytes + integer 4 bytes => 29 Bytes
für Zeichenketten integer 4bytes + bigint 8bytes + textlänge+2bytes + bit 1byte + integer 4bytes + integer 4 bytes => 19 Bytes + Anzahl der Buchstaben
für Logikwerte    integer 4bytes + bigint 8bytes + bit+bit 1byte + integer 4bytes + integer 4 bytes => 17 Bytes

je Datenbankeintrag. Siehe https://dev.mysql.com/doc/refman/8.0/en … ments.html

Ergibt z.B. für 10000 Zahlenwerte am Tag 290000 Bytes = 283,2KB -> Fast nichts. ;)

Und dann gibt es ja auch noch die Datenbank-Komprimierung. https://dev.mysql.com/doc/refman/8.0/en ... ssion.html

Nicht das Du das jetzt machen must...

[ManfredH]

@Stabilostick:

Ergibt z.B. für 10000 Zahlenwerte am Tag 290000 Bytes = 283,2KB -> Fast nichts. ;) `
Mag sein, daß die Größe in Bytes da nicht das Kraut fett macht. Unter "Größe" verstehe ich eher die Anzahl der Records. Und je größer die ist, desto langsamer der Zugriff - da beißt die Maus keinen Faden ab. Nicht umsonst legen Hersteller wie SAP ihre Datenbanken mittlerweile in den Hauptspeicher (HANA).

Für mich ist das Thema insofern erledigt, als ich Daten, die sich oft ändern, deren Werte ich aber nicht so feingranular benötige (z.B. Außentemperatur) halt zyklisch (1 h) innerhalb meiner HomeMatic-Installation in eine zus. Variable kopiere und nur die speichere/logge.

[Stabilostick]

Habe Erfahrungen mit Einzeltabellengrößen von über 30TB. Wie gesagt, DBs können vieles. Alles eine Frage der Einstellung. :geek: