Ankündigung

Einklappen
Keine Ankündigung bisher.

Neues Database Plugin

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

    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.
    Viele Grüße
    Martin

    There is no cloud. It's only someone else's computer.

    Kommentar


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

      Kommentar


        Zitat von jonsson Beitrag anzeigen
        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):
        Code:
        eval: value if sh.pfad_zum_bypass_item() else none
        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.

        Zitat von jonsson Beitrag anzeigen
        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

        Kommentar


          Zitat von Tom Bombadil Beitrag anzeigen
          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.
          Viele Grüße
          Martin

          There is no cloud. It's only someone else's computer.

          Kommentar


            Zitat von Msinn Beitrag anzeigen
            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):

            Code:
            [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

            Kommentar


              Ä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.
              Viele Grüße
              Martin

              There is no cloud. It's only someone else's computer.

              Kommentar


                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

                Kommentar


                  Wo soll das Problem denn auftreten? Der erweiterte Parser für series unterbindet negative durations ja explizit
                  Viele Grüße
                  Martin

                  There is no cloud. It's only someone else's computer.

                  Kommentar


                    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

                    Kommentar


                      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

                      Kommentar


                        Zitat von aschwith Beitrag anzeigen
                        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

                        Kommentar


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

                          Kommentar


                            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
                            Zuletzt geändert von aschwith; 26.06.2020, 14:46.

                            Kommentar


                              Code:
                              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.
                              Code:
                                      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..?

                              Kommentar


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

                                Code:
                                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 )

                                Kommentar

                                Lädt...
                                X