...ich habe vor ein paar Tagen mal wieder ein Update von FHEM gefahren. Mir ist aufgefallen das meine HM-PB-6-WM55 auf einmal schlecht auf lange Tastendrücke reagierten. Nach ein wenig Beobachtung und Eingrenzung des Fehlverhaltens, habe ich festgestellt das nach einem langen Tastendruck, der aber nicht länger wie eine Sekunde dauert nur ein Long 1 getriggert wird. Das LongRelease, auf das meine Notifys reagieren kommt nur auf Tastedrücke länger wie eine Sekunde.. also Long2..Longrelease2...Long3..Longrelase3 usw... Nach Short kommt also Long1, aber ohne ein LongRelease1 nach dem loslassen des Tasters. Wenn man nun also den Taster ein wenig länger drückt um nicht Short zu triggern, aber nicht lang genug, bleibt das LongRelease aus. Das war doch nicht immer so oder irre ich mich da?
bitte einmal sniffen
### kurzer Tastendruck
2017.06.11 11:45:34.582 0 : HMLAN_Parse: HMusb R:E2FBB12 stat:0000 t:3855C99C d:FF r:FFCC m:FF A640 2FBB12 2CC535 0125
2017-06-11 11:45:34.618 CUL_HM TA_Kueche battery: ok
2017-06-11 11:45:34.618 CUL_HM TA_Kueche CMDs_done
2017-06-11 11:45:34.618 CUL_HM TA_Kueche TA_Kueche_Btn_01 Short
2017.06.11 11:45:34.624 1 : TA_Kueche_Btn_01_Short -> Leuchte_Deko OFF
2017-06-11 11:45:34.633 CUL_HM TA_Kueche_Btn_01 Short (to vCCU)
2017-06-11 11:45:34.633 CUL_HM TA_Kueche_Btn_01 trigger: Short_37
2017-06-11 11:45:34.633 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 37
2017-06-11 11:45:34.638 CUL_HM vCCU_Btn1 trigLast: TA_Kueche_Btn_01:short
2017-06-11 11:45:34.638 CUL_HM vCCU_Btn1 trig_TA_Kueche_Btn_01: Short_37
2017-06-11 11:45:34.663 structure Alle_Leuchten ON
2017-06-11 11:45:34.670 HUEDevice HUEDevice1 onoff: 0
2017-06-11 11:45:34.670 HUEDevice HUEDevice1 pct: 0
2017-06-11 11:45:34.670 HUEDevice HUEDevice1 OFF
2017-06-11 11:45:34.686 structure Alle_Leuchten OFF
2017-06-11 11:45:34.692 HUEDevice HUEDevice2 onoff: 0
2017-06-11 11:45:34.692 HUEDevice HUEDevice2 pct: 0
2017-06-11 11:45:34.692 HUEDevice HUEDevice2 OFF
### Tastendruck ca. 1 Sec. Long, aber kein LongRelease daher kein Trigger
2017.06.11 11:47:30.742 0 : HMLAN_Parse: HMusb R:E2FBB12 stat:0000 t:38578F6D d:FF r:FFC8 m:06 A640 2FBB12 2CC535 412A
2017-06-11 11:47:30.779 CUL_HM TA_Kueche battery: ok
2017-06-11 11:47:30.779 CUL_HM TA_Kueche CMDs_done
2017-06-11 11:47:30.779 CUL_HM TA_Kueche TA_Kueche_Btn_01 Long
2017-06-11 11:47:30.785 CUL_HM TA_Kueche_Btn_01 Long 1_42 (to vCCU)
2017-06-11 11:47:30.785 CUL_HM TA_Kueche_Btn_01 trigger: Long_42
2017-06-11 11:47:30.785 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 42
2017-06-11 11:47:30.789 CUL_HM vCCU_Btn1 trigLast: TA_Kueche_Btn_01:long
2017-06-11 11:47:30.789 CUL_HM vCCU_Btn1 trig_TA_Kueche_Btn_01: Long_42
2017-06-11 11:47:30.842 HMLAN HMusb loadLvl: low
### Tastendruck > 1 Sec. LongRelease triggert
2017-06-11 11:47:05.870 HMLAN HMusb loadLvl: low
2017.06.11 11:47:06.165 0 : HMLAN_Parse: HMusb R:E2FBB12 stat:0000 t:38572F6B d:FF r:FFC8 m:04 8440 2FBB12 2CC535 4129
2017-06-11 11:47:06.187 CUL_HM TA_Kueche battery: ok
2017-06-11 11:47:06.187 CUL_HM TA_Kueche TA_Kueche_Btn_01 Long
2017-06-11 11:47:06.194 CUL_HM TA_Kueche_Btn_01 Long 1_41 (to vCCU)
2017-06-11 11:47:06.194 CUL_HM TA_Kueche_Btn_01 trigger: Long_41
2017-06-11 11:47:06.194 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 41
2017-06-11 11:47:06.199 CUL_HM vCCU_Btn1 trigLast: TA_Kueche_Btn_01:long
2017-06-11 11:47:06.199 CUL_HM vCCU_Btn1 trig_TA_Kueche_Btn_01: Long_41
2017.06.11 11:47:06.453 0 : HMLAN_Parse: HMusb R:E2FBB12 stat:0000 t:38573076 d:FF r:FFCD m:05 A240 2FBB12 2CC535 4129
2017-06-11 11:47:06.477 CUL_HM TA_Kueche battery: ok
2017-06-11 11:47:06.477 CUL_HM TA_Kueche CMDs_done
2017-06-11 11:47:06.477 CUL_HM TA_Kueche TA_Kueche_Btn_01 LongRelease
2017.06.11 11:47:06.482 1 : TA_Kueche_Btn_01_Long -> Leuchte_Deko 30
2017-06-11 11:47:06.491 CUL_HM TA_Kueche_Btn_01 LongRelease 2_41 (to vCCU)
2017-06-11 11:47:06.491 CUL_HM TA_Kueche_Btn_01 trigger: Long_41
2017-06-11 11:47:06.491 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 41
2017-06-11 11:47:06.496 CUL_HM vCCU_Btn1 trigLast: TA_Kueche_Btn_01:long
2017-06-11 11:47:06.496 CUL_HM vCCU_Btn1 trig_TA_Kueche_Btn_01: Long_41
Ich habe jetzt mal das Backup eingespielt. Mit der "00_HMLAN.pm 13605" ist dieses Verhalten definitv nicht so. Es gibt einen Short und nach längerm drücken gleich ein LongRelease_1. Einen Zwischenzustand der nur also Long Trigger bestehen bleibt gibt es hier nicht.
1) bist du sicher, dass es hmlan ist oder sind im backup mehr files ungerschiedlich?
2) ich sehe keine long press. wo sind die gesnifften Messages?
...nein, dass es an HM_LAN liegt war nur eine Vermutung und dazu noch falsch. Ich habe jetzt aber der Reihe nach wieder die Updates gefahren. HM_LAN bewirkte noch nicht den Fehler, erst nach einspielen von CUL_HM kann ich es wieder reproduzieren.
Hier die letzen Messages:
2017.06.13 21:33:00.426 0: HMLAN_Parse: HMusb R:E3C8D09 stat:0000 t:44BC45B6 d:FF r:FFA6 m:DD A641 3C8D09 34AE04 01E6C8
2017.06.13 21:33:00.554 0: HMLAN_Parse: HMusb R:E34AE04 stat:0000 t:44BC463A d:FF r:FFB5 m:DD A002 34AE04 3C8D09 04EA795506558700
2017.06.13 21:33:00.810 0: HMLAN_Parse: HMusb R:E34AE04 stat:0000 t:44BC4734 d:FF r:FFB6 m:DD 8002 34AE04 3C8D09 0099C20035
2017.06.13 21:33:01.194 0: HMLAN_Parse: HMusb R:E34AE04 stat:0000 t:44BC48B6 d:FF r:FFB5 m:72 B011 34AE04 35F8B9 0201C80000
2017.06.13 21:33:01.578 0: HMLAN_Parse: HMusb R:E34AE04 stat:0000 t:44BC4A47 d:FF r:FFB5 m:72 B011 34AE04 35F8B9 0201C80000
2017.06.13 21:33:01.711 0: HMLAN_Parse: HMusb R:E35F8B9 stat:0000 t:44BC4AC6 d:FF r:FFAF m:72 8002 35F8B9 34AE04 0101C80000
2017.06.13 21:33:01.802 0: HMLAN_Parse: HMusb R:E3C8D09 stat:0000 t:44BC4B16 d:FF r:FFAA m:DF A241 3C8D09 34AE04 01E6C8
2017.06.13 21:33:01.930 0: HMLAN_Parse: HMusb R:E34AE04 stat:0000 t:44BC4B99 d:FF r:FFB5 m:DF A002 34AE04 3C8D09 04445E939DCD8400
2017.06.13 21:33:02.314 0: HMLAN_Parse: HMusb R:E458DC5 stat:0000 t:44BC4D26 d:FF r:FFA2 m:5D 865A 458DC5 000000 24F42E
2017.06.13 21:33:11.122 0: HMLAN_Send: HMusb I:K
2017.06.13 21:33:11.178 0: HMLAN_Parse: HMusb V:03C7 sNo:LEQ0659466 d:2CC535 O:2CC535 t:44BC6FBD IDcnt:0003 L:0 %
2017.06.13 21:33:11.211 0: HMLAN_Parse: HMusb R:E37F419 stat:0000 t:44BC6FD3 d:FF r:FFA8 m:5E 8610 37F419 000000 0A88E60A0040
2017.06.13 21:33:12.842 0: HMLAN_Parse: HMusb R:E3CE9B4 stat:0000 t:44BC7638 d:FF r:FFB8 m:24 8610 3CE9B4 000000 0A88E60C0040
2017.06.13 21:33:22.314 0: HMLAN_Parse: HMusb R:E458DC5 stat:0000 t:44BC9B45 d:FF r:FFA3 m:5D 8470 458DC5 000000 00F42E
2017.06.13 21:33:36.125 0: HMLAN_Send: HMusb I:K
2017.06.13 21:33:36.170 0: HMLAN_Parse: HMusb V:03C7 sNo:LEQ0659466 d:2CC535 O:2CC535 t:44BCD15C IDcnt:0003 L:0 %
2017.06.13 21:33:59.028 0: HMLAN_Parse: HMusb R:E2FBB12 stat:0000 t:44BD2A92 d:FF r:FFC7 m:3A A640 2FBB12 2CC535 4157
2017.06.13 21:34:00.586 0: HMLAN_Parse: HMusb R:E3CE979 stat:0000 t:44BD30B9 d:FF r:FFB3 m:DA 8610 3CE979 000000 0A24F40C0040
2017.06.13 21:34:01.127 0: HMLAN_Send: HMusb I:K
2017.06.13 21:34:01.163 0: HMLAN_Parse: HMusb V:03C7 sNo:LEQ0659466 d:2CC535 O:2CC535 t:44BD32FC IDcnt:0003 L:0 %
Letzter Status in der Detailansicht ist wieder nur ein Long.
schwer zum Erkennen.
erst kommt ein trigger des 3C8D09. der ist short.
dann dein taster mit einem long. der trigger wird identisch zu diesem zeitpunkt geschrieben. ich sehen keine verzoegerung. und nur eine message des buttons.
...das Problem ist ja, der LongRelease fehlt. Es muss doch immer ein LongRelease als letzter Trigger vorhanden sein, weil ja der Taster und immer irgendwann losgelassen wird. Zumindest war es so bisher. Diesen LongRelease habe ich aber jetzt immer erst nach Long.2, also den etwas längeren Tastendruck. Wenn ich zu kurz drücke, aber nicht kurz genug für den Short, bleibt der Long als letztes Event stehen und kein Long Release, wie es doch eigentlich sein müsste, oder?
bei long erwarte ich einige trigger long. und dann den lerzten.
in deinem log sehe ich einen einzigen. warum?
ist der button gepeert? mit welcher id?
...wenn ich den taster etwas länger drücke dann kommen auch die long trigger.. immer wieder bis zum letzten longrelease. ABER, bei der neuen version der cul_hm fehlt der longrelease_1 im state. den gibts irgendwie nicht mehr. nehme ich das backup ist er wieder da. also kurze tastendrucke short, nur ein bisschen länger bleibt long im state stehen anstatt longrelease1. drückt man nun noch etwas länger kommen die long trigger gefolgt vom jeweiligen longrelease. hier ist wieder alles richtig.
ich habe mit der alten und der neuen version logfiles erzeugt, vielleicht hilft dir das.
gepeert sind die taster mit virt. kanälen der vccu. 2CC535
neue cul_hm version mit fehlendem longrelease 1
2017.06.16 22:57:21.509 0: HMLAN_Parse: HMusb R:E2FBB12 stat:0000 t:547C85CC d:FF r:FFCC m:5B A640 2FBB12 2CC535 416F
2017.06.16 22:57:43.740 0: HMLAN_Send: HMusb I:K
2017.06.16 22:57:43.781 0: HMLAN_Parse: HMusb V:03C7 sNo:LEQ0659466 d:2CC535 O:2CC535 t:547CDCD0 IDcnt:0003 L:0 %
2017.06.16 22:58:50.533 0: HMLAN_Parse: HMusb R:E2FBB12 stat:0000 t:547DE1A1 d:FF r:FFCC m:5D A640 2FBB12 2CC535 4171
2017.06.16 22:58:55.876 0: HMLAN_Parse: HMusb R:E3CE9A2 stat:0000 t:547DF668 d:FF r:FFB2 m:33 8610 3CE9A2 000000 0A98FB0C0000
alte cul_hm version
2017.06.16 23:01:57.804 1: TA_Kueche_Btn_01_Short -> Leuchte_Deko OFF
2017.06.16 23:01:59.244 0: HMLAN_Send: HMusb I:K
2017.06.16 23:01:59.301 0: HMLAN_Parse: HMusb V:03C7 sNo:LEQ0659466 d:2CC535 O:2CC535 t:5480C2EF IDcnt:0003 L:0 %
2017.06.16 23:02:05.636 0: HMLAN_Parse: HMusb R:E2FBB12 stat:0000 t:5480DBB3 d:FF r:FFCC m:5F A640 2FBB12 2CC535 4173
2017.06.16 23:02:05.664 1: TA_Kueche_Btn_01_Long -> Leuchte_Deko 30
zum besseren verständnis noch mal die abfolge was ich überhaupt meine.
alte version ... alles i.O.
short (im state)
long1
longrelease1 (im state)
long2
longrelease2 (im state)
long3
longrelease3 (im state)
long4
longrelease4 (im state)
long5.....
neue version ... long im state
short (im state)
long1 (im state)!!! daher kein trigger wenn longrelease in regex und taster zu früh loggelassen wird, aber schon ausserhalb von short
long2
longrelease2 (im state)
long3
longrelease3 (im state)
schau dir bitte mal zeile 3437 in cul_hm an.
#$state .= ($mhp->{mFlgH} & 0x20 ? "Release" : "")." $mhp->{cHash}{helper}{BNOCNT}_$cnt" # not sufficient
$state .= ((($mhp->{mFlgH} & 0x24) == 0x20) ? "Release" : "")." $mhp->{cHash}{helper}{BNOCNT}_$cnt"
if($long eq "long");
die zeile die du auskommentiert hast und durch eine änderung ersetzt. dort schleicht sich das "fehlverhalten" wohl ein, wie ich austesten konnte.
...ich würde das thema gern noch mal hoch holen und fragen ob dem entwickler des hm moduls etwas aufgefallen ist oder meine fehlerbeschreibung zu unpräzise formuliert war...
Mein HM-LC-Sw1PBU-FM Unterputz-Schalter hat die Long-Funktion nicht, wenn ich richtig liege sonst würde ich das gerne auch mal versuchen nachzuvollziehen. Vielleicht gibt es sonst noch jemand mit einem entsprechenden Teil, der den Versuch machen könnte?
Hallo duke-f.
Naja, wenigstens einer, der sich meiner annimmt. Ich verstehe das gar nicht, daß keiner hier sich meldet. Entweder es triggert keiner auf LongRelease mit diesem Taster oder es drücken alle doch sehr lang und stoßen damit nie auf den "Bug". Ich drücke halt doch sehr kurz, gerade so um über den Short zu kommen und dann bleibt Long im state stehen und meine Notifys triggern nicht. So ein Mist, warum mich der Moderator und Modulentwickler ignoriert kann ich auch nicht nachvollziehen obwohl ich versucht habe auf alle Fragen einzugehen. Jetzt sitze ich hier nun mit meinem Problem.... :-\
Seh's vielleicht einfach optimistisch, @martinp876 ist vielleicht einfach so mit der Lösung Deines Problems beschäftigt, dass er nicht mal zum Antworten kommt ;)
gib mir etwas Zeit. komme gerade nicht dazu, steht aber au der Liste
danke.. ich hab mal die zeiten gemessen. jedenfalls so ungefähr. bis 0.5 sec tastendruck kommt der short. von ca. 0.5 bis 1.0 sec steht nur Long im state, der LongRelease bleibt aus. Ab 1.0 sec Tastendruck triggern die Longs ganz normal und der jeweilige LongRelease steht auch dann im state beim loslassen, ab da also alles normal.
so, bin einmal durchgegangen.
Leider sehe ich ein Messagelog von einem schönen langen "press". Du filterst viel vor, was ich sehen und selbst machen muss.
Was ich aus dem unvollständigen Log sehe ist, dass der erste Trigger kommt und noch kein release signalisiert wird.
Danach kommt ein release. Aber losgelassen wird erst in der 2. message.
Die Auswertung ist nun also korrekt.
Deine zusammenstellung der FHEM events ist von dir zusammengefasst.
so sieht ein eventlog eines long trigger aus.
2017-07-01 06:45:54.037 CUL_HM FB12 FB_01 Long
2017-07-01 06:45:54.044 CUL_HM FB_01 Long 1_50 (to laDimmer)
2017-07-01 06:45:54.044 CUL_HM FB_01 trigger: Long_50
2017-07-01 06:45:54.044 CUL_HM FB_01 trigger_cnt: 50
2017-07-01 06:45:54.288 CUL_HM FB_01 Long 2_50 (to laDimmer)
2017-07-01 06:45:54.541 CUL_HM FB_01 Long 3_50 (to laDimmer)
2017-07-01 06:45:54.793 CUL_HM FB_01 Long 4_50 (to laDimmer)
2017-07-01 06:45:55.045 CUL_HM FB12 FB_01 LongRelease
2017-07-01 06:45:55.052 CUL_HM FB_01 LongRelease 5_50 (to laDimmer)
2017-07-01 06:45:55.052 CUL_HM FB_01 triggerTo_laDimmer: Long_50
Schicke doch einmal einen diesmal kompletten log der messages und events.
Möglich, dass dein Taster anders arbeitet (eQ5 und die Nachbauten sind nicht immer sauber) - muss ich aber einmal kompett sehen.
Ich nutze LongRelease inzwischen nur noch mit einem Notify auf einer Taste und verarbeite sonst anderweitig, weil auch die Logik speziell ist - die Aktion erfolgt ja erst nach Loslassen. Seit einiger Zeit beschwert sich die bessere Hälfte über ein angebliches Nichtfunktionieren dieser Taste... und das hier könnte due Ursache sein. Wird gerade im Langzeittest geloggt...
hallo.. danke das wir am thema dranbleiben können.
Zitat
Möglich, dass dein Taster anders arbeitet (eQ5 und die Nachbauten sind nicht immer sauber) - muss ich aber einmal kompett sehen.
ich habe zwei dieser teile mit unterschiedlichem kaufdatum. bei beiden zeigt sich dieses verhalten mit der aktuellen cul_hm version, mit der alten keine probleme mehr.
Zitat
Schicke doch einmal einen diesmal kompletten log der messages und events.
ich hoffe der neue log ist jetzt so wie du ihn gefordert hast. ich habe die einstellungen wie im hm sniffen wiki vorgenommen.
2017-07-01 11:06:41.825 CUL_HM TA_Kueche_Btn_01 Long 1_249 (to vCCU)
2017-07-01 11:06:41.825 CUL_HM TA_Kueche_Btn_01 trigger: Long_249
2017-07-01 11:06:41.825 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 249
2017-07-01 11:06:42.081 CUL_HM TA_Kueche_Btn_01 Long 2_249 (to vCCU)
2017-07-01 11:06:42.081 CUL_HM TA_Kueche_Btn_01 trigger: Long_249
2017-07-01 11:06:42.081 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 249
2017-07-01 11:06:42.336 CUL_HM TA_Kueche_Btn_01 Long 3_249 (to vCCU)
2017-07-01 11:06:42.336 CUL_HM TA_Kueche_Btn_01 trigger: Long_249
2017-07-01 11:06:42.336 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 249
2017-07-01 11:06:42.622 CUL_HM TA_Kueche_Btn_01 Long 4_249 (to vCCU)
2017-07-01 11:06:42.622 CUL_HM TA_Kueche_Btn_01 trigger: Long_249
2017-07-01 11:06:42.622 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 249
2017-07-01 11:06:42.879 CUL_HM TA_Kueche_Btn_01 Long 5_249 (to vCCU)
2017-07-01 11:06:42.879 CUL_HM TA_Kueche_Btn_01 trigger: Long_249
2017-07-01 11:06:42.879 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 249
2017-07-01 11:06:43.146 CUL_HM TA_Kueche_Btn_01 LongRelease 6_249 (to vCCU)
2017-07-01 11:06:43.146 CUL_HM TA_Kueche_Btn_01 trigger: Long_249
2017-07-01 11:06:43.146 CUL_HM TA_Kueche_Btn_01 trigger_cnt: 249
2017.07.01 11:13:42.341 0: HMLAN_Parse: HMusb R:E37F419 stat:0000 t:9F377267 d:FF r:FFAC m:63 8610 37F419 000000 0A88CF0A0040
2017.07.01 11:13:45.893 0: HMLAN_Parse: HMusb R:E3CE9B4 stat:0000 t:9F37804E d:FF r:FFBE m:2A 8610 3CE9B4 000000 0A88DB0B0040
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
2017.07.01 11:13:51.296 1: TA_Kueche_Btn_01_Long -> Leuchte_Deko 30
2017.07.01 11:13:52.133 0: HMLAN_Parse: HMusb R:E3CE979 stat:0000 t:9F3798A9 d:FF r:FFB4 m:F0 8610 3CE979 000000 0A24F30B0040
ich muss hier aber noch mal betonen. ich triggere nicht auf die longs, sondern wie priemler nur auf short und longrelease.
der fehler zeigt sich nur wenn man den taster zwischen
ca. 0.5 und 1 sec drückt also gerade lang genug um den short schon übergangen zu haben. es fehlt dann das event LongRelease
1_xxx. nur in diesem kurzen zeitfenster hat man das das problem, weil dann Long 1_xxx (to vCCU) im STATE bleibt, wenn man schon losgelassen hat. alles was noch längere tastendrucke betrifft, also über 1 sec. ist ja wieder alles in ordnung. es gibt nur keinen LongRelease
1_xxx mehr!!!
Anders als Dittel im Post #10 vermutet, wird das LongRelease ja quasi als letztes Event einer Long-Kette gesendet:
Long_1
Long_2
...
Long_5
LongRelease_6
Leider kann ich nicht annähernd genug Perl, um zu erkennen, warum durch die Änderung in CUL_HM ein Release nach nur einem Long nicht als solches verarbeitet wird.
So isses. Release,also das loslassen, wird beim loslassen gesendet. Bis vor einiger zeit hatte ich es behelfsmässig an Meldungen zu peers befestigt. Da der mechanismus nun klar ist, isr die Implementation verbessert.
Dass es später kommt kann ich nicht ändern, ist dem system geschuldet.
Dein notify kann schneller sein, wenn du den ersten long nutzt. Long.1_.*
Schneller geht nicht.
Dein Device verhält sich vorbildlich
glaube wir reden etwas aneinander vorbei. meine und sicherlich auch pfriemler´s notifys triggern nur die Shorts für kurze und die LongRelease.* für etwas längere losgelassene tastendrucke um eine zweite funktion zu realisieren und nicht um zu dimmen etc. die longs beachte ich überhaupt nicht. ABER:
es gibt keinen LongRelease 1_xxx mehr. betonung auf "1". Es steht ein nur der Long1 im STATE und demzufolge triggern die Notifys nicht. es beginnt erst mit dem LongRelease 2_xxx und so weiter. demzufolge löst das notify manchmal nicht aus, wenn man halt etwas kurz drückt. dann passiert gar nichts.
@priemler: konntest du das auch so reproduzieren? ich weiss echt nicht mehr wie ich es anders schildern soll. mit der alten version gehts doch auch?? :-[
es darf doch kein Long im STATE stehen bleiben, wenn ich die taste schon längst losgelassen habe...
Hatte ich von longrelease1 gesprochen? Das kann es sowieso nicht geben.
Ich habe umfänglich verstanden was du meinst.
Hast du verstanden, was ein release ist? Was ein long 1_20 ist und ein long 2_20?
Ein shortrelease kommt immwr sofort. Logisch, sonst waere es long.
Ein long release kommt immer nach dem loslassen. Also SPÄTER. Liegt in der Natur des triggees
Schade wenn du den falschen trigger zur Auswertung gewählt hast.
Von dimmen habe ich auch nichts gesagt.
Wenn du auf jeden long einmal reagieren willst mache es wie ich geschrieben habe. Das ist der einzig korrekte weg
Vielleicht bin ich als Laie hier zu naiv, aber ich dachte, Dittels Problem verstanden zu haben, habe aber das Gefühl, @martinp876 schafft es aber trutz aller Mühe nicht. Kann natürlich sein, ich sehe es wirklich viel zu einfach.
Es soll doch wohl so sein:
Kurzer Tastendruck liefert Signal "Short" - funktioniert
Langer Tastedruck liefert etwas wie eine Serie an Signalen wie
"Long_1"
"Long_2"
.
.
.
"Long_10"
LongRelease_10"
Funktioniert auch, aber nur bei mehr als einem "Long_1".
Wird unmittelbar nach "Long_1" die Taste los gelassen, passiert danach absolut nichts mehr. Es fehlt das abschließende "LongRelease_1" komplett. Folgt auch nicht irgendwann später.
So richtig? Sonst: Entschuldigt, dass ich mich einmische...
Fast richtig ... nur dass es nach einem Long_(x) kein LongRelease_(x) gibt, sondern ein LongRelease_(x+1). Schrieb ich ein paar Posts vorher, siehe auch die vom TE geposteten Logs.
Insofern hat Martin recht: Es kann nie ein LongRelease_1 geben. Aber es gibt eben auch kein LongRelease_2 nach einem Long_1.
...jetzt verstehe ich gar nichts mehr. den longrelease 1_xxx gab es bisher immer! soll der jetzt so falsch sein?? wie soll man denn jetzt die longrelease ordentlich verarbeiten, wenn man auf einmal einen undefinierten zustand hat. kein short und kein longrelease... was soll das denn darstellen, da drückt ja auch niemand die taste mehr, also gehört da auch ein release für losgelassen rein und kein long. die logik erschliesst sich mir nicht....
Ich kann dir nicht wirklich folgen.
Wenn es vorher tatsaechlich ein longrelease1 gegeben hat war es ein fehler. Muesste prüfen, ob es so war.....
Was fehlt nach der erklaerung her noch?
Short ist ein trigger kommt und ist per definition zu ende, released. Fragen?
Long ist per definition eine serie von messages. NACH der serie kommt ein release. Grenzfall ist eine serie mit einer message. Auch hier gilt, dass NACH der serie das release kommt. Daher deine .5s. So arbeitet der taster, so bildet fhem es ( jetzt besser) ab.
Damit dem user eine erweiterte auswertung ermoeglicht wird habe ich einen zaehler eingebaut, den es bei hm nicht gibt. Hm liefert einen zaehler, der wievielte tastendruck es war. Also ein wert fuer alle messages einer longpress. Der zusaetzliche zaehler zaehlt die messages immerhalb eines long. Damit kannst du fast alles. Wenn du auf die 1_ triggerst reagierst du auf das erste erkennen eines long - allerdings weist du nicht, wie lange der long dauert und ob zu diesem zeitpunkt schon losgelassen wurde. Das weis selbst der taster erst etwa .3s nach der ersten message.
Du kannst also trigger
A) auf das erste erkennen eines long
B) auf das 2. 3. 4. oder jede wiederholung
C) auf das loslassen nach einem long (mit .5s delay, weil es erst dann passiert). Das loslassen nach genau 1 2 3 oder 5 messages laesst sich einrichten, ist aber kein direkter trigger.
Hm bietet das abzaehlen der laenge des long nicht an, da vermutlich nicht erwartet wird, dass ein anwender es praezise steuern kann.
Ist es dir nun wichtig, dass der anwender den taster GENAU zwischen .4 und .8s lang drueckt? Ist .9 schon eine andere aktion? Kleiner .4 ist short. Ab .9 kommt msg 2. Sollte das egal sein steht immer noch mein vorschlag weiter oben. Genau was du brauchst. Sollte >.8 ein problem sein musst du dich .5s gedulden.
Hallo Martin... danke das du dir noch mal die Zeit nimmst. Ich weiss, man hat es nicht leicht mit Querulanten wie mir. ;)
Das es den LongRelease 1_xxx wirklich gegeben hat, siehst du ja in meinem Screenshot, also ich erzähle jetzt wirklich keine Unwahrheiten.
Zum Short gibts soweit keine Fragen mehr, eigentlich auch nicht zum Long, ich habe auch begonnen die Notify´s auf ":trigger" umzubauen.
Aber du schreibst selbst... Zitat:
ZitatLong ist per definition eine serie von messages. NACH der serie kommt ein release. Grenzfall ist eine serie mit einer message. Auch hier gilt, dass NACH der serie das release kommt.
Und genau das trifft nicht ein. Es bleibt nur ein Long 1_xx im state stehen und zwar dann wenn der Tastendruck zu kurz war, aber trotzdem noch lang genug um den Short schon übergangen zu haben. Ob nun ein LongRelaese 1 oder 2 dahin gehört, sei mal dahingestellt. Das Event wird nicht mit einem LongRelease x_xx beendet im state. Ich will jetzt nicht darauf beharren was richtig und was falsch ist und wenn du sagst es ist jetzt korrekt so, dann nehme ich das so hin. Aber der Logik nach sollte ein Tastendruck doch immer mit Release beendet werden und im state dann so stehen oder nicht? Wenn noch andere auf LongRelease.* regexen und mit der Zeit ihre Updates fahren, werden sich sicher noch mehr melden, die sich wundern warum manchmal die Taster nicht mehr reagieren.
Trotzdem werde ich jetzt mit dem Umbau meiner Notifys beginnen.
Achso... und danke für den ausführlichen Support.
Ihr redet noch immer aneinander vorbei...
Zitat von: Dittel am 01 Juli 2017, 21:32:35
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:
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:
ZitatAber 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.
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?
ZitatDass 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.
Zitat von: PfriemlerAlso 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 (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.
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 von: Dittel
Zitat
Aber der Logik nach sollte ein Tastendruck doch immer mit Release beendet werden und im state dann so stehen oder nicht?
Zitat von: Pfriemler
Sehe ich auch so.
Ist Martin auch der Meinung?
weil es kein Release ist. Schlecht, nur die eine Message - kann ich nicht weiter beurteilen.
...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.
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
Zitatstimme 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.
Zitat
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.
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.