Support Thread - "DatabaseAddOn" Plugin

[Sisamiwe]

Wärmesumme weicht deutlich ab; 2,5 - 4,5 fache im Portal

Hier wird die gleiche Temperaturreihe wie bei Grünlandtemperatur und Kältesumme verwendet (ist auch im Debug Log zu finden).
Die Auswertung erfolgt im Code ab Zeile 1800

Wachstumstaggrade 10°C weicht ab; ca. 2 - 3 fache im Portal

Hier wird die gleiche Temperaturreihe wie bei Grünlandtemperatur und Kältesumme verwendet (ist auch im Debug Log zu finden).
Die Auswertung erfolgt im Code ab Zeile 1836. Es sind 3 Berechnungsvarianten verfügbar.

Vielleicht fällt Dir was auf.

[Cannon]

Zitat von Cannon Beitrag anzeigen
Wärmesumme weicht deutlich ab; 2,5 - 4,5 fache im Portal



Hier wird die gleiche Temperaturreihe wie bei Grünlandtemperatur und Kältesumme verwendet (ist auch im Debug Log zu finden).
Die Auswertung erfolgt im Code ab Zeile 1800

Da das so undefiniert ist, kann man dazu eigentlich erst mal nichts sagen.

Zitat von Cannon Beitrag anzeigen
Wachstumstaggrade 10°C weicht ab; ca. 2 - 3 fache im Portal



Hier wird die gleiche Temperaturreihe wie bei Grünlandtemperatur und Kältesumme verwendet (ist auch im Debug Log zu finden).
Die Auswertung erfolgt im Code ab Zeile 1836. Es sind 3 Berechnungsvarianten verfügbar.

Ja mir ist da was aufgefallen. Zum einen ist in der Doku nicht klar erkenntlich, was der defaultt-Wert ist. Kannst du dir das noch mal anschauen: https://smarthomeng.github.io/smarth.../user_doc.html

Zudem, wenn ich mir den Code ab Zeile 1876 anschaue, gibt es zwischen Variante 0 und Variante 2 keinen Unterschied in der Berechnung.

Und was die Werte selbst betrifft, würde ich mit Variante 1 einen höheren Wert als Variante 0 erwarten. Alle Varianten geben mir jedoch immer den gleichen Ergebniswert aus.

[android]

Hallo,

ich glaube mein Anliegen geht mit dem Plugin nicht, aber ich frage trotzdem mal hier.

Ich habe bei meinem Danfoss WR zwei string-genaue Items mit Tages-Energieertragsständen (der letzte Wert eines Tages ist immer der Tagesertrag) in einer sqllite db. Ich würde daraus gerne Monats bzw. Jahres Energieerträge String genau berechnen, geht das mit dem Plugin? Oder gibt es sonst eine einfache Möglichkeit über eine Logik?

Danke

Gruß

Philipp

[Cannon]

Ich würde daraus gerne Monats bzw. Jahres Energieerträge String genau berechnen, geht das mit dem Plugin? Oder gibt es sonst eine einfache Möglichkeit über eine Logik?

Schau mal hier. Ich hatte mal einen Thread zum Thema. Du könntest quasi Mitternacht oder so den Wert in die DB speichern und dann hättest du nur die Tagesertragswerte: https://knx-user-forum.de/forum/supp...-mehrerer-tage

[Sisamiwe]

Ja mir ist da was aufgefallen. Zum einen ist in der Doku nicht klar erkenntlich, was der defaultt-Wert ist. Kannst du dir das noch mal anschauen:

Bei der Berechnung der Wachstumgradtage sind folgende Parameter per default gesetzt:
- year: current (also aktuell 2024)
- variant: 9 (also Berechnung nach einfachem Durchschnitt)
- threshold: 10

Zudem, wenn ich mir den Code ab Zeile 1876 anschaue, gibt es zwischen Variante 0 und Variante 2 keinen Unterschied in der Berechnung.

Das ist richtig. Ich werden die Methode/Variante entfernen

Und was die Werte selbst betrifft, würde ich mit Variante 1 einen höheren Wert als Variante 0 erwarten. Alle Varianten geben mir jedoch immer den gleichen Ergebniswert aus.

Das ist bei mir auch der Fall.

Wenn ich deine Werte (log 2024-03-07 17:07:03) nutze ergibt Variante 0: 93 und Variante 1: 132,6

[Cannon]

Das ist bei mir auch der Fall.

Wenn ich deine Werte (log 2024-03-07 17:07:03) nutze ergibt Variante 0: 93 und Variante 1: 132,6

Wir reden noch über die Wachtsumsgradtage? Aktuell habe ich mit Variante 0 und 1 keinen Unterschied und viel zu kleine Werte. Je nach Messstation habe ich nur 6 bzw. 11 als Ergebnis.

[Sisamiwe]

Wachtsumsgradtage

Ja.

Mach bitte mal folgendes:
Löse mal im WebIF die Berechnung des Items mit den Wachstumsgradtage mal neu aus und schicke mir nochmal das debug Log dazu

[Sisamiwe]

Cannon

Ich habe den Fehler bei den Wachstumsgradtagen gefunden. Der Parameter muss "variant" und nicht "method" lauten.
Den Fix habe ich den PR geschoben.
Testest Du mal bitte?

[Cannon]

Ich habe den Fehler bei den Wachstumsgradtagen gefunden. Der Parameter muss "variant" und nicht "method" lauten.
Den Fix habe ich den PR geschoben.
Testest Du mal bitte?

Passt. Die Werte sehen nun mit variant=1 viel besser aus. Kannst du die Doku dazu noch mal korrigieren? Die ist ohne Zeilenumbrüche auch recht verwirrend.

Ist der Fehler eigentlich auch irgendwie lösbar oder bin ich der einzige mit diesem Problem:

2024-03-10  16:47:36 NOTICE   lib.smarthome       --------------------   SmartHomeNG initialization finished   --------------------
2024-03-10  16:52:59 WARNING  plugins.database    Problem dumping env.core.memory: database is locked
2024-03-10  16:53:04 WARNING  plugins.database    Problem dumping env.core.threads: database is locked
2024-03-10  16:53:09 WARNING  plugins.database    Problem dumping env.core.scheduler.worker_threads: database is locked
2024-03-10  16:53:14 WARNING  plugins.database    Problem dumping env.core.scheduler.idle_threads: database is locked
2024-03-10  16:54:00 WARNING  plugins.database    Problem dumping Zentral.Energie.Photovoltaik.SUN2000_WR_Haus.input_power: database is locked
2024-03-10  16:54:05 WARNING  plugins.database    Problem dumping Zentral.Energie.Photovoltaik.SUN2000_WR_Haus.grid_voltage: database is locked
2024-03-10  16:54:10 WARNING  plugins.database    Problem dumping Zentral.Energie.Photovoltaik.SUN2000_WR_Haus.line_voltage_A_B: database is locked
2024-03-10  17:00:03 NOTICE   lib.smarthome       --------------------   Init SmartHomeNG v1.10.0-master (4b25822a0)   --------------------​

Das hängt am db_addon. Ohne diesem habe ich diesen Fehler nicht. So immer wieder.

[Sisamiwe]

Kannst du die Doku dazu noch mal korrigieren? Die ist ohne Zeilenumbrüche auch recht verwirrend.

Was meinst du?

[Cannon]

Was meinst du?

Die Doku zum plugin auf der offiziellen Seite von SmartHomeNG. Da steht auch noch method drin und die default-Werte sind da irgendwie vertauscht.

[Sisamiwe]

Die Doku zum plugin

Die Doku habe ich korrigiert; sie ist auch im PR. Denn der PR gemerged ist, ist die develop docu dann auf Stand. Die release docu dann wieder nach release.
Schau dir mal die user_doc.rst an. Ist das nun verständlicher?

[ooUrmeloo]

Hallo Sisamiwe,
ich bin zufällig auf Dein Plugin gestoßen und würde dieses gerne verwenden.
Ich bin gerade dabei, es auszuprobieren, aber so richtig scheint das nicht zu funktionieren und ich weiß ehrlich gesagt nicht, warum ...
Das Plugin läuft grundsätzlich und ich habe Zugriff auf das WebIF. Ich kann auch manuell den Trigger über das WebIF auslösen aber die Trigger "onchange" funktionieren bei mir irgendwie nicht.
Im Plugin steht unter "Verbunden" auch "Nein", obwohl ab und zu unter "Item in Berechnung" was auftaucht. Und wie gesagt, manuell triggern scheint zu funktionieren.
Hier mal exemplarisch:

grafik.png
Ich nutze folgende einfache Funktionen:

temperatur:
   aussen:
           min1d:
               type: num
               database_maxage: 30
               database: yes
               cache: True
               knx_dpt: 9
               db_addon_fct: minmax_tag_min
               db_addon_database_item: 'paradigma.Aussentemperatur'

     Betriebsstunden_Tag_bisher:
        type: num
        visu_acl: ro
        database_maxage: 30
        database: yes
        cache: True
        db_addon_fct: verbrauch_tag
        db_addon_database_item: 'paradigma.Betriebsstunden'

Aber irgdnwie triggert er nicht bei einer Änderung des Items. Eine Idee, woran das liegen könnte?

Apropos ... noch eine Frage: Was ist eigentlich der Unterschied zwischen 'minmax_tag_min' und 'minmax_heute_min' bzw. 'verbrauch_tag' und verbrauch_heute'?

[Sisamiwe]

Im Plugin steht unter "Verbunden" auch "Nein", obwohl ab und zu unter "Item in Berechnung" was auftaucht. Und wie gesagt, manuell triggern scheint zu funktionieren.

Ich schaue mir das mal an. Kann aber etwas dauern.

Du könntest aber mal das Debug-Log einschalten und mir mal einen Auszug schicken.

Was ist eigentlich der Unterschied zwischen 'minmax_tag_min' und 'minmax_heute_min' bzw. 'verbrauch_tag' und verbrauch_heute'?

Die sind jeweils synonym zueinander, daher gibt es keinen Unterschied. (Das kam aus der Entwicklungshistorie)

[ooUrmeloo]

Hier mal ein Auszug aus dem Debug-Log nach einem Neustart von SHNG:

2024-04-07  21:41:42 INFO     plugins.db_addon    All cache_dicts will be initiated.
2024-04-07  21:42:27 INFO     plugins.db_addon    Set scheduler for calculating startup-items with delay of 123s to 2024-04-07 21:44:30.287874+02:00.
2024-04-07  21:44:30 INFO     plugins.db_addon    0 items will be calculated for option='startup'.
2024-04-07  21:44:40 INFO     plugins.db_addon    + Updated item 'sonnenbatterie.Consumption_W' with value 325 is now due to be put to queue for processing. 1 items to do.
2024-04-07  21:44:40 INFO     plugins.db_addon    + Updated item 'sonnenbatterie.GridFeedIn_W' with value -40 is now due to be put to queue for processing. 2 items to do.
2024-04-07  21:44:40 INFO     plugins.db_addon    # 1 item(s) to do. || 'onchange' item=sonnenbatterie.Consumption_W with value=325 will be processed.
2024-04-07  21:44:40 INFO     plugins.db_addon    + Updated item 'sonnenbatterie.Pac_total_W' with value 286 is now due to be put to queue for processing. 2 items to do.
2024-04-07  21:44:40 INFO     plugins.db_addon    # 1 item(s) to do. || 'onchange' item=sonnenbatterie.GridFeedIn_W with value=-40 will be processed.
2024-04-07  21:44:40 INFO     plugins.db_addon    # 1 item(s) to do. || 'onchange' item=sonnenbatterie.Pac_total_W with value=286 will be processed.
2024-04-07  21:45:11 INFO     plugins.db_addon    + Updated item 'sonnenbatterie.Consumption_W' with value 333 is now due to be put to queue for processing. 1 items to do.
2024-04-07  21:45:11 INFO     plugins.db_addon    + Updated item 'sonnenbatterie.GridFeedIn_W' with value -56 is now due to be put to queue for processing. 2 items to do.
2024-04-07  21:45:11 INFO     plugins.db_addon    # 1 item(s) to do. || 'onchange' item=sonnenbatterie.Consumption_W with value=333 will be processed.
2024-04-07  21:45:11 INFO     plugins.db_addon    + Updated item 'sonnenbatterie.Pac_total_W' with value 281 is now due to be put to queue for processing. 2 items to do.
2024-04-07  21:45:11 INFO     plugins.db_addon    # 1 item(s) to do. || 'onchange' item=sonnenbatterie.GridFeedIn_W with value=-56 will be processed.
2024-04-07  21:45:11 INFO     plugins.db_addon    # 1 item(s) to do. || 'onchange' item=sonnenbatterie.Pac_total_W with value=281 will be processed.
2024-04-07  21:45:14 INFO     plugins.db_addon    Recalc of item=paradigma.Betriebsstunden_Tag_bisher called via WebIF. Item put to Queue for new calculation.
2024-04-07  21:45:14 INFO     plugins.db_addon    1 items will be calculated for option='item'.
2024-04-07  21:45:14 INFO     plugins.db_addon    # 1 item(s) to do. || 'on-demand' item=paradigma.Betriebsstunden_Tag_bisher will be processed.
2024-04-07  21:45:14 INFO     plugins.db_addon      No values for item=paradigma.Betriebsstunden in requested timeframe between 1712440800000/2024-04-07 00:00:00 and 1712527200000/2024-04-08 00:00:00 in database found.
2024-04-07  21:45:14 INFO     plugins.db_addon      Item value for 'paradigma.Betriebsstunden_Tag_bisher' will be set to 0
2024-04-07  21:45:31 INFO     plugins.db_addon    Recalc of item=temperatur.aussen.min1d called via WebIF. Item put to Queue for new calculation.
2024-04-07  21:45:31 INFO     plugins.db_addon    1 items will be calculated for option='item'.
2024-04-07  21:45:31 INFO     plugins.db_addon    # 1 item(s) to do. || 'on-demand' item=temperatur.aussen.min1d will be processed.
2024-04-07  21:45:31 INFO     plugins.db_addon      Item value for 'temperatur.aussen.min1d' will be set to 9.5
2024-04-07  21:47:14 INFO     plugins.db_addon    + Updated item 'sonnenbatterie.Consumption_W' with value 301 is now due to be put to queue for processing. 1 items to do.
2024-04-07  21:47:14 INFO     plugins.db_addon    + Updated item 'sonnenbatterie.GridFeedIn_W' with value -27 is now due to be put to queue for processing. 2 items to do.
2024-04-07  21:47:14 INFO     plugins.db_addon    # 1 item(s) to do. || 'onchange' item=sonnenbatterie.Consumption_W with value=301 will be processed.
2024-04-07  21:47:14 INFO     plugins.db_addon    + Updated item 'sonnenbatterie.Pac_total_W' with value 269 is now due to be put to queue for processing. 2 items to do.
2024-04-07  21:47:14 INFO     plugins.db_addon    # 1 item(s) to do. || 'onchange' item=sonnenbatterie.GridFeedIn_W with value=-27 will be processed.
2024-04-07  21:47:14 INFO     plugins.db_addon    # 1 item(s) to do. || 'onchange' item=sonnenbatterie.Pac_total_W with value=269 will be processed.​

Auch interessant ... Die Items 'sonnenbatterie.Consumption_W' und 'sonnenbatterie.GridFeedIn_W' rufe ich gar nicht mehr auf, sondern 'sonnenbatterie.GridFeedIn_W.Hour' ... Das hatte ich falsch gemacht und korrigiert, tauchen aber hier noch auf. Verstehe ich nicht ... In der Liste im WebIF gibt's die Einträge nicht mehr und auch keine aktualisierten Werte für z.B. 21:45:11 ... komisch ...
Gibt es einen Cache o.ä., den ich leeren muss, wenn ich was ändere?

Das Item 'temperatur.aussen.min1d' zum Beispiel wird nie getriggert, obwohl sich die Temperatur in der Database ständig ändert. Wenn ich manuell anstoße 'on-demand', scheint es ordnungsgemäß zu funkionieren. (siehe log)
Was mir bei dem gleichen Item (und den anderen Temperaturen) auch aufgefallen ist: Es wird - obwohl 'onchange' - um kurz nach Mitternacht getriggert und setzt den Wert auf '0', was nicht sein kann:

grafik.png