Database Plugin und Sh.py Neustart

[aschwith]

Hi zusammen,

Msinn: Ich sehe das Problem aktuell auch nur in Verbindung mit database:init. Das Verhalten wird genau wie von strupp3003 beschrieben sichtbar.

a) Item bekommt einen bestimmten Wert und wird in die DB geschrieben
b) SmarthomeNG wird neu gestartet
c) Nach dem Neustart wird das item wegen database:init aus der DB korrekt initialisiert.

Bis hierher alles wie gewünscht. Die DB wurde bis jetzt nicht verändert Jetzt passiert aber das störende:
d) Die DB Funktion update_item wird aufgerufen und der Wert, der durch die DB Initialisierung geschrieben wurde, wird jetzt nochmal in die DB geschrieben.
Defakto gab es keine Änderung des Items und trotzdem wird ein neuer DB Eintrag geschrieben. Bei Plots von Werten wir Zählerständen etc. macht das keinen Sinn und sieht störend aus.


Ich teste gerade einen Patch für das DB plugin bei dem ich in der update_item Funktion das Schreiben in die DB blockiere, falls das item mit database:init konfiguriert ist und die Item Eigenschaft changed_by == 'DBInit' ist.

Msinn: Siehst Du darin ein Problem? Sobald mein Test abgeschlossen ist, schiebe ich den Patch zum Testen ins Develop.

Mit enforce_updates hat es meiner Meinung nach nichts zu tun. Jede item Änderung von außerhalb des Plugins wird weiterhin geschrieben. Bei enforce_updates: true werden halt auch identische Werte geloggt.

[Msinn]

Klingt nach der Idee, die ich dazu hätte: Bei der Initialisierung (lesen aus der DB) zu verhindern, dass der Wert in den Cache geschrieben wird, wodurch er dann beim nächsten Dump erneut in die DB geschrieben würde.

[aschwith]

Hallo Msinn,

Deine Idee würde ich gerne nochmal detaillieren. Mein Vorschlag oben, die update_item Funktion des DB plugins für aus DB initialisierte Werte funktioniert nicht, weil die Initialisierung des items über die DB bewusst nicht die update_item Methode triggert.

Wo genau würdest Du das Schreiben in den Cache verhindern? Meinst Du das self._buffer_insert in der parse_item Funktion des DB plugins? Diese wird bei mir nie aufgerufen.

Ich glaube, wir müssen wirklich das Schreiben direkt in der dump Funktion verriegeln. Das bei der Initialisierung gesetzte Item wird ohne Trigger nämlich im Dump gar nicht weg geschrieben. Erst bei der Vorbereitung der Stop Funktion beim Beenden von smarthomeNG werden alle beim DB registrierten Items nochmal weggeschrieben.

[aschwith]

In dem "finalize" branch in der _dump Funktion des DB Plugins wird beim Beenden jedes Item nochmal ein letztes Mal in die DB geschrieben. Hier würde ich blockieren, das funktioniert.

Meine Frage an Euch, soll
a) das Schreiben beim Shutdown für alle Item mit Attribut database:init ausgelasen werden oder
b) Soll ich ein neues Item attribute "database_write_on_shutdown einführen?

VG

[aschwith]

Im Develop befindet sich eine neue DB plugin version bereit fürs Testing. Über ein neues optionales Item attribute "database_write_on_shutdown: False" kann das standardmäßig konfigurierte neu Schreiben aller im Plugin registrierten Items beim Runterfahren von smarthomeNG unterdrückt werden.

Für Items mit attribute "database_write_on_shutdown: False" wird jetzt beim Runterfahren nur noch der aktuell schon vorhandene Eintrag aktualsiert aber kein zustätzlicher mehr geschrieben. Damit sollten nur noch Werte in der DB abgelegt werden, die wirklich geändert wurden, oder, falls zusätzlich enforce_updates:True gesetzt ist, ein update bei identischem Wert bekommen haben.

[Onkelandy]

Gibt es beim Nicht-Schreiben beim Shutdown nicht das Problem, dass dann die Dauer nicht korrekt in die Datenbank geschrieben wird, sondern eben None bleibt?

[aschwith]

Die Dauer bleibt solange None in der DB, bis der nächste Wert in die DB geschrieben wird. Dann erst kann die Duration für das vorherige Item bestimmt werden.
So ist das im regulären Betrieb und jetzt auch über einen Restart hinweg. Gerne testen!

[bmx]

Eventuell könntest Du in die Doku unter user_doc noch etwas schreiben, bei welchen Dateneinträgen man diesen Eintrag sinnigerweise ergänzt und bei welchen man eher den Standard bestehen läßt. Wennn dazu noch ein Bild käme um das zu erläutern wäre das Oberklasse :-)

[aschwith]

bmx, ja schiebe ich nach. In der Readme steht schon was dazu, in die user_doc ergänze ich noch was. VG

[Msinn]

Die user_doc.rst ist die wichtigere von beiden. Sie wird ja automatisch in die SmartHomeNG Doku einbezogen.
die README ist hingegen eine aussterbende Spezies.

[aschwith]

Ja, das ist bekannt. Beim DB plugin ist leider die Hauptdoku immer noch die Readme. Das muesst auch mal ungestellt werden. Ich habe auf jeden Fall die user_doc.rst für das neue Feature ergänzt.

[bmx]

Ok, ich habe das eben gemergt und meine wenigen Übersetzung mit beigefügt sowie eine Erweiterung was das Aufräumen von alten Einträgen mit maxage betrifft.

[Onkelandy]

Ich hatte parallel an einigen Änderungen des Plugins gearbeitet, was leider zu einer Menge unschöner Konflikte geführt hat. Ich glaube, ich habe alles sauber gelöst - aber könntet ihr vielleicht mal reinschauen und testen bitte?
https://github.com/smarthomeNG/plugins/pull/637

[wvhn]

aschwith Onkelandy

Wenn Ihr am Plugin arbeitet: habt Ihr das Thema der zusätzlichen Werte bei der Plot-Abfrage auf dem Schirm? Hier ist das Problem einschließlich der ggfls. zu löschenden Programmzeilen recht gut beschrieben.

Das Feature der zusätzlichen Werte ist bei Linien-Plots sinnvoll, da es sicher stellt, dass die Kurven immer die volle Zeitspanne bis an die Ränder abbilden. Insbesondere bei langsam veränderlichen Werten ist das gut.

Bei Säulen-Plots passen aber die Zeitraster für die zusätzlichen Werte meistens nicht und so entwickelt sich das Feature zum Bug. Da Highcharts sich am kleinsten vorhandenen Zeitintervall orientiert und dann alle Säulen entsprechend schmal darstellt, sehen die Plots oft nicht gut aus. Ich kann das in smartVISU leider nicht einfach wieder rausrechnen.

Optimal wäre eine Datenbank-Ausgabe, die die zusätzlichen Werte separat übermittelt oder besonders kennzeichnet, so dass smartVISU je nach Plot-Typ entscheiden kann, ob und wie diese Werte verwendet werden. Zur Übermittlung fehlt mir aber noch die zündende Idee.

Gruß
Wolfram

[bmx]

Ich habe mal unter Issue #787 die Notwendigkeit von Websocket Änderungen dokumentiert wenn man Serien mit verschiedenen Zeiträumen ein und desselben Items haben möchte.

Wenn Du eine Idee hast wie wird das in Zukunft handhaben wollen, kannst Du das dort oder unter diesem Issue kommentieren.