Ankündigung

Einklappen
Keine Ankündigung bisher.

Logging von Werten - präzise Zeitpunkte, Aggregation und zeitliche Limitierung

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    [Featurewunsch] Logging von Werten - präzise Zeitpunkte, Aggregation und zeitliche Limitierung

    Hi!

    Mittlerweile ist sh.py ja wie ich meine extrem gereift und lässt in meinen Augen keine - bis auf einen - Wünsche offen.

    Nach wie vor werde ich - auch in Unkenntnis von SQL - nicht mit der sqlite-Datenbank warm.

    Dass die Aggregation für mich momentan nicht ganz zu durchschauen ist wäre zu verschmerzen und ich müsste mir das mal ansehen. Allerdings sehe ich nach wie vor zwei wesentliche Punkte, die nicht geklärt sind:

    - Bei Bool-Werten macht eine Mittelung nur sehr selten Sinn. Klar repräsentiert dass ein Tastverhältnis - aber wenn ich Fenster AUF/ZU habe ist sowas extrem unnütz. Statt dessen möchte ich da lieber den exakten Zeitpunkt haben, und nicht "am 25.10.2013 zwischen 00:00 und 23:59 war das Fenster mal auf weil der Wert 0.8454 ist".
    - Viele meiner Werte möchte ich wirklich nur 3 Tage oder so speichern. Eine Statistik über die geöffneten Fenster in Relation zur Raumtemperatur vor 3 Jahren brauche ich nicht. Klar tut es bei ausreichender Aggregation nicht weh - aber irgendwie vermisse ich auch da die Möglichkeit, eine "begrenzte Haltbarkeit" einzustellen.

    ein weiterer Punkt: Datenreihen die einmal drin sind, kriegt man nicht mehr (mit sh.py Bordmitteln) raus. Sei es durch Umbenennung des Items oder Entfall.

    Natürlich kann ich jetzt selektiv oder generell RRDs nehmen - aber mich würde interessieren ob man da nicht generell Bedarf gesehen wird.

    Vielleicht gibt es für Bools die Möglichkeit, item-spezifisch einzustellen "logge die exakten Werte und führe keine Aggregation durch, solange nicht mehr als "x Werte in Zeit y" anfallen. Für derartig deklarierte Items sollten die Series dann auch die exakten Werte und keine "Zeitscheiben" liefern.
    Weiteres Attribut: "schmeiße alle Werte älter x weg"

    Dann beim Start: evtl. mit einem warning oder infos alle "herrenlosen" Datenreihen aufzählen. Evtl. kann man die dann per <zusatztool.sh name> entfernen wenn man möchte!?

    Das ist nicht als "macht-mal" zu verstehen - ich code es auch gerne selber - allerdings sollte vorher dann klar sein, dass das so angenommen wird - weil das diff sicher zu groß ist um es dann bei jeder Änderung selber zu mergen.

    Weitere Ideen?

    Als Anhang mal ein Bild, wie Bool-Items aktuell aussehen. (Nein, max bessert nur die Optik - aber da die Zeitscheiben immer noch 15min umfassen macht es das kaum besser). Da Überschneiden sich Betriebszustände der Wärmepumpe dann etc.

    Grüße
    Robert
    Angehängte Dateien

    #2
    Hallo Robert,

    ich kann Deine Gedanken sehr gut nachvollziehen und sehe es ebenso.

    Vor dem 1.0 Release möchte ich aber nicht weiter darüber nachdenken.
    Ich schreibe es mal auf meine Todo Liste.

    bzgl. der Bool-Werte würde ich hier wahrscheinlich den Weg einer separaten Tabelle gehen.
    Also sqlite = bool oder io dann wird eine Tabelle eigene Tabelle verwendet, die regelmäßig 'alte' Einträge entfernt.

    Bis bald

    Marcus

    Kommentar


      #3
      Hallo Marcus,

      sehe ich das richtig, dass momentan JEDES Item was sqlite = true hat alle dump_cycles in die DB geschrieben wird? Egal ob sich was ändert oder nicht? Also eine Wärmepumpe die 3x am Tag anspringt (= 6 Einträge) bei cycle=300 am Tag 24*12 Einträge produziert?

      Grüße
      Robert

      Kommentar


        #4
        Hallo Robert,

        ja, das ist korrekt.
        Dieser Umstand hat eine gewaltige Performance-Verbesserung gebracht, da für die Anzeige der Plots alles in der DB erledigt werden kann. Vorher musste das durch Python aufbereitet werden. Der zusätzlich Speicher 'kostet' nichts und wird über das Packen relativ bald eingegrenzt.

        Bis bald

        Marcus

        Kommentar

        Lädt...
        X