Neues Database Plugin

[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]

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

[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

[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]

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]

Ä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.

[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]

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

[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

[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]

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

[Onkelandy]

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

[aschwith]

Onkelandy : Interessant. Bei welchen items taucht das bei Dir auf? Ich habe es bei mir bis jetzt ausschließlich bei Enocean items gesehen.

Wenn Du im Database WebIf nachschaust, solltest Du bei dem entsprechenden Item dort auch die negativen Durations sehen. Die machen natürlich dann Probleme, wenn man Einschaltdauern berechnet oder integriert. VG

[Onkelandy]

2020-06-24 23:45:32 WARNING plugins.database Negative duration: start: 1593034968604, end 1593034968603, prevChange: 2020-06-24 23:42:48.604280+02:00, lastChange: 2020-06-24 23:42:48.603951+02:00, item: og bewegung
2020-06-24 23:45:32 WARNING plugins.database Negative duration: start: 1593034968604, end 1593034968603, prevChange: 2020-06-24 23:42:48.604280+02:00, lastChange: 2020-06-24 23:42:48.603951+02:00, item: og bewegung
2020-06-24 23:45:32 WARNING plugins.database Negative duration: start: 1593034968604, end 1593034968603, prevChange: 2020-06-24 23:42:48.604280+02:00, lastChange: 2020-06-24 23:42:48.603951+02:00, item: og bewegung
2020-06-24 23:45:32 WARNING plugins.database Negative duration: start: 1593034968604, end 1593034968603, prevChange: 2020-06-24 23:42:48.604280+02:00, lastChange: 2020-06-24 23:42:48.603951+02:00, item: og bewegung

Das item ist ein normales Item, das von KNX Items getriggert wird.

        type: bool
        visu_acl: ro
        database: yes
        influxdb: yes
        crontab: init
        enforce_updates: True
        cycle: 60
        name: og bewegung
        eval: 1 if (sh.bewegung.og.kueche() + sh.bewegung.og.abgang() + sh.bewegung.og.podest()) >= 1 else 0
        eval_trigger:
          - bewegung.og.kueche
          - bewegung.og.abgang
          - bewegung.og.mensch
          - bewegung.og.podest

Möglicherweise vertragen sich hier crontab: init und database: yes nicht so ganz..?

[aschwith]

Deine Vermutung ist nicht schlecht. Bei mir tritt das Problem aber z.B. mit diesem Item auf:

power:
type: num
value: 0
enocean_rx_key: VALUE
database: init
enforce_updates: True
visu_acl: ro

Tritt also auch ohne contab auf. Ich habe eher das database init (und damit das verbundene Database Caching) im Verdacht. Kann das Problem vielleicht mit der Reihenfolge beim Start zusammenhängen? Also Beispiel:
1) SmarthomeNG wird gestartet.
2) Ein plugin (bei mir Enocean) wird gestartet und aktualisiert ein item. Der vorherige Wert wird im previous value abgespeichert.
3) Das Database plugin wird gestartet und stellt über den Database Caching mechanismus den previous Wert wieder her? Irgendwie muss dabei der Zeitstempel falsch berechnet werden. Wie ist mir noch nicht klar.

Es ist aber schonmal gut, dass wir sehen, dass es dort ein Problem gibt (was nicht nur bei mir auftritt )