Hast Du mal versucht die entsprechende Entity explizit zu „includen“?
Nein, denn ich bin mir ziemlich sicher, dass das so nicht funktioniert. Entweder die Entität unterstützt LTS (long term statistics) oder nicht. „include“ ist dafür gedacht wie du es gemacht hat, wenn man nur bestimmte Entitäten langfristig speichern möchte.
Kein Wert wird übrigens länger als die Tage gespeichert, der in „purge keep days“ hinterlegt sind.
Also entweder den Wert erhöhen oder die Daten in eine andere DB schreiben.
Das war vielleicht etwas unsauber formuliert von mir. Mir ist bewusst, dass in den LTS ein statischer Mittelwert pro Stunde(?) erfasst wird sowie min und max. Aber genau das möchte ich ja für alle meine Werte. Meine „purge keep days“ habe ich von 10 auf 7 gesenkt. So habe ich eine Woche alle gemessenen Rohwerte, quasi in maximaler Auflösung. Darüber hinaus reicht mir der statistische Wert. Die Art, wie HA das macht, ist prinzipiell schon gut. Perspektivisch werde ich die „purge keep days“ vermutlich sogar noch weiter senken, auf vielleicht 3 Tage. Denn gerade Sensoren für CPU-Load- oder RAM-Auslastung „messen“ i.d.R alle paar Sekunden, eine separate DB möchte ich aber vermeiden. Zumal ich die Daten in voller Auflösung ohnehin nicht benötige für weiter in die Vergangenheit.
Ich habe die Historie so konfiguriert, dass sie nur Werte speichert, die ich explizit in der yaml aufliste. Da das nur eine Handvoll sind, kann ich mir erlauben, den Wert „purge keep days“ extrem hoch zu setzen. In der vorgegebenen Einstellung würde es auf kurz oder lang aufgrund einer zu großen Datenbank zu Problemen kommen, wenn man den Wert ändert.
Richtig, deshalb sollte der Wert nicht erhöht werden, wenn man viele Werte hat und mit „exclude“ arbeitet. Ich möchte aber auch weiterhin alles in der Statistik haben, denn die Notwendigkeit ergibt sich oftmals erst später. Die Brennerstarts meiner Gasheizung hätte ich beispielsweise nie in der Statistik gespeichert, denn was interessiert es mich, wann das Ding an oder aus war. Dann aber kam der Tag, als ich meine Heizung optimieren wollte und da war es essenziell, auch Daten zu haben, die länger zurückliegen. Oder wie eben jetzt, der Kilometerstand vom Smart. Bisher reichte mir der aktuelle / letzte Wert. Wenn ich mir das aber monatlich anzeigen lassen möchte, brauche ich LTS.
Ich habe knapp über 1000 Entitäten und davon etwa 700 Sensoren. Meine DB ist ca. 4 Jahre alt und ich bin noch unter 1 GB DB-Größe. Trotzdem kann ich sehen, wie warm es vor 3 Jahren im Juli war oder wie hoch mein Gasverbrauch im Vergleich zum Vorjahreszeitraum ist - bei Bedarf sogar stundenscharf. Das reicht mir vollkommen. Wichtig bei diesem Vorgehen ist, die Sensoren zu identifizieren, die wirklich viel Daten erzeugen und diese zu „excluden“. Ich hoffe ja, dass irgendwann mal noch eine „purge keep days“ Einstellung pro Entität kommt. Dann kann man das viel besser konfigurieren als dieser „alles oder nichts“-Ansatz. Der Feature-Wunsch hat jedenfalls schon viele Likes im Backlog.
In dem Sinne: danke für den Tipp, aber ich fahre mit meinem Ansatz generell gut und er entspricht auch der Standard-Konfiguration von HA. Bei deinem Ansatz müsste ich vorher schon für jede Entität genau wissen, ob ich historische Daten benötige.
Wenn ich das so richtig verstanden habe müsste der Wert eine property "state_class" vom Typ "measurement", "total" oder "total_increasing" habe. Z.B. die gefahrenen Kilometer wäre dann "total_increasing".
Richtig, so auch mein Verständnis von der Konfiguration diverser Template-Sensoren. Ich denke, das muss auch die Integration für alle Entitäten setzen, damit es funktioniert.
Ich habe mir übrigens einen Helfer erstellt, der mir die geladene Energie aufsummiert und die landen in der Langzeitstatistik.
Ich habe mir gestern kurzerhand Template-Sensoren erstellt. Diese duplizieren einfach den bereits vorhandenen Sensor und haben die o.g. propertys gesetzt, damit Langzeitdaten gespeichert werden.
IMG_0492.jpg
Damit möchte ich dann zukünftig eine grafische Auswertung, wie ich sie für unseren Zweitwagen bereits habe:
IMG_0493.jpeg
Die monatlich gefahrenen Kilometer haben seit März komischerweise extrem abgenommen 
Stick rein, GPS weg. Stick raus, GPS da. Hab dann sogar auf der Ladematte besten Empfang, da wo vorher gar kein Empfang war. Logisch: da liegt das Handy ja auch direkt neben dem Stick.