NEWS
Verbrauchsdaten sinnvoll loggen
-
Hallo zusammen,
ich habe seit kurzem ein paar Tasmota-Stecker und möchte nun die Daten loggen (bzw. mach ich das schon). Ich nutze dazu die influxDB. Meine Stecker hab ich auf einen publish-Intervall von 5s gesetzt. In den Standardeinstellung wird ja nun jede Veränderung geloggt. Im "schlechtesten" Fall also alle 5s. Ich bin aber noch zu frisch in der Thematik, um abschätzen zu können welche Datenmenge hier zusammen kommt. Aus dem Bauch heraus würde ich schätzen, dass innerhalb eines Jahres eine große Menge an Daten zusammen kommt und entsprechend viel Speicherplatz einnimmt. Wie sollte ich also die Daten loggen, um verwertbare Ergebnisse zu erhalten und möglichst Ressourcen zu schonen?
Gruß Martin
@mariatschi0815 Ich logge >200 DPs, davon auch einige im 6 Sekundentakt.
Das ergibt schon bei History eine Menge Daten. Datenbanken sind da wahrscheinlich etwas sparsamer.
Aber bei heutigen Speichermediengrößen ist das auch kein Problem. -
Hallo zusammen,
ich habe seit kurzem ein paar Tasmota-Stecker und möchte nun die Daten loggen (bzw. mach ich das schon). Ich nutze dazu die influxDB. Meine Stecker hab ich auf einen publish-Intervall von 5s gesetzt. In den Standardeinstellung wird ja nun jede Veränderung geloggt. Im "schlechtesten" Fall also alle 5s. Ich bin aber noch zu frisch in der Thematik, um abschätzen zu können welche Datenmenge hier zusammen kommt. Aus dem Bauch heraus würde ich schätzen, dass innerhalb eines Jahres eine große Menge an Daten zusammen kommt und entsprechend viel Speicherplatz einnimmt. Wie sollte ich also die Daten loggen, um verwertbare Ergebnisse zu erhalten und möglichst Ressourcen zu schonen?
Gruß Martin
@mariatschi0815
Wenn man "nur Änderungen aufzeichnet" (ist z.B. beim SQL-Adapter Standard) hält sich die Datenmenge eigentlich in Grenzen.
Und 'ne halbwegs vernünftige Datenbank sollte auch mit Millionen von Datensätzen nicht wirklich Probleme bekommen.
Zusätzlich lässt sich die Aufbewahrungsdauer einstellen.Ich persönlich arbeite das mit dem SQL-Adapter und 'ner MySQL (MariaDB) Datenbank - auch wenn Influx da wegen zeitorientierter Speicherung angeblich Vorteile haben soll. Ich bin halt beruflich bzgl. SQL vorbelastet ;-)
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@mariatschi0815 Ich logge >200 DPs, davon auch einige im 6 Sekundentakt.
Das ergibt schon bei History eine Menge Daten. Datenbanken sind da wahrscheinlich etwas sparsamer.
Aber bei heutigen Speichermediengrößen ist das auch kein Problem.@homoran Achso, die ganze Geschichte läuft auf einem Pi4 mit rund 30GB verfügbarem diskspace. Habe ich vergessen zu erwähnen.
-
@mariatschi0815
Wenn man "nur Änderungen aufzeichnet" (ist z.B. beim SQL-Adapter Standard) hält sich die Datenmenge eigentlich in Grenzen.
Und 'ne halbwegs vernünftige Datenbank sollte auch mit Millionen von Datensätzen nicht wirklich Probleme bekommen.
Zusätzlich lässt sich die Aufbewahrungsdauer einstellen.Ich persönlich arbeite das mit dem SQL-Adapter und 'ner MySQL (MariaDB) Datenbank - auch wenn Influx da wegen zeitorientierter Speicherung angeblich Vorteile haben soll. Ich bin halt beruflich bzgl. SQL vorbelastet ;-)
@codierknecht Na um die Datenbank mach ich mir da keine Sorgen. :D
Es geht mir eher um den benötigten Speicher, da ich die Daten mindestens ein Jahr aufbewahren möchte. Die Einstellung mit dem Vorhalten ist mir auch bekannt. Ich bin nur unschlüssig ob es sinnvoll ist die Daten länger als ein Jahr zu behalten.
-
@homoran Achso, die ganze Geschichte läuft auf einem Pi4 mit rund 30GB verfügbarem diskspace. Habe ich vergessen zu erwähnen.
@mariatschi0815 said in Verbrauchsdaten sinnvoll loggen:
Achso, die ganze Geschichte läuft auf einem Pi4 mit rund 30GB verfügbarem diskspace. Habe ich vergessen zu erwähnen.
Das wird Deine SD-Karte sehr sehr viel schreiben müssen. Eventuell auf die Lebensdauer achten.
-
@mariatschi0815
Wenn man "nur Änderungen aufzeichnet" (ist z.B. beim SQL-Adapter Standard) hält sich die Datenmenge eigentlich in Grenzen.
Und 'ne halbwegs vernünftige Datenbank sollte auch mit Millionen von Datensätzen nicht wirklich Probleme bekommen.
Zusätzlich lässt sich die Aufbewahrungsdauer einstellen.Ich persönlich arbeite das mit dem SQL-Adapter und 'ner MySQL (MariaDB) Datenbank - auch wenn Influx da wegen zeitorientierter Speicherung angeblich Vorteile haben soll. Ich bin halt beruflich bzgl. SQL vorbelastet ;-)
@codierknecht sagte in Verbrauchsdaten sinnvoll loggen:
Wenn man "nur Änderungen aufzeichnet" (ist z.B. beim SQL-Adapter Standard) hält sich die Datenmenge eigentlich in Grenzen.
Trugschluss!
Eine Messsteckdose wird nie keine Änderung in der Leistung haben! Außer der angeschlossene Verbraucher ist ausgeschaltet.
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@codierknecht sagte in Verbrauchsdaten sinnvoll loggen:
Wenn man "nur Änderungen aufzeichnet" (ist z.B. beim SQL-Adapter Standard) hält sich die Datenmenge eigentlich in Grenzen.
Trugschluss!
Eine Messsteckdose wird nie keine Änderung in der Leistung haben! Außer der angeschlossene Verbraucher ist ausgeschaltet.
-
@codierknecht sagte in Verbrauchsdaten sinnvoll loggen:
Wenn man "nur Änderungen aufzeichnet" (ist z.B. beim SQL-Adapter Standard) hält sich die Datenmenge eigentlich in Grenzen.
Trugschluss!
Eine Messsteckdose wird nie keine Änderung in der Leistung haben! Außer der angeschlossene Verbraucher ist ausgeschaltet.
@homoran said in Verbrauchsdaten sinnvoll loggen:
Eine Messsteckdose wird nie keine Änderung in der Leistung haben! Außer der angeschlossene Verbraucher ist ausgeschaltet.
Oder der angeschlossene Verbraucher ändert seine Leistung dynamischSorry, ich habe die doppelte Verneinung überflogen.
-
@codierknecht Na um die Datenbank mach ich mir da keine Sorgen. :D
Es geht mir eher um den benötigten Speicher, da ich die Daten mindestens ein Jahr aufbewahren möchte. Die Einstellung mit dem Vorhalten ist mir auch bekannt. Ich bin nur unschlüssig ob es sinnvoll ist die Daten länger als ein Jahr zu behalten.
@mariatschi0815 sagte: da ich die Daten mindestens ein Jahr aufbewahren möchte.
Was macht man mit zeitlich so hoch aufgelösten Daten nach einem Jahr?
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: RPi 2 mit S.USV, HM-MOD-RPI und SLC-USB-Stick mit root fs -
@mariatschi0815 sagte: da ich die Daten mindestens ein Jahr aufbewahren möchte.
Was macht man mit zeitlich so hoch aufgelösten Daten nach einem Jahr?
@paul53 sich ärgern!
aber in dem Moment braucht man es.
Hab auch noch keine Lösung gefunden, außer zwei Datenreihen mit unterschiedlicher Retention zu basteln. -
@mariatschi0815 sagte: da ich die Daten mindestens ein Jahr aufbewahren möchte.
Was macht man mit zeitlich so hoch aufgelösten Daten nach einem Jahr?
@paul53 said in Verbrauchsdaten sinnvoll loggen:
Was macht man mit zeitlich so hoch aufgelösten Daten nach einem Jahr?
Das ist der Punkt, letztlich möchte ich ja nur wissen wieviel kWh Waschmaschine usw. verbraucht haben. Eventuell mal noch prüfen wann der Verbrauch am höchsten war, eventuell monats- oder wochenweise.
-
@paul53 sich ärgern!
aber in dem Moment braucht man es.
Hab auch noch keine Lösung gefunden, außer zwei Datenreihen mit unterschiedlicher Retention zu basteln.@homoran Darauf läuft es aber wohl ehesten hinaus. :grin:
-
@paul53 said in Verbrauchsdaten sinnvoll loggen:
Was macht man mit zeitlich so hoch aufgelösten Daten nach einem Jahr?
Das ist der Punkt, letztlich möchte ich ja nur wissen wieviel kWh Waschmaschine usw. verbraucht haben. Eventuell mal noch prüfen wann der Verbrauch am höchsten war, eventuell monats- oder wochenweise.
@mariatschi0815 sagte: wann der Verbrauch am höchsten war
Tagesverbrauch ermitteln und historisieren.
Support us
467
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge