Item mit Zeitberechnung bspw für Verbrauchsauswertung als Systemitems bereitstellen

[Sisamiwe]

Onkelandy
Ich habe parallel eine Logik erstellt, die auch die Berechnung durchführt. Das ist in Summer übersichtlicher.

Nun hadere ich nur noch mit den "Live" Einträgen, also heute, woche, monat und jahr. Hier müsste die Logik bei jeder Wertänderung des Parentitems getriggert werden.
Hier fehlt mir noch die Idee, wie man das generell machen kann.

Ich könnte mit

watch_item:
    - '*.heute'
    - '*.woche'
    - '*.monat'
    - '*.jahr'

Auf alle entsprechenden Items hören, aber wie triggere ich diese, ohne den Wert des Parents zu übergeben? Nur eval_trigger ohne eval geht nicht.

Und für die Überachung der ParentItems habe ich noch keine Möglichkeit gefunden. Die Gemeinsamkeit ist die Verwendung des structs mit bestimmten Namen. Allerdings habe ich keinen Ahnung (deshalb die Frage im Forum), ob es dafür eine Möglichkeit gibt.

[Onkelandy]

Ich hab jetzt rumprobiert und das ganze in einen funktionierenden eval Ausdruck gepackt. Es scheint zu klappen, abgesehen von dem kleinen Problem: der Name des Plugins hängt von der Konfiguration im etc/plugin.yaml ab. Bei mir heißt es zB database_mysql. Das ist aber vernachlässigbar.

Vielleicht kannst du dennoch mal diesen Code hier testen..?

eval: round((sh...() - (sh...db('max', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i') or sh.plugins.return_plugin('database').readLogs(sh.plugins.return_plugin('database').id(sh.return_item(sh....property.path)), sh.plugins.return_plugin('database').readOldestLog(sh.plugins.return_plugin('database').id(sh.return_item(sh....property.path))))[0][4])), 2)

[Onkelandy]

Oha, das ist schon mal cool. Der Eval-String dürfte da aber ziemlich ekelhaft werden hehe.. müsste man mal schauen, ob man das irgendwie sinnvoll mit der Logik kombinieren kann.

[Sisamiwe]

Hätte jemand ne Idee wie man das Problem beim Berechnen der Wertehistorie abfangen kann, wenn zu besagtem Abfragezeitpunkt keine Daten in der Datenbank sind?

Ich bin ein Stück weitergekommen. Im Database Plugin ist eine Funktion integriert, die den Timestamp des ältesten Eintrags zu einer Item-ID zurückgibt. Ich habe das mal in eine Testlogik gegossen:

#!/usr/bin/env python3
# db_test.py

plugin = sh.plugins.return_plugin('database')
id = plugin.id(sh.raumtemp.aussen.nord)

readOldestLog = plugin.readOldestLog(id)
readOldestLog = datetime.datetime.fromtimestamp(readOldestLog/1000, datetime.timezone.utc).astimezone().strftime('%Y-%m-%d %H:%M:%S %Z%z')  

logger.info(readOldestLog)

Ausgabe ist:

2021-10-10  17:31:48 INFO     logics.db_test                           2017-08-12 21:04:30 CEST+0200

Also ist der älteste Eintrag für dieses Item vom 12. Aug 2017.

Jetzt muss man das nur noch sinnvoll einbauen

[Onkelandy]

Hätte jemand ne Idee wie man das Problem beim Berechnen der Wertehistorie abfangen kann, wenn zu besagtem Abfragezeitpunkt keine Daten in der Datenbank sind?
Also ganz konkret.. Ich hab seit Mai 2021 ein neues Item am Start und möchte den max Wert vom Jahr 2021 ermitteln. Hier kommt ein "None" zurück, da zu Beginn des Jahres noch keine Daten vorhanden sind. Es sollte also statt beginning_of_year der Zeitpunkt des ersten db Eintrags für das Item herangezogen werden.

Selbes Spiel dann halt auch für den Monat. Wenn man ein Item erst am 10. des Monats angelegt hat, man aber am 30. des Verbrauch im laufenden Monat abfragen will.
Das würde die obigen Abfragen noch ein Stück robuster und wertvoller machen Sisamiwe
Vielen Dank!

[Hochpass]

Das läuft soweit prima

O.k. ein langes Wochenende mit schlechtem Wetter steht vor der Tür. Ich guck mal ob ich das zum laufen kriege.

Danke!

[Sisamiwe]

Ich nutze bei mir die Logik von #47 und den Code für shtime.py von meinem PR. Das läuft soweit prima

Genau so mache ich das auch. Funktioniert prima.

[Onkelandy]

Mein PR ist noch offen und muss getestet werden bzw. wollte Msinn das Ganze etwas anders lösen. Ich nutze bei mir die Logik von #47 und den Code für shtime.py von meinem PR. Das läuft soweit prima - ansonsten müsste man sich noch etwas gedulden.

[Hochpass]

Sowas? https://www.smarthomeng.de/user/

Ja ist natürlich bekannt aber das Thema ist dann wohl veraltet.

Das Beispiel würde man anders lösen
https://www.smarthomeng.de/user/beis...zeitdaten.html

[Sisamiwe]

Welche Anpassungen meinst Du, die nicht im Release sein sollten?

Ich denke, er meint den PR von Onkelandy aus dem Beitrag #48.
So wie ich das sehe, ist diese Änderung für V1.9 vorgemerkt.

[Morg]

Cool fände ich eine kleine Anwenderdoku.

Sowas? https://www.smarthomeng.de/user/

[Msinn]

Welche Anpassungen meinst Du, die nicht im Release sein sollten?

[Hochpass]

Moin,
ich guck gerade wie ich meine PV Anlage, Verbrauch und E-Auto Visualisiere.

Dies scheint wohl die "latest and greates" Lösung zu sein. Es sind aber vermutlich noch nicht alle Anpassungen im Release? Cool fände ich eine kleine Anwenderdoku. Verstanden habe ich es nähmlich noch nicht zu 100%. Habt ihr da was geplant?

[Sisamiwe]

Man müsste sich also die shtime.py aus dem PR hier selbst ziehen:

Ich habe mir die shtime.py aus Deinem Github gezogen. Damit geht es. Msinn hatte auch schon eine Korrektur an der shtime.py bzgl. der beginning_since_week vorgenommen, die auch in den den Rechenfehler zum Jahreswechsel hatte.

[Onkelandy]

Update ist vermutlich zu umfangreich für das kommende Release Man müsste sich also die shtime.py aus dem PR hier selbst ziehen:
https://github.com/smarthomeNG/smarthome/pull/375

In der Logik sollten übrigens sh.now() durch shtime.now() ersetzt werden. Danke sonst schon mal für die evals und Logiken, ich teste die Tage mal.