Monatsrückblick Januar/Februar 2026 ist online!

[photographix]

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?

[apollon77]

Log oder History-Data?

[Pman]

@apollon77:

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.

[apollon77]

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

[photographix]

@apollon77:

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)

[Pman]

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.

[AlCalzone]

@apollon77:

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?

[apollon77]

@Pman:

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

[apollon77]

Change auf Github: Testergebnisse bitte posten!

http://forum.iobroker.net/posting.php?m … =36&t=5519

[photographix]

mit dem neuen Github Release habe ich auch keine Probleme mehr.

Der Adapter ist jetzt seit 83915 Sekunden online, connected und ohne Probleme.