Support Thread - "DatabaseAddOn" Plugin

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

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

[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

[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

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

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]

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.

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

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.

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

[Onkelandy]

Zieh dir das Plugin am besten hier: https://github.com/sisamiwe/plugins/tree/dev-db_addon

Das Plugin ist bei dir wohl nicht richtig geladen, schau doch mal im Log vor dem struct Fehler, ob was dazu steht. Database Plugin läuft?

Was stört dich am hohen Zählerstand? Der Verbrauch wird ja relativ berechnet.

[Yfkt5A]

Zieh dir das Plugin am besten hier: https://github.com/sisamiwe/plugins/tree/dev-db_addon

Da ich das Docker-Image von jentz1986 nutze ist das nicht so einfach möglich, oder?
Leider ist der noch auf dem Stand von 1.9.3, aber habe leider kein aktuelleres finden können.

Was stört dich am hohen Zählerstand? Der Verbrauch wird ja relativ berechnet.

Schon, aber z.B. wenn mein Zählerstand jetzt sagen wir 25000kWh hat und ich die Berechnungen starte, wird der Tag eins wohl die 25000kWh zuviel haben, genau wie die erste Woche, Monat und Jahr. Oder habe ich einen Denkfehler, bzw. die Berechnung nicht verstanden!?

Anders wenn ein Zähleraustausch stattfindet, dann hätte man am Vortag noch z.B. 60000kWh und nach dem Tausch 0kWh und damit einen Minuswert!?

[Sisamiwe]

Anders wenn ein Zähleraustausch stattfindet, dann hätte man am Vortag noch z.B. 60000kWh und nach dem Tausch 0kWh und damit einen Minuswert!?

Das DBADDON Plugin nutzt nur die Daten aus der Datenbank. Um das zu beschrieben Verhalten zu umgehen, müssten die Daten in der Datenbank bspw. über Items lösen.

Beste Grüße

[Onkelandy]

Szenario 1:
1.12. 0:00 Zählerstand 25.000
1.12. 23:59 Zählerstand 25.100
-> Verbrauch_heute = 100

Szenario 2:
30.11. 0:00 Zählerstand 60.000
1.12. 0:00 Zählerstand 0
-> Warnung im Log wegen negativem Wert für Tag, Woche, etc. Ja. Das kannst du nur verhindern, wenn du nach einem Reset über ein Hilfsitem in die Datenbank schreiben lässt, wo automatisch 60.000 dazu gezählt wird. Ich glaub, es gibt im Forum irgendwo was in die Richtung Höchststand * Resetamount + aktueller Stand

Ich denke, du kannst dir aus dem Git einfach das zip ziehen und den Ordner db_addon im Docker ersetzen. Aber wie oben geschrieben liegt das Problem eher woanders. Sollte alles auch mit der alten Version klappen.

[Cannon]

Gern würde ich das DataBaseAddon nutzen, jedoch führt das bei mir immer wieder zu Problemen, weil die Datenbank blockiert wird. Kann man das irgendwie verhindert? So werden ja auch kritische Dinge nicht in die Datenbank geschrieben. Es hilft übrigens auch nicht das Plugin zu pausieren, es muss wirklich komplett in der plugin.yaml auskommentiert werden.