Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[wendy2702]

@church:

@wendy2702:

Hm,

mal einen höheren Wert probiert?

1000ms = 1 Sekunde… je nach Qualität des Klingeltasters... `

s. meinen Beitrag `

Verstehe ich nicht

Gesendet von iPhone mit Tapatalk Pro

[church]

Genau diesen Wert (1000ms) habe ich doch beschrieben!

[wendy2702]

Ja, und ich meine du sollst den mal erhöhen auf z.b. 3000

Oder hast du das schon getestet und wir reden aneinander vorbei <emoji seq="1f92d">🤭</emoji>

Gesendet von iPhone mit Tapatalk Pro

[church]

O.K., dann habe ich das missverstanden :| Ich dachte, Dein Vorschlag wäre auf 1000ms zu erhöhen.

Aber im Ernst: 3s prellen doch keine Taster, sieht man ja auch an den Werten in meinem log, die liegen max. im 100ms Bereich!

Wäre aber trotzdem schön wenn es eine Lösung dafür gäbe!

[wendy2702]

Hast schon recht, der sollte keine 3 Sekunden prellen.

Sollte auch nur ein Versuch sein um zu sehen ob es etwas ändert.

[apollon77]

Hm … im Log oben bei History sieht man leider nicht wann genau ein Wert geloggt wird :-(

Also ich vermute das es ist wie oben geschrieben:

In deinem Fall "kombinieren sich" die Dinge von "Nur Änderungen Loggen" und Debounce.

Debounce sorgt dafür das der Wert grundsätzlich "verzögert" geschrieben wird erst wenn seit mehr als 1s kein neuer Wert mehr rein kam.

"Nur Änderungen "loggen schiesst da aber jetzt im Zweifel quer bzw sorgt dafür das auch wenn sich werte nicht ändern immer der letzte gemerkt wird und sobald sich der Wert dann ändert der letzte auch geschrieben wird damit die Grafische Darstellung am Ende noch korrekt ist. Die soll nämlich trotzdem anzeigen wie lange der Wert unverändert geblieben ist.

Jetzt muss man mal überlegen ob das so sinn macht ... Kann ich mich ab Anfang Juni gern mal reindenken :-) Vorher bitte so akzeptieren

[church]

> Hm … im Log oben bei History sieht man leider nicht wann genau ein Wert geloggt wird :-(

Steht das nicht hier?

history.0	2018-05-16 20:00:08.079	debug	Min-Delta ignored because no number rpi2.0.gpio.16.state, last-value=false, new-value=true, ts=1526493608074

` > In deinem Fall "kombinieren sich" die Dinge von "Nur Änderungen Loggen" und Debounce.

Debounce sorgt dafür das der Wert grundsätzlich "verzögert" geschrieben wird erst wenn seit mehr als 1s kein neuer Wert mehr rein kam.

"Nur Änderungen "loggen schiesst da aber jetzt im Zweifel quer bzw sorgt dafür das auch wenn sich werte nicht ändern immer der letzte gemerkt wird und sobald sich der Wert dann ändert der letzte auch geschrieben wird damit die Grafische Darstellung am Ende noch korrekt ist. Die soll nämlich trotzdem anzeigen wie lange der Wert unverändert geblieben ist. `

Genau das war´s! "Entprellzeit" und "nur Änderungen loggen" kommen sich in die Quere! Wenn ich "nur Änderungen loggen" ausschalte, werden die Werte nicht mehr doppelt aufgezeichnet, ausser wenn der gleiche Wert NACH Ablauf der Entprellzeit gesendet wird (was ja auch gewollt ist).

"Nur Änderungen loggen" war bei mir Default und ist bei der Aufzeichnung des Klingeltasters eh unnötig!

Per Default habe ich bei fast allen Datenpunkten beides aktiviert, aber bisher ist mir ähnliches nicht aufgefallen! Ich denke das tritt nur auf, wenn ein Datenpunkt wirklich auch prellt (also e-mechanische Taster). Ist das richtig?

Danke nochmal!

[apollon77]

Danke für die Verifizierung!

Ja es tritt nur auf wenn im Rahmen der Entprellzeit andere Werte reinkommen.

Muss ich irgendwie umbauen …

[church]

Super, danke!

Was mir bei der Gelegenheit noch aufgefallen ist:

Wenn z.B. ein Homematic Gerät über Javascript geschaltet wird, werden in History zwei gleiche Einträge erzeugt. Einmal mit Quelle Javascript und kurz danach nochmal vom hm-prc Adapter! Ist das so richtig?

[church]

Klappt jetzt:

Lag wohl daran, dass der Wert aus Javascript nicht bestätigt war (über "steuern" gesendet). Wenn ich über "aktualisieren" sende ist der Wert direkt aus Java bestätigt und wird nicht mehr von hm-rpc gespeichert!

Ich muss mich nochmal genau mit dem Unterschied zwischen steuern und aktualisieren vertraut machen :?

[paul53]

@church:

Wenn ich über "aktualisieren" sende ist der Wert direkt aus Java bestätigt und wird nicht mehr von hm-rpc gespeichert! `
…und auch nicht mehr an die (virtuelle) CCU gesendet :!:
@church:

Wenn z.B. ein Homematic Gerät über Javascript geschaltet wird, werden in History zwei gleiche Einträge erzeugt. Einmal mit Quelle Javascript und kurz danach nochmal vom hm-prc Adapter! Ist das so richtig? `
Ja: Erst wird der Wert mit ack = false (Quelle: javascript) auf den Datenpunkt geschrieben, dann an die CCU gesendet, von dieser bestätigt und dann ack = true gesetzt (Quelle: hm-rpc).

https://forum.iobroker.net/viewtopic.php?f=22&t=14300#p150738.