Bist Du sicher dass Dich Dein Gefühl nicht täuscht ?
Was Du da nutzt ist ja die Vorklimatisierung... keine Ahnung wie das über Home Assistant läuft aber das nutzt ja die gleiche API wie die Smartphone-Apps. Darüber wird auch eine Temperatur übergeben.
Wenn Du dann zum Fahrzeug kommst und das Fahrzeug aufschliest stoppt sofort die Vorklimatisierung und das Fahrzeug aktiviert wieder die zuletzt IM Fahrzeug eingestellten Einstellungen der Klimaanlage.
Bist Du sicher dass Dich Dein Gefühl nicht täuscht ?
Was Du da nutzt ist ja die Vorklimatisierung... keine Ahnung wie das über Home Assistant läuft aber das nutzt ja die gleiche API wie die Smartphone-Apps. Darüber wird auch eine Temperatur übergeben.
Wenn Du dann zum Fahrzeug kommst und das Fahrzeug aufschliest stoppt sofort die Vorklimatisierung und das Fahrzeug aktiviert wieder die zuletzt IM Fahrzeug eingestellten Einstellungen der Klimaanlage.
Hallo
Danke für deine Antwort
Ja ich bin mir hier ziemlich sicher. Meine Frage war, wie ich den Temperaturwert per Home Assistant an das Fahrzeug übermitteln kann.
Gruss Daniel
Hab' mir heute mal bei meinem Home Assistant die Integration https://github.com/DasBasti/SmartHashtag installiert. Funktioniert hervorragend:
Das kann ich nur bestätigen. Ich habe mir allerdings noch nicht so ein schönes Dashboard gebaut. Bisher nur alle Entities als Zahlen 
cmdrfletcher schönes Dashboard - kleiner Tipp: du kannst beim Reifendruck die Einheit in bar ändern, wenn du im more-info Dialog der Entität auf das Zahnrad klickst - HA rechnet das dann automatisch um für die Anzeige. Auch die Genauigkeit (Nachkommastellen) lassen sich dort einstellen.
Frage bzgl. Home Assistant: hat jemand historische Daten, sogenannte long term statistics, also Werte die über die im recorder „purge keep days“ eingestellte Zeit hinausgehen? Der Wert liegt standardmäßig bei 10 Tagen … hat jemand Werte die älter sind?
Ich wollte mir die monatlich gefahrenen Kilometer anzeigen lassen und habe dabei festgestellt, dass er die Daten gar nicht speichert. Ich vermute die Integration muss das bereit stellen, ggf. fehlt hier noch eine device_class oder unit_of_measurement damit HA das speichert, denn selbst aktiv was einstellen kann man meines Wissens nach nicht (hab natürlich geprüft, dass die von der Integration bereit gestellten Entitäten im recorder nicht „excluded“ sind). Kein der Smart-Entitäten scheint bei mir historische Daten zu speichern.
Hast Du mal versucht die entsprechende Entity explizit zu „includen“?
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.
Meine Vorgehensweise ist allerdings noch eine andere:
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.
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.
Damit möchte ich dann zukünftig eine grafische Auswertung, wie ich sie für unseren Zweitwagen bereits habe:
Die monatlich gefahrenen Kilometer haben seit März komischerweise extrem abgenommen 
