LongRelease Totzeit

[Pfriemler]

Ihr redet noch immer aneinander vorbei...

Das es den LongRelease 1_xxx wirklich gegeben hat, siehst du ja in meinem Screenshot, also ich erzähle jetzt wirklich keine Unwahrheiten.

Also entweder habe ich Tomaten auf den Augen oder aber da ist nichts. In Deinem Eingangspost sehe ich ganz klar "LongRelease 2_..."

Nochmal ganz klar: Ein "Long x_y"-Event zählt in x die Länge des Tastendruckes in 0.3-s-Schritten (default, m.W. änderbar) durch, während y für den jeweiligen Tastendruck immer gleich ist. Das letzte Event eines Long ist ein "LongRelease x_y". Im Log von Dittel 10 Posts zuvor sieht man das sogar in den Sniffes:

Code Auswählen Erweitern

2017.07.01 11:13:49.669 0: HMLAN_Parse: HMusb R:E2FBB12   stat:0000 t:9F378F14 d:FF r:FFCD     m:78 8440 2FBB12 2CC535 41FF
2017.07.01 11:13:49.925 0: HMLAN_Parse: HMusb R:E2FBB12   stat:0000 t:9F379020 d:FF r:FFCD     m:79 8440 2FBB12 2CC535 41FF
2017.07.01 11:13:50.213 0: HMLAN_Parse: HMusb R:E2FBB12   stat:0000 t:9F37912B d:FF r:FFCD     m:7A 8440 2FBB12 2CC535 41FF
2017.07.01 11:13:50.469 0: HMLAN_Parse: HMusb R:E2FBB12   stat:0000 t:9F379236 d:FF r:FFCD     m:7B 8440 2FBB12 2CC535 41FF
2017.07.01 11:13:50.725 0: HMLAN_Parse: HMusb R:E2FBB12   stat:0000 t:9F379341 d:FF r:FFCD     m:7C 8440 2FBB12 2CC535 41FF
2017.07.01 11:13:51.013 0: HMLAN_Parse: HMusb R:E2FBB12   stat:0000 t:9F37944C d:FF r:FFCD     m:7D 8440 2FBB12 2CC535 41FF
2017.07.01 11:13:51.269 0: HMLAN_Parse: HMusb R:E2FBB12   stat:0000 t:9F379557 d:FF r:FFCF     m:7E A240 2FBB12 2CC535 41FF

siehe "m:": die fortlaufende 78-7E zeigt die einzelnen Telegramme, das folgende 8440 ändert sich zuletzt in A240 - das Release. Einen passenden Sniff mit nur einem Long habe ich bisher hier nicht gesehen.


Weiter:

Aber der Logik nach sollte ein Tastendruck doch immer mit Release beendet werden und im state dann so stehen oder nicht?

Sehe ich auch so.

Fakt ist: Offenbar scheint es den LongRelease gerade nach einem Long 1 nicht zu geben, was bedeutet, dass Notifys die auf ein LongRelease triggern, in diesem einen Grenzfall nicht funktionieren. (Blöderweise habe ich auf trigger geloggt und kann das bis jetzt nicht belegen).

Dass es sinnvoll ist, auf "Long 1" zu triggern statt auf "LongRelease", ist Ansichtssache - die Bedienhaptik erwartet normalerweise eine Reaktion während des Tastendruckes, aber für den Anfänger ist ein LongRelease leichter zu regexen - "Long.1", wie man es im notify nämlich einfach schreiben würde, triggert nämlich nach ca. drei Sekunden auch auf "Long 10" bis "Long 19" und sorgt für (meist unerwünschte) Mehrfachwiederholungen des Notify. Selbst ich müsste jetzt nachschlagen wie man das besser macht.

[martinp876]

nun, bei Fragen ist es in jedem Fall ok, diese zu klären.
Und man könnte etas ändern:
bei Long kommen min 2 Messages: ein Long und ein Release. Zumindest habe ich jetzt kein Device, was es anders macht.
Aktuelle Implementierung: der Zähler wird für jede Meldung genutzt - kann also nicht "1" sein.
alte Implementierung: Die Releaseabfrage war "falsch" - zumindest nicht 100% korrekt. Es kann leicht unterschiedlich gwesen sein (untersuche ich wie gesagt nicht mehr weiter).
neue Implementierung: der Release wird nicht mehr als Ereignis gezählt.

Was ändert sich für dich? Nicht viel. Es geht immer noch nicht schneller. Das Release kommt später - kann ja nicht eher.

Wie sollte man es implementieren?

Dass es sinnvoll ist, auf "Long 1" zu triggern statt auf "LongRelease", ist Ansichtssache

stimme nicht zu. Es hängt klar davon ab, was man will.
a) ich will auf "long" reagieren - egal wie lange man drückt
   Ich triggere nicht gerne auf "STATE", also anderer event
   Event: FB2_2 trigger: Long_194
   notify: FB2_2 trigger.*Long.*
   hat man eventonchangereading .* gesetzt (sollte man unbedingt) bekommt man schnellstmöglich einen Trigger und das notify wird schnell ausgeführt.
  => nach ~0.5s drücken wird notify ausgelöst
b) Long soll mindestens 3 sec gedrückt werden
   bei .4s je Wiederholung muss man 8 trigger abwarten. Hier muss man state nutzen
   notify: FB2_2.Long.8_.*
c) Long soll genau gedrückt werden: 0.4. bis 0.7s also eine message
   notify: FB2_2.LongRelease.1_.*
   => Notify wird ~1s nach drücken ausgeführt (vgl. a) )
d) will man erst nach den Loslassen des Buttons, min long, egal wie lange gedrückt reagieren muss man
   notify: FB2_2.LongRelease.*
   nutzen. Dauert natürlich längen - bis eben losgelassen wird.

Es ist also nicht egal, welches notify man nutzt - aber es gibt kein generelles "Richtig".
Geändert hat sich (nach update morgen) nur die Nummer in LongRelease. Das ist eins weniger.
 

[Navigator]

Also entweder habe ich Tomaten auf den Augen oder aber da ist nichts. In Deinem Eingangspost sehe ich ganz klar "LongRelease 2_..."

....doch, doch den LongRelease 1.xxx gabs wirklich, das Bild ist einen Beitrag von mir weiter oben.

https://forum.fhem.de/index.php?action=dlattach;topic=73039.0;attach=80970;image

Aber das ist eigentlich auch nicht so wichtig wie die Bezeichnung dafür war. Ich hätte ja auch mit einem LongRelease2...3...4  leben können, die hätten alle meine Notify´s getriggert, weil ich LongRelease.* als RegEx benutzt habe.  Aber es stand halt nur noch der Long 1_xxx  im STATE wenn ich einen etwas zu schnellen Finger hatte und eben zwischen diesen 0.4-0.7s den Taster zu schnell losgelassen habe. Der Release wurde nie nachgereicht. Der einzige Sniff der dann erscheint ist dieser hier.

Code Auswählen Erweitern

2017.07.02 18:55:30.704 0: HMLAN_Parse: HMusb R:E2FBB12   stat:0000 t:A604944B d:FF r:FFCE     m:D7 A640 2FBB12 2CC535 4179


Kann man hier vielleicht erkennen warum hier das Release nicht nicht folgt? Das wird doch nur in FHEM umgesetzt oder?

Egal wie die Sache hier jetzt oder später endet, ich habe begonnen Martins Vorschläge umzusetzen und baue meine Notfiy´s um.

Zitat

    Aber der Logik nach sollte ein Tastendruck doch immer mit Release beendet werden und im state dann so stehen oder nicht?

Sehe ich auch so.

Ist Martin auch der Meinung?

[martinp876]

weil es kein Release ist. Schlecht, nur die eine Message - kann ich nicht weiter beurteilen.

[Navigator]

...den Finger habe ich definitiv nicht mehr auf dem Taster...  ... ich habe zum sniffen "global mseclog 1, verbose 1 und hmusb logID all,sys" als Einstellungen genommen.

Aber ich sehe gerade das ca. 6 Sekunden später noch ein Event nachgereicht wird.

Code Auswählen Erweitern

2017-07-01 10:53:59 CU2017.07.02 20:55:19.003 0: HMLAN_Send:  HMusb I:K
2017.07.02 20:55:19.057 0: HMLAN_Parse: HMusb V:03C7 sNo:LEQ0659466 d:2CC535 O:2CC535 t:A672434F IDcnt:0003 L:0 %
2017.07.02 20:55:25.937 0: HMLAN_Parse: HMusb R:E37F232   stat:0000 t:A6725E3A d:FF r:FFB3     m:13 8610 37F232 000000 0A88D40B0040

[Pfriemler]

stimme nicht zu. Es hängt klar davon ab, was man will.
a) ich will auf "long" reagieren - egal wie lange man drückt

Das war das eigentliche Ziel mit dem LongRelease, nur dass es bei nur einer Long-Message beim TE nicht funktioniert. Aber diese Meldung kommt nur einmal im Verlaufe eines Long und triggert das Notify eben dann auch nur einmal.

   Event: FB2_2 trigger: Long_194
   notify: FB2_2 trigger.*Long.*
   ... eventonchangereading .* gesetzt (sollte man unbedingt) ... 

Das hat mir nochmal die Augen geöffnet. "trigger" beinhaltet nämlich NICHT die fortlaufende Nummer der während des Gedrückthaltens erzeugten Telegramme, und mit dem eventonchangereading erreicht man dann wohl, dass nur der erste "trigger" ein event und damit das Notify auslöst. So hat man dann schnellstmögliche Auslösung, nur ein Event und eine Ausführung noch während des Tastendrucks.

[martinp876]

eventonchangereqding .* stellt sicher, dass identische readings keine trigger ausloesen. culhm ist so ausgelegt, dass ein neues ereigniss einen neuen Trigger auslöst. es veraendert sich etwas um reading. daher dringende Empfehlung dies fuer alle einzustellen.
um long bei einem druecken nur einmal zu sehen kann man auch 1_ nutzen. der sollte immer ganz am anfang kommen-und nur einmal.