SQLite Plugin überarbeitet (in Release 1.1)

[JanT]

Hallo,

aus meiner Sicht muss man die Problemstellung in zwei aufteilen: die Speicherung der Daten (sqlite) und die Renderung bzw. Interpretation der Daten (highcharts). Das Verfahren die Marcus gewählt hat ist sehr effizient und mathematisch korrekt. Die konstante Phase bei einer stetiger Funktion wie von Dir beschrieben toggle sind in den Datenbank auch gespeichert in dem die Dauer der konstanten Phase eingetragen ist. Das "Problem" entsteht aufgrund der lehren Antwort von sqlite in den Zeitfenstern ohne Einträge. Obwohl max, min und average für das Zeitfenster bekannt sind, wird es nicht weitergegeben. Entsprechend kann highcharts für den Plot nur zwischen zwei Möglichkeiten wählen: den Wert seit der letzten Information konstant zu lassen (stair) oder eine lineare Interpolation auszuführen (line).

Ohne alle Nebenwirkungen beurteilen zu können würde ich mir folgende Lösung des Problems wünschen: wenn ich den Datenbank nach 100 Werte Frage, möchte ich auch 100 Werte zurückbekommen. Das interpretieren der Daten kann der Datenbank am besten. Dadurch würde Mirkos Plot trotz line als Darstellungsoption mit einen Flankenanstieg über 70min/100 Werte = 42 Sekunden dargestellt werden.

Viele Grüße,

Jan

[callidomus]

Hallo,

Aber ich kann deine Meinung nicht teilen, dass alles in Ordnung ist. JuMi hat es doch experimentell belegt, dass man nicht das zurück bekommt, was man abgespeichert hat. Ich habe das Gefühl, dass dieser Nachweis nicht gut genug ist. Denn ihm wurde auch nahe gelegt Stairs zu benutzen.

Nein, Mirko hat experimentell belegt, das er nicht das angezeigt bekommt was er angezeigt bekommen möchte bzw. erwartet. Soweit ich Ihn verstanden habe, würde in seinem Fall Stairs zu dem gewünschten Bild führen.

Stetige Funktionen können auch Phasen haben, in denen der Wert konstant bleibt. Um solche Phasen in der DB korrekt abzubilden, muss man einen Wert am Anfang einer solchen Phase und den gleichen Wert am Ende speichern. Wenn der gleiche Wert am Ende fehlt, wird eine Erhöhung der Visu-Auflösung nichts bringen.

Da gebe ich Dir Recht. Auf der Basis kann man auch miteinander reden.
Woher soll das Plugin wissen ob ein Zahlenreihe eine stetige Funktion entspricht und die Phasen mit den konstanten Werten erkennen?

Es gibt aber auch Zahlenreihen die nur bei Wertänderung aktualisiert werden, bei den würden "künstlich" eingefügte DB Einträge aber zu falschen Einträgen führen. Das will man ja aber auch nicht, und das bläht die DB unnötig auf.

Ich denke man muss hier differenzieren. Items die nur bei Wertänderung aktualisiert werden und Items die zyklisch aktualisiert werden.

Momentan werden alle Items, durch die Architektur bedingt, behandelt als ob sie nur bei Wertänderung aktualisiert werden. Für Logiken und ähnliches gibt es deswegen, das enforce_updates. So etwas ähnliches müsste es auch für die DB geben.

Ohne alle Nebenwirkungen beurteilen zu können würde ich mir folgende Lösung des Problems wünschen: wenn ich den Datenbank nach 100 Werte Frage, möchte ich auch 100 Werte zurückbekommen. Das interpretieren der Daten kann der Datenbank am besten. Dadurch würde Mirkos Plot trotz line als Darstellungsoption mit einen Flankenanstieg über 70min/100 Werte = 42 Sekunden dargestellt werden.

Danke Jan, für Deinen konstruktiven Beitrag.

Ich denke das würde nicht das eigentliche Problem lösen, da ja auch hier z.T. falsche Werte generiert werden würden. Weiterhin fällt mir momentan keine SQL-Query ein, mit der ich das bewerkstelligen könnte. Und ich möchte/muss aus Performancegründen die Ausgabe der DB 1:1 an die Visu durchreichen.

Alternativ könnte ich mir auch vorstellen als Plot eine Mischung aus Stairs und Splines zu implementieren, das dürfte aber für den Client (Smartphone) wahrscheinlich ziemlich schwer werden das schnell zu bauen/zeichnen.

Ich denke ich werde das Plugin noch einmal anpassen um eine Art 'enforce_updates' zu unterstützen. Ich habe es auf meine Backlog-Wand gehängt.

Bis bald

Marcus

[toggle]

Ich denke ich werde das Plugin noch einmal anpassen um eine Art 'enforce_updates' zu unterstützen. Ich habe es auf meine Backlog-Wand gehängt.

Das wäre gut. Allerdings würde man die Filterung in allen betroffenen Plugins machen müssen.

Alternativ könnte man in sqlite eine Filterfunktion für Wertänderungen einbauen:
Man prüfe beim Speichern vom Wert n, die Werte n-1 und n-2.
Ist x[n] == x[n-1] == x[n-2], dann x[n-1] löschen.

Viele Grüße
toggle

[JanT]

Hallo,

Ich denke das würde nicht das eigentliche Problem lösen, da ja auch hier z.T. falsche Werte generiert werden würden.

Falsch ist interpretationssache. Wenn bei ein leeres Zeitfenster der nächsten Wert zurückgegeben wird (Zeitfenster innerhalb dessen duration), begrenzt min und max auf jedem Fall den Verlauf. avg wäre ungenau - ist sie bisher aber auch da nur vom Zeitfenster umschlossene Einträge berücksichtigt werden und nicht wie für die Einselwertabfrage _single eine Interpolation durchgeführt wird.

Weiterhin fällt mir momentan keine SQL-Query ein, mit der ich das bewerkstelligen könnte. Und ich möchte/muss aus Performancegründen die Ausgabe der DB 1:1 an die Visu durchreichen.

Ja, verstehe ich. Ich habe gerade mir die Quellen angeguckt und gesehen, dass Du ja für die _series Anfrage mit eine einfache SELECT ohne Schleifen oder Berechnungen klarkommst.

Ich denke ich werde das Plugin noch einmal anpassen um eine Art 'enforce_updates' zu unterstützen. Ich habe es auf meine Backlog-Wand gehängt.

enforce_updates habe ich nicht gewagt vorzuschlagen, da es nur "Mittel zum Zweck" ist für den Datenbank und keine Zusatzinformationen enthält. Für Items die zyklisch aktualisiert werden ist das eine mögliche Lösung. Der Flankenanstieg wäre dann gleich die Zykluszeit. In ein anderen Fall berechne ich einmalig am Mitternacht die Regenvorhersage für die nächsten 24 Stunden und plotte das als Histogramm. Wenn die neue Vorhersage die letzte gleicht, wird nichts eingetragen in den Datenbank und entsprechend fehlt in den Plot der Balken für den Tag. Mit enforce_updates wäre das Problem auch gelöst!

Vielen Dank, ich freue mich auf den update!

Jan

[Onkelandy]

Wäre jemand so lieb zu posten, wie ich mittels sqlite Plugin den letzten (vorherigen) Wert eines Items abfragen kann..? Ich hatte hierzu zwar eine Lösung in einem anderen Thread gefunden, das funktioniert so aber definitiv nicht mehr.

Meine Versuche, mittels SELECT _avg from num WHERE _item = '{0}' ORDER BY _start DESC LIMIT 1 Eintrag im sqlite Plugin etwas zu bewirken, sind leider kläglich gescheitert. Jetzt heißt es beim Abruf immer

Item leinwand.zuvor: problem evaluating sh.leinwand.db('last','30d'): 'str' object is not callable

.
Bin offenbar zu blöd für diese kleine Adaption und wäre um jede Hilfe froh. Danke!

[callidomus]

Hallo,

wieso nicht einfach sh.leinwand.prev_value()?

Beim Start von Sh.py kommt evtl. ein falscher Wert an. Das müsste aber über 'cache = True' bei leinwand.zuvor umgangen werden können.

Bis bald

Marcus

[Onkelandy]

Hm, das ist eine gute Frage... ich hatte mir eingebildet, es damit schon probiert zu haben, aber in dem Fall wohl irgendwie falsch Funktioniert einwandfrei, vielen lieben Dank - perfekt!!!!

[Onkelandy]

Ein Problem habe ich dennoch: der Wert für prev_value wird beim Starten irgendwie nicht richtig gelesen.. Habe schon mit crontab = init, value = blabla, etc. probiert, aber beim Neustart klappt das irgendwie nicht wie es soll..

['leinwand']
    type = num
    knx_dpt = 5
    visu_acl = rw
    cache = True
    sqlite = init
    enforce_updates  = yes
    [['zuvor']]
    type = num
    knx_dpt = 5
    visu_acl = r
    cache = True
    enforce_updates  = yes
    eval = sh.leinwand.prev_value()
    eval_trigger = leinwand
    # crontab = init versucht, bringt nix
    # value = sh.leinwand.prev_value() bringt auch nix.

Irgend ne Idee, was ich falsch mache?
Vielen Dank!

[mumpf]

Hi,

ich würde vermuten, dass das enforce_uptates bei "leinwand" das Problem ist.
Ohne enforce_updates werden bei init beide Werte aus dem cache initialisiert und "zuvor" wird erst nach einem Wechsel von leinwand getriggert, wobei dann prev_value ja definiert ist.
Mit enforce_updates zwingst Du sh.py sozusagen schon beim init auch "zuvor" zu triggern, beim Init ist aber leinwand.prev_value nicht definiert. Ob Du ein enforce_updates brauchst, kann ich natürlich nicht beurteilen.

Gruß, Waldemar

[Onkelandy]

Vielen Dank für deinen netten Hinweis! Leider hat es aber das Problem nicht gelöst. Ich habe nun bei leinwand und bei zuvor das enforce_updates raus genommen; aber auch schon nur bei einem der beiden. Leider kein Erfolg.

De facto passiert Folgendes: Ich schalte Leinwand auf 1,78 aus 0 heraus. Als "zuvor" wird die 0 angezeigt. Passt, Nun fahr ich auf 0 hoch und das "zuvor" wird auf 1,78 gesetzt. Alles perfekt. Nur eben, sobald ich Smarthome.py neu starte, ist "zuvor" IMMER 0, auch wenn es eigtl. noch 1,78 sein sollte..

[mumpf]

Hi,

eine Idee hätt ich noch (allerdings ohne das jemals ausprobiert zu haben):
Ich glaube, dass es an dem

eval = sh.leinwand.prev_value()

liegt, das beim Init durchlaufen wird - da gibt es eben noch kein prev_value(). Versuch doch mal folgendes:

eval = sh.leinwand.zuvor() if trigger['by'] == "Init" else sh.leinwand.prev_value()

Ich weiß aber nicht, ob man trigger['by'] im eval abfragen kann.

Gruß, Waldemar

[Onkelandy]

Vielen Dank für den Tipp.. leider gibt es das trigger tatsächlich nicht. Habe es jetzt aber so geschafft.. mal sehen, ob das auch dauerhaft funzt Gerade wenn die init Reihenfolge anders wäre, gings wohl nicht. Erste Tests sahen soweit aber schon mal gut aus.

    eval = sh.leinwand.zuvor() if sh.leinwand.changed_by() == "SQLite:None" else sh.leinwand.prev_value()

[PaddyX]

Hallo zusammen,

ich hab smarthome.py schon seit 15 Monaten auf einem Raspberry Typ B mit ROT-Erweiterung am laufen und einer größere Datenbasis in der Datenbank (etwa 1,5 Millionen Einträge). Glücklicherweise habe ich bisher keinerlei Problem mit der SD-Karte bekommen. Mich hat dieser Thread interessiert und ich habe meine Stable/Master Version mit der neueren Sqlite-Plugin Version von Develop erweitert.

Erstmal großes Kompliment an den Entwickler, die GUI und die Plots sind jetzt deutlich schneller.

Leider habe ich aber jetzt ein Problem mit der nächtlichen Sqlite-Maintenance. Heute wie gestern war diese auch um 17:00 Uhr noch nicht fertig gewesen. Einträge in die Datenbank konnten heute so gut wie gar nicht reingeschrieben werden. Der Raspberry voll ausgelastet (insbesondere durch den mmcqd/0 Prozess). Habe daher smarthome.py neu starten müssen.

Um der Datenbank etwas mehr Performance zu geben, habe ich ein tmpfs Filesystem angelegt (liegt lediglich flüchtlig im Arbeitsspeicher) und dort die smarthome.db reingelegt. Den Maintenance habe ich dann manuell gestartet. Dieser läuft aber selbst jetzt schon wieder über 2h und ist die letzte Periode am abarbeiten.

Welche Möglichkeiten habe ich noch. Wie kann man das beschleunigen?

Danke für eure Antworten.

Gruß
Patrick

[PaddyX]

So ich bin etwas weiter gekommen. Nach 3h Stunden Lauf mit der Datenbank im RAM (smarthome.db) war das SQL-Packing durch. Interessanterweise hat die SD-Karte immer noch teilweise gebremst, da Linux jeden Zugriff auf das Verzeichnis ./var/db/ scheinbar nochmal im Filesystem abspeichert (Accesstime). Ein

mount -o remount,nodiratime /

hat das deutlich verbessert.

Schlussendlich hab ich nach dem Packing nur noch 800.000 Einträge gehabt. Ca. 250.000 davon habe ich nochmal manuell gelöscht, weil ich darauf verzichten kann.

Der letzte nächtliche Lauf dauert jetzt noch ca. 80 Minuten ist also wieder im Rahmen. Vielleicht hilft mein Beitrag ja jemanden, der auch viele Daten hat und auf die neue SQLite-Version umsteigt.

Gruß
Patrick

[PaddyX]

Hallo Marcus,

[...]
Es wird allerdings nur ein Wert in die DB geschrieben wenn er sich ändert.
Dieser Wert ist dann gültig bis ein neuer kommt.
[...]

Das kann ich bei allen Werte jetzt beobachten, außer bei den Werten der 1wire Sensoren (Plugine onewire).

Hier sehe ich trotzdem zyklisch gleichartige Einträge in der DB. Hier ein Beispiel:

select datetime((_start/1000),'unixepoch','+002 hours') as tag, _item, _min, _dur, _max from num where _item like 'sensorik.kg.hausgarage.temperatur' and tag like '2015-10-03%' order by tag;
2015-10-03 09:32:34|sensorik.kg.hausgarage.temperatur|17.81|1 48432|17.8125
2015-10-03 09:35:02|sensorik.kg.hausgarage.temperatur|17.81|1 49465|17.8125
2015-10-03 09:37:32|sensorik.kg.hausgarage.temperatur|17.81|1 50413|17.8125
2015-10-03 09:40:02|sensorik.kg.hausgarage.temperatur|17.81|1 51641|17.8125
2015-10-03 09:42:34|sensorik.kg.hausgarage.temperatur|17.81|1 50153|17.8125
2015-10-03 09:45:04|sensorik.kg.hausgarage.temperatur|17.81|1 49399|17.8125
2015-10-03 09:47:33|sensorik.kg.hausgarage.temperatur|17.81|1 49481|17.8125
2015-10-03 09:50:03|sensorik.kg.hausgarage.temperatur|17.81|1 50601|17.8125
2015-10-03 09:52:34|sensorik.kg.hausgarage.temperatur|17.81|1 51735|17.8125

Das Plugin habe ich auch aus dem Develop-Zweig aktualisiert. Hat aber am Verhalten nichts geändert.

Gruß
Patrick