Support Thread - "DatabaseAddOn" Plugin

[Sisamiwe]

Gibt es dafür einen guten Grund oder kann ich das guten Gewissens ändern?

Hallo Gunnar,

es gibt keinen spezifischen Grund. Ich hatte die Fragen auch aus einem anderen Kanal.
Es gibt einen PR, um das wieder zu aktivieren.

Beste Grüße
Michael

[gklein]

Hallo Sisamiwe

ich habe eine Frage zum integrierten Struct. Nach dem Neustart von SHNG dauert es ja eine Weile bis die Daten neu berechnet werden, was hier im Hause zu temporärer Verwirrung geführt hat
Ich habe jetzt überlegt, das Struct um "cache: yes" zu erweitern und dabei im Code gesehen, dass Du das dort schon drin aber auskommentiert hast.

  
item_structs:
    verbrauch_1:
        name: Struct für Verbrauchsauswertung bei Zählern mit stetig ansteigendem Zählerstand (Teil 1)
        verbrauch_heute:
            name: Verbrauch heute
            db_addon_fct: verbrauch_heute
            type: num
            visu_acl: ro
            # cache: yes

        verbrauch_woche:
            name: Verbrauch seit Wochenbeginn
            db_addon_fct: verbrauch_woche
            type: num
            visu_acl: ro
            # cache: yes​
​

Gibt es dafür einen guten Grund oder kann ich das guten Gewissens ändern?

Danke und Grüße
Gunnar

[gklein]

Hi,

ich habe jetzt angefangen meine vorhanden Berechnung zu erweitern und habe bei einem Wert noch ein Problem mit den Werten für Monat, Vormonat und Jahr für ein Item.
Heute, gestern, vorgestern, Woche und Vorwoche werden berechnet.In der DB steht ein ordentlicher Wert zum 1.1.23. Trotz allem wird als Wert "-4294962458.1" ermittelt - siehe Screenshot



ac_energy.pngDas Debug-Log hat mich noch nicht weitergebracht.

2023-03-30 13:48:24 UTC DEBUG    __init__          Main         parse item: Haus.Zentral.Wechselrichter.ac_energy_total.verbrauch_jahr due to 'db_addon_fct'  --  (__init__.py:parse_item:233)
2023-03-30 13:48:24 UTC DEBUG    __init__          Main         [B]Attribut 'database' has not been found for item=Haus.Zentral.Wechselrichter.ac_energy_tota[/B]l.verbrauch_jahr 1 level above item.  --  (__init__.py:get_database_item:198)
2023-03-30 13:48:24 UTC DEBUG    __init__          Main         Item 'Haus.Zentral.Wechselrichter.ac_energy_total.verbrauch_jahr' added with db_addon_fct=verbrauch_jahr and database_item=Haus.Zentral.Wechselrichter.ac_energy_total  --  (__init__.py:parse_item:262)
2023-03-30 13:48:24 UTC DEBUG    __init__          Main         Item 'Haus.Zentral.Wechselrichter.ac_energy_total.verbrauch_jahr' added to be run on-change.  --  (__init__.py:parse_item:349)
​.
.
.
plugins.db_addon.work_item_queue Item value for 'Haus.Zentral.Wechselrichter.ac_energy_total.verbrauch_jahr' will be set to -4294962458.1  --  (__init__.py:handle_onchange:742)
​

Das "database"-Attribut ist da, sonst könnte er den Rest ja vermutlich auch nicht berechnen?
Das genaue Statement habe ich noch nirgendwo beim Debug gefunden, sonst würde ich das mal direkt gegen die DB laufen lassen. Weitere Items funktionieren problemlos.
Ich bin für Tipps und Hinweise zur weiteren Fehlersuche dankbar.

Danke und Grüße
Gunnar

Edit: Mittlerweile habe ich das Statement gefunden - Item-ID 52
:

Called with query='SELECT time, ROUND(MIN(val_num), 1) as value FROM log WHERE item_id = :item_id AND time BETWEEN :ts_start AND :ts_end AND val_bool = 1 ORDER BY time ASC', params={'item_id': 52, 'ts_start': 1679270400000, 'ts_end': 1679788800000},

und noch eins, inkl. unsinnigem Result

SELECT time, ROUND(MAX(val_num), 1) as value FROM log WHERE item_id = 52 AND time BETWEEN 1672531200000 AND 1675209600000 AND val_bool = 1 ORDER BY time ASC;
+---------------+-----------+
| time          | value     |
+---------------+-----------+
| 1672561002447 | 4294967.3 |
+---------------+-----------+
1 row in set (0.957 sec)

​

-----------------

In der DB waren sinnlose Einträge,die beim Select durchschlagen. Die hat auch das WebIF vom Database-Addon nicht angezeigt, ware nur über Abfrage im mySQL zu finden.

1670336740253 | 3584.88 |
| 1670337550326 | 3584.89 |
[B]| 1670376078067 | 4294967.29 |[/B]
| 1670396301329 | 3584.89 |
| 1670398162051 | 3584.9 |
| 1670398522470 | 3584.91 |
| 1670398852291 | 3584.92 |

​MariaDB [smarthome]> delete from log WHERE item_id = 52 and val_num='4294967.29';
Query OK, 27 rows affected (19.562 sec)

Danach passten die Berechnungen.

[Cannon]

Die Agrartemperatursummen werde ich basierend auf der Tagesmitteltemperatur berechnen.
Aktuell wird diese aus dem Mittelwert der Stundenmittelwerte aller in der DB enthaltenen Daten errechnet. Mal schauen, vielleicht fällt mir noch was besseres ein.

Ja ich habe mich ein wenig durch den Quellcode gewühlt und auch gedacht, dass das anders sicherlich sinnvoller ist. Klingt gut.

Ggf. noch ein Hochpass- und TiefpassFilter, so dass alle Werte unterhalb und überhalb ignoriert werden. Hast Du da eine Idee?
Schlussendlich kann die Auswertung nur so gut sein, wie die Daten in der DB.

Ich denke ein Filter wäre nicht notwendig. Da sollte ja nur das gespeichert sein, was man auch braucht, außer im Zweifel Nullwerte, die da nicht reingehören, die man aber noch mit dem Parameter im Item filtern könnte. Es wird bei mir jede Wertänderung gespeichert.

Das ist tatsächlich viel. Kannst Du dir die Rohdaten in der DB mal anschauen, ab diese korrekt sind?

Habe ich gemacht, aber so richtig schlau werde ich draus nicht. Ich habe erst einmal alle Daten in Excel importiert, die das Jahr 2023 betreffen. Aber letztendlich nützen mir die Zahlen nichts. Zumindest wüsste ich nicht, wo ich da was prüfen sollte. Summenwerte, Mittelwerte?

Was ich aber noch gemacht habe die Kältesumme noch mal an einem anderen Messpunkt ermitteln lassen. So ergibt sich einmal eine Kältesumme von 117 und beim anderen messpunkt von 140. Beide Werte etwas hoch, wie ich meine.

[Sisamiwe]

So ich habe mir die Sachen noch mal angeschaut und nun auch mit der Kältesumme getestet. Das passt auch irgendwie nicht.

Hi,
ich überarbeite das Plugin grad nochmal und stelle auch die Berechnungen um, so dass wie Werte wieder korrekt sind.

Die Agrartemperatursummen werde ich basierend auf der Tagesmitteltemperatur berechnen.
Aktuell wird diese aus dem Mittelwert der Stundenmittelwerte aller in der DB enthaltenen Daten errechnet. Mal schauen, vielleicht fällt mir noch was besseres ein.
Ggf. noch ein Hochpass- und TiefpassFilter, so dass alle Werte unterhalb und überhalb ignoriert werden. Hast Du da eine Idee?
Schlussendlich kann die Auswertung nur so gut sein, wie die Daten in der DB.

Aktuell steht da bei mir -117 °C

Das ist tatsächlich viel. Kannst Du dir die Rohdaten in der DB mal anschauen, ab diese korrekt sind?

[Cannon]

So ich habe mir die Sachen noch mal angeschaut und nun auch mit der Kältesumme getestet. Das passt auch irgendwie nicht.

Kältesumme:
Aktuell steht da bei mir -117 °C. Da von allen negativen Temperaturen nur der Betrag addiert werden sollte, sollte es auch keine negativen Werte geben. Aber selbst dann erscheint mir der Wert sehr hoch. Auf dem Wetter-Portal sehe ich andere Werte und bei mir als Vergleich würde ich zwischen Berlin-Pankow (7,8) und Frankfurt (26,4) irgendwie einen Wert erwarten.

Wärmesumme:
Eine Anpassung auf das komplette Jahr wäre wirklich interessant.

Grünlandtemperatur:
Funktioniert auch mit der manuellen Berechnung nicht.

[Cannon]

Den Log Level kannst du bereits heute ohne Neustart umstellen. Im AdminIF Menü unter logs geht das. Wenn du für das Plugin keinen extra Logger definiert hast, kannst du den log level für alle Plugin während der Laufzeit ändern. Hast du für das Plugin einen eigenen Logger definiert, dann auch nur für DAS Plugin.

Das ist ja toll und ich starte immer wieder neu und tippe da in irgendwelche Dateien rum. Großartig!!! :-)

So und nun zum Log. Offensichtlich gibt es doch auch ERROR im Log, die ich nicht gesehen habe, weil die nur nach dem manuellen anstoßen des Updates auf Grund des bekannten Bugs auftreten. Hier mal mit Log:

2023-03-22  09:38:14 INFO     plugins.db_addon    Zentral.Wetter.Wetterstation.Temperatur.Gruenlandtemperatursumme received.
2023-03-22  09:38:14 INFO     plugins.db_addon    # 6 item(s) to do. || 'on-demand' item Zentral.Wetter.Wetterstation.Temperatur.Gruenlandtemperatursumme will be processed.
2023-03-22  09:38:14 ERROR    plugins.db_addon    _query_item: ItemId for item=Zentral.Wetter.Wetterstation.Temperatur.Gruenlandtemperatursumme not found. Query cancelled.
2023-03-22  09:38:14 INFO     plugins.db_addon      Result was None; No item value will be set.​

Offensichlich wird das Item nicht gefunden, aber warum?

Bzgl der Temperatursumme: ich habe kein Problem damit, die Definition zu ändern bzw eine weitere Funktion hinzu zu bringen.
Was meinst du?

Ich bin ja nicht der einzige. Aber ich teste das auch mal mit der Kältesumme. Wenn das dem auf der Agrarseite entspricht, sollten wir uns evtl. daran orientieren. Es ergibt meiner Meinung nach auch mehr Sinn die Wärmesumme ab Januar zu rechnen, wenn es denn entsprechend warm wäre.

[Sisamiwe]

Cannon

Den Log Level kannst du bereits heute ohne Neustart umstellen. Im AdminIF Menü unter logs geht das. Wenn du für das Plugin keinen extra Logger definiert hast, kannst du den log level für alle Plugin während der Laufzeit ändern. Hast du für das Plugin einen eigenen Logger definiert, dann auch nur für DAS Plugin.
Schau mal.

Bzgl der Temperatursumme: ich habe kein Problem damit, die Definition zu ändern bzw eine weitere Funktion hinzu zu bringen.
Was meinst du?

[Cannon]

Die Wärmesumme ist nicht eindeutig definiert. Ich habe es so implementiert, dass bei "current" die Jahreswärmesumme als Summe der Tagesmitteltemperaturen in der Zeit vom 20.3. und 21.9 des aktuellen Jahres errechnet werden. D.h. bislang war der Ergebnis per Definition 0.

Gruenlandtemperatursumme ist mehr oder weniger definiert. Hier werden für das laufende Jahr die (positiven) Tagesmitteltemperaturen addiert. Die Werte im Januar werden mit 0,5 gewichet, die von Februar mit 0,75.

Ja die Grünlandtemperatur ist klar. Allerdings führte auch eine Neuberechnung über das Web-Interface nicht zu einem Ergebnis > 0. Ich werde das Log-Level dann noch mal hoch setzen. -> Vielleicht ist es künftig machbar, dass man das LogLevel der Plugins im WebIF (ohne Neustart) einstellen kann. :-)

Wäremesumme ist ist der Tat komplizierter als ich dachte. Aber ich habe eine Seite gefunden, wo mehrere der Definitionen Verwendung finden, vielleicht kann man das im plugin noch weiter aufteilen. Schau mal hier: https://www.wetterportal.net/agrarwerte.php Da gibt es die Wärmesumme, die wie ich vermute einfach alle positiven Werte addiert (und das Datum außer Acht lässt) und dann noch mal Wachstumstage bei 5 °C bzw. 10 °C.

Ich versuche das mit den Daten intelligent für meien Rasenbewässerung und Düngung umzusetzen, deshalb sind die Zahlen alle sehr interessant. Denn die Temperaturen spielen eine entscheidene Rolle. Ich weiß nur noch nicht welche genau. Beispiel: Wenn wir jetzt 30°C draußen hätten, wäre der Boden mit 19% Bodenfeuchte schon fast zu trocken. Jetzt bei 10 °C würde ich aber gar nicht auf die Idee kommen zu wässern - wäre ja auch verrückt. Dennoch muss ich da immer noch recht viel manuell machen, weil es nicht pefekt an Hand der Feuchte läuft.

[Sisamiwe]

Cannon


Ich habe mich nochmal schlau gemacht:

Die Wärmesumme ist nicht eindeutig definiert. Ich habe es so implementiert, dass bei "current" die Jahreswärmesumme als Summe der Tagesmitteltemperaturen in der Zeit vom 20.3. und 21.9 des aktuellen Jahres errechnet werden. D.h. bislang war der Ergebnis per Definition 0.

Gruenlandtemperatursumme ist mehr oder weniger definiert. Hier werden für das laufende Jahr die (positiven) Tagesmitteltemperaturen addiert. Die Werte im Januar werden mit 0,5 gewichet, die von Februar mit 0,75.

Es gibt in der Tat einen Fehler im Plugin. Der Parameter "db_addon_startup: yes" wird aktuell für die Temperatursumme nicht beachtet.

Bei einer im WebIF ausgelösten Neuberechnung funktioniert die Berechnung bei mit.
Wenn du den Log-Level auf Debug stellst, kannst Du im Log die Berechnung der Items verfolgen. Bei mir sieht das so aus:

2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        handle_ondemand        handle_ondemand: _db_addon_fct='gruenlandtempsumme' detected; _db_addon_params={'year': 'current', '_database_item': Item: wetter.foshk.outdoor.temp}
2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        _query_item            _query_item called with func='max', item=wetter.foshk.outdoor.temp, timeframe='year', start=0, end=0, group='day', group2=None, ignore_value=None
2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        _get_oldest_log        _get_oldest_log for item wetter.foshk.outdoor.temp = 1658055085967
2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        _query_item            _query_item: Requested timeframe='year' with start=0 and end=0 resulted in start being timestamp=1672531200000 / 2023-01-01 00:00:00 and end being timestamp=1704067200000 / 2024-01-01 00:00:00
2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        _query_log_timestamp   _query_log_timestamp: Called with func='max', item_id=996, ts_start=1672531200000, ts_end=1704067200000, group='day', group2=None, ignore_value=None
2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        _query_log_timestamp   _query_log_timestamp: query="SELECT time, ROUND(MAX(val_num), 1) as value FROM log WHERE item_id = :item_id AND time BETWEEN :ts_start AND :ts_end AND val_bool = 1 GROUP BY date((time/1000),'unixepoch') ORDER BY time ASC", params={'item_id': 996, 'ts_start': 1672531200000, 'ts_end': 1704067200000}
2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        _query                 _query: Called with query="SELECT time, ROUND(MAX(val_num), 1) as value FROM log WHERE item_id = :item_id AND time BETWEEN :ts_start AND :ts_end AND val_bool = 1 GROUP BY date((time/1000),'unixepoch') ORDER BY time ASC", params={'item_id': 996, 'ts_start': 1672531200000, 'ts_end': 1704067200000}, cur=None
2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        _query                 _query: Result of 'SELECT time, ROUND(MAX(val_num), 1) as value FROM log WHERE item_id = 996 AND time BETWEEN 1672531200000 AND 1704067200000 AND val_bool = 1 GROUP BY date((time/1000),'unixepoch') ORDER BY time ASC': []
2023-03-21  22:17:04 INFO     plugins.priv_db_addon        _handle_query_result    No values for item in requested timeframe in database found.
2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        _query_item            _query_item: value for item=wetter.foshk.outdoor.temp with timeframe='year', func='max': [[0, 0]]
2023-03-21  22:17:04 DEBUG    plugins.priv_db_addon        handle_ondemand        handle_ondemand: result is 0 for item 'wetter.foshk.outdoor.temp.gruenlandtempsumme_aktuell' with '_db_addon_fct='gruenlandtempsumme''
2023-03-21  22:17:04 INFO     plugins.priv_db_addon        handle_ondemand          Item value for 'wetter.foshk.outdoor.temp.gruenlandtempsumme_aktuell' will be set to 0​

Schau bei dir bitte nochmal.

Fix kommt dann später.

[Cannon]

Rechnet es gar nicht oder nur die Wärmesummer und Gruenlandtemperatursumme nicht?

Das musste ich erst einmal prüfen. Mehr als die beiden Sachen nutze ich ja gar nicht. Ich habe nun noch mit minmax_heute_min und minmax_heute_max getestet. Das geht. Also gehen nur die Temperatursummen nicht.

Als Ansatz evtl. die minmax werden bei on_change aktualisiert, die Temperaturen nur täglich. Vielleicht ist da ein Problem?

[Sisamiwe]

Es rechnet einfach nicht.

Rechnet es gar nicht oder nur die Wärmesummer und Gruenlandtemperatursumme nicht?

[Cannon]

Was sagt denn das Debug-Log dazu?

Ich habe jetzt nochmal mit dem Plugin gespielt. Also das Plugin mal im Webif pausiert und wieder fortgesetzt. Beides steht im Log. Es gibt aber sonst keine Meldungen vom Plugin. Es rechnet einfach nicht.

[Cannon]

Was sagt denn das Debug-Log dazu

Kein Eintrag dazu.

[Sisamiwe]

Habe ich was übersehen?

Die Konfig sieht gut aus.

Was sagt denn das Debug-Log dazu?