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