Entprellzeit bei history Adapter
-
Hm,
mal einen höheren Wert probiert?
1000ms = 1 Sekunde… je nach Qualität des Klingeltasters...
-
Nur so ne' Idee…
wie wird der Klingeltaster versorgt? Wechselspannung?
hatte ich auch mal vor Jahren, hab' mir mit Diode und Elko zum "glätten" geholfen, funktioniert jetzt stabil...
-
Ich habe da eine Vermutung. Wenn der Adapter einen Wert nicht loggt weil noch nicht stabil, wird dennoch der letzte Wert gemerkt und bei der nächsten "echten" Änderung mit geschrieben.
Um es das ist müsste man jetzt mit Debug Log schauen. Also wenn es Dich interessiert dann Instanz mal auf Debug schalten und dann eine Änderung machen 8also Klingeln) … dann das Log von kurz davor und kurz danach mal schicken.
-
Hm,
mal einen höheren Wert probiert?
1000ms = 1 Sekunde… je nach Qualität des Klingeltasters... `
s. meinen Beitrag
Nur so ne' Idee…
wie wird der Klingeltaster versorgt? Wechselspannung?
hatte ich auch mal vor Jahren, hab' mir mit Diode und Elko zum "glätten" geholfen, funktioniert jetzt stabil... `
Klingeltaster schaltet potentialfrei
Ich habe da eine Vermutung. Wenn der Adapter einen Wert nicht loggt weil noch nicht stabil, wird dennoch der letzte Wert gemerkt und bei der nächsten "echten" Änderung mit geschrieben.
Um es das ist müsste man jetzt mit Debug Log schauen. Also wenn es Dich interessiert dann Instanz mal auf Debug schalten und dann eine Änderung machen 8also Klingeln) … dann das Log von kurz davor und kurz danach mal schicken. `
Ich habe mal einen log angehangen, geschrieben wurde true (also Taster los) wieder doppelt mit gleichem timestamp
history.0 2018-05-16 20:00:08.112 debug value not changed rpi2.0.gpio.16.state, last-value=true, new-value=true, ts=1526493608096 history.0 2018-05-16 20:00:08.111 debug value not changed rpi2.0.gpio.16.state, last-value=true, new-value=true, ts=1526493608094 history.0 2018-05-16 20:00:08.111 debug value not changed rpi2.0.gpio.16.state, last-value=true, new-value=true, ts=1526493608092 history.0 2018-05-16 20:00:08.109 debug value not changed rpi2.0.gpio.16.state, last-value=true, new-value=true, ts=1526493608090 history.0 2018-05-16 20:00:08.088 debug value not changed rpi2.0.gpio.16.state, last-value=true, new-value=true, ts=1526493608083 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 history.0 2018-05-16 20:00:08.001 debug Min-Delta reached javascript.0.Klingel timeout, last-value=0, new-value=1, ts=1526493607995 history.0 2018-05-16 20:00:07.944 debug value not changed javascript.1.Klingel aktiv, last-value=true, new-value=true, ts=1526493607928 history.0 2018-05-16 20:00:07.942 debug value not changed javascript.1.Klingel aktiv, last-value=true, new-value=true, ts=1526493607926 history.0 2018-05-16 20:00:07.926 debug Min-Delta ignored because no number javascript.1.Klingel aktiv, last-value=false, new-value=true, ts=1526493607921 history.0 2018-05-16 20:00:07.878 debug value not changed rpi2.0.gpio.16.state, last-value=false, new-value=false, ts=1526493607851 history.0 2018-05-16 20:00:07.878 debug value not changed rpi2.0.gpio.16.state, last-value=false, new-value=false, ts=1526493607849 history.0 2018-05-16 20:00:07.877 debug value not changed rpi2.0.gpio.16.state, last-value=false, new-value=false, ts=1526493607846 history.0 2018-05-16 20:00:07.877 debug value not changed rpi2.0.gpio.16.state, last-value=false, new-value=false, ts=1526493607844 history.0 2018-05-16 20:00:07.877 debug value not changed rpi2.0.gpio.16.state, last-value=false, new-value=false, ts=1526493607842 history.0 2018-05-16 20:00:07.876 debug value not changed rpi2.0.gpio.16.state, last-value=false, new-value=false, ts=1526493607839 history.0 2018-05-16 20:00:07.875 debug value not changed rpi2.0.gpio.16.state, last-value=false, new-value=false, ts=1526493607837 history.0 2018-05-16 20:00:07.832 debug value not changed rpi2.0.gpio.16.state, last-value=false, new-value=false, ts=1526493607827 history.0 2018-05-16 20:00:07.817 debug Min-Delta ignored because no number rpi2.0.gpio.16.state, last-value=true, new-value=false, ts=1526493607812
Sollte "true" bei ts=1526493607921 dann nicht ignoriert werden?
-
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
-
Genau diesen Wert (1000ms) habe ich doch beschrieben!
-
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
-
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!
-
Hast schon recht, der sollte keine 3 Sekunden prellen.
Sollte auch nur ein Versuch sein um zu sehen ob es etwas ändert.
-
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 -
> 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!
-
Danke für die Verifizierung!
Ja es tritt nur auf wenn im Rahmen der Entprellzeit andere Werte reinkommen.
Muss ich irgendwie umbauen …
-
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?
-
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 :?
-
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.
