ich bin seit ein paar Wochen am lernen und noch im Status “Nachbauen” und noch nicht im Status “Selberbauen”.
Ich möchte grafisch sehen, wie sich der aktuelle Kilometerstand meiner beiden Leasingfahrzeuge im Vergleich zu den gemäss Leasingvertrag aktuell vorgesehenen Kilometern darstellt. Die Autos sind Skodas und die Skoda-Integration is installiert. Odometer (meistens) also in HA.
Ich habe mir die folgenden Templates erstellt.
#Berechnung der aktuellen Kilometer vs den eigentlich erlaubten Kilometern
Template
- trigger:
- platform: time
at: "23:59:00"
- trigger: state
entity_id: input_button.neu_berechnung_leasingkilometer
sensor:
- name: "LAU CK 504 - aktuelle Kilomterer vs aktuel erlaubte Leasingkilometer"
unit_of_measurement: km
device_class: distance
icon: mdi:speedometer
state_class: total_increasing
state: >
{% set start = as_timestamp("2022-04-14") %}
{% set end = as_timestamp("2026-04-13") %}
{% set tnow = as_timestamp(now()) %}
{{ states('sensor.lau_ck_504_odometer') | int(0) - ((40037 * ((tnow - start) / (end - start))) | int(0)) | int }}
- name: "LAU D 504E - aktuelle Kilometer vs aktuel erlaubte Leasingkilometer"
unit_of_measurement: km
device_class: distance
icon: mdi:speedometer
state_class: total_increasing
state: >
{% set start = as_timestamp("2022-12-08") %}
{% set end = as_timestamp("2026-12-07") %}
{% set tnow = as_timestamp(now()) %}
{{ states('sensor.lau_d_504e_odometer') | int(0) - ((40000 * ((tnow - start) / (end - start))) | int(0)) | int }}
Soweit funktioniert das auch. Allerdings ist die Skoda-Integration sehr unzuverlässig und v.a. bei dem einen Auto ist der Odometer sehr häufig “0”, was dann natürlich bei der Berechnung des Templates zu negativen Werten führt. Also möchte ich die Bedingung “Führe die Berechnung (neben der Uhrzeit) nur durch wenn Odometer > 0” aus.
Jetzt bin ich verwirrt. IN der HA-Doku steht, man kann Conditions in Templates integrieren … allerdings spuckt er mir dann eine Fehlermeldung aus. Und wenn man in Foren etc. liesst scheint es auch so zu sein, dass Conditions nicht in Templates integriert werden können?
Du kannst ein if/then in Deinen Jinja Code einbauen.
{% set odometer = states('sensor.lau_d_504e_odometer') | int(0) %}
{% if odometer > 0 %}
Deine Berechnung
{% else %}
Brauchtst Du ein else und was soll dann gemacht werden?
Vielleicht einfach nur eine 0
{% endif %}
EDIT:
Ich überlege noch wofür Du eigentlich ein Trigger basiertes Sensortemplate brauchst? Du hast 2 Odo-Sensoren und entweder über einen Button-Klick oder täglich um 23:59 Uhr soll eine Berechnung stattfinden, die sagt ob/wieviel km Du noch über hast.
Dafür würden auch 2 einfache Template Sensoren über die UI reichen, die ständig den Verbrauch berechnen/anzeigen ohne daß extra ein Button geklickt werden muß.
Auch einen Verbrauchszähler zu nehmen als Sensor ist für mich noch nicht schlüssig, es sei denn die Odo-Sensoren geben immer nur einzelne km-Stände an, die Du zählen willst, und nicht den gesamten? Dafür spräche Dein 23:59 Uhr Trigger aber andererseits kann der auch einfach nur dafür sein, auf dem Dashboard den Stand des letzten Tages zu haben.
Wenn ich die gewollte Logik nur nicht verstehe, nimm das if/then von oben und das sollte passen. Ansonsten schau mal ob Du nicht das Ganze schlanker machen kannst.
den Button habe ich nur vorübergehend eingebaut, weil ich nicht immer bis 23:59 Uhr warten wollte um es auszulösen um zu sehen was passiert … wenn alles läuft kommt er weg
Die Idee mit dem if/else etc. hatte ich auch bereits, aber noch nicht probiert. Brauche ich denn ein else? Weil z.B. 0 möchte ich ja eben nicht … er soll einfach nichts berechnen wenn Odo nicht grösser 0 … also nicht wirklich verfügbar.
Wenn ich else einfach auf “none” stelle, passiert genau nix? das wäre dann die Lösung
Dieses Template würde dann aber jede Minute den Sensor neu berechnen, richtig? Auch das wollte ich gerne vermeiden. Die “gemäss Leasing erlaubten” Kilometer würden sich dann im Laufe des Tages ständig verändern - so wäre zumindest meine Vermutung gewesen, wenn er denn ganz genau rechnen würde. Oder nimmt er dann tatsächlich nur die Tage? Grundsätzlich würde mir der Wert einmal am Tag reichen … daher der Trigger 23:59. Grundsätzlich soll das ganze dann über einen längeren Zeitraum grafisch dargestellt werden - da reicht mir der Wert einmal am Tag.
Sorry für die blöde Frage (sagte ja, bin noch am lernen und spiele daher bewusst noch mit nur so belanglosen Sachen rum): was genau meinst du mit Verbrauchszähler? Du meinst wegen der state_class: total_increasing?
Die Odometer geben natürlich fortlaufende Zahlen, eben den aktuellen Kilometerstand.
Ich meine mal gelesen zu haben, dass nur mit der state-class: total_increasing die Werte in die HA-eigene Datenbank gehen und sich nur somit auch längere Zeitachsen grafisch darstellen lassen. Und er summiert tatsächlich auch nicht auf - hätte gedacht dies liegt an der ständigen Neuberechnung.
Habe auf jeden Fall schon wieder was gelernt … vielen Dank schonmal.
hier rechne ich mit *(-1) die Tage aus, die ich das Auto habe, die *27 sind die täglichen km bei 10000 km Fahrleistung/Jahr, davon subtrahiere ich die gefahrenen km. In dem Sensor habe ich dann die aktuell möglichen km.
Wenn die Abweichung jetzt über 250 km ist, bekomme ich eine Meldung auf meinem Dasboard, die kann ich dann anklicken und es öffnet sich ein Popup, in dem die überschrittenen km stehen.
Vielen Dank Stephan und roudini,
beides sehr interessante Ansätze … und ich hä auch wieder eine Menge gelernt.
So wie ich das sehe, löst aber beides nicht mein Hauptproblem. Der Odometer vom den einen Auto (Octavia iV) ist sehr unzuverlässig und zeigt häufig 0 km. Der des Kodiaq wiederum ist eigentlich immer akurat - sollte also nicht zwingend an der Skoda-Integration liegen. Heisst also immer wenn eine Berechnung durchgeführt wird (also egal ob jede Minute, stündlich, möglich oder wann auch immer) sind die Ergebnisse natürlich falsch. Daher sehen natürlich auch jegliche Graphen total blöd aus.
Das Hauptthema ist also, eine Berechnung zu unterbinden wenn der Odometer mal wieder auf 0 steht - egal wie oft und in welcher Form eine Berechnung stattfindet.
Ich werde es jetzt mal mit dem if/else und else non probiere.
Du könntest auch den kompletten ELSE Zweig dann weglassen.
Ja es würde minütlich berechnet werden und als Ergebnis die Berechnung der Werte ausgeben, die es gerade bekommen hat.
Das finde ich gut. Jede Abkürzung bei den Basics holt einen später sowieso wieder ein und dann merkt man man hätte viele Dinge von Anfang an anders machen sollen. Nimmt man sich dann die Zeit, um alles wieder umzubauen, geht doch erstmal? Ich habe es fast immer gemacht.
Ja, das macht Deinen Template Sensor zu einem Verbrauchszähler.
Vielleicht reicht bei Dir auch einfach als State Class: measurement um Dir am Ende den Verlauf anzuschauen.
Da schwimme ich etwas weil ich selbst mit keinem Total_Increasing Sensor arbeite.
Meine Erklärung geht in in diese Richtung: Deine Berechnung berechnet Unterschiede zwischen einem fixen und variablem km Stand. In der Doku steht:
Similar to SensorStateClass.TOTAL , with the restriction that the state represents a monotonically increasing positive total which periodically restarts counting from 0, e.g. a daily amount of consumed gas, weekly water consumption or lifetime energy consumption. Statistics of the accumulated growth of the sensor’s value since it was first added is updated every 5 minutes. A decreasing value is interpreted as the start of a new meter cycle or the replacement of the meter.
)
