Item mit Zeitberechnung bspw für Verbrauchsauswertung als Systemitems bereitstellen

[Sisamiwe]

whe

Das Plugin geht nun auch mit sqlite

[whe]

wenn ich das richtig in Erinnerung habe funktioniert das aber nur mit MySQL und nicht mit SQLite.
dann schau ich mal weiter.

Danke

[Sisamiwe]

ich breche mir da die Gräten mit diesen Funktionen, das ist für eine Laien nur schwer nachvollziehbar.

Deshalb habe ich das Plugin erstellt. Damit funktionieren diese Art von Auswertung sehr einfach.

[whe]

danke Markus,

wie würde ich das denn mit shtime für die letzte Stunde auswerten können?

ich breche mir da die Gräten mit diesen Funktionen, das ist für eine Laien nur schwer nachvollziehbar.

[Sisamiwe]

whe


Schau mal hier, das Plugin ist noch in der Testphase und kann das von Hause aus.
Vielleicht ist es was für Dich?

[whe]

für die Kalkulation von "heute" ist der Fehler am 2. Tag weg.
aber für Monat und Jahr kommt das immer noch.
ob das neue databas plug-In das Problem löst ?
https://knx-user-forum.de/forum/supp...tere-testphase
seit ein paar Jahren suche ich schon nach einer funktionierenden Lösung.
alles was ich bisher ausprobiert habe führt in bestimmten Situationen zu Fehlern.

[SMarcus]

Ich denke Post Nr. 8 (https://knx-user-forum.de/forum/supportforen/smarthome-py/1475640-item-mit-zeitberechnung-bspw-für-verbrauchsauswertung-als-systemitems-bereitstellen?p=1510191#post1510191) hilft Dir weiter....

[whe]

versuche gerade die Laufzeit meiner Heizung nach diesem Schema zu ermitteln.
die Formeln tun's aber bei mir nicht; ich benutze aber shng 1.9.3

2022-12-08  16:16:27 WARNING  lib.item.item       Item Buderus.Brenner.Betrieb.woche: problem evaluating 'round((sh.Buderus.Brenner.Betrieb() - sh.Buderus.Brenner.Betrieb.db('max', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i')), 2)': unsupported operand type(s) for -: 'float' and 'NoneType'
2022-12-08  16:16:28 WARNING  lib.item.item       Item Buderus.Brenner.Betrieb.monat: problem evaluating 'round((sh.Buderus.Brenner.Betrieb() - sh.Buderus.Brenner.Betrieb.db('max', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i')), 2)': unsupported operand type(s) for -: 'float' and 'NoneType'
2022-12-08  16:16:28 WARNING  lib.item.item       Item Buderus.Brenner.Betrieb.jahr: problem evaluating 'round((sh.Buderus.Brenner.Betrieb() - sh.Buderus.Brenner.Betrieb.db('max', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i')), 2)': unsupported operand type(s) for -: 'float' and 'NoneType'
2022-12-08  16:47:31 WARNING  lib.item.item       Item Buderus.Brenner.Betrieb.monat: problem evaluating 'round((sh.Buderus.Brenner.Betrieb() - sh.Buderus.Brenner.Betrieb.db('max', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i')), 2)': unsupported operand type(s) for -: 'float' and 'NoneType'
2022-12-08  16:47:31 WARNING  lib.item.item       Item Buderus.Brenner.Betrieb.woche: problem evaluating 'round((sh.Buderus.Brenner.Betrieb() - sh.Buderus.Brenner.Betrieb.db('max', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i')), 2)': unsupported operand type(s) for -: 'float' and 'NoneType'
2022-12-08  16:47:31 WARNING  lib.item.item       Item Buderus.Brenner.Betrieb.jahr: problem evaluating 'round((sh.Buderus.Brenner.Betrieb() - sh.Buderus.Brenner.Betrieb.db('max', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i')), 2)': unsupported operand type(s) for -: 'float' and 'NoneType'
2022-12-08  16:47:31 WARNING  lib.item.item       Item Buderus.Brenner.Betrieb.heute: problem evaluating 'round((sh.Buderus.Brenner.Betrieb() - sh.Buderus.Brenner.Betrieb.db('max', str(shtime.time_since(shtime.today(), 'im')) + 'i', str(shtime.time_since(shtime.today(), 'im')) + 'i')), 2)': unsupported operand type(s) for -: 'float' and 'NoneType'

[Sisamiwe]

Onkelandy

Ich habe das gist nochmal aktualisiert und meine letzte Logik Version dort abgelegt.

Leider ist die Performance der Logik deutlich schlechter also bei einer Abbildung über eval. Die Logik zum Aktualisieren der Items läuft mehrere Minuten und damit (gefühlt) um Faktoren länger, also bei der Aktualisierung über evals. Ich habe versucht die DB Zugriffe zu minimieren. Das ergab aber keine Besserung.

Kannst Du Dir die Logik bitte mal anschauen, ob da strukturell was nicht passt?
Danke

[Onkelandy]

Oh, da hast ja Vollgas gegeben, dankeschön!

Soweit scheint das mal gut zu klappen, muss ich aber noch beobachten. Die Message
No entries for Item stromverbrauch.energiemodul.c.stand.kwh in DB found for requested end 417450i; oldest entry used instead
kommt wegen dem "Anfang Jahr gibt es keinen Eintrag", oder? Ich würde das nicht unbedingt als Warnung ausgeben.

[Sisamiwe]

Onkelandy
Hallo,

ich habe an der Logik und den beiden structs noch etwas gefeilt.

Es gibt nun 2 structs, das struct "wertehistorie_total" für ein Item mit stetig steigendem Zählerstand (bspw. Strom) und das struct "wertehistorie_minmax" für ein Item mit Werten in einem bestimmten Bereich (bspw. Temp).

Die Aktualisierung dieser Items übernimmt eine Logik. In der Logik kann man den Ebenenunterschied zwischen dem "Zähleritem" (dem Item in das immer die aktuellen Werte geschrieben werden) und den Items, die die structs erzeugen, einstellen. Die Konfiguration der Logik für die logic.yaml ist auch in der Logik hinterlegt.
Die Logic prüft, ob das Plugin "database" aktiv ist. Falls Nein, wird die Logik deaktiviert.

Es werden 3 Trigger für die Logik unterschieden:

1. Trigger durch ein Item: In den structs ist je ein Trigger-Item eingebaut, dass bei Aktualisierung des Zähleritems via eval und eval_trigger ebenfalls aktualisiert wird (im struct muss ggf. die Ebene noch noch angepasst werden). Dieses (bzw. alle diese) Trigger-Item(s) triggert die Logik. Mit der Logik werden dann die "dynamischen Werteitems", also alle die, die den neuesten Wert des Zähleritems mit nutzen, aktualisiert. "Dynamischen Werteitems" sind bspw. Verbrauch heute, Verbrauch Woche etc.
2. Trigger durch crontab: Wird die Logik über den crontab getriggert, werden alle "statischen Werteitems" (wie bspw. gestern, vorgestern, etc) berechnet und der Wert ins jeweilige Item geschrieben. Welche Items berechnet werden, hängt vom Auslösezeitpunkt bzw. Datum ab. So werden Items bspw. für Wochenverbrauch nur zu Wochenbeginn berechnet.
3. Trigger durch Admin (manuell ausglöst): Hier werden alle "statischen Werteitems" berechnet.

Ich habe 3 Gists erzeugt:

• Logik
• struct wertehistorie_total
• struct wertehistorie_minmax

Kannst Du das mal testen?
Merci!

[Sisamiwe]

Cool wäre noch, wenn man einfach zB über ein Logik-Attribut einstellen könnte, in welchem Unteritem das struct abgelegt wird.

Schau mal ins Gist. Da gibt es ein Update u.a. mit der Möglichkeit den "level-Unterschied" zwischen Zähleritem und struct einzugeben.

Vielleicht möchte das jemand auch noch mehr verschachteln zB in "historie/min_max" und "historie/zaehler" oder wie auch immer. Was meinst du?

Wie meinst du das?

Ich arbeite auch an einer Logik für min/max. Welche Auswertungen nutzt du? Min/Max heute, gestern, letzte 24h....

[Onkelandy]

Super Arbeit, sieht prima aus. Cool wäre noch, wenn man einfach zB über ein Logik-Attribut einstellen könnte, in welchem Unteritem das struct abgelegt wird. Ich hab zB bei meinen Items eigene Unteritems "min_max" und "wertehistorie". Dann wäre nicht das parent_item relevant, sondern eben die Großeltern. Vielleicht möchte das jemand auch noch mehr verschachteln zB in "historie/min_max" und "historie/zaehler" oder wie auch immer. Was meinst du? Dann test ich die Sache sehr gerne mal. Sollten wir dann jedenfalls in der Doku verewigen... https://www.smarthomeng.de/user/beis...xere-beispiele

[Sisamiwe]

Zeigst du mal deine Logik?

Klar. Schau mal hier

Die Logik funktioniert so:

Für die "statischen" Items, also die, die nicht vom direkt vom ParentItem -dem Zähleritem- abhängen, durchsucht die Logik alle Items nach den entsprechenden Items gemäß dem struct und ermittelt dann die historischen Werte. Gibt es pro Item für keines der beiden Abfragezeiten Einträge in der DB, wird nicht berechnet. Gibt es nur den späteren nicht, gibt es eine Warnung im Log und es wird der älteste Eintrag der DB benutzt.
Getriggert wird über crontabs. Funktioniert!

Für die "dynamischen" Items, also die, die sich bei jeder Änderung der vom ParentItem -dem Zähleritem- ändern (heute, woche, monat, jahr), kann die Logik auch die Berechnung durchführen. Allerdings fehlt mir die Idee, wie die Logik getriggert wird. Klar kann man alle Zähleritems als Trigger setzen, ich suche aber etwas generisches. Das was alle Zähleritems gemeinsam haben, ist das struct mit dem Namen "wertehistorie". Das wäre Lösungweg A.

Als Lösungsweg B könnte man alle Items, die auf "heute" enden als watch_item setzen, aber wie kann man diese Items ändern, so dass die Logik getriggert wird und der Wert dann wirklich per Logik ins Item geschrieben wird?

Lösungsweg C wäre im struct ein eigenes Item mit festem Namen anzulegen, dass immer dann getriggert wird, wenn das ParentItem sich ändern und damit die Logik auslöst. Das probier ich mal aus.

Update:
Im gist findest Du die akutelle Logik und "nabendran" auch das passende struct.
Umgesetzt ist Lösungsweg C. Klappt gut!

[Onkelandy]

Ich denke übrigens, dass wir generell die "if .. is not None else 0" Abfrage ersetzen sollten durch "(.. or sh..())" - das würde eine Datenbankabfrage ersparen.

Zeigst du mal deine Logik? Eigentlich wäre es nicht schlecht, wenn ALLES in der Logik gemacht wird. Oder probierst du das eh? Die Frage verstehe ich aktuell noch nicht ganz.