NEWS
SQL.0 loggt Daten viel zu oft
-
@sneak-l8 Also in deinem Log sieht man das ein "skipped Wert" geloggt wird. Wenn das der wert ist den Du nicht willst dann kannst du das jetzt doch ausschalten ... liess doch mal oben ... ist dieses "zusätzliche Werte zur grafischen Darstellungsoptimierung" ... kannste jetzt ausschalten.
Zu Null vs 0 ... aahhhhhjjaaaaa ... also nur die Null solls nicht sein? ... puuhhhh
Am Ende kann man bei getHistory, wo man Daten abfragt, sagen das null ignoriert werden sollen ... Hilft Dir das?
-
@apollon77 Ah, ok, wenn der zusätzliche Wert bewusst gelogtgt wird, um die Darstellung zu optimieren (das war mir nicht klar), dann hat alles seine Ordnung.
Meinst Du mit "am Ende" die Option: "Schreibe NULL-Werte an Start-/Stop-Grenzen"? Kommen die NULL-Werte daher? Dann kann ich die Option natürlich auch deaktivieren.
-
@sneak-l8 sagte in SQL.0 loggt Daten viel zu oft:
@apollon77 Ah, ok, wenn der zusätzliche Wert bewusst gelogtgt wird, um die Darstellung zu optimieren (das war mir nicht klar), dann hat alles seine Ordnung.
naja wenn Du History 2.0 gerade testet lies dochmal meinen monolog am Anfang des Threads ... da ist das alles beschrieben
-
@apollon77 Ich hab's jetrzt nochmal gelesen (hatte ich davor auch schon). Bin mir nicht sicher, ob ich das mit dem "Wert erinnern" ganz verstehe: Es gibt Gründe, ein paar ausgelassene Werte zu schreiben, damit die Darstellung besser ist (ich vermute, um die Linie vom alten zum neuen Wert zeitlich erst dann ansteigen zulassen, wenn die Änderung auch stattfand).
Auch wenn ich mir die Texte durchlese. Ic hseeh derzeit keine Möglichkeit, nur auf die Null-Werte zu verzichten, aber "0" schreiben zulassen.
Am Ende kann man bei getHistory, wo man Daten abfragt, sagen das null ignoriert werden sollen ... Hilft Dir das?
Das meint, wenn ich programmseitig die Werte aus der History lese oder? Mir wäre es lieber, die Null-Werte würden gar nicht erst in die History geschrieben. Daher der Wunsch die Option nicht für Null- und 0-Werte sondern nur für Null-Werte anzubieten. Die 0-Werte kann ich ja auch durch > 0,0001 und < -0,00001 etc. ausfiltern, wenn ich möchte.
-
@sneak-l8 also ja deine Deutung warum zur Darstellungsoptionen mehr werte geschrieben werden ist korrekt. Die Null Werte sind aber was anderes. Da gibts die Einstellung extra ob null werte beim start/Ende des Adapters geschrieben werden. Schau mal in die instanz Einstellungen.
Die sind dafür da das man sehen kann das gar nichts geloggt wurde. Am Ende auch wieder für die grafische Darstellung weil das sonst ne laaaange Linie zwischen zuletzt geloggtem wert vorm stop und dem ersten nach dem Start ist - was ja auch falsch ist weil sonstwas und Wirklichkeit dazwischen passiert sein kann.
Durch die null werte kann man dann aber sehen das was war und grafische Darstellung geht da meist auf 0 runter.
Ich denke morgen wenn alles klappt gibts auch sql in ner 20.0 Alpha.
-
@sneak-l8 Ich befasse mich auch gerade mit den Werten, welche in die Influxdb geschrieben werden.
Mein TV, welcher am Shelly-Plug-S hängt schreibt alle 15 Sekunden einen Wert in. die DB
Mein iMac, ebenfalls an einem Shelly, schreibt die Werte sogar jede Sekunde in die DBDie Einstellungen im Adapter sind folgende:
Ich habe was gelesen, das man die Daten mit einem retention code nach einer bestimmten Zeit löschen kann. Allerdings frage ich mich wie man die Protokollierung dann über einen längeren Zeitraum (mindestens 1Jahr) durchführt. Außerdem ist bei mir ja alles in einer DB.
Wenn ich das richtig verstanden habe, könnte ich die Datenmenge begrenzen, indem ich bei Delta z.B. den Wert 15 eintrage.Obwohl ich eben bei dem Shelly vom iMac mal den Delta Wert 15 und auch mal 150 eingetragen habe, loggt er weiter im sekündlichen Abstand.
Als letztes würde mich noch interessieren mit welchem Befehl ich die Größe meiner Datenbank abfragen kann?
-
@damrak2022 jetzt mischst du aber einige Fragen rein die nicht zu sql gehören.
Was das „zu viel loggen“ angeht ist influxdb ggf vom gleichen Bug betroffen wie sql und History auch und wird demnächst gefixt. Kannst ja mal versuchen ob ein History 2.0.0 vom github (siehe Alpha thread) dabei gleichen settings das gleiche log verhalten zeigt. Würde erwarten nicht.
Für die influxdb fragen am besten neuen thread auf machen oder was passendes suchen
-
@apollon77 Danke für die Erläuterung zu "null". Hab gerade mal geschaut. Hab keine großen "null"-Werte mehr in der History gefunden. Vielleicht war das auch in einer älteren Version mal ein Problem. Das ist der Punkt für mich erledigt. Die null-Werte bei Start und Stop des Adapters finde ich sinnvoll.
-
So, dann für die "mutigen" ;))
--> https://forum.iobroker.net/topic/54662/test-adapter-sql-2-0-0
-
@apollon77
Super, Danke.
Eine Frage, weil sich ja nun doch einiges grundsätzlich verändert hat und ich gerne alle betroffenen Datenpunkte prüfen würde:
Gibt es eine einfache Möglichkeit, alle Datenpunkte zu ermitteln, für die ein Logging in die Datenbank mittels SQL Adapter aktiviert ist? -
@alexi sagte in SQL.0 loggt Daten viel zu oft:
Gibt es eine einfache Möglichkeit, alle Datenpunkte zu ermitteln, für die ein Logging in die Datenbank mittels SQL Adapter aktiviert ist?
rechts oben die Objekte filtern auf SQL
pulldown "Einstellungen" -
@homoran
Danke. Sorry, wenn ich mich dumm anstelle und doof frage:
Kann man die gefilterten Objekte auch ganz ausblenden? Denn sonst muss ich immer noch alle Knoten aufklappen, da ich die Nicht-SQL Objekte immer noch sehe, wenn auch gedimmt. -
@alexi der Vollständigkeit halber zur Antwort von Homoran: im Admin unter Objekte letzte Spalte rechts oben wählen. Dann warten bis er gefiltert und neu geladen hat. Kann ein bissl dauern.
Oder den Adapter starten und im log schreibt er zu jedem Objekt eine Zeile. ;-)) das erste ist bissl einfacher zu sehen.
Aber weitere sql 2.0 fragen bitte in sql 2.0 thread
-
@alexi sagte in SQL.0 loggt Daten viel zu oft:
Kann man die gefilterten Objekte auch ganz ausblenden
warten!
das dauert leider etwas -
@apollon77 sagte in SQL.0 loggt Daten viel zu oft:
Aber weitere sql 2.0 fragen bitte in sql 2.0 thread
ich habe keine 2.0 Frage gesehen.