Hallo zusammen!
Ich verwende die Homematic Schlüsselanhänger, um in Verbindung mit meinem Nuki Schloss das zu öffnen oder zu schließen. Ich habe immer mal wieder die Situation, dass wenn ich z.B. auf die Taste drücke, die zum öffnen der Tür von mir programmiert wurde, dass der Befehl erst nicht, dann aber verspätet ausgeführt wird. Das führt dann dazu, wenn man ungeduldig nochmal auf das Öffnen der Tür drückt, dass die Tür mehrmals hintereinander geöffnet wird. Kann man die Wiederholung, die möglicherweise aufgrund eines Verbindungsproblems zustande kommt, irgendwie unterbinden?
p7
Hi,
Hängt davon ab wie Du das realisiert hast?
Bei einem notify gibt's disableAfterTrigger
Gruß Otto
Zitatdass der Befehl erst nicht, dann aber verspätet ausgeführt wird.
warum erst nicht? ist da wlan im spiel?
Die Nuki Bridge ist via WLAN angebunden. Wenn ich z.B. über die Nuki App öffne, habe ich solche Situationen nicht. Das tritt nur in Verbindung mit FHEM/Homematic auf.
In Code sieht das bei mir so aus:
define Wohnung3.Unzugeordnet.Device.Fernbedienung.unlock.short notify Wohnung3.Unzugeordnet.Device.Fernbedienung[0-9].(unlock|armInt):Short.* {\
openAppartment();;\
}
Die Funktion dazu:
sub openAppartment() {
Log 3, "[openAppartment]";
my $deviceName = "Wohnung3.Flur.Device.Wohnungstuer";
my $state = InternalVal("$deviceName", "STATE", "unknown");
Log 3, "$deviceName: State -> ".$state;
if($state eq "locked") {
Log 3, "[Appartment] Door was locked";
fhem("set $deviceName unlatch");
fhem("define DoorFloorOn at +00:00:05 set Wohnung3.Flur.Device.Schaltaktor1 on-for-timer 300");
fhem("define DoorTableOn at +00:00:10 set Wohnung3.Kueche.Device.Schaltaktor1_Esstisch on");
} else {
Log 3, "[Appartment] Door was not locked";
fhem("set $deviceName unlatch");
}
}
Zitat von: Otto123 am 16 November 2021, 23:19:03
Hängt davon ab wie Du das realisiert hast?
Bei einem notify gibt's disableAfterTrigger
Wenn alle Stricke reißen, könnte ich es ja damit probieren. Aber falls ich die Ursache finden kann, wäre mir das lieber als die Symptome zu behandeln.
Hallo prodigy7,
noch schlimmer ist es bei einem Garagentor. Da führt ein und der selbe Befehl zu auf, stop, zu, auf, ... Laut Otto's Vermutung handelt es sich wohl um ein Grundgesetz, dass in der Menschenrechtscharta verankert ist, so dass alle Garagentore nach diesem Prinzip funktionieren. Die Erklärung ist natürlich Blödsinn und frei erfunden 8), aber so gefällt es mir besser ;D.
Es ist nicht lustig, wenn man bei geöffnetem Garagentor rausfährt, und wenn sich währenddessen das Tor schließt. Ich hab jeder einzelnen Taste eine sinnvolle Aktion zugeordnet, und durch Abfragen in verschiedenen notifys (offen/in Fahrt/geschlossen) gegenseitig ausgeschlossen.
Viele Grüße Gisbert
Wenn ich den Code rund um "openApartment" oben sehe, weiß ich wieder, was ich an meinen DOIFs habe... Dort kann man mit allen erdenklichen Attributen jede Zeitsteuerung ohne temporäre at's realisieren und auch Wiederholungen temporär unterbinden.
Verzögerungen durch verspätete Übertragungen an das NUKI sind kniffliger. Man könnte das Absetzen erneuter "unlatch" für eine Zeit unterbinden nach einer Aussendung, aber was wenn man das absichtlich macht, weil die Tür wieder zugefallen ist? Dann steht man 2 Minuten vor der Tür?
Gäbe es vielleicht eine Möglichkeit, den Erhalt des Fernbedienungsbefehls für den Benutzer sichtbar zu quittieren? etwa ein von außern sichtbares Licht für eine kurze Zeit einzuschalten? Dann weiß man dass der Befehl angekommen ist und prozessiert wurde. Ein Peering des FB-Buttons mit einem virtuellen Button (vccu oder virtual-Device) liefert zumindest an der Fernbedienung ein Indiz dafür, ob der Befehl in FHEM angekommen ist (grüne LED, sonst rot). Dann kann man sich das erneute Drücken erst mal ersparen und wartet...
jm2c
Nachtrag: Liefert das NUKI eine Rückmeldung über einen erfolgreich ausgeführten Befehl? Dann könnte man aus FHEM die Absendung erneuter Befehle (für eine Zeitlang) unterbinden und bei Empfang einer Quittung die Sperre zurücksetzen. Dann wären auch beabsichtige Wiederholungen problemlos ohne Wartezeit machbar.
P.S.: Ich habe einen Rademacher DUOFERN Garagentorantrieb, der gar keinen toggle-Befehl kennt, nur explizite Fahranweisungen. Für einen einzelnen Taster (genauer: ein HM-Signalsender, den ich in das Bremslicht meines Motorrollers eingeschleift habe), musste ich extra eine Logik bauen, die das in explizite Auf-Zu-Befehle umwandelt...
Hingegen gibt es auch Rademacher-Sender (sowas wie universelle Schalter/Taster-Interfaces), die mit dem Antrieb gekoppelt toggeln können und wo ich genau das gleiche Problem einer undefinierten Aussendung habe. Glücklicherweise haben die Dinger zwei Kanäle, also habe ich jetzt einen zweiseitigen Wipptaster im Auto zur Steuerung...
jm2c
Hi p7,
jetzt wäre noch die Frage wie ist Wohnung3.Unzugeordnet.Device.Fernbedienung[0-9] wirklich angebunden? Nur angelegt? gepairt? Mit einem virtuellen Aktor gepeert?
Und Du hast ja schon ein Log eingebaut, schreib doch da einfach noch den ganzen $EVENT mit ins Log damit man sieht was im Problemfall für Events kommen?
Deine Fehlerbeschreibung klingt ja so, als ob nicht ein Übertragungsproblem des Schlüsselanhängers die Ursache ist, sondern Homematic verzögert reagiert? Blockiert in dem Moment etwas? Hast Du freezemon laufen?
Gruß Otto
Danke für eure Antworten! Ich schau mir das mal am WE an, ob ich die erfolgreiche Ausführung irgendwie handlen kann.
Bzgl. der Freezes habe ich mal Freezmon eingebunden, um zu schauen ob es was findet.
Die Fernbedienung habe ich mit einem mit meiner VCCU gepeert. Also sprich: Suche aktiviert, bei der Fernbedienung in dem Loch den Trigger ausgelöst damit die sich mit der VCCU austauscht. Ich habe noch düster in Erinnerung, dass man die Fernbedienung auch so peeren konnte, dass der Druck auf der Fernbedienung mit einem grünen Licht quittiert werden konnte. Wie ging das nochmal?
So: https://wiki.fhem.de/wiki/HM-RC-4-2_Funkfernbedienung_4_Tasten
Aber !!! beachte den Problem Thread im Homematic Forum. Je nach Update Stand ist CUL_HM "kaputt" - ich weiß nicht genau, was dann noch geht ;)