Danke dir Vaio 105 . Bestellt und bezahlt, bin gespannt. 
Beiträge von Kanecaine
-
-
Wenn bei dir das GPS vom Smart gestört ist, ist das aber womöglich ein gänzlich anderes Fehlerbild. Ich kann zum GPS des Smarts nichts sagen, da ich das Smart Navi bisher kaum verwendet habe. Die Probleme hatte ich mit dem GPS am Handy und zwar direkt nach dem Einsteigen, auch wenn das Handy gar nicht mit dem Auto verbunden ist.
Wie dem auch sei: die Probleme ließen sich bei mir durch Verwendung eines anderen USB-Sticks beheben und ich bezweifle dass die von Smart genannten Schritte bei mir geholfen hätten.
-
Was ist der Fehler gewesen in welchem Zustand muss nach bestätigen SW installieren das Fahrzeug sein?
Ich würde sagen, so wie im Display angezeigt: Auto verlassen und abschließen.
-
Oder ne schaltbare Stromunterbrechung, die bequem aus dem Innenraum erreichbar ist
-
Interessante Frage - habs ausprobiert: das Problem tritt in dem Fall nicht auf, der GPS- Empfang wird nicht beeinträchtigt. Probiert an verschiedenen Geräten, selbst wenn der Stick direkt im iPhone steckt.
-
Geht ansonsten auch mit Bordmitteln, nur nicht ganz so hübsch:
Code
Alles anzeigentype: statistics-graph chart_type: bar period: month entities: - entity: sensor.i3s_120_mileage name: Kilometer title: Gefahrene Kilometer stat_types: - change days_to_show: 120 hide_legend: true logarithmic_scale: false -
Hey, danke … das mit dem customizing der Entities probier ich mal aus. Wäre mir deutlich lieber, als die vorhandenen Entitäten zu duplizieren.
Die grafische Auswertung nach Monaten kannst du mit Apex-Charts aus dem HACS store erreichen. Hier mein Code für das Chart oben.
Code
Alles anzeigentype: custom:apexcharts-card header: show: true title: Gefahrene Kilometer show_states: true colorize_states: true graph_span: 5month span: end: month apex_config: dataLabels: background: enabled: true borderWidth: 0 opacity: 0 foreColor: black dropShadow: enabled: true color: '#000' opacity: 0.3 style: fontSize: 14px fontWeight: normal plotOptions: bar: borderRadius: 6 borderRadiusApplication: end dataLabels: position: top chart: height: 200px dropShadow: enabled: true opacity: 0.3 grid: padding: top: 0 right: 0 bottom: 0 left: 0 yaxis: lines: show: false legend: show: false xaxis: labels: datetimeFormatter: month: '' day: MMMM tooltip: enabled: false tooltip: enabled: false all_series_config: type: column show: datalabels: true yaxis: - id: left min: 0 show: false series: - entity: sensor.i3s_120_mileage name: monatlich i3s color: '#2adea8' opacity: 0.9 show: in_header: false statistics: type: change period: month align: middle - entity: sensor.i3s_120_mileage name: gesamt BMW i3s color: '#2adea8' opacity: 0.9 show: in_chart: false -
Aber was ich immer höre wegen dem Piepsen usw. das Problem habe ich nicht und muss auch nicht immer alles neu ausstellen.
Weil du einen #1 fährst. Das nervige Verhalten betrifft aktuell nur den #3.
-
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
-
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.
