[gelöst] Resends von Sensoren/FB unterdrücken, optimal wie?

Begonnen von Pfriemler, 24 April 2015, 10:47:34

Vorheriges Thema - Nächstes Thema

Pfriemler

Ich nutze einen Taster im Eingangsbereich für verschiedene Komfortsteuerungen. Sein protokollierter rssi zum HMLAN schwankt zwischen -78 und -94.

Die Aktion soll auf einen langen Tastendruck reagieren. Da das Filtern auf :Long.* beim Notify ja dazu führt, dass die Aktion bei jeder Long-Message (Long 3, Long 4 ... ) getriggert wird, könnte man nun auf die Idee kommen, gleich auf bspw. :Long.5.* zu triggern. Blöderweise wird gerade dieser Trigger in etwa einem von zehn Fällen verschluckt und dann nichts ausgeführt. Der WAF ist entsprechend niedrig.

Gut funktioniert hingegen LongRelease. Man drückt halt länger und erwartet die Aktion erst beim Loslassen. Hier nun habe ich vermehrt den Effekt, dass die gewünschte Aktion zweimal ausgeführt wird. Grund dafür ist, dass der Taster LongRelease tatsächlich oft zweimal sendet, wohl weil er das ACK nicht schnell oder sicher genug erhält.

Ich sehe zwei Lösungsmöglichkeiten:
a) Das Register für die Resends im Taster auf 1 setzen. Das verringert mir aber unter Umständen die Zuverlässigkeit.
b) als erstes im Notify einen Dummy abfragen, nur wenn der nicht gesetzt, als erstes ihn setzen und dann die Verarbeitung - so würden weitere Instanzen des Notify nicht zu Ende laufen. Problem ist das Rücksetzen: Die Befehlskette ist meist fertig, bevor der nächste Trigger einläuft.
c) die Verarbeitung in DOIF verlegen und mit cmdPause eine wiederholte Verarbeitung unterbinden (z.B. drei Sekunden).

c) gefällt mir am besten. Hat noch jemand eine bessere Idee?
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

Zitat von: frank am 24 April 2015, 11:49:29
funk verbessern.

Ja, mann, ...  :D ... theoretisch schon. Wichtig wäre vor allem den Empfang des Tasters im Eingang zu verbessern, damit der nicht so viel Resends macht. Die letzten aktuellen rssi lagen um die 80, insgesamt -das wird nur noch von meinem Neigungssensor unterboten, der sich mit -83 ... -93, Schnitt -89, aber empfangstechnisch unauffällig verhält (obgleich er aus der geschlossenen Blechgarage herausbrüllt). Ansonsten ist der Platz des HMLAN gerade ziemlich optimal für alles Übrige im Haus.
Der Türkontakt der Haustür liegt in fast demselben Winkel, einen Meter längere Funkstrecke, und der schafft -70..-75. Rund um die beiden Geräte ist es funktechnisch eigentlich sehr still, da sollte auch bei rssi's um -85 noch kein Mangel sein.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Mr. P

Vielleicht ist ja das Attribut 'event-min-interval' was für dich. ;-)
Greetz,
   Mr. P

frank

vergleiche mit rssi zwischen mehreren devices halte ich für schlecht.

das problem bei den rssi, ist zb, dass du ja keine angabe bekommst, bei welchem rssi es nicht mehr funktioniert. alle geloggten werte haben funktioniert. aber das sie beim nächsten mal wieder funktioniern ist nicht garantiert. ausserdem gibt es immer 2 funkstrecken. die 2 könnte ganz anders aussehen. wenn du bei diesem device resends erkennst, gibt es doch wohl funkprobleme.

ich kenne jetzt deinen schalter nicht, aber generell wird ein funkschalter durch den bediener beim schalten in gewisser weise abgeschirmt/gestörrt. die person hält sich in der funkstrecke auf. beim fensterkontakt sieht das meist anders aus. eventuell gibt es die resends, wenn du dein metallic lackiertes disco-outfit beim schalten trägst.  :)  oder jemand der ein LTE-handy in der tasche hat.

ich habe bei mir schon sehr seltsame rssi-plots gesehen. unter anderem scheinen auch reflexionen (fenster, türen, jalousien) grossen einfluss zu haben. zb rssi in den keller: ist bei einem io bei geschlossener tür besser, beim nächsten mit geöffneter tür.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

ZitatVielleicht ist ja das Attribut 'event-min-interval' was für dich. ;-)

Jawoll. Danke. Gut versteckt. Das merke ich mir für's nächste Mal. Das wäre soszusagen Eventvermeidung an der Quelle.
Inzwischen hatte ich die gesamte Verarbeitung sowieso in ein DOIF verlagert - der Taster setzt nur einen Dummy auf einen Zustand, und das DOIF reagiert auf Zustandsänderungen des Dummys in größerem Kontext (Anwesenheit etc.). cmdpause funktioniert hier prächtig.

@frank: Es handelt sich um den HM Sechsfach-Wandtaster, den ich um 90 Grad quergelegt habe, zwecks besserer Bedienbarkeit (drei Spalten mit jeweils up/down). Die Antenne liegt dann weitgehend horizontal - im besagten Fensterkontakt aber auch. Der Taster ist fast über Kopfhöhe angebracht (nix für Kiddies  8)) und wird sozusagen "von unten" bedient - die Abschattung durch den Benutzer ist praktisch null. Im Umkreis von 1,50m gibt es kein weiteres elektrisches Gerät. Und den Fensterkontakt stört das Handy auch nicht... Beide müssen sehr diagonal eine Geschossdecke durchfunken.
Der Garagentorsensor hat auch einen Nachbarn: eine Einfach-Aktor-Platine. Dessen Antenne ragt durch ein Löchlein aus dem Blechhaus ins Freie. Der rssi ist >20 besser.
Punkt. Ich mach mal ein "gelöst."
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."