Ankündigung

Einklappen
Keine Ankündigung bisher.

Support Thread - "DatabaseAddOn" Plugin

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Yfkt5A
    antwortet
    Zitat von Onkelandy Beitrag anzeigen
    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.

    Zitat von Onkelandy Beitrag anzeigen
    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!?

    Einen Kommentar schreiben:


  • Onkelandy
    antwortet
    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.

    Einen Kommentar schreiben:


  • Yfkt5A
    antwortet
    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:
    Code:
    db_addon:
        plugin_name: db_addon
    werden die structs trotzdem nicht gefunden
    Code:
    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?
    Zuletzt geändert von Yfkt5A; 29.11.2023, 17:06.

    Einen Kommentar schreiben:


  • Cannon
    antwortet
    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.

    Einen Kommentar schreiben:


  • Cannon
    antwortet
    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! :-)

    Einen Kommentar schreiben:


  • Cannon
    antwortet
    Zitat von Sisamiwe Beitrag anzeigen
    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.

    Zitat von Sisamiwe Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


  • Sisamiwe
    antwortet
    Zitat von Cannon Beitrag anzeigen
    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.

    Zitat von Cannon Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


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

    Code:
                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?

    Code:
    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?
    Zuletzt geändert von Cannon; 16.06.2023, 20:55.

    Einen Kommentar schreiben:


  • Sisamiwe
    antwortet
    Zitat von gklein Beitrag anzeigen
    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

    Einen Kommentar schreiben:


  • gklein
    antwortet
    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.

    Code:
      
    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​

    Einen Kommentar schreiben:


  • gklein
    antwortet
    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.png​Das Debug-Log hat mich noch nicht weitergebracht.

    Code:
    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
    :
    Code:
    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.

    Code:
    
    
    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.
    Zuletzt geändert von gklein; 30.03.2023, 19:38. Grund: Info zur Lösung

    Einen Kommentar schreiben:


  • Cannon
    antwortet
    Zitat von Sisamiwe Beitrag anzeigen
    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.

    Zitat von Sisamiwe Beitrag anzeigen
    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.

    Zitat von Sisamiwe Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


  • Sisamiwe
    antwortet
    Zitat von Cannon Beitrag anzeigen
    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.

    Zitat von Cannon Beitrag anzeigen
    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?

    Einen Kommentar schreiben:


  • Cannon
    antwortet
    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.
    Zuletzt geändert von bmx; 23.03.2023, 11:46.

    Einen Kommentar schreiben:


  • Cannon
    antwortet
    Zitat von Sisamiwe Beitrag anzeigen
    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:

    Code:
    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?

    Zitat von Sisamiwe Beitrag anzeigen
    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.

    Einen Kommentar schreiben:

Lädt...
X