InfluxDB 1.4.1/SQL 1.5.1/History 1.6.1 bitte testen
-
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
