[gelöst] HMInfo - Keymatic liefert kurzzeitig uncertain beim auf- und zusperren

[new_rasp]

1. Wenn ich im Webinterface unter HMInfo rein schaue dann steht bei

Internals
ERR_names - (Name der Keymatic)

Was will mir HMInfo damit sagen?

2. Ich hatte auch einen uncertain von der Keymatic. Dies sehe ich jetzt bei den

Readings
ERR_uncertain - no:1;

Kann ich dies irgendwie wieder löschen?

[martinp876]

Hminfo checkt die readings der entities.
Wenn der zustand im device beseitigt ist verschwindet die meldung
Du kannst auch einstellen, was ein error ist. Schau die attribute in hminfo an.
Entscheiden kannst du selbst, was ein fehler ist und was eine warnung

[new_rasp]

Der Zustand (uncertain) wird aber bei der Keymatic nicht mehr angezeigt. Aktuell wird der Status (unlocked) angezeigt. Im Fehlerfall wurde (uncertain) zusätzlich zum aktuellen Zustand angezeigt. Somit sollte der Zustand beseitigt worden sein!? (Ich habe auch keine Ahnung wie dieser Zustand hervorgerufen wurde)

Kann ich das auch per Hand löschen?
Ich möchte dies auch als Attribut für einen Error haben. Nur liegt dieser ja nicht mehr vor und sollte ja gelöscht werden...

[new_rasp]

Kurzer Nachtrag. Hab jetzt im Webinterface den Zustand beobachtet. Beim auf- und zusperren wird kurzzeitig in Klammer (uncertain) angezeigt. Ist der Vorgang beendet dann verschwindet das wieder. Ist das normal?

[martinp876]

Hminfo reagiert nicht sofort auf aenderungen... wegen der performance. Es wird regelmaessig gepollt, einstellbar.
Du kannst einen update in hminfo jederzeit starten, dass du den regelmaessigen update eingeschaltet hast setze ich voraus. Falls nicht wird ein wert der readings beim booten gelesen und ausgewertet. Ziemlich sinnlos.

Das uncertain wird von der keymatic gesendet und ist sicher ein transienter zustand. Aus meiner sicht nur kritisch, wenn er nicht verschwindet. Da hminfo nur alle paar minuten pollt wird er eher nicht gesehen und gemeldet
Siehe attr autoupdate und set update

[Mitch]

Das mit uncertain ist ganz normal und kommt bei jedem öffnen und schliessen, wären das Keymatic den Zylinder bewegt und verschwindet dann wieder.
Uncertain heißt nur, dass das Keymatic den Status nicht 100% sicher angeben kann.

Wenn man z.B: mit dem Schlüssel zu oder aufsperrt, steht uncertain dauerhaft im state.

[new_rasp]

Danke für die Antworten.

@martinp876:
Also autoupdate hab ich auf fünf Minuten gesetzt um den aktuellen Status der Batterien zu überprüfen. Kritisch finde ich dies auch nicht. Nur ein wenig unschön.

@Mitch:
Das hab ich nicht gewusst das es normal ist. Danke für den Hinweis.

Gibt es hier einen Trick (außer den Zustand zu den Warnings hinzuzufügen - und bei Error zu entfernen) um dies bei den Zylinderbewegungen zu vermeiden?

Ich ändere mal den Titel da es ja hier explizit um diesen Punkt geht

[martinp876]

Mir ist das problem nicht klar.
Das device meldet transient uncertain, was in sich korrekt ist. Dies sollte nicht stehen bleiben.
Hminfo prueft alle 5 min. Moeglich, dass uncertain genau hier auftritt, dann wird es erkannt. Sollte dann beim naechsten mal weg sein.
Wenn uncertain nicht in hminfo detektiert werden soll, schalte es ueber die attribute ab.
Uncertain vom device nicht zu melden waere fahrlaessig. Es ist moeglich, dass ein sicherer zustand nicht erreicht wird..... dann siehst du nichts mehr.
Kritisch ist, wenn uncertain nicht verschwindet, nach ein paar sec. das muesste man auswerten.

[new_rasp]

Das war jetzt vielleicht etwas unverständlich. Problem ist es ja nur wie von dir geschildert wenn genau im dem Moment wo auf- oder zugesperrt wird ein Update ausgeführt wird. Dann wird kurzzeitig ein Fehler gemeldet der keiner ist. Hier könnte ich das autoupdate noch kürzer einstellen um schneller den richtigen Zustand zu erkennen.

Ich wollte nur fragen ob es hier evtl einen Trick gibt diesen Fehlerfall abzufangen. Deshalb hätte ich gemeint das es etwas unschön ist.

Das ist jetzt aber eher kosmetisch gesehen da es im richtigen Fehlerfall ja eh dauerhaft angezeigt bleibt - da gebe ich dir recht!

[martinp876]

hm - wie ist den der typische Ablauf? Sinn macht ja nur ein timer, der prüft ob uncertain auch mal verschwindet.
kannst du das einmal posten?

[new_rasp]

ich hab einem das auf- und zusperren gelogt.

Events:
2015-05-17 09:37:22 CUL_HM EG_Haustuer trig_Master_Remote_unlock: short
2015-05-17 09:37:22 CUL_HM EG_Haustuer trigLast: Master_Remote_unlock :short
2015-05-17 09:37:22 CUL_HM Master_Remote battery: ok
2015-05-17 09:37:22 CUL_HM Master_Remote Master_Remote_unlock Short (to EG_Haustuer)
2015-05-17 09:37:22 CUL_HM Master_Remote_unlock Short (to EG_Haustuer)
2015-05-17 09:37:22 CUL_HM Master_Remote_unlock trigger: Short_16
2015-05-17 09:37:22 CUL_HM EG_Haustuer aesKeyNbr: 00
2015-05-17 09:37:22 CUL_HM EG_Haustuer battery: ok
2015-05-17 09:37:22 CUL_HM EG_Haustuer uncertain: yes
2015-05-17 09:37:22 CUL_HM EG_Haustuer direction: up
2015-05-17 09:37:22 CUL_HM EG_Haustuer error: none
2015-05-17 09:37:22 CUL_HM EG_Haustuer lock: locked
2015-05-17 09:37:22 CUL_HM EG_Haustuer locked (uncertain)
2015-05-17 09:37:29 CUL_HM EG_Haustuer battery: ok
2015-05-17 09:37:29 CUL_HM EG_Haustuer uncertain: no
2015-05-17 09:37:29 CUL_HM EG_Haustuer direction: none
2015-05-17 09:37:29 CUL_HM EG_Haustuer error: none
2015-05-17 09:37:29 CUL_HM EG_Haustuer lock: unlocked
2015-05-17 09:37:29 CUL_HM EG_Haustuer unlocked
2015-05-17 09:37:32 CUL_HM EG_Haustuer trig_Master_Remote_lock: short
2015-05-17 09:37:32 CUL_HM EG_Haustuer trigLast: Master_Remote_lock :short
2015-05-17 09:37:32 CUL_HM Master_Remote battery: ok
2015-05-17 09:37:32 CUL_HM Master_Remote Master_Remote_lock Short (to EG_Haustuer)
2015-05-17 09:37:32 CUL_HM Master_Remote_lock Short (to EG_Haustuer)
2015-05-17 09:37:32 CUL_HM Master_Remote_lock trigger: Short_34
2015-05-17 09:37:32 CUL_HM EG_Haustuer aesKeyNbr: 00
2015-05-17 09:37:32 CUL_HM EG_Haustuer battery: ok
2015-05-17 09:37:32 CUL_HM EG_Haustuer uncertain: yes
2015-05-17 09:37:32 CUL_HM EG_Haustuer direction: down
2015-05-17 09:37:32 CUL_HM EG_Haustuer error: none
2015-05-17 09:37:32 CUL_HM EG_Haustuer lock: unlocked
2015-05-17 09:37:32 CUL_HM EG_Haustuer unlocked (uncertain)
2015-05-17 09:37:40 CUL_HM EG_Haustuer battery: ok
2015-05-17 09:37:40 CUL_HM EG_Haustuer uncertain: no
2015-05-17 09:37:40 CUL_HM EG_Haustuer direction: none
2015-05-17 09:37:40 CUL_HM EG_Haustuer error: none
2015-05-17 09:37:40 CUL_HM EG_Haustuer lock: locked
2015-05-17 09:37:40 CUL_HM EG_Haustuer locked
2015-05-17 09:37:43 CUL_HM EG_Haustuer battery: ok
2015-05-17 09:37:43 CUL_HM EG_Haustuer uncertain: no
2015-05-17 09:37:43 CUL_HM EG_Haustuer direction: none
2015-05-17 09:37:43 CUL_HM EG_Haustuer error: none
2015-05-17 09:37:43 CUL_HM EG_Haustuer lock: locked
2015-05-17 09:37:43 CUL_HM EG_Haustuer locked

Hier sieht man schön das immer kurzzeitig uncertain ausgegeben wird. Das mit dem zweiten Timer hätte ich mir auch schon überlegt. Wenn ich das autoupdate auf eine Minute und den Timer auf zwei Minuten setzen würde dann könnte man dies abfangen. Schöner wäre es natürlich wenn man das autoupdate in dieser Zeit (auf- zusperren) kurzzeitig nicht ausführen würde. Dann könnte man den Fehlerfall komplett unterbinden. Der Vorgang an sich dauert ja nur ca. 7 Sekunden.

Das komische ist wenn ich von locked auf direkt öffnen gehe dann wird kein uncertain angezeigt

Events:
2015-05-17 09:49:58 CUL_HM EG_Haustuer trig_Master_Remote_open: short
2015-05-17 09:49:58 CUL_HM EG_Haustuer trigLast: Master_Remote_open :short
2015-05-17 09:49:58 CUL_HM Master_Remote battery: ok
2015-05-17 09:49:58 CUL_HM Master_Remote Master_Remote_open Short (to EG_Haustuer)
2015-05-17 09:49:58 CUL_HM Master_Remote_open Short (to EG_Haustuer)
2015-05-17 09:49:58 CUL_HM Master_Remote_open trigger: Short_45
2015-05-17 09:49:58 CUL_HM EG_Haustuer aesKeyNbr: 00
2015-05-17 09:49:58 CUL_HM EG_Haustuer battery: ok
2015-05-17 09:49:58 CUL_HM EG_Haustuer uncertain: no
2015-05-17 09:49:58 CUL_HM EG_Haustuer direction: none
2015-05-17 09:49:58 CUL_HM EG_Haustuer error: none
2015-05-17 09:49:58 CUL_HM EG_Haustuer lock: locked
2015-05-17 09:49:58 CUL_HM EG_Haustuer locked
2015-05-17 09:50:10 CUL_HM EG_Haustuer battery: ok
2015-05-17 09:50:10 CUL_HM EG_Haustuer uncertain: no
2015-05-17 09:50:10 CUL_HM EG_Haustuer direction: none
2015-05-17 09:50:10 CUL_HM EG_Haustuer error: none
2015-05-17 09:50:10 CUL_HM EG_Haustuer lock: unlocked
2015-05-17 09:50:10 CUL_HM EG_Haustuer unlocked
2015-05-17 09:50:10 CUL_HM EG_Haustuer battery: ok
2015-05-17 09:50:10 CUL_HM EG_Haustuer uncertain: no
2015-05-17 09:50:10 CUL_HM EG_Haustuer direction: none
2015-05-17 09:50:10 CUL_HM EG_Haustuer error: none
2015-05-17 09:50:10 CUL_HM EG_Haustuer lock: unlocked
2015-05-17 09:50:10 CUL_HM EG_Haustuer unlocked

Soll ich sonst noch was loggen oder beschreiben?

[martinp876]

Sieht also so aus:
wenn direction up oder down ist ist uncertain auch yes.
Direction "None" ist ein stabiler Zustand, up/down ist transient.

Unklar, warum es 7-8 sec dauert, bis der stabile Zustand gemeldet wird. Meine Vermutung: Das Device wartet, wenn es Aktionen gibt 8-7 secunden und schickt - wenn alles stabil ist - einen statusreport. Dann ist direction = none und uncertain = no.

Ich gehe davon aus, dass nach einem trigger - wenn EG_Haustuer = uncertain für 8 sec ist, ein statusrequest den stabilen Zustand zeigen würde. Kannst du das testen?

Mein Vorschlag wäre: Nach einem Uncertain = yes einen Timer von 10 sec starten. Bei Uncertain = no wird der timer gestoppt. Wenn er abläuft wird uncertain = permanent gesetzt. Das kann man dann in HMInfo entsprechend ändern.

[new_rasp]

Hier wäre das Logfile mit statusrequest:

2015-05-17 12:20:52 CUL_HM EG_Haustuer trig_Master_Remote_lock: short
2015-05-17 12:20:52 CUL_HM EG_Haustuer trigLast: Master_Remote_lock :short
2015-05-17 12:20:52 CUL_HM Master_Remote battery: ok
2015-05-17 12:20:52 CUL_HM Master_Remote Master_Remote_lock Short (to EG_Haustuer)
2015-05-17 12:20:52 CUL_HM Master_Remote_lock Short (to EG_Haustuer)
2015-05-17 12:20:52 CUL_HM Master_Remote_lock trigger: Short_36
2015-05-17 12:20:52 CUL_HM EG_Haustuer aesKeyNbr: 00
2015-05-17 12:20:53 CUL_HM EG_Haustuer battery: ok
2015-05-17 12:20:53 CUL_HM EG_Haustuer uncertain: yes
2015-05-17 12:20:53 CUL_HM EG_Haustuer direction: down
2015-05-17 12:20:53 CUL_HM EG_Haustuer error: none
2015-05-17 12:20:53 CUL_HM EG_Haustuer lock: unlocked
2015-05-17 12:20:53 CUL_HM EG_Haustuer unlocked (uncertain)
2015-05-17 12:20:56 CUL_HM EG_Haustuer battery: ok
2015-05-17 12:20:56 CUL_HM EG_Haustuer uncertain: yes
2015-05-17 12:20:56 CUL_HM EG_Haustuer direction: down
2015-05-17 12:20:56 CUL_HM EG_Haustuer error: none
2015-05-17 12:20:56 CUL_HM EG_Haustuer lock: unlocked
2015-05-17 12:20:56 CUL_HM EG_Haustuer unlocked (uncertain)
2015-05-17 12:21:00 CUL_HM EG_Haustuer battery: ok
2015-05-17 12:21:00 CUL_HM EG_Haustuer uncertain: no
2015-05-17 12:21:00 CUL_HM EG_Haustuer direction: none
2015-05-17 12:21:00 CUL_HM EG_Haustuer error: none
2015-05-17 12:21:00 CUL_HM EG_Haustuer lock: locked
2015-05-17 12:21:00 CUL_HM EG_Haustuer locked
2015-05-17 12:21:04 CUL_HM EG_Haustuer battery: ok
2015-05-17 12:21:04 CUL_HM EG_Haustuer uncertain: no
2015-05-17 12:21:04 CUL_HM EG_Haustuer direction: none
2015-05-17 12:21:04 CUL_HM EG_Haustuer error: none
2015-05-17 12:21:04 CUL_HM EG_Haustuer lock: locked
2015-05-17 12:21:04 CUL_HM EG_Haustuer locked

uncertain wird hier trotzdem angezeigt!

[martinp876]

ok. Der Mechanismus könnte trotzdem so bleiben.
Also genauer: 10 sec nach dem letzten uncertain=yes schicken wir ein statusrequset. Sollte vorher ein uncertain=no kommen wird alles abgeblasen.
sollte der Statusrequest imme noch uncertain sein wird uncertain auf "permanent" gesetzt.

Klingt ok?

[new_rasp]

hört sich sogar sehr gut an! Evtl würde ich den Timer aber noch etwas verlängern da bei anderen der Vorgang etwas länger dauern könnte (abhängig vom Schließzylinder). Um paar Sekunden hin oder her geht es ja hier auch nicht. Aber das wäre nur eine Idee meinerseits.