Support Thread - "DatabaseAddOn" Plugin

[Yfkt5A]

Edit: Gerade gesehen das das Plugin wohl erst mit der 1.9.4 dazugekommen ist... https://smarthomeng.github.io/smarth...en-bei-plugins

Wie kann ich das Plugin denn überhaupt aktivieren?

In der Webif finde ich es nicht, ausser ich habe Tomaten auf den Augen und wenn ich in der plugin.yaml folgendes ergänze:

db_addon:
    plugin_name: db_addon

werden die structs trotzdem nicht gefunden

ERROR lib.config add_struct_to_item_template: Struct definition for 'db_addon.verbrauch_1' not found (referenced in item Zaehlersta nd)
ERROR lib.config add_struct_to_item_template: Struct definition for 'db_addon.verbrauch_2' not found (referenced in item Zaehlersta nd)
ERROR lib.config add_struct_to_item_template: Struct definition for 'db_addon.zaehlerstand_1' not found (referenced in item Zaehlersta nd​

Zusatzfrage:
Gibt es eine Möglichkeit den Zählerstand zu setzen? Beispielsweise hat mein Stromzähler schon einige tausend kwh aufm Buckel, dann wäre der erste Tageswert extrem hoch. Oder man bekommt einen neuen Zähler, dann hätte man einen Tag mit Minuswert. Oder sehe ich das fasch?

[Cannon]

Noch mal ein Update. Es funktioniert leider doch nicht wie erwartet:

Regen-Item: letzte Änderung 17.06.2023 18:08:40 -> jetzt False, davor True

jetzt 19.06 0:30 Uhr:
minmax_heute_max: -> immernoch "true", letztes Update 17.06.2023 13:47:36 -> Warum gestern und heute kein Update?
minmax_heute_minus1_max -> immernoch "true", letztes Update 18.06.2023 00:01:19 -> Warum heute noch keine Update?

Auch ein erzwingen der Neuberechnung im WebIF führt nicht zu Änderungen dieser beiden.

[Cannon]

Vielleicht noch eine Anregung für zukünftige Versionen:

Beispiel: minmax_last_24h_max, minmax_last_7d_max, ....

Man könnt das für den Endnutzer flexibler machen, wenn man das auf minmax_last_max reduziert und den zusätzlichen Paremeter mittels Item-Attribut festlegt, also beispielsweise:

in Stunden:

db_addon_time: 24h

oder andere Stunden:

db_addon_time: 12h

oder in Sekunden:

db_addon_time: 86400

oder in Tagen:

db_addon_time: 7d

Also ich fände das toll! :-)

[Cannon]

Alle Berechnungen, die sich auf heute bzw. eine aktive Periode (heute, Woche, Monat, Jahr) beziehen, werden per se nicht beim Start ausgeführt, sondern erst, wenn der erste neue Wert empfangen wird. Das sollte so auch im Log stehen.

Naja, wenn ich auf DEBUG umstelle evtl. So steht da aber nichts. Heute ist ein neuer Tag und "gestern" wurde berechnet. Ich habe den cache auf yes gesetzt und dann geht das auch, wie gewünscht. Die Berechnung muss ja dann auch nicht zu Systemstart statfinden.

Ich denke, dass Du hier mit einem Hilfsitem arbeiten musst, um die Wandlung von num auf bool zu machen. Es kann auch sein, dass der Parser in shNG das auch kann.

Es funktioniert auch so, ohne Umwandlung. Ein eval: bool(value) funktionierte auch nicht. Wenn das so nicht ginge, wäre wohl wirklich ein Hilfsitem nötig.

[Sisamiwe]

minmax_heute_max geht aber irgendwie nicht. Im plugin steht dann unten bei update_cycle daily und bei run on Init steht da Nein, obwohl auch bei startup yes eingestellt wurde. Das mit minus1 geht hingegen. Woran kann das liegen?

Alle Berechnungen, die sich auf heute bzw. eine aktive Periode (heute, Woche, Monat, Jahr) beziehen, werden per se nicht beim Start ausgeführt, sondern erst, wenn der erste neue Wert empfangen wird. Das sollte so auch im Log stehen. Deshalb steht auch im WebIF (auch in Deinem Auszug oben), dass die Berechnung "on-change" passiert, also wenn ein neuer Wert empfangen wird.
Das hast Du richtig aus dem Code gelesen. Das ist so umgesetzt, um die Zugriffe auf die DB zu reduzieren. Ich kann ja mal überlegen, ob das nicht auch anders geht.

Ich habe das jetzt mal so mit num gestetet. Langfristig wollte ich natürlich mein Item auf bool umstellen. Das sollte ja ohne weitere Umwandlung gehen oder?

Ich denke, dass Du hier mit einem Hilfsitem arbeiten musst, um die Wandlung von num auf bool zu machen. Es kann auch sein, dass der Parser in shNG das auch kann.

[Cannon]

Ich wollte die Funktion dafür missbrauchen zu wissen, ob es heute oder gestern geregnet hat.

            Regen:
                type: bool
                knx_dpt: 1
                knx_cache: 4/3/0
                visu_acl: rw
                database: init
                database_maxage: 732
                heute:
                    type: num
                    visu_acl: rw
                    db_addon_fct: minmax_heute_max
                    db_addon_startup: yes
                gestern:
                    type: num
                    visu_acl: rw
                    db_addon_fct: minmax_heute_minus1_max
                    db_addon_startup: yes

minmax_heute_max geht aber irgendwie nicht. Im plugin steht dann unten bei update_cycle daily und bei run on Init steht da Nein, obwohl auch bei startup yes eingestellt wurde. Das mit minus1 geht hingegen. Woran kann das liegen?

Zentral.Wetter.Wetterstation.Regen.gestern     num     minmax_heute_minus1_max     daily     Ja     0     16.06.2023 21:40:53     16.06.2023 21:40:53
Zentral.Wetter.Wetterstation.Regen.heute     num     minmax_heute_max     on-change     Nein     0     16.06.2023 21:40:53     16.06.2023 21:40:53​​

Ich habe das jetzt mal so mit num gestetet. Langfristig wollte ich natürlich mein Item auf bool umstellen. Das sollte ja ohne weitere Umwandlung gehen oder?

Nachtrag: Ich habe mal im Code geschaut. Das ist da so fest verbaut, dass minmax_heute_max nur bei on_change aufgerufen wird, also erst dann sehe ich die Werte. Bei dem minus1 hingegen auch beim Startup. RIchtig?

[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.