Support Thread - "DatabaseAddOn" Plugin

[Sisamiwe]

Morg
Kannst Du meinen PR morgen.
Getestet hat ooUrmeloo.
Dann kann ich mir das mal anschauen.

[Morg]

Aktuell gibt es ja im Plugin noch eine eigene "Pause" Funktion oder.

Ich habe nur die Möglichkeit gefunden, einzelne Items zu "suspenden", das habe ich so gelassen. Das globale suspend war auskommentiert, darum habe ich pause_item hier nicht eingebaut. Sollte aber kein Problem sein, wenn jemand, der sich mit der "inneren Logik" auskennt, sicherstellt, dass bei stop() alles geschrieben und bei run() alles gelesen wird, was notwendig ist...

[ooUrmeloo]

Das Thema ist die Belastung der Datenbank bei einer solchen Auswertung.
Für Tageswerte etc. legt das Plugin einen Cache an und nutzt den, so dass die DB nur einmal zum Lesen verwendet wird.

Für den gleitenden Durchschnitt müsste man sich was überlegen. Bei jedem neuen Wert die DB auszulesen klappt sicher nicht.
Hättest Du da einen Vorschlag?

Bspw gibt es "verbrauch_last_24h" mit Verbrauch innerhalb letzten 24h | Berechnung: hourly | Item-Type: num. Hier wird die Berechnung stündlich gemacht. Auch das ist bzgl. DB Belastung schon grenzwertig.

Bevor ich das DB_Addon gefunden hatte, hatte ich das selbst für min/max so umgesetzt, um DB Zugriffe zu minimieren.
Der Tages-Min/Max wird immer vom Item getriggert -> viele DB Aufrufe ...
Aber Woche wird nur getriggert, wenn es eine Änderung des Tages-Max gibt, Monat wird nur getriggert, wenn es eine Änderung des Wochen-Max gibt, etc.
So hatte ich gehofft, die DB möglichst minimal zu halten. Als ich das DB_Addon gesehen habe, dachte ich, du machst das bestimmt besser :-)

temperatur:
   aussen:
           max1d:
               type: num
               database_maxage: 30
               database: yes
               cache: True
               enforce_updates: True
               knx_dpt: 9
               eval: sh.paradigma.Aussentemperatur.db('max', '1d')
               eval_trigger: paradigma.Aussentemperatur
           max7d:
               type: num
               database_maxage: 75
               database: yes
               cache: True
               knx_dpt: 9
               eval: sh.temperatur.aussen.max1d.db('max', '7d')
               eval_trigger: temperatur.aussen.max1d
           max1m:
               type: num
               database_maxage: 365
               database: yes
               cache: True
               knx_dpt: 9
               eval: sh.temperatur.aussen.max7d.db('max', '1m')
               eval_trigger: temperatur.aussen.max7d
           max1y:
               type: num
               database_maxage: 365
               database: yes
               cache: True
               knx_dpt: 9
               eval: sh.temperatur.aussen.max1m.db('max', '1y')
               eval_trigger: temperatur.aussen.max1m

[ooUrmeloo]

Das müsstest Du noch etwas beobachten. Da das Plugin nur auf die Werte der Datenbank zugreift und den Cache des Datenbank-Plugins nicht kennt, kommt es immer zu Verzögerungen in der Auswertung.
Schau mal im Log, ob die Berechnung gar nicht gestartet wird oder das "falsche" Ergebnis errechnet wird.

ich hab den Logger mal auf Debug laufen lassen ... aber heute Nacht war alles 'normal'.
Ich schau mir das nochmal an, bin jetzt aber erstmal im Urlaub. Melde Mich danach nochmal.

[Sisamiwe]

gleitenden min/max Wert der letzten 24h / letzten Woche / letzten Monat / letzten Jahr auswerten.

Das Thema ist die Belastung der Datenbank bei einer solchen Auswertung.
Für Tageswerte etc. legt das Plugin einen Cache an und nutzt den, so dass die DB nur einmal zum Lesen verwendet wird.

Für den gleitenden Durchschnitt müsste man sich was überlegen. Bei jedem neuen Wert die DB auszulesen klappt sicher nicht.
Hättest Du da einen Vorschlag?

Bspw gibt es "verbrauch_last_24h" mit Verbrauch innerhalb letzten 24h | Berechnung: hourly | Item-Type: num. Hier wird die Berechnung stündlich gemacht. Auch das ist bzgl. DB Belastung schon grenzwertig.

[Sisamiwe]

Für 'minmax_Tag_min' habe ich häufiger (aber nicht immer, und nicht für alle Items gleichzeitig) das Verhalten, dass kurz nach Mitternacht die Temperatur von '0' ermittelt wird.

Das müsstest Du noch etwas beobachten. Da das Plugin nur auf die Werte der Datenbank zugreift und den Cache des Datenbank-Plugins nicht kennt, kommt es immer zu Verzögerungen in der Auswertung.
Schau mal im Log, ob die Berechnung gar nicht gestartet wird oder das "falsche" Ergebnis errechnet wird.

[Sisamiwe]

Aktuell gibt es ja im Plugin noch eine eigene "Pause" Funktion

Richtig

die Frage wäre noch, ob es die braucht oder das dann auch über stop/run implementierbar wäre.

Aus meiner Sicht kann die Funktion über Stop/Start realisiert werden. Klären müsste man, wann/nach welcher Pausezeit man den Plugin-Werte-Cache als ungültig erklärt und löscht.

[ooUrmeloo]

Übrigens mal noch eine Verständnisfrage. Ich würde eigentlich lieber den gleitenden min/max Wert der letzten 24h / letzten Woche / letzten Monat / letzten Jahr auswerten.
Wenn ich das richtig sehe, muss ich dann eher 'minmax_last_24h_min' und 'minmax_last_7d_min' und für Monat und Jahr mir was "selber basteln":

            db_addon_fct: minmax
            db_addon_params_dict: "{'func': 'min', 'timeframe': 'month', 'start': 1}"

In der user_doc steht allerdings, dass das dann bei 'timeframe' berechnet wird. Wird das dann nicht 'onchange' aktualisiert?

[ooUrmeloo]

Ich habe den Bug gefunden und den PR aktualisiert.
Kannst Du bitte nochmal testen?

Ich musste erst nochmal das alte db file reinladen, um das zu testen. Sieht aber gut aus. Jetzt nimmt er den 'oldest_log'. Danke!

Ich habe aber noch ein nicht ganz erwartetes Verhalten beobachtet.
Für 'minmax_Tag_min' habe ich häufiger (aber nicht immer, und nicht für alle Items gleichzeitig) das Verhalten, dass kurz nach Mitternacht die Temperatur von '0' ermittelt wird.
Das hatte heute z.B. dann das Resultat, dass auch 'minmax_Woche_min' und 'minmax_Monat_min' auf '0' gesetzt wurden.
Bei einem händischen Trigger über das WebIF wird dann aber der richtige Wert berechnet.


Screenshot_20240701-075439.png

[Onkelandy]

Aktuell gibt es ja im Plugin noch eine eigene "Pause" Funktion oder.. die Frage wäre noch, ob es die braucht oder das dann auch über stop/run implementierbar wäre.
Vielleicht gleich mal entsprechend umsetzen und testen..? https://github.com/smarthomeNG/smarthome/pull/657

[Sisamiwe]

Warum er also immer den Gesamt-Zählerstand für 'Jahr_bisher' nimmt, weiß ich nicht. Evtl. stimmt da noch was nicht mit der "oldest_log"

Ich habe den Bug gefunden und den PR aktualisiert.
Kannst Du bitte nochmal testen?

[Sisamiwe]

Morg

Das setzt voraus, dass das Plugin "restartable" ist, also bei stop() alles Notwendige aufräumt und bei run() alles Notwendige wieder startet, ohne dass init(), parse_item() o.ä. notwendig wäre.

Das sollte jetzt bereits gehen

Das heißt insbesondere, dass bei zusätzlichen Threads diese in run() neu erstellt werden müssen (und nicht gestartet), da Threads aufgrund eines Fehlers (?) in Python nicht neugestartet werden können.

Es werden keine zusätzlichen Threads neu gestartet. (Das war mal, habe ich aber wieder entfernt)

Dazu wäre die Frage: gibt es Funktionen, die das Plugin bei suspend() ausführen (können) soll? Oder würde stop/run für euch den gleichen Zweck erfüllen?

Ich habe nochmal im Code nachgeschaut und ja, Stop/Start würde das gleich machen wie suspend.

Kurzum, können wir gern bei dem Plugin so machen.

Beste Grüße

[Morg]

Moin,

aufgrund von geplanten Änderungen am SmartPlugin überlegen wir, die suspend-Funktionalität anzupassen. Die Änderungen würden sich insoweit auswirken, dass das Plugin nicht "stummgeschaltet" wird (wie jetzt in suspend), sondern angehalten (über stop()) und entweder von Hand oder per Item mit run() wieder gestartet wird.

Das setzt voraus, dass das Plugin "restartable" ist, also bei stop() alles Notwendige aufräumt und bei run() alles Notwendige wieder startet, ohne dass init(), parse_item() o.ä. notwendig wäre.
Das heißt insbesondere, dass bei zusätzlichen Threads diese in run() neu erstellt werden müssen (und nicht gestartet), da Threads aufgrund eines Fehlers (?) in Python nicht neugestartet werden können.

Dazu wäre die Frage: gibt es Funktionen, die das Plugin bei suspend() ausführen (können) soll? Oder würde stop/run für euch den gleichen Zweck erfüllen?

Wenn wir das umsetzen, kann ich bei den ggf. notwendigen Änderungen gern unterstützen.

Gruß
Sebastian

[ooUrmeloo]

So, ich kam heute auch mal dazu, zu testen ...

Das liegt daran, dass der Reiter nur bei eingestellten LogLevel <20 gefüllt wird.
Stell mal den LogLevel auf Debug (geht ja "on-runtime") und dann sollte dort was stehen.

Unter dem Maintenance Reiter kommen folgende Einträge, die erstmal plausibel aussehen. Das sind wirklich die ältesten Einträge, ungleich '0'. Warum er also immer den Gesamt-Zählerstand für 'Jahr_bisher' nimmt, weiß ich nicht. Evtl. stimmt da noch was nicht mit der "oldest_log" Abfrage?!
Die Zeitpunkte passen auch, nachdem meine DB abgeschmiert war. Beides Anfang April.

Item: paradigma.Brenner_Starts: {'id': 51, 'oldest_log': 1712376255378}, Item: paradigma.Betriebsstunden: {'id': 50, 'oldest_log': 1712257958735}

****************

Du könntest wie folgt vorgehen:

• smarthomeNG beenden (dass nicht in die DB geschrieben wird)
• die DB mit einem Tool zB DB Browser öffnen
• mit dem Tool eigene Einträge machen, dazu müsstest den timestamp berechnen (unix-time in microsekunde)
• DB Bearbeitung beenden
• smarthomeNG starten

Das habe ich genau so ausprobiert, und einen manuellen Datenpunkt für 31.12.23 erzeugt. Hat wunderbar geklappt. Jetzt rechnet das Addon sofort den richtigen Wert aus.

Danke für die Hilfe!

[gklein]

Sisamiwe

Kannst Du bitte noch folgende Infos liefern:

• Plugin Version
• Item Definition

Danke dir

Sorry für das späte Feedback - das war bei mir untergegangen:

Plugin-Version ist die 1.2.7
Und hier ist das Item:

...
ac_energy_total:
        type: num
        visu_acl: ro
        smamb_register@wrpv: 30529
        smamb_datatype: U32
        database: true
        eval: round(float( value / 1000.0 ) , 2)
        database: init
      
        db_addon_ignore_value: 0
      
        struct:
          - db_addon.verbrauch_1

-----
In der Visu eingebunden dann über

{{ basic.print('ErzeugToday', '  Haus.Zentral.Wechselrichter.ac_energy_total.verbrauch_tag', '%01,1f kWh' ) }}​

Danke und schönen Sonntag
Gunnar