Database Plugin und Sh.py Neustart

[henfri]

Hallo,

Ich berechne täglich meinen Stromverbrauch und den Anteil nachts und Tagsüber über folgendes Eval:

        Nachtsuebersumme:
            name: Last
            type: num
            database: 'yes'
            eval: (sh.Haustechnik.Stromzaehler.Zaehlerstand()-sh.Haustechnik.Stromzaehler.Zaehlerstand.db('min', '16h'))
            crontab: '30 9 * * =1'
            visu: 'yes'
            influx: true
            enforce_updates: true

Jetzt ist mir aufgefallen, dass hier manchmal Peaks von ca. 3000 entstehen.

Nach langem überlegen ist mir aufgefallen, dass das passieren kann, wenn 0 subtrahiert wird, denn 3000 entspricht dem Zaehlerstand().

Ich habe also im database-Plugin Webinterface nachgeschaut und tatsächlich finden sich vereinzelnd nullen. Ich habe nun herausgefunden, dass sich diese finden, wenn ich sh.py neustarte.

Wie kann ich das Problem umgehen?

Gruß,
Hendrik

[henfri]

Hallo,

ich glaube, wenn ich dem Item Zählerstand einen parameter
database: 'init' gebe, sollte es klappen, oder?

Gruß,
Hendrik

[Onkelandy]

Bin mir nicht sicher, ob er nicht trotzdem den Wert durch das eval dann überschreibt - aber prinzipiell wäre das der richtige Ansatz, ja. Eventuell musst du im eval noch sowas in die Richtung einfügen eval: sh.Nachtsuebersumme() if sh.Nachtsuebersumme.changed_by() == "Database:none" else deine Formel.

[Maexle]

Zählerstand einen parameter
database: 'init' gebe, sollte es klappen

Hallo Hendrik,

hat das so geklappt?
Verstehe ich das richtig? Du speicherst einen Wert um 9:30? Nur diesen einen oder mehrmals am Tag?

vielleicht magst hier
https://knx-user-forum.de/forum/supp...-e#post1720446
mal einen Blick drauf werfen.
danke

[aschwith]

Ich habe ein Ähnliches Problem im Zusammenspiel mit dem Database Plugin und einem SmarthomeNG Neustart:

Das Problem: Normalerweise wird beim Start wie gewollt, das Item per Database Init direkt aus der Datenbank initialisiert. Aber es gibt reproduzierbar Fälle, in denen das Item erst auf den normalen Init Wert initialisiert wird und anschließend erst auf den letzten Wert aus der DB gesetzt wird. Leider verstehe ich die Systematik dahier noch nicht.

Meine Item Konfiguration sieht so aus:

waermemenge:
    type: num
    visu_acl: ro
    value: -1000
    enforce_updates: True
    database: init
    log_change: q_hkr_items

Der Wert value: -1000 ist absichtlich gewählt, um den Wert eindeutig identifizieren zu können. Wenn das Problem auftritt sieht die Datenbank (WebIf database plugin) z.B so aus:

72    26.04.2022 16:38:43    None    47160559.0    26.04.2022 16:39:48
72    26.04.2022 16:26:10    752.9    -1000.0    26.04.2022 16:39:48
72    26.04.2022 16:25:07    63.1    47160362.0    26.04.2022 16:36:06

Man kann erkennen, dass hier das Item nach dem Neustat erst auf den Init Wert (-1000.0) gesetzt wird und anschließend erst der Wert über das database:init gesetzt wird.

Kennt einer das Problem bzw. kann etwas zu dem Austartverhalten von item init sagen? Wie wird im Normalfall mit database:init das Setzen eines Items auf den Initialwert unterdrückt? Kann das ein Timing Problem sein?

[Msinn]

Aber es gibt reproduzierbar Fälle, in denen das Item erst auf den normalen Init Wert initialisiert wird

Das ist bei jedem Iteem mit database: init während der Initialisierungsphase so. Liest und verwendest Du die Werte evtl. schon bevor die Initialisierung von SmartHomeNG abgeschlossen ist?

[aschwith]

Hi Martin,

ich nutze das Item anschließend in einem eval für ein anderes Item. Aber das ist, glaube ich nicht der springende Punkt. Ich sehe die Unterschiede in der Item Initialisierung über das log_change (siehe Item Definition oben) und auch die Datenbank selber.

a) Wenn alles aus meiner Sicht "richtig" läuft, wird nach einem Neustart das Item direkt auf den Init Wert aus der Datenbank initialisiert. Das sehe ich zum einen über das log_change logfile und in der Datenbank. Hier taucht der Initialisierungswert (= -1000) nirgendwo auf.

b) Wenn es aus meiner Sicht "schief" läuft, wird das Item erst auf -1000 gesetzt und anschließend auf den DB Initwert. Das sehe ich auch zum einen an den DB Einträgen, bei denen auch die -1000 in der Datenbank abgelegt wird und zum anderen wieder im log_change log. Du sagst ja, das sei eigentlich immer der normale Weg.


Wie ist den für Punkt a) der normale Weg, den regulären Initialisierungswert (hier die -1000) zu unterdrücken und statt dessen nur mit dem DB Initwert zu initialisieren? Sinn und Zweck ist ja auf jeden Fall, dass die -1000 nicht in die DB geschrieben werden.

Außderdem wäre meine Erwartung, dass die -1000 auch nicht als Update getriggert werden und damit in alle nachgelagerten Eval Ketten eingehen. Liege ich da richtig?

VG
Alex

[Msinn]

Genau die eval Nutzung könnte der entscheidende Punkt sein.

Die initialisierung der Items (initial_value und die initials eval Berechnunung) findet statt, bevor die Plugins initialisiert (init und parse_item) und gestartet (run) werden. Damit erscheint mir das von Dir beschreibene Verhalten logisch. Das wird auch andere Plugins, wie z.B. das knx Plugin betreffen.

[aschwith]

Hallo @Msinn,

etliche Log Erweiterungen und Analysen später, habe ich das Problem gefunden: Das Problem liegt im database plugin:

• Du hast recht, die Initialisierung bei einem item mit Eigenschaft database:init läuft IMMER so ab: Erst wird durch den Corde das Item auf den Initial_Value gesetzt. Nennen wir diesen Wert i. Anschließend wird das Item auf den Wert aus der DB gesetzt. Nennen wir diesen Wert x. Das geschieht in der parse_items() Methode, also bevor das DB plugin normal läuft.
• Sobald das DB plugin läuft und die update_item() Methode mit item Wert y getriggert wird, schreibt das Plugin zwei Werte in den DB Buffer:

Einmal den previous Wert, in diesem Fall Wert x und

Anschließend den aktuellen Wert, in diesem Beispiel Wert y mit bis jetzt noch unbekannter Dauer (duration).

• Das ist genau das gewünschte Sollverhalten bei database:init. Der Item Inital_Value taucht gar nicht in der DB auf, versaut die Plots nicht und macht auch keine Probleme bei evtl. anschließenden evals.
• Das Problem tritt bis jetzt immer dann auf, wenn der item Wert sich in der Restart Phase nicht ändert, d.h. x=y. Hier wird die update_item() Methode immer noch mit Wert y getriggert. Das Plugin schreibt jetzt wieder zwei Werte in die DB:

Einmal den previous Wert. Dieser ist in diesem Fall der Initial_Value, Wert i, da x=y.

Einmal den aktuellen Wert, in diesem Beispiel Wert y=x.

• Hier wird jetzt auf einmal der Initial_Value des items in die DB geschrieben. Ein Umstand, den man mit database:init nicht haben möchte.
• Mein Lösungsansatz ist, vor dem schreiben des previous Values in der update_item() Methode des DB Plugins zu überprüfen, ob das Item Attribut previous_change_by ein Setzen durch Init:Initial_Value anzeigt und genau für diesen Fall ein Schreiben in die DB zu unterdrücken. Damit ist meiner Meinung nach das Konzept wieder sauber. Lösung mit Commit 17a9114.

[henfri]

Klasse.
Danke für die aufwändige Analyse und Erklärung!

Gruß,
Hendrik

[strupp3003]

Hallo Zusammen,

wäre es auch möglich ein Attribut einzubauen, das verhindert dass der Init wert überhaupt in die DB geschrieben wird?

Use-Case: Lasse mir 1x pro Stunde den Energieverbrauch der letzten Stunde auf den KNX senden und den möchte ich in der DB haben.
Also z.B. einen Eintrag 15,7kWh um 09:00:01 (für den Zeitraum 08:00-09:00) 13,3kWh um 10:00:01 (für 09:00-10:00) usw.
Das kann man sich dann mit Grafana schön als Bar-Graph anzeigen lassen.

Wenn ich jetzt zwischendurch SHNG neu starte habe ich auf einmal noch einen Datenpunkt mit dem letzten Wert (Init-Wert) dazwischen, also z.B. 15,7kWh 09:24:05
Das würde ich gerne vermeiden....
Sonst muss ich diese doppelten Werte iwie per Workaround ausfiltern, z.B. in dem ich initial_value auf einen negativen wert setze...

[Msinn]

Das ist bisher im database Plugin nicht vorgesehen.

[aschwith]

strupp3003, Du sprichst mir aus der Seele. Steht bei mir auch schon lange auf der TODO Liste. Nötig wären zwei Dinge:

a) Das Schreiben von Werten, die durch die DB selber beim Start initialisiert werden, müsste unterdrückt werden. Hierzu würde sich das Attribut item.source() anbieten.
b) Aktuell schreibt das DB Pluging für Items, die durch das Plugin initialisiert werden, als Item Source 'Init' rein. Das müssten wir nochmal in 'DBInit' ändern, um gezielt in a) nur DB Initialisierungen und nicht generell Initialisierungen durch den Core zu unterdrücken.

[Msinn]

Ich bin mir nicht sicher, dass das so simpel ist. Das Plugin schreibt keinen bewussten "Init-Wert". Das Schreiben dieses Wertes entsteht dadurch, dass das Item beim Start 0 ist. Sobald das Item anschließend einen neuen Wert erhält, wird dieser durch die Veränderung (0 -> neuer Wert) in die Datenbank geschrieben.

Ob diese Wert-Änderung die erste Änderung nach dem Start von SmartHomeNG ist, kann das Plugin nicht feststellen. Dadurch würde das unterdrücken des ersten Wertes dazu führen, dass kein erster Wert geschrieben würde und daher die zweite Wertänderung as die erste erscheinen würde und daher auch nicht geschrieben würde...

Um das zu umgehen, müsste das database Plugin eine Liste aller Items verwalten in der es sich merkt, ob der 1. Wert bereits unterdrückt wurde.

Mir ist auch nicht ganz klar, was der Zweck der Übung ist. Das Plugin schreibt jede Wertänderung in die Datenbank, was ja auch das ist, was es tun soll.

Wenn man bewusst nur zu bestimmten Zeitpunkten Daten schreiben will, benötigt man ein Item, welches nur zu den entsprechenden Zeitpunkten verändern wird. Dieses Item wird dann mit dem Attribut database: init versehen. Dadurch wird beim Start das Item mit dem letzten Wert aus der Datenbank initialisiert. Danach wird erst zum nächsten gewünschten Zeitpunkt das Item aktualisiert (und damit auch die Datenbank).

[strupp3003]

Danke für eure Gedanken und Antworten!

“Wenn man bewusst nur zu bestimmten Zeitpunkten Daten schreiben will, benötigt man ein Item, welches nur zu den entsprechenden Zeitpunkten verändern wird.”

Ja, genau das habe ich ja: Ein Item, das nur zu bestimmten Zeitpunkten geschrieben wird (stündlich) - Und hald dann, wenn SHNG neu gestartet wird…

Mit database: init statt database: true schreibt er mir hald statt der 0 den letzten wert nochmal rein. Effekt ist der gleiche, ich bekomme in meinem Balkendiagramm einen zusätzlichen Balken den ich nicht brauchen kann.

Hab es bei mir jetzt so gelöst, dass ich initial_value auf -1 gesetzt habe. Da meine (echten Verbrauchs-) Werte alle positiv sind filtere ich in Grafana in der MySQL Query einfach auf Werte >= 0.
Wenn man auch negative Werte braucht (z.B. Temparatur) könnte man ja auch mit beliebig anderen eindeutig sinnlosen Werten (z.B. -1000) initialisieren…
—> nicht der eleganteste Weg aber funktioniert :-)
Und damit auch Einträge geschrieben werden, wenn sich der Wert nicht ändert oder mehrere Stunden hintereinander auf 0 bleibt noch enforce_change: true