[gelöst] History Adapter bleibt öfters stehen
-
Bei "Debounce" geht es darum das es Geräte gibt die bei einem Schaltvorgang nicht sauber von Zustand A nach B wechseln sondern wo es durchaus zu wachlern ON-OFF-ON kommen kann, meist in sehr kurzen zeitpunkten (z.B. bei tastern bei Kontaktfehlern o.ä.). Um hier das Logging dieser "falschen Zwischenwerte" zu verhindern kann man so eine Debounce-Zeit setzen. Es ist der Zeitraum in dem Statusänderungen ignoriert werden und nicht geloggt werden.
Also Beispiel:
Wert= 1000 = 1 Sekunde
jetzt kommt wert ON
jetzt+100ms kommt Wert OFF - ignoriert
jetzt+200ms kommt Wert ON - ignoriert
jetzt+1100ms (=1 sekunde+100ms) kommt Wert OFF -> wird geloggt
Besser verständlich?
-
ok danke
habe jetzt debounce auf 2000 gestellt.
Problem mit dem Restart bzw Stop des History Adapters bleibt aber bestehen. Das iobroker Log Verzeichnis belegt 16GB und geht "nur" bis in den September 2016 zurück. Ist das normal?
-
Log oder History-Data?
-
jetzt kommt wert ON
jetzt+100ms kommt Wert OFF - ignoriert
jetzt+200ms kommt Wert ON - ignoriert
jetzt+1100ms (=1 sekunde+100ms) kommt Wert OFF -> wird geloggt `
Ist dies wirklich das Verhalten des History Adapters? Meiner Meinung nach müsste der letzte Wert schlussendlich auf jeden Fall geloggt werden, das loggen sollte nur aufgeschoben werden und ggf. abgeändert.
-
Sagen wir es so: Laut code funktioniert debounce so für alle History-Adapter (SQL, InfluxDB und History).
Die Frage ist theoretisch Ansichtssache. Wenn man debounce so definiert das der erste neue Status immer das Ziel ist und man ausgleicht das es ggf. nen "Rückfall" gibt, dann ist das aktuelle Vorgehen korrekt.
Von Kontakten kenne ich Debounce so das man warten auf welchen Wert sich das ganze "stabilisiert", das wäre eher dein Ansatz.
Meinungen? Kann man denke ich gefahrlos umbauen
-
Log oder History-Data? `
Das Verzeichnis c:\iobroker\iobroker-data\history\ 16GB
Das Verzeichnis c:\ioBroker\log\ 1,9GB (wegen Debug, ansonsten nur 30-50MB pro Tag)
-
Das sprengt jetzt zwar den Ramen dieses Threads, aber:
Ich denke grundsätzlich sollte der gespeicherte Wert am Ende dem tatsächlichen entsprechen, wenn es tatsächlich so gelöst ist wie von dir beschrieben wäre es gut möglich, dass am Ende der falsche Wert gespeichert wird, da der letzte einfach verworfen wurde.
Beispiel:
Wert= 1000 = 1 Sekunde
jetzt kommt wert ON -> wird geloggt
jetzt+800ms kommt Wert OFF -> wird ignoriert
keine Änderung mehr -> falscher letzter Wert geloggt
Wäre dies aktuell der Fall? Dann würde ich eher so vorgehen:
Wert= 1000 = 1 Sekunde
jetzt kommt wert ON -> wird geloggt (es gab zuvor für mind. 1000ms keine Änderung)
jetzt+100ms kommt Wert OFF -> Wert wird nach 1000ms geloggt, falls keine weitere Änderung
jetzt+200ms kommt Wert ON -> OFF wird verworfen und Wert wird nach 1000ms geloggt, falls keine weitere Änderung
jetzt+900ms kommt Wert OFF -> ON wird verworfen und Wert wird nach 1000ms geloggt, falls keine weitere Änderung
jetzt+1900ms -> OFF wird geloggt.
So würde auf jeden Fall jede (kurze) Änderung geloggt und ebenfalls der korrekte letzte Wert. Das "Flimmern" würde jedoch nicht geloggt.
-
Ich glaube der Standard für "Anzahl RAM" sind 960 … also nicht sooo wild, weiterhin wird eh alle 30 Sekunden alles ins File geschrieben. Also das sollte nicht das Problem sein `
Kann man diese 30s-Intervalle konfigurieren? Und wenn ja, wo? -
So würde auf jeden Fall jede (kurze) Änderung geloggt und ebenfalls der korrekte letzte Wert. Das "Flimmern" würde jedoch nicht geloggt. `
Nach etwas drüber nachdenken sehe ich das genau so. Verzögerung beenden und neu starten
bei jeder Änderung im Zeitraum … Baue es überall ein. Gibt dann nen tester Thread
-
Change auf Github: Testergebnisse bitte posten!
-
mit dem neuen Github Release habe ich auch keine Probleme mehr.
Der Adapter ist jetzt seit 83915 Sekunden online, connected und ohne Probleme.
