NEWS
InfluxDB 1.4.1/SQL 1.5.1/History 1.6.1 bitte testen
-
Ja, es war bei allen Datenpunkten so…
iobroker hatte ich schon mehrmals neu gestartet, Browsercache leeren etc. hat auch nix gebracht.
Was geholfen hat war ein Neustart des Rechners auf dem ich den Browser mit dem ioBroker-Admin offen hatte! Was sich da auch immer "verschluckt" hatte...
-
So, hab die neue Version seit gestern Abend laufen. Sieht soweit gut aus, keine Fehlermeldungen und kein exzessives Logging ;)
Allerdings finde ich nirgends die (neue) Möglichkeit den Datentyp der zu loggenden DP's einzustellen. Der Konfig-Dialog sieht aus wie immer… Und dabei habe ich das jetzt wirklich auf verschiedenen Rechnern mit verschiedenen Browsern getestet. Und "iobroker upload SQL" hab ich diesmal auch gemacht ;) . Aber warten wir mal ab, diese Browser-Caches sind sowieso nicht meine Freunde :roll: vielleicht überlegen die sich irgendwann doch noch, die neuen Einstellungen zu laden...
-
Es wurde auf Request in http://forum.iobroker.net/viewtopic.php?p=57214#p57214 noch die ARbeitsweise von "Debounce" geändert auf etwas was dem Namen gerecht wird :-)
Bisher: Es wurden so lange wie in Debounce-Time angegeben keine weiteren Änderungen geloggt. Bedeutet aber das potentiell nicht der aktuellste Wert auch als letztes geloggt wurde. Damit Statistiken pot. falsch.
Ab den neuen Versionen: Wenn während der Debounce-Zeit eine weitere Änderung der Daten kommt, dann wird der letzte Wert nicht geloggt und die Debounce-Zeit für den neuen Wert neu gestartet. Damit ist sichergestellt das ein "stabiler Wert" (der sich in der Debounce-Zeit nicht nochmals geändert hat) in jeder Fall geloggt wird und damit der aktuellste Wert da ist. 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.
Bitte Versionen vom Github 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
-
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?
-
Support us
522
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge