SQLite Plugin überarbeitet (in Release 1.1)

[Orion]

Hallo,

das Thema hatte ich auch (es gab dann kleine Sprünge in Plots) und auch die Themen mit Rückgabewert None siehe Beispiel unten:

Init SmartHome.py 1.1.0.man
2015-01-04 19:53:23 WARNING  zaehler.gas.volumenstrom Item zaehler.gas.volumenstrom: problem evaluating (sh.zaehler.gas.counter.db('max','5i') - sh.zaehler.gas.counter.db('min','5i')) * 12.0 / 100.0: unsupported operand type(s) for -: 'NoneType' and 'NoneType'
2015-01-04 22:00:00 WARNING  zaehler.wasser.verbrauch_stunde_zaehler-eval Item zaehler.wasser.verbrauch_stunde_zaehler: problem evaluating (sh.zaehler.wasser.counter.db('max', '1h')-sh.zaehler.wasser.counter.db('min', '1h'))/1000.0: unsupported operand type(s) for -: 'NoneType' and 'NoneType'
2015-01-05 00:00:02 WARNING  zaehler.strom.verbrauch_woche_zaehler-eval Item zaehler.strom.verbrauch_woche_zaehler: problem evaluating (sh.zaehler.strom.counter.db('max', '1w')-sh.zaehler.strom.counter.db('min', '1w'))/250.0: unsupported operand type(s) for -: 'float' and 'NoneType'
2015-01-05 00:00:02 WARNING  zaehler.wasser.verbrauch_woche_zaehler-eval Item zaehler.wasser.verbrauch_woche_zaehler: problem evaluating (sh.zaehler.wasser.counter.db('max', '1w')-sh.zaehler.wasser.counter.db('min', '1w'))/1000.0: unsupported operand type(s) for -: 'float' and 'NoneType'
2015-01-05 00:00:02 WARNING  zaehler.wasser.verbrauch_tag_zaehler-eval Item zaehler.wasser.verbrauch_tag_zaehler: problem evaluating (sh.zaehler.wasser.counter.db('max', '1d')-sh.zaehler.wasser.counter.db('min', '1d'))/1000.0: unsupported operand type(s) for -: 'float' and 'NoneType'
2015-01-05 00:00:02 WARNING  zaehler.gas.verbrauch_tag_zaehler-eval Item zaehler.gas.verbrauch_tag_zaehler: problem evaluating (sh.zaehler.gas.counter.db('max', '1d')-sh.zaehler.gas.counter.db('min', '1d'))/100.0: unsupported operand type(s) for -: 'float' and 'NoneType'
2015-01-05 00:00:06 WARNING  zaehler.strom.verbrauch_stunde_zaehler-eval Item zaehler.strom.verbrauch_stunde_zaehler: problem evaluating (sh.zaehler.strom.counter.db('max', '1h')-sh.zaehler.strom.counter.db('min', '1h'))/250.0: unsupported operand type(s) for -: 'float' and 'NoneType'
2015-01-05 00:00:07 WARNING  zaehler.strom.verbrauch_tag_zaehler-eval Item zaehler.strom.verbrauch_tag_zaehler: problem evaluating (sh.zaehler.strom.counter.db('max', '1d')-sh.zaehler.strom.counter.db('min', '1d'))/250.0: unsupported operand type(s) for -: 'float' and 'NoneType

sind jetzt komplett weg. Danke !

Michel

[MichaelBu]

Hallo,
Ich habe es gestern installiert. Seither ist Ruhe :-)
Vielen Dank nochmal.

Michael

[toggle]

Funktioniert die develop-Version vom sqlite-Plugin mit dem smarthome.py aus der Release-Version?

Denn ich habe es gerade versucht, aber keiner der Items mit "sqlite = yes" konnte angelegt werden:

Item thz.flowTempHC1: problem creating: () -- item.py:__init__:222

Exceptions oder weitere Meldungen gab es auch im Debug-Modus keine. Sie werden wohl irgendwo abgefangen, aber nicht gemeldet.

Die Datenbank wurde innerhalb von 10 Minuten ohne Fehler konvertiert, war anschließend aber kein bisschen kleiner als vorher (21MB).

PS: Ich wollte migrieren, weil ich mit der V2 jede Nacht einen Blackout in der DB von 2-3 Stunden habe (so etwa ab 3 Uhr nachts).

[MichaelBu]

Hallo,
Ich hatte den gleichen Fehler.
Tausche mal die Datei item.py in /usr/smarthome/lib auch gegen die im
development Zweig. Bei mir hats geholfen.

Michael

[JuMi2006]

Hallo Marcus,

von mir auch nochmal ein Frage zur Datenbankabfrage.
Nehmen wir an ich schreibe einen Stromwert in die Datenbank.

Wenn ich den ganzen Tag über "0" schreibe und um 16:00 die Waschmaschine anschalte die 1000W zieht dann sollte doch um 16:30Uhr folgendes raus kommen

item.db('avg','60i') = 500,00 W

Wenn ich jetzt eine Abfrage mache die seit Tagesbeginn läuft würde ich (16,5 Stunden * 60 Minuten = 1020 Minuten) das so abfragen:

item.db('avg','1020i') = 29,41 W

Das entspreche 29,41 = ((30 * 1000)/ 1020).

Nun zur eigentlichen Frage, gehe ich in meiner Annahme richtig ? Was würde passieren wenn keine Werte in die Datenbank geschrieben werden ?

Wenn ich alles nach W*min auflöse (Verbrauchsberechnung) dann sollte ich mit beiden Berechnungen den gleichen Wert (Rundungsfehler ausgenommen) erhalten:

500W * 60min = 30.000 Wmin
29,41W * 1020min = 30.000 Wmin


Gruß Mirko

[toggle]

[OT]
Mein Taschenrechner ist der Meinung, dass 16,5 * 60 = 990 ist.
[/OT]

[callidomus]

Hi Mirko,

Du gehts in Deiner Annahme richtig. (Bis auf die halbe Stunde

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

Ich denke das Plugin berechnet jetzt alles richtig.

Details findest Du hier: https://github.com/mknx/smarthome/bl...init__.py#L353

Bis bald

Marcus

[JuMi2006]

@Toggle:
Den Taschenrechner hätte ich vielleicht einmal mehr benutzen sollen .

@Marcus:
Vielen Dank, wenn der Aktor wieder tut kann ich das mal verifizieren. Der hat sich leider gerade verabschiedet so dass ich keine Tests machen kann.


Bis dahin erstmal Danke!

[toggle]

Hallo zusammen,

ich benutze die develop-Versionen von sqlite und item.py seit ca. einer Woche. Dabei sind mir zwei Punkte aufgefallen:

• Ich habe jede Nacht einen "Blackout" von ca. 2 Stunden (zwischen 3 und 5 Uhr) wie mit der alten sqlite-Version. D.h. in dieser Zeitspanne sind keine Daten vorhanden. Ließe es sich irgendwie vermeiden oder zumindest minimieren?
• Die ohne Fehler konvertierte Datenbank schrumpft jede Nacht um mehrere 100 kB. Von den ursprünglichen 27MB sind mittlerweile nur noch 20MB übrig. Was hat es zu bedeuten? Wie lange wird dieser Schrumpfprozess noch andauern?

Gruß
toggle

[callidomus]

Hallo,

in dieser Zeit wird die DB komprimiert. Die Werte gehen in dieser Zeit nicht "verloren", sie werden zu einem späteren Zeitpunkt in die DB geschrieben. Es geht dabei allerdings Detailinformationen verloren, da sie bereits komprimiert in die DB geschrieben werden.
Das kann man nicht so einfach verändern.

Ich arbeite aber daran die Pack-Zeit zu reduzieren.

Die Abnahme der Größe der DB bedeutet, das nicht in dem gleichen Maß neue Daten hinzukommen in der alte Werte komprimiert werden.

Bis bald

Marcus

[toggle]

Es geht dabei allerdings Detailinformationen verloren, da sie bereits komprimiert in die DB geschrieben werden.

Wie stark werden die Daten ausgedünnt, wenn sie komprimiert werden? Konstant bleibende Werte kann man mit Sicherheit gut komprimieren. Aber ich möchte keine Daten/Ereignisse verlieren, die sich öfter als alle 5 Minuten ändern.

[toggle]

Die Plots erscheinen mittlerweile ziemlich zerhackt, obwohl ich an den Plot-Parametern nichts geändert habe.
Plot.JPG
Die Datenselektion kommt mir irgendwie willkürlich vor, weil zwischen zwei Nachbarwerten mal 15 Minuten, mal 2 Stunden liegen (und nicht nur nach Mitternacht). Dabei ist sqlite-cycle auf 180 Sekunden gesetzt. Die Integrität der SD-Karte ist absolut im grünen Bereich.

[callidomus]

Hi,

es erfolgt maximal ein Eintrag pro Item über die ganze Komprimierungszeit.

Das Cycle besitze kein Relevanz mehr, da die Daten nicht mehr zyklisch in die DB geschrieben werden.

Deinen Graphen kann ich leider nicht deuten, da mir die Referenz und der Kontext fehlt.

Bis bald

Marcus

[toggle]

Hallo Marcus,

offensichtlich ist diese Art von Kompression nicht optimal für meine Daten. Es ist schon klar, dass man die Plots schlecht ohne der zugrunde liegenden Daten deuten/beurteilen kann. Zur Veranschaulichung:
Ende Dezember hatte ich noch die alte sqlite-Plugin-Version. Da hat ein Plot so ausgesehen:
THZ3.JPG
Mit der neuen Version sieht der Verlauf so aus:
Plot1.jpg
Man sieht, dass es plötzlich vertikale Sprünge in einer kontinuierlichen Steigung gibt. D.h. die DB gibt zwei Werte zurück, die zeitlich nebeneinander liegen, aber eine hohe Differenz haben, was definitiv nicht gemessen wurde. Andererseits gibt es Stellen, wo es tatsächlich Sprünge gibt (Zurücksetzen auf 0 um Mitternacht). Diese werden aber als ein Gefälle über 2-3 Stunden mit nur 2 Punkten dargestellt, obwohl der in die DB gespeicherte Wert bis zur Mitternacht konstant war. Jedenfalls sah der Plot um Mitternacht (live) deutlich anders aus als am nächsten Tag nach der Kompression.

Es sieht so aus, als ob die "neuen" vertikalen Sprünge durch eine Verschiebung eines Wertes nach hinten auf der Zeitskala zustande kommen. Die "Glättung" der Mitternachtssprünge könnte man anhand der folgenden Zahlenreihe mit einer Periode von 5 min erklären:

10-15-20-25-25-25-25-25-25-25-25-25-25-25-25-25-0-0-0-1-

Der Plot bekommt sie nach der Kompression in dieser Form:

10-15-20-25-                                   -0-     -1-

Für saubere Plots wäre aber folgende Umwandlung erforderlich:

10-15-20-25-                                [COLOR=Red]-25-[/COLOR]0-     -1-

Ich kann mich gerne am Wochenende um Mitternach hinsetzen und einen präziseren Vergleich aufzeichnen.

Gruß
toggle

[Orion]

Hallo,

ich verfolge das Thema mit den Sprüngen ebenfalls. Ich hatte ähnliche Beobachtungen.

@ Marcus: Du wolltest doch noch einmal für Bool'sche Items etwas überlegen. Denn deren Aufzeichnung mit der neuen Komprimierung ist nicht optimal. Wenn ich mit von toggle die Werte anschaue, dann wäre ein Wert (nach langer Zeit ohne Veränderung) kurz vor dem Sprung die Lösung - auch für Bool items.

Liege ich da richtig ?

Michel