Neues Database Plugin

[Onkelandy]

Ich hab beim Start auch im shng log negative Durations angemeckert bekommen. Werde ich mal beobachten.

[wvhn]

Ihr redet von der duration der Anfrage für die series

Da hast Du Recht. Sorry. Das liegt sicher daran, dass wir gerade an dem Thema gearbeitet haben

[aschwith]

Hallo wvhn und Msinn ,

Ihr redet von der duration der Anfrage für die series, ich rede von Werten in der Datenbank, die negative Durations haben, d.h. bei denen der Endzeitpunkt in der DB jünger als der Startzeitpunkt ist. Ich vermute, dass das Problem irgendwo mit dem Caching des Database plugins zusammenhängt. Das Problem der negativen Durations in der DB habe ich in diesem Thread schon ausführlich beschrieben. Falls jemand eine Idee hat, oder evtl. auch negative Durations auftauchen, gerne melden.

VG

[wvhn]

Der erweiterte Parser in v2.7.2 setzt negative durations explizit auf 0. Das muss so sein, damit man in der SV die Plots auf der Zeitachse in die Zukunft laufen lassen kann. SV und shNG können dazu sowohl mit absoluten Zeitstempeln umgehen (bei beiden ein undokumentiertes Feature), als auch mit durations.

Die highcharts arbeiten mit absoluten Zeitstempeln, was zu der kuriosen Situation führt, dass SV intern die durations in Zeitstempel umrechnet, in Richtung shNG Kommandos mit durations versendet und die Antworten aus dem database-plugin über den Websocket mit Zeitstempeln zurück kommen. Vom io-Treiber werden die Werte in Verbindung mit der update-Methode der widgets direkt in den item-buffer geschrieben, aus dem sich die Plots bedienen. Deshalb sind die Möglichkeiten, in SV noch an den empfangenen Werten zu manipulieren, begrenzt.

Ein kontrovers diskutiertes Thema ist noch die "eigenmächtige" Ergänzung der series um 2 Werte. Dies hat zum Zweck, dass die series immer bis 'now' gehen, aber es sind eben keine echten Werte und stören z.B. die (gestackten) Plots für die Darstellung der Tagesverbräuche. Das müssen wir uns in einer nächsten Version nochmal gemeinsam ansehen.

Gruß
Wolfram

[Msinn]

Wo soll das Problem denn auftreten? Der erweiterte Parser für series unterbindet negative durations ja explizit

[aschwith]

Ich habe eine Warning Log Message für das Database plugin ins Develop gepusht, dass bei negativen durations (Problembeschreibung und Diskussion hier im Thread) eine entsprechende Warning ausgibt. Ich bin gespannt, bei wem das Problem noch sporadisch auftritt. Ich will bei dem Problem mal vorankommen

[Msinn]

Änderungen beim database Plugin in SmartHomeNG v1.7.2


Das Datenbank Plugin wird beim ersten Start einige Zeit benötigen und erhebliche CPU Last produzieren. Das rührt daher, dass das Plugin ab v1.7.2 eine regelmäßige Aktualisierung der Datenbank durchführt und dabei Datensätze löscht, die älter als ein gewisses Alter sind. Da die Datenbank eine größere Zahl älterer und nicht mehr benötigter Datensätze enthält, wird das beim ersten Start einige Zeit in Anspruch nehmen.

Gesteuert wird diese Datenbank Pflege über ein neues Item Attribut des database Plugins. Das Attribut database_maxage bei einem Item gibt die Anzahl Tage an, die History Daten für das Item in der Datenbank gespeichert werden sollen.

Items, bei denen das Attribut gesetzt ist, sind

• env-Items wie cpu Load, Anzahl Threads, etc. Für diese Items werden die History Daten gelöscht, die älter als 30 Tage sind.
• Teile der Items des darksky Plugins, wenn die struct Definitionen des Plugins genutzt werden. Hierbei handelt es sich um Vorhersage Daten. Diese Daten werden für 3 Monate aufgehoben. Danach interessiert sicher niemand mehr, ob die Vorhersage von vor 93 Tagen für den Folgetag (also vor 92 Tagen) richtig war

Alle anderen Daten bleiben unberührt.

Bei dieser Reorganisation wird die Datenbank nicht kleiner. Es wird aber in der Datenbank freier Platz geschaffen um neue Daten aufzunehmen. Wenn die Datenbank auf der HDD verkleinert werden soll, muss auf die Mittel des verwendeten Datenbank Systems (SQLite bzw. MySQL) zurück gegriffen werden.

[Tom Bombadil]

Das geht schon auf Grund der Datenspeicherung nicht. Es werden nur Veränderte Werte und die Dauer eines Wertes geschrieben. Einen Wert "kein Wert" gibt es nicht.

Und genau das hat mich schon immer gewundert. Denn bei der Kommunikation shNG --> sV werden keine Dauern, sondern Zeitstempel in Unix Millis übertragen (der Zeitstempel Datensatz dran):

[io.smarthome.py] receiving data:  {"series":[[1590235879494,0.0],[1590238972539,1.0],[1590240712776,0.0],[1590262192645,1.0],[1590264352766,0.0],[1590298496502,1.0],[1590299996430,0.0],[1590310677664,1.0],[1590313137495,0.0],[1590332338386,1.0],[1590334138748,0.0],[1590346978590,1.0],[1590348718786,0.0],[1590381060482,1.0],[1590382560615,0.0],[1590415083800,1.0],[1590416583421,0.0],[1590435124662,1.0],[1590436804668,0.0],[1590471486694,1.0],[1590473106626,0.0],[1590475386812,1.0],[1590477666700,0.0],[1590517747639,1.0],[1590519427828,0.0],[1590523687775,1.0],[1590525847357,0.0],[1590560047639,1.0],[1590561547886,0.0],[1590599469632,1.0],[1590601391420,0.0],[1590609733610,1.0],[1590611533884,0.0],[1590648314402,1.0],[1590650114791,0.0],[1590685997854,1.0],[1590688038625,0.0],[1590694400402,1.0],[1590695900605,0.0],[1590725722418,1.0],[1590727222644,0.0],[1590758305517,1.0],[1590759805702,0.0],[1590783807579,1.0],[1590785728447,0.0],[1590821191882,1.0],[1590822931562,0.0],[1590828512688,1.0],[1590830972921,0.0],[1590830972921,0.0],[1590840679495,0.0]],"cmd":"series","sid":"heizung.rk3.ladepumpe|raw|7d|now|100"}

Gemäß currentmillis.com entspricht z.B. der erste Wert in der obigen Serie 1590235879494 --> Sat May 23 2020 14:11:19.

Da die DB ja auch ein String-Feld für jeden Datensatz mitführt, denke ich, dass es technisch nicht unmöglich ist, dort bei 'none' auch 'none' reinzuschreiben, und dies der sV entsprechend mitzuteilen und dort auszuwerten.

/tom

[Msinn]

Das dürfte dann etwas schwieriger werden - ich wüsste nicht, dass die sV mittlerweile unterbrochene Plots zeichnen kann; das Thema wurde in der Vergangenheit schon das eine oder andere Mal diskutiert.

Das geht schon auf Grund der Datenspeicherung nicht. Es werden nur Veränderte Werte und die Dauer eines Wertes geschrieben. Einen Wert "kein Wert" gibt es nicht.

[Tom Bombadil]

danke für den Gedankenanstoß - ich werde versuchen, ob ich das pluggit plugin entsprechend anpassen kann

Meiner Meinung nach müsstest Du dafür nicht mal an das Plugin ran, sondern nur an die betreffenden Items. Füge dort ein eval hinzu, das ungefähr so aussieht (ungetestet):

eval: value if [I]sh.pfad_zum_bypass_item()[/I] else [I]none[/I]

Das setzt natürlich voraus, dass für den bypass ein boolsches Item oder eins mit 0/1 für zu/auf existiert - sonst ggf. das eval-Statement entsprechend anpassen. Alternativ könnte man auch sowas wie

eval: value * not(sh.pfad_zum_bypass_item())

verwenden, wenn für den Bypass 0/1 für zu/auf vorliegen.

konkret geht es um 4 Temperaturen der KWL, bei denen 2 nicht gültig sind wenn der Bypass offen ist. diese möchte ich dann nicht loggen um sie auch nicht im Plot in der SmartVISU zu haben.

Das dürfte dann etwas schwieriger werden - ich wüsste nicht, dass die sV mittlerweile unterbrochene Plots zeichnen kann; das Thema wurde in der Vergangenheit schon das eine oder andere Mal diskutiert.

/tom

[jonsson]

danke für den Gedankenanstoß - ich werde versuchen, ob ich das pluggit plugin entsprechend anpassen kann

[Msinn]

Wenn sicher der Wert eines Items nicht ändert, wird er nicht geloggt. Du müsstest also nur verhindern, dass die ungültigen Werte dem entsprechenden Item zigewiesen werden.

[jonsson]

hallo zusammen,

ich habe eine Frage, kann ich Items in Abhängigkeit anderer Items in die DB schreiben?
konkret geht es um 4 Temperaturen der KWL, bei denen 2 nicht gültig sind wenn der Bypass offen ist. diese möchte ich dann nicht loggen um sie auch nicht im Plot in der SmartVISU zu haben.
Alternativ wäre die Idee Werte in Abhängigkeit vom bypass einfach nicht darzustellen, das sehe aber mit den Plots als noch viel schwieriger umsetzbar.

Danke!

[jzehnter]

- Falls MariaDB auf dem PI läuft, installierst Du am besten die selbe Version der MariaDB auf dem neuen Rechner. Anschließend stoppst Du MariaDB und kopierst die entsprechenden Datendateien in die neue MarisDB Installation.

Sobald sich kleinere Versionänderungen in der Server-Version ergeben, wäre der sicherer Weg über einen MySQL-Dump zu gehen.
Dump:
https://mariadb.com/kb/en/making-bac...ith-mysqldump/

Restore:
https://mariadb.com/kb/en/restoring-...om-dump-files/

[Msinn]

Das hängt davon ab wo und wie Du die MariaDB installiert hast:
- Falls MariaDB auf einem anderen Rechner läuft, brauchst Du nichts zu tun
- Falls MariaDB auf dem PI läuft, installierst Du am besten die selbe Version der MariaDB auf dem neuen Rechner. Anschließend stoppst Du MariaDB und kopierst die entsprechenden Datendateien in die neue MarisDB Installation.