BETA-Tester: ESC Einfach und schnell Sensoren und Auswertungen erstellen -ohne Vorkenntnisse

RELASE CANDIDATE VERÖFFENTLICHT

Was kann ESC für dich machen?

wenn du neu bei Home Assistant bist, merkst du schnell, wie unglaublich mächtig es ist. Du merkst aber auch, dass manche Dinge, die einfach klingen, plötzlich kompliziert werden und du Code in seltsamen “YAML”-Dateien schreiben sollst.

Genau hier setzt diese Integration an. “ESC Easy Sensor Creation” ist deine Abkürzung zu mächtigeren Sensoren – ganz ohne eine einzige Zeile Code.

Stell dir vor, du möchtest eine der folgenden, typischen Aufgaben erledigen:

  1. “Ich will meinen Stromverbrauch im Energie-Dashboard sehen!”
  • Der normale Weg: Du musst manuell einen komplizierten “Riemann-Summen-Integral-Sensor” in einer YAML-Datei erstellen, um den Verbrauch von Watt (W) in Kilowattstunden (kWh) umzurechnen.
  • Der Weg mit ESC: Du klickst auf “kWh-Sensor erstellen”, wählst deinen Steckdosen-Sensor aus, gibst ihm einen Namen. Fertig.
  1. “Ich habe drei Lampen im Wohnzimmer. Was verbrauchen die zusammen?”
  • Der normale Weg: Du musst einen “Template-Sensor” in YAML schreiben, der die Werte der drei einzelnen Lampen zusammenzählt und dabei auf Fehler achten muss.
  • Der Weg mit ESC: Du klickst auf “Summen-Sensor erstellen”, wählst die drei Lampen aus der Liste aus. Fertig. Der Sensor zeigt dir immer die aktuelle Gesamtsumme an.
  1. “Was war heute die höchste Temperatur auf dem Balkon?”
  • Der normale Weg: Das ist richtig schwierig und erfordert oft komplexe Datenbankabfragen (SQL), um an die Verlaufsdaten zu kommen.
  • Der Weg mit ESC: Du klickst auf “Verlaufs-Statistik erstellen”, wählst “Maximum - Heute” und deinen Temperatursensor aus. Fertig.

Warum ist das gerade für Anfänger ideal?

Diese Integration nimmt dir die komplizierte und fehleranfällige Arbeit im Hintergrund ab. Sie bietet dir eine einfache, geführte Menü-Oberfläche für Aufgaben, die sonst tiefes technisches Wissen erfordern würden.

Du kannst dich darauf konzentrieren, was du erreichen möchtest, anstatt daran zu verzweifeln, wie du es programmieren musst.

Kurz gesagt: ESC ist dein Werkzeugkasten, um Home Assistant schnell und einfach um nützliche, intelligente Sensoren zu erweitern, die dir einen echten Mehrwert bieten.

ESC Easy Sensor Creation - v5.1.0-rc1

CHANGELOG:

Ich freue mich, den ersten Release-Candidate für eine von Grund auf modernisierte Version von ESC Easy Sensor Creation zu veröffentlichen. Dein Feedback war entscheidend, um die Integration stabiler, sauberer und viel benutzerfreundlicher zu machen. Ich habe die Kernfunktionen beibehalten, aber die Art und Weise, wie sie umgesetzt werden, drastisch verbessert.


## Was ist NEU und BESSER? (Vergleich zur alten Version)

1. Energie-Sensor (W → kWh): Komplett neu und 100% robust!

  • FRÜHER: Es gab einen eigenen “Wh Integration Sensor”, der mit einer eigenen Formel (E = P_old × Δt / 1000) die Energie berechnet hat. Das war gut, aber nicht perfekt und musste nach einem Neustart den Status wiederherstellen.
  • JETZT: Ich habe diesen eigenen Sensor komplett entfernt! Wenn Du jetzt einen kWh-Sensor erstellst, weist Du ESC an, einen nativen Home Assistant Riemann-Summen-Helfer zu erstellen.
    • :white_check_mark: Maximale Präzision: Nutzt den offiziellen, vom Home Assistant Team gepflegten Algorithmus.
    • :white_check_mark: Zukunftssicher: Profitiert automatisch von allen zukünftigen Verbesserungen in Home Assistant.
    • :white_check_mark: Echter Helfer: Du findest und verwaltest Deinen neuen Sensor direkt unter Einstellungen > Geräte & Dienste > Helfer. Er ist perfekt für das Energie-Dashboard geeignet.

2. Summen-Sensor: Jetzt noch intelligenter!

  • FRÜHER: Der Sensor hat einfach alles addiert, was Du ihm gegeben hast.
  • JETZT: Die Kernfunktion bleibt, aber mit einem wichtigen Sicherheitsnetz. Der Sensor prüft jetzt, ob alle Deine Quellsensoren die gleiche Maßeinheit haben. Das verhindert unsinnige Berechnungen (z.B. Temperatur + Watt) und sorgt für verlässliche Ergebnisse.

3. SQL Statistik-Sensoren: Der Kern der Integration, aber aufgeräumt!

  • FRÜHER: Du hattest eine lange Liste an Sensor-Typen und musstest Dich um die Datenbank-Verbindung (SQLite oder MariaDB) kümmern. Der Sensor hatte eine komplexe Fallback-Logik zur states-Tabelle.
  • JETZT: Die mächtige Funktion, Durchschnitts-, Maximal- und Minimalwerte für Tag, Monat und Jahr zu erstellen, bleibt das Herzstück! Aber ich habe es vereinfacht:
    • :white_check_mark: Keine Datenbank-Konfiguration mehr: Du musst Dich nicht mehr um MariaDB-Zugangsdaten kümmern. Der Sensor nutzt die moderne Recorder-API von Home Assistant, die das für Dich im Hintergrund erledigt.
    • :white_check_mark: Sauber und zuverlässig: Die Abfragen sind jetzt standardisiert und nutzen die offizielle Schnittstelle, was sie robuster macht.

## Weitere Verbesserungen

  • :sparkles: Zentrales Gerät: Anstatt für jeden Sensor ein neues Gerät zu erstellen, gibt es jetzt nur noch ein einziges Gerät “ESC Easy Sensor Creation”. Alle Deine Summen- und Statistik-Sensoren werden dort sauber als Entitäten angehängt.
  • :sparkles: Klares UI: Alle Texte und Beschreibungen im Konfigurations-Dialog wurden überarbeitet, um Dich besser durch die Erstellung zu führen.
  • :sparkles: Sensor-Klassifizierung (Device Class): Auf mehrfachen Wunsch kannst Du Deinen Sensoren nun eine Klasse zuweisen (z.B. Energie, Power, Temperatur). Dies hilft Home Assistant, das richtige Icon und die korrekte Formatierung anzuzeigen.
  • :sparkles: Neues Logo: Die Integration hat jetzt ein schickes neues Logo für eine bessere Wiedererkennung.

## Installation / Update

Die Installation erfolgt am einfachsten über HACS. Wenn Du die Integration bereits installiert hast, sollte Dir HACS das Update auf v5.1.0-rc1 anbieten.

Für Neuinstallationen:

  1. Öffne HACS und gehe zu “Integrationen”.
  2. Klicke auf die 3 Punkte oben rechts und wähle “Benutzerdefinierte Repositories”.
  3. Füge die Repository-URL hinzu und wähle die Kategorie “Integration”.
  4. Suche nach “ESC Easy Sensor Creation” und installiere es.
  5. Starte Home Assistant neu.

## Beispiele für die neue Erstellung

kWh-Sensor erstellen:

  1. Gehe zu Einstellungen > Geräte & Dienste und klicke auf Integration hinzufügen.
  2. Suche und wähle ESC Easy Sensor Creation.
  3. Wähle “kWh Sensor (erstellt Riemann Sensor für Energie-Dashboard)”.
  4. Wähle Deinen Power-Sensor (in W oder kW) als Quellsensor aus.
  5. Benenne Deinen neuen kWh-Sensor.
  6. Fertig! Du findest ihn ab sofort unter Einstellungen > Geräte & Dienste > Helfer.

Statistik- oder Summen-Sensor erstellen:

  1. Starte wie oben den Konfigurations-Dialog von ESC.
  2. Wähle “Verlaufs-Statistik” oder “Summe”.
  3. Wähle den oder die passenden Quellsensoren aus.
  4. Folge den weiteren Schritten (Statistik-Typ, Klassifizierung, Name).
  5. Fertig! Du findest Deinen neuen Sensor als Entität unter dem Gerät “ESC Easy Sensor Creation”.

Bitte teste diesen Release-Candidate und gib mir Feedback! Danke für Deine Unterstützung!

3 „Gefällt mir“

Super Idee!
Im Prinzip machst Du ja nur db abfragen, richtig?
Also nichts anders als die SQL Integration.

Wäre für viele Anwendungsfälle auch mein Favorit, wenn die SQL Abfragen nicht so kompliziert wären. :tired_face:
Ich würde das nicht nur auf die Energie reduzieren.
Sowas wie Regenmenge, Außentemperatur, Anwesenheitszeit, fände ich fast schon spannender.

Gruß Osorkon

Via Hacs Integration klappt leider nicht:

Nein, genau das macht es nicht! Es berechnet anhand von Meta_Id`s es ist also keine reine Abfrage! Alles was Du aufgezählt hast, kannst Du damit locker umsetzen ohne eigene Abfragen schreiben zu müssen!

DANKE!! Ich fixe das … Moment bitte

1 „Gefällt mir“

Kann bitte mal jeamd prüfen ob es nun via HACS geht? Ich habe ein Struktur-Problem gefixt

Immer noch der gleiche Fehler, wie oben von @Samhain berichtet.

Gruß Osorkon

Ohh, das ist ja sehr vielversprechend.
Bin relativ neu in HA (komme von IPSymcon) und breche mir gerade bei diesen Dingen einen ab.
Warum nur muß so Basic Zeugs das in HA sooo mühsam sein..

vielen Dank, werds am Abend gleich ausprobieren.-
bb

GitHub hat eine Gedenkminute gebraucht :slight_smile:

Läuft… :wink: Danke für den Hinweis!

Damit bist du nicht allein! Mich hat es wahnsinnig gemacht, immer 100x zu klicken, um einen simplen Template-Sensor zu basteln. “Wie war das nochmal mit dem Aufsummieren in Jinja2?” – und dann das YAML vollzumüllen, Einrückungsfehler jagen und debuggen wie im Mittelalter. Ein echter Albtraum!Vor einiger Zeit hab ich mir ein Skript gebastelt, das die gängigsten Tasks übernimmt: Sensoren erstellen, ohne YAML-Horror, und coole Vergleiche wie:

  • Durchschnittstemperatur letztes Jahr vs. dieses Jahr (inkl. Min/Max-Werte)
  • Energieertrag laufender Monat vs. letztes Jahr
  • Und vieles mehr – direkt vergleichbar, ohne manuelles Rechnen!

Ich war total genervt von dem ganzen Fummelei, daher hab ich’s zu einer vollwertigen Integration umgewandelt. Einfach installieren, konfigurieren – und los! Kein Jinja2-Kopfschmerz mehr, automatisierte Insights pur.Wer braucht schon endlose Klicks? Probiert’s aus und spart euch Nerven!

ABER wie gut meine Skripte als Integration funktionieren .. das kann ich nicht abschätzen.. es sind BETA`S .. zum spielen und Testen

Meine Anmerkungen:

  • Es wird bei jedem Sensor ein neues Gerät erstellt. Meiner Meinung nach sollten Entitäten und nicht Geräte erstellt werden. Die Möglichkeit die Entität einem Gerät zuzuordnen, wie es bei den Helfern der Fall ist, wäre Top!
  • Bei jedem neuen Sensor, muss ich die dB Zugangsdaten (mariaDB) neu eingeben. Könnte man diese bei der Erstellung des ersten Sensors speichern?
  • Device Class und State Class und Einheit fehlt mir persönlich

Gruß Osorkon

Richtig, das ist so gewollt und man kann sie einem Raum zuordnen
DB-Password.. das ist Absicht um keine Zugangsdaten / Persönliche Daten im skript selbst zu speichern.
State / Claas.. das ist ein Guter Hinweis! Grundsätzlich läuft es aktuell so das es die State-Tabelle nimmt und wenn dort nichts gefunden wird, in anderen Tabellen sucht.

Dann habe ich aber immer mehr neue Geräte mit jeweils nur einer Entität. Für mich persönlich unpraktisch.
Bsp. Die Tägliche Max Und die Min Temperatur. Die Ist Temperatur erfasst meine Wetterstation, die Max und Min Werte möchte ich dem Gerät Wetterstation zuordnen und nicht den Raum Garten. Das macht es aus meiner Sicht viel Übersichtlicher und aufgeräumter.

Wenn ich es einem Gerät zuordne, weiß ich noch in einem Monat, welches Gerät die Grundlage bildet.

Gruß Osorkon

@Osorkon

Du meinst sowas im Bezug auf Wetter -oder? Das sind alles SQL-Sensoren…

Hmm.. verstehe dein Problem… / Einwand.. ich schau mal was man da machen kann! - Muss da mal drüber nachdenken

Ich meine nicht das Dashboard, sondern die Geräte und Entitäten Struktur.

Neuer Punkt:
Habe einen DB Sensor angelegt, Minimum - Aktuelles Jahr. Für die Außentemperatur.
Das Ergebnis ist 4,0 ?!
Nachweislich war die gemessene Min Tiefsttemperatur dieser Jahr -6

Die gleiche Entität habe ich für den Min Sensor verwendet.

Der gleiche Fehler bei der Jahres Max Temperatur, hier zeigt der Sensor 17,3 an?!

Es scheint so zu sein, dass die Langzeit Statistik nicht berücksichtigt wird.

Werden inkorrekte db zugangansdaten eingetragen, lässt sich der Sensot trotzdem ohne Fehlermeldung erstellen. Ergebnis-> Sensor zeigt Unbekannt an.

Gruß Osorkon

Ich glaube ich sehe den Fehler - ein häufiger Fehler! Du arbeitet mit Purge-Befeheln (!) Das erkannt man Nan an Hellblau vs Dunkelblau. d.h das die original Werte nicht mehr da sind (in der DB sondern nur noch noch im recorder. Das ist übrigens ein häufiger Fehler wenn man von einer Datenbank zur anderen wechselt ohne in der Yaml den entsprechenden Eintrag zu setzen. oder einfacher gesagt - Du hast keine historischen Daten mehr, über den Punkt x hinaus ( in der DB)

Das wäre meine erste Vermutung wenn ich deinen Screenshot sehe. _ Hier kommt übrigens mein anderes Projekt zum greifen um verlorene Daten wieder zu bekommen. :slight_smile:

Das wäre zumindest meine erste Vermutung. Schau doch mal mit dem Terminal in die Datenbank und lass Dir anzeigen a) wieviele Einträge, b) früherster Eintrag c) letzter Eintrag..

Wenn du den entsprechenden Befehl brauchst melde dich!

Moin,

da machst Du aber einen Denkfehler!

Es ist genau so gewollt, dass nicht alles, über Jahre in den Historientabellen liegt, sondern im Standard aggregiert wird und in die Statistiktabellen übertragen wird.
Um die Laufzeittabellen, die HA also ständig im Zugriff hat schnell und weniger Speicherhungriger macht, zumal die Standarddatenbankmanager SQLite und / oder MariaDB in der Grundeinstellung nicht darauf ausgelegt sind, große Mengen an historischen Daten zu verwalten und somit kommt es zu Bufferüberläufen, wenn so eine Datenbank erst einmal > 1 -2 Jahre läuft.

Die Datenbank durch Recordereinstellungen > 30 Tage unnötig aufzublasen ist der falsche weg, meine persönliche Meinung.

VG
Bernd

1 „Gefällt mir“

Ich verstehe deinen Punkt und bin mir dessen durchaus bewusst!
Allerdings müssen wir hier sehr klar definieren, worüber wir sprechen. Ich beziehe mich auf die statistics-Tabellen in Home Assistant.
In den history-Tabellen (ehemals history_stats) liegen nach meinem Wissen keine abrufbaren Langzeitdaten – zumindest keine, die nach einem Purge-Prozess erhalten bleiben.
Der Purge-Prozess wirkt sich primär auf die statistics-Tabellen aus, und die zugehörigen Langzeitstatistiken (long_term_statistics) enthalten keine echten Rohdaten mehr.
Wie auch – andernfalls würde der Purge unnötig sein.

Hast du Infos darüber, wo und wie HA die Langzeit-Historie (Long-Term History) speichert? Das wäre ein entscheidendes Wissen und würde Backups oder Daten-Dumps erheblich vereinfachen.

Meine Theorie:
Nach einem Purge entfernt HA die Datenpunkte aus den Tabellen und nutzt eine Art Zwischenspeicher oder aggregierte View (z. B. via SQL-Views).
Hast du andere Erkenntnisse dazu? - Kurz gesagt: Sag mir doch bitte, wo die “Historie” inklusive der Datenpunkte nach einem Purge abgelegt wird. Das wäre, wie schon erwähnt, ein Game-Changer, diese zu lokalisieren. Die statistics-Tabellen sind es jedenfalls nicht. Ggf ist es auch irgendein komprimiertes File?!

Performance-Probleme oder Overheads mit MariaDB hatte ich bisher nie – im Gegenteil, es läuft sehr effizient. Das könnte aber auch von der Host-Performance abhängen.

BTW: Genau für solche Fälle ist der von mir vorgestellte “work-around” im Thread zur Wiederherstellung von Daten nach falschem Purge, Datenverlust,.. (was der Theorie widerspricht das ei Purge alle Daten entfernt!)

Moin,

das sind die Tabellen in der Datenbank


Die historischen Daten liegen in statistic_short_term und von dort werden sie, im Standard nach 10 Tage, in die Tabelle statistic verschoben und in short_term gelöscht. Da ist kein Fehler im falschen Purge, die Tabelle short_term sollte immer so schlank wie möglich gehalten werden, damit das Gesamtsystem performant arbeiten kann.

Das ist leider ein Verwirrspiel von HA, das sie von History sprechen, aber damit eigentlich nur die Auflösung der Daten meinen, im Standard ist die Auflösung so wie die Sensoren auch melden, wenn da jede Sekunde ein Wert kommt, dann wird der auch in der statistic_shor_term auch so abgespeichert, nach 10 Tagen wird der raus fallende Tag, auf Stundenbasis aggregierte und in die Tabelle statistic geschrieben, also bleiben von dem Tag noch 24 Werte übrig.

Noch einmal, der Purge bereinigt nur die Tabellen

  • Event
  • statistic_short_term
  • statistic_runs

Alle anderen Tabellen werde bereinigt, wenn Geräte, oder Entitäten, gelöscht werden, nicht durch Purge, die Tabelle statistic wird aktuell überhaupt nicht angefasst und behält somit die Langzeitdaten nach dem 10 Tag bis zum Sanktnimmerleinstag.

Nein, das Datenmodell ist relativ dumm, und mit Views, Task (Prozeduren) usw. wird da nicht gearbeitet, die Logik in HA ist der zugrundeliegende Python-Code, dort werden Daten aufgearbeitet und in die Tabellen geschrieben, dadurch ist die Datenbank, das Modell auch recht einfach gehalten.

VG
Bernd