InfluxDB 1.4.1/SQL 1.5.1/History 1.6.1 bitte testen
-
Zum Thema Datentypen: Ich hatte (mit der alten Version) den Fall, dass ein Datenpunkt zu Beginn schon falsch angelegt wurde, da der erste Wert nach anlegen der History-Einstellungen nicht dem korrekten Typ entsprach (String statt Bool). Dadurch war der Typ schon falsch in der Datenbank und ich musste ihn schlussendlich manuell aus der Datenbank entfernen. Ich glaube, dass auch jetzt mit deiner Version dieses Problem nicht behoben wäre, da du sagst, dass dieses Einstellung nur einmalig getätigt werden kann. Ich würde demnach vorschlagen, dass man einen ENTFERNEN Button hinzufügt, mit dem man den Datenpunkt wieder komplett aus der Datenbank raus bekommt, inkl. allen Werten. Natürlich müsste da noch ein Bestätigungsdialog auftauchen, damit man nicht aus Versehen löscht.
Es "fehlen" pot. Werte die dazwischen waren, aber das war vorher auch so. Es kann jetzt aber passieren, dass bei falschen Debounce-Einstellungen nichts mehr geloggt wird weil die Werte schneller kommen als die Debounce-Einstellung und damit nie stabil sind. Das muss ggf geprüft werden. `
Dass manche Werte nicht geloggt werden ist ja irgendwie auch Sinn der Sache. Wenn gar nicht mehr geloggt wird, weil die Werte dauerhaft zu schnell kommen, sollte man die Debounce-Zeit verringern, das ist dann eher ein Konfigurationsfehler finde ich. Der Standardwert sollte evtl. eher 0 (aus) oder ein geringer Wert wie 100ms sein, damit bei nicht-Beachtung dieser Einstellung weniger schief gehen kann.Eine Anmerkung/Frage hätte ich noch: wird der Wert eigentlich mit dem ursprünglichen Timestamp gespeichert oder mit dem Zeitpunkt wenn er denn endgültig gespeichert wird?
-
Zum Thema Datentypen: Ich hatte (mit der alten Version) den Fall, dass ein Datenpunkt zu Beginn schon falsch angelegt wurde, da der erste Wert nach anlegen der History-Einstellungen nicht dem korrekten Typ entsprach (String statt Bool). Dadurch war der Typ schon falsch in der Datenbank und ich musste ihn schlussendlich manuell aus der Datenbank entfernen. Ich glaube, dass auch jetzt mit deiner Version dieses Problem nicht behoben wäre, da du sagst, dass dieses Einstellung nur einmalig getätigt werden kann. Ich würde demnach vorschlagen, dass man einen ENTFERNEN Button hinzufügt, mit dem man den Datenpunkt wieder komplett aus der Datenbank raus bekommt, inkl. allen Werten. Natürlich müsste da noch ein Bestätigungsdialog auftauchen, damit man nicht aus Versehen löscht. `
Habe es als Feature-Request ins Trello gepackt.
@Pman:Es "fehlen" pot. Werte die dazwischen waren, aber das war vorher auch so. Es kann jetzt aber passieren, dass bei falschen Debounce-Einstellungen nichts mehr geloggt wird weil die Werte schneller kommen als die Debounce-Einstellung und damit nie stabil sind. Das muss ggf geprüft werden.
Dass manche Werte nicht geloggt werden ist ja irgendwie auch Sinn der Sache. Wenn gar nicht mehr geloggt wird, weil die Werte dauerhaft zu schnell kommen, sollte man die Debounce-Zeit verringern, das ist dann eher ein Konfigurationsfehler finde ich. Der Standardwert sollte evtl. eher 0 (aus) oder ein geringer Wert wie 100ms sein, damit bei nicht-Beachtung dieser Einstellung weniger schief gehen kann.
Der aktuelle Default-Wert für Debounce sind 10 Sekunden. Zu viel? 1s wäre vllt besser?Eine Anmerkung/Frage hätte ich noch: wird der Wert eigentlich mit dem ursprünglichen Timestamp gespeichert oder mit dem Zeitpunkt wenn er denn endgültig gespeichert wird? `
Es ist immer der eigentliche Timestamp. Nur das schreiben an sich ist verzögert. An den Daten wird da nichts geändert. -
Die Frage ist: Was ist ein guter default-Wert für Leute, die nichts an dem Wert verändern und erwarten, dass es einfach funktioniert, also loggt.
Zu kleiner Wert:
Bei Datenpunkten mit starkem "flimmern" wird der Historyadapter überlastet und es werden sehr schnell große Datenmengen geloggt.
Zu großer Wert:
Es werden Werte unerwartet nicht geloggt.
Ich würde jetzt aus dem Bauch heraus eher zu 1s tendieren.
-
Da stellt sich doch die Frage, ob "debouncen" die richtige Strategie fürs Loggen von Daten ist. Man will ja schließlich auch Daten speichern.
Sollte man dann nicht eher "throttlen"?
Bildhafter Vergleich: http://demo.nimius.net/debounce_throttle/
-
Naja, throtteln ist mal in sofern drin dass man nur geänderte Werte speichern kann und sowas … also da ist ja schon ein bestimmtes Featureset da.
So gesehen war die bisherige Definition eher "Throtteln" weil schnelle Änderungen hintereinander nicht geloggt wurden ... aber es wurde der erste Wert geloggt und der letzte war halt verlohren ... Am Ende ist da sdie Änderung - wir loggen jetzt eher den letzten (also aktuellsten) als den ersten
-
Die Definition von Throttle in obigem Link scheint mir eine Kombination aus dem zu sein, was du vorhast und was schon existiert:
-
Reduktion der Datenmenge durch nicht-loggen zu schneller Änderungen
-
Wenn eine Weile keine Änderungen kamen, den letzten empfangenen Wert speichern (selbst wenn dieser zuvor ignoriert wurde).
So wird einerseits eine Überlastung / zu große Datenmengen verhindert, andererseits aber garantiert, dass immer der "korrekte" Wert zuletzt in der DB steht.
Wäre das eine Überlegung wert?
-
-
Ich habe gestern die Doku zu den Adaptern gemacht, aber noch nicht freigegeben.
IMHO ist genau das bereits integriert.
Du kannst auf "nur Änderungen" einstellen und trotzdem alle x Sekunden den gleichen Wert loggen.
Gruß
Rainer
-
Du kannst auf "nur Änderungen" einstellen und trotzdem alle x Sekunden den gleichen Wert loggen. `
Ohja, natürlich. Daran hatte ich nicht mehr gedacht. -
So gesehen war die bisherige Definition eher "Throtteln" weil schnelle Änderungen hintereinander nicht geloggt wurden … aber es wurde der erste Wert geloggt und der letzte war halt verlohren ... Am Ende ist da sdie Änderung - wir loggen jetzt eher den letzten (also aktuellsten) als den ersten `
Diesbezüglich ist mir noch etwas aufgefallen, ein Beispiel:
Zustand ist OFF. Bei einer sehr kurzen Änderung zu ON und wieder OFF wird nur OFF geloggt und die Änderung geht in der History verloren -> In diesem Fall müsste dann korrekterweise die Einstellung zu "gleichen Werten" berücksichtigt werden.
Bessere Lösung?:
Der erste Wert wird direkt ohne Timer geloggt (also wenn aktuell kein Debounce-Timer läuft) und erst danach wird der Debounce-Mechanismus gestartet. So gehen auch kurze Änderungen nicht verloren und es gibt auch keine Änderungen OFF -> OFF.
-
Zustand ist OFF. Bei einer sehr kurzen Änderung zu ON und wieder OFF wird nur OFF geloggt und die Änderung geht in der History verloren `
stimmt! Aber liegt das wirklich an den History Einstellungen, oder bekommt ioBroker das vielleicht gar nicht mit? oder ist das die Entprellzeit mit Standard 10000msec.ich hatte nämlich auch schon solche Fälle.
Gruß
Rainer
-
Bessere Lösung?:
Der erste Wert wird direkt ohne Timer geloggt (also wenn aktuell kein Debounce-Timer läuft) und erst danach wird der Debounce-Mechanismus gestartet. So gehen auch kurze Änderungen nicht verloren und es gibt auch keine Änderungen OFF -> OFF. `
Klappt für Deinen Fall … bei OFF -> ON -> OFF kurz hintereinander ists wieder blöd weil er "OFF" + "OFF" loggen würde ...
-
oder ist das die Entprellzeit mit Standard 10000msec.
ich hatte nämlich auch schon solche Fälle. `
Also ja mit 10 Sekunden Debounce-Zeit ist das ein bissl blöd weil 10 sekunden sind echt lang.Neue Adapter-Installationen haben da auch nur noch 1s stehen …
-
Bessere Lösung?:
Der erste Wert wird direkt ohne Timer geloggt (also wenn aktuell kein Debounce-Timer läuft) und erst danach wird der Debounce-Mechanismus gestartet. So gehen auch kurze Änderungen nicht verloren und es gibt auch keine Änderungen OFF -> OFF. `
Klappt für Deinen Fall … bei OFF -> ON -> OFF kurz hintereinander ists wieder blöd weil er "OFF" + "OFF" loggen würde ... `
Dann müsste der Algo sein:
-
1. Event (kein Debounce-Timer läuft) -> direkt loggen
-
weitere Events werden gedebounced :lol:
-
letzter Event wird gespeichert, falls der Wert nicht gleich dem initalen 1. Wert ist.
Habe ich jetzt noch einen Fall übersehen?
-
-
oder ist das die Entprellzeit mit Standard 10000msec.
ich hatte nämlich auch schon solche Fälle. `
Also ja mit 10 Sekunden Debounce-Zeit ist das ein bissl blöd weil 10 sekunden sind echt lang.Neue Adapter-Installationen haben da auch nur noch 1s stehen … `
Wenn ich das ändern möchte muss ich jeden einzeln alten Datenpunkt anfassen?
-
Ich denke mir was anderes aus … ich denke die Änderung macht ggf doch zuviel kaputt
Oder was meint Ihr?Alles wieder zurück und "Entprellzeit" als Beschriftung ändern in "Neue Werte maximal Speichern nach x Sekunden" und ggf eine ENtprellzeit zusätzlich einbauen ?!
Meinungen vor
-
Wenn ich das ändern möchte muss ich jeden einzeln alten Datenpunkt anfassen? `
Nein,Du wählst als Filter oben rechts "mit" statt "alle", klickst oben das Zahnrad an u d änderst nur den Wert bei Entprellzeit.
Das wird dann in allen Datenpunkten übernommen.
Alles andere sollte unverändert bleiben.
Gruß
Rainer
-
Wenn ich das ändern möchte muss ich jeden einzeln alten Datenpunkt anfassen? `
Nein,Du wählst als Filter oben rechts "mit" statt "alle", klickst oben das Zahnrad an u d änderst nur den Wert bei Entprellzeit.
Das wird dann in allen Datenpunkten übernommen.
Alles andere sollte unverändert bleiben. `
Oh je…
es etwas Zeit vergangen, als ich dafür zuletzt die Filter benutzt habe... und schon muss man mich neu anlernen :oops:
Danke!!
-
Wat machmer nu … ?!
So lassen oder zurückändern?
-
Ich finde die aktuelle Implementierung super, bis auf die angesprochene Änderung. Für mich funktioniert es bei ganz verschiedenen Szenarien jetzt super. Natürlich muss man dabei immer im Hinterkopf haben, wie die Funktion arbeitet, aber das war auch vorher der Fall finde ich.
Gibt es denn konkret Beispiele für Fälle, wo es etwas kaputt macht?
-
Da bei ruhr70 das Massen-Edit scheinbar geklappt hat ist alles super
Ist auch schon gepublished … ich warte jetzt mal Feedback ab
