LongRelease Totzeit

Begonnen von Navigator, 10 Juni 2017, 22:40:30

Vorheriges Thema - Nächstes Thema

duke-f

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 ;)
Cubietruck, 3 Raspberry Pis,
CUL868, RFXtrx433, CUL433, SCC868, HM-USB,
IRTrans, EZcontrol XS1, IguanaWorks USB IR Transceiver
ESPEasy, Fritz!Box, Samsung TV+BD, LMS, Squeezelite

martinp876

gib mir etwas Zeit. komme gerade nicht dazu, steht aber au der Liste

Navigator

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.

martinp876

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.

Pfriemler

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...
"Ä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 ..."

Navigator

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!!!

Pfriemler

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.
"Ä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 ..."

martinp876

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

Navigator

#23
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...

martinp876

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

duke-f

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...
Cubietruck, 3 Raspberry Pis,
CUL868, RFXtrx433, CUL433, SCC868, HM-USB,
IRTrans, EZcontrol XS1, IguanaWorks USB IR Transceiver
ESPEasy, Fritz!Box, Samsung TV+BD, LMS, Squeezelite

Pfriemler

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.

"Ä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 ..."

Navigator

#27
...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....

martinp876

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.

Navigator

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.