Hi Community!
influxdb soll doch eigentlich nur bei Statusänderungen von Entitäten einen Datensatz durchreichen, oder?
Ich habe schon öfter bei Queries in Grafana festgestellt, dass z.B. bei binären Sensoren mehrmals hintereinander “off” oder “on” steht. Das widerspricht doch der Logik von influxdb, oder nicht?
Hier ein Beispiel einer Tür:
time
state.device_class_str
state.domain
state.entity_id
state.state
state.value
23.09.2024 09:54
door
binary_sensor
door_entry_1_contact
off
0
23.09.2024 09:56
door
binary_sensor
door_entry_1_contact
off
0
23.09.2024 10:08
door
binary_sensor
door_entry_1_contact
off
0
23.09.2024 10:43
door
binary_sensor
door_entry_1_contact
off
0
23.09.2024 10:48
door
binary_sensor
door_entry_1_contact
off
0
23.09.2024 10:50
door
binary_sensor
door_entry_1_contact
on
1
23.09.2024 10:50
door
binary_sensor
door_entry_1_contact
off
0
23.09.2024 11:09
door
binary_sensor
door_entry_1_contact
on
1
23.09.2024 11:09
door
binary_sensor
door_entry_1_contact
off
0
23.09.2024 11:39
door
binary_sensor
door_entry_1_contact
off
0
Oder noch besser zu sehen bei einem Tageszeitensensor (Abends = 18:00 - 00:00 Uhr)
time
state.device_class_str
state.domain
state.entity_id
state.state
state.value
23.09.2024 09:44
binary_sensor
abends
off
0
23.09.2024 09:51
binary_sensor
abends
off
0
23.09.2024 10:02
binary_sensor
abends
off
0
23.09.2024 10:37
binary_sensor
abends
off
0
23.09.2024 10:48
binary_sensor
abends
off
0
23.09.2024 11:38
binary_sensor
abends
off
0
23.09.2024 13:27
binary_sensor
abends
off
0
23.09.2024 18:00
binary_sensor
abends
on
1
23.09.2024 22:04
binary_sensor
abends
on
1
24.09.2024 00:00
binary_sensor
abends
off
0
Es sind erschreckend viele Einträge, die m.E. unnötig sind und nur Speicherplatz wegnehmen.
Eine Zeit lang dachte ich, es liegt vielleicht an Änderungen von Attributen von Sensoren, an Neustarts von HA (weil sich ja dann immer der Status von “unavailable”/“unknown” wieder ändert), aber 1) betrifft es auch Sensoren ohne Attribute und 2) kann man gar nicht so oft HA neustarten wie das passiert.
Daher meine Frage: ist das normal? Ist das bei Euch auch so?
Hier meine Konfiguration für influxdb:
influxdb:
username: ha_influxdb_user
password: !secret influxdb_password
precision: ms
tags:
source: HA
tags_attributes:
- friendly_name
default_measurement: state
eigentlich wären “viele” Einträge durchaus eine gute Sache. Wenn sich der Status nicht regelmässig aktualisiert, hast du ggf keine Daten mehr in Grafana. Du kannst natürlich den Query Zeitraum höher drehen, das geht aber wieder zu Lasten der Performance.
InfluxDB ist eine Timeseries Datenbank, und somit werden Daten anhand der Zeit, gespeichert, wenn jetzt in HA ein binary-sensor, oä. sich vom Status nicht ändert, aber trotzdem sich bei HA meldet,
Hallo HA, bei mir gibt es nichts neues, stehe immer noch auf off
Dann ist das ein anderer Zeitstempel und somit wird dieser auch an InfluxDB übertragen, sollte es in der Gleichen ms zwei Meldungen geben, dann vermute ich mal, dass dann nur einer in InfluxDB eingetragen wird, man kann glaube ich auch aus ns gehen, das ist für Daten wichtig, die sich wirklich auf diesem Zeitbereich abspielen.
Eine andere Sache ist, welchen Sinn es macht, diese Daten in InfluxDB aufzubewahren, sollte man das brauchen, könnte man den/diese Sensoren auch in HA direkt für länger als den Standardzeitraum speichern.
Hi Bernd,
danke für deinen Beitrag.
Per Definition soll HA nur Statusänderungen nach InfluxDB übertragen. Das soll ja die Datenbank so sparsam machen, was Speicherplatz angeht, denn sie ist darauf ausgelegt, über viele Jahre Daten zu speichern. Timeseries bedeutet einfach nur, dass jeder Datensatz einen Zeitstempel kriegt.
Die interne HA-Datenbank speichert bei mir 10 Tage und ist 1,5 GB groß. Zum Vergleich: meine InfluxDB-Datenbank ist 1,8 GB groß und schreibt seit 1,5 Jahren Daten für die gleichen Sensoren.
Über viele Jahre betrachtet macht es daher einen großen Unterschied, wie viele Datensätze in InfluxDB geschrieben werden. Wenn ich eine Tür habe, die 2 Jahre lang geschlossen ist, dann sollte nach meinem Verständnis am Anfang der 2 Jahre ein “off” mit Zeitstempel geschrieben werden und der nächste Eintrag erst nach Ablauf der zwei Jahre mit “on” erfolgen. Aber so wie das bei mir läuft habe ich nach zwei Jahren hunderte bis tausende Einträge mit “off”, und das bei ca. 70 Sensoren insgesamt.
Daher vermute ich, dass die Speicherung der Daten bei mir nicht so läuft wie vorgesehen, und mich interessiert, ob die Ursache/Lösung dafür in InfluxDB oder HA liegt.
maybe it is because one of the entity’s attributes changes every 30 seconds.
Habe das im englischsprachigen Forum schon mal kritisiert. Ein Nebensatz erklärt vermutlich das Verhalten. Wahrscheinlich ändert sich ein Attribut und das nimmt dann deinen Wert “off” mit auf.
Du kannst mal testen und Attribute komplett rausnehmen oder einen separaten Template Sensor anlegen der nur On/Off logggt. Dann hast du nur den einen Wert.
Ansonsten kannst du einen Bug im Issue Tracker anlegen. Vermutlich wird es aber geblockt.
Hi mostie,
danke für Deinen Betrag. Wir nähern uns…
ich habe jetzt sämtliche Atrribute ausgeschlossen, so wie ich die Doku verstanden habe, siehe hier:
Allerdings ist mir aufgefallen, dass weiterhin mehrere "off"s hintereinander stehen. Nach der Verlaufsanalyse ist es “battery”, also das Attribut Batteriestand der Entität ‘contact’, was sämtliche Duplikate triggert. Es wechselt z.B. von 75% auf 74% und nach einer Weile wieder zurück. Dies scheint durch meine ignore-Anweisung nicht verhindert zu werden, also vermute ich, sie hat keine Wirkung. Kannst Du eventuell sehen, ob ich etwas falsch gemacht habe?
Ein Template für alle Geräte würde ich gerne vermeiden. Das ist viel Arbeit bei den ganzen Türen und Fenstern und zumindest ein “einfaches” Template kriegt das Problem nicht korrigiert, dass bei einem HA-Neustart nochmals geschrieben wird, weil sich der Status von “unknown” oder “unavailable” auf “off” ändert. Das müsste man zusätzlich mit Triggern machen.
Aber “ignore_attributes” hört sich trotzdem irgendwie nach der richtigen Lösung an. Ich finde nirgendwo ein gültiges Beispiel, wie man es richtig in die YAML schreibt…
Ich meinte mit Attribute rausnehmen, die Sensoren im Device zu deaktiveren. Dann hast du in deinem Fall aber keine Prozentangabe zur Batterie.
Damals habe ich in der Diskussion den Kommentar gemacht da die Aussage war, es gibt nur eine Änderung wenn sich der Wert ändert. Was bei mir nachgewiesen nicht der Fall ist. Bei dir genau so wenig.
Ich habe alles virtualisiert, Blech und Speicher ist im Überfluss vorhanden darum akzeptiere ich es wie es ist und lass die Datenbank wachsen.
Wachstum scheint aber dennoch zu groß. Setze explizit was du includieren willst. Ich denke nicht dass der Türsensor alleine die Datenbank so wachsen lässt. Viel mehr die Summe aller. Du kannst bei include/exclude auch mit Platzhaltern arbeiten, … “- sensor.temperatur”.
Hi,
ja die Excludes und Includes habe ich auch schon konfiguriert, nur nicht mit gepostet mangels Relevanz.
Ich hatte kürzlich eine große Aufräumaktion, in der ich die Datenbank von 2,6 GB auf 1,8 GB verkleinert hatte. Speicher habe ich noch genug, aber da ich Backups noch zu einer weiteren Adresse übers Internet uploade will ich sie nicht unnötig groß haben. Außerdem versuche ich mich parallel am Thema “state duration” (z.B. Wie lange lief der Fernseher in diesem Monat/Jahr?), bei dem man eigentlich zwei Punkte braucht (on bis off) und dann die Zeit aus den timestamps abzieht. Und das geht natürlich nicht so gut, wenn man mehrere "on"s hintereinander hat.
Ich glaube immernoch, dass es irgendwie mit den configuration variables gehen muss…
Falls ich was rausfinde, poste ich hier. Ansonsten sind weitere Vorschläge, insbesondere, ob mein “ignore_attributes” verbessert werden könnte, gern gesehen
