Meine halbe Automatisierung ging nicht mehr, weil die Matches nicht mehr stimmten, da in der Ausgabe beim Long-Befehl nun der Bindestrich zum Unterstrich wurde. Super! Gibt's da irgendwie mal eine Ankündigung, dass wenn die Ausgaben verändert wurden?
von was sprichst du hier, mach lieber ein beispiel des Events vorher-nacher
Vorher:
CUL_HM SW1_Btn_01 Long 1-104 (to broadcast)
Jetzt:
CUL_HM SW1_Btn_01 Long 1_103 (to broadcast)
Beispiel: Hier reagiere ich auf den ersten Long-Befehl:
Vorher:
define AusserHaus_l notify SW1_Btn_02.Long.1-.* {\
fhem('set PwrStatus 0');;\
fhem('set Heizungen_Alle off');;\
}
Jetzt:
define AusserHaus_l notify SW1_Btn_02.Long.1_.* {\
fhem('set PwrStatus 0');;\
fhem('set Heizungen_Alle off');;\
}
Ansich ist die Änderung ja einheitlicher. Man könnte solche Bindezeichen auch mit Regex anders matchen oder andere Ausgaben nehmen. Aber im Prinzip ist so eine Änderung immer mit Funktionsausfällen verbunden. Da ich etwa 30 Komponenten habe, kann es schon aufwändiger werden. Letztens gab es auch eine Änderung bei der "Long"-Ausgabe, die mich ersteinmal fragend stehen ließ. :)
Ich bezweifle das das Absicht ist,
Martin wird bestimmt etwas dazu sagen, aber die Thread Übeschrift würde ich ändern :)
Du hast Recht. Es war nicht nett formuliert. ::)
Ein
attr SCHALTER event-on-change-reading state
und dann ein Umbau des notifys auf
SW1_Btn_02.Long.* {
fhem('set PwrStatus 0');
fhem('set Heizungen_Alle off');
}
macht dich unabhängig von solchen Änderungen
Würde das aber nicht auf alle "Long"-Befehle reagieren?
D.h, wenn ich die Taste länger gedrückt halte, werden kontinuierlich aufzählende Long_1, Long_2, Long_3 usw. gesendet.
Diese kann man dazu nutzen, dass z.B. ab einem 3 Sek. Long etwas weiteres ausgeführt wird.
Somit kann ich auf einen kürzeren Long oder einen langen Long reagiern. Z.B. 1 oder 10.
Bei einem Long.* wird das Script u.U. mehrmals ausgeführt, da es auf alle Long-Übertragungen reagiert.
Zitatevent-on-change-reading state
da würden bei mir die ganzen SHORT nur einmal funktionieren und dann nie wieder, es sei denn ich drück mal ein LONG
ne, da muß sich Martin nochmal dazu äußern, die Logeinträge haben sich bei meiner Fernbedienung auch geändert
das mit dem -_ habe ich nicht gesehen.
Grund der Umstellung war ein weiterer Button - nun werden alle Buttons (messages dieser Art) generisch beantworte.
Eigentlich fehlen noch ein paar Parameter in diesem Trigger.
Leider kenne ich keinen Mechanismus in FHEM, diese notwendige Vereinheitlichung anzukündigen. Es wäre bei Releasehandling möglich.
Es gibt noch weitere Änderungen - insbesondere für User, die keine Button-Entites nutzen. Das ist eine sehr alte Form - vor meiner Zeit in FHEM.
Zu deinem Notify: Beachte, dass ein Long 2 Zähler hat. Einmal ein Eventcounter, der vom Button kommt und dann ein Wiederholzähler über den man die länge des Press ersehen kann.
Du willst nur die Erste der messages auswerten, die bei einem Longpress kommen. Das klappt nicht immer mit deinem Notify. Wenn dein Button gepeert ist und auch LongRelease gemeldet wird kann man ein "LongRelease 1-" erzeugen.
Ich nutze nach Möglichkeit nie "state". Dir steht "trigger " zu Verfügung. Wenn du event-on-change-reading setzt (empfehle ich dringend - immer) kannst du:
define AusserHaus_l notify SW1_Btn_02:trigger:.Long.* {\
das kommt genau einmal bei Long - und auch bei "kurzem long"
Will man erst nach 5sec triggern braucht man doch "state"
define AusserHaus_l notify SW1_Btn_02.(Long|LongRelease).40_.* {\
Das ist eigentlich unschön - sollte man verbessern. Wäre aber noch eine Änderung.
Das _ kann ich gegen ein - tauschen - seid ihr bereit?
Wie wäre es, wenn man den Zähler vorne mit Nullen auffüllen würde? Also anfangen bei 01 oder 001?
unüblich, sicher möglich. Ein sauberer Trenner wäre schon. ein eigenes Reading... auch nicht gut. Das Leerzeichen ist ungünstig, da man es in FHEM nicht einfach parsen kann. 001 löst das Problem mit dem Release auch nicht komplett - oder?
Ob Unterstrich oder Bindestrich ist eigentlich egal. Jetzt habe ich alles auf Unterstrich abgeändert.
Die Sache mit dem "event-on-change-reading" kannte ich noch nicht und hört sich interessant an. Verstehe ich das so, dass ein gleiches Event nicht beachtet wird? Und wenn ja, wird dann ein Short nur 1x ausgeführt, wenn ein späteres Short kommt (wie fhem-hm-knecht beschrieben hat)?
Das mit dem LongRelease vs. Long habe ich noch nie so richtig verstanden. Kommen die erst, wenn es ein Peering gibt?
Eventonchange loest nur einen trigger aus, wenn sich das reading aendert. Kommt ein status oder ack mit identischer info 2mal wird das reading auch 2mal geschrieben. Die message war nicht doppelt, nur der inhalt.
Eventonchange filtert dies. Readings sind in culhm so aufgebaut, dass sich im reading etwas aendert wenn ein ereigniss new ist. Das siehst du aber selbst, wenn du den inhalt analysiertst.
Longrelease kommt nur, wenn der kanal gepeert ist. Eigentlich meldet das der kanal garnicht... aber nach ende des long werden die peers nach einem ack abgefragt. Das erzeugt in fhem das release. M.e. ein hilfreicher trigger. Da bei unpeered keon ack gepollt werden kann (von wem auch ) gibt es auch kein release
Ich hatte auch Probleme nach einem Update kamen die Long-States nicht mehr wie gewohnt an...
statt:
015-04-06_00:17:52 Taster2 Taster2_Btn_02 Long 1-8440- (to CUL868)
2015-04-06_00:17:53 Taster2 battery: ok
2015-04-06_00:17:53 Taster2 Taster2_Btn_02 Long 2-8440- (to CUL868)
2015-04-06_00:17:53 Taster2 battery: ok
2015-04-06_00:17:53 Taster2 Taster2_Btn_02 Long 3-8440- (to CUL868)
2015-04-06_00:17:53 Taster2 battery: ok
2015-04-06_00:17:53 Taster2 Taster2_Btn_02 Long 4-8440- (to CUL868)
2015-04-06_00:17:53 Taster2 battery: ok
2015-04-06_00:17:53 Taster2 Taster2_Btn_02 Long 5-8440- (to CUL868)
2015-04-06_00:17:54 Taster2 battery: ok
2015-04-06_00:17:54 Taster2 CMDs_done
2015-04-06_00:17:54 Taster2 Taster2_Btn_02 LongRelease 6-A240- (to CUL868)
kam
2015-04-06_20:55:57 Taster2 Taster2_Btn_01 Long
2015-04-06_20:55:57 Taster2 battery: ok
2015-04-06_20:55:57 Taster2 Taster2_Btn_01 Long
2015-04-06_20:55:57 Taster2 battery: ok
2015-04-06_20:55:57 Taster2 Taster2_Btn_01 Long
2015-04-06_20:55:58 Taster2 battery: ok
2015-04-06_20:55:58 Taster2 Taster2_Btn_01 Long
2015-04-06_20:55:58 Taster2 battery: ok
2015-04-06_20:55:58 Taster2 Taster2_Btn_01 Long
2015-04-06_20:55:58 Taster2 battery: ok
2015-04-06_20:55:58 Taster2 Taster2_Btn_01 Long
2015-04-06_20:55:59 Taster2 battery: ok
2015-04-06_20:55:59 Taster2 CMDs_done
2015-04-06_20:55:59 Taster2 Taster2_Btn_01 LongRelease
Ich hatte Events, die nach auf die "Long 5" "Long 10" etc. lauschen und bei längerem Drücken Farben rotieren.
Diese funktionieren nun nach dem Update nicht mehr.
Taster2 ist das Device
Taster2_Btn_02 der Button.
Wo sind die Trigger des Buttons? Hast du die weggefiltert? Am Button hätte ich dein Notify erwartet
Ich habe dann solche Ereignisse darauf, die gehen dann nach dem letzten Update nicht mehr...
define Licht_Kueche_FARB1 DOIF ([Taster2_Btn_01:state] =~ /Long.1-.*/) (set LED2 RGB 0080ff)
define Licht_Kueche_FARB2 DOIF ([Taster2_Btn_01:state] =~ /Long.5-.*/) (set LED2 RGB ff4800)
define Licht_Kueche_FARB3 DOIF ([Taster2_Btn_01:state] =~ /Long.10-.*/) (set LED2 RGB ff004b)
define Licht_Kueche_FARB4 DOIF ([Taster2_Btn_01:state] =~ /Long.15-.*/) (set LED2 RGB 0000ff)
define Licht_Kueche_FARB5 DOIF ([Taster2_Btn_01:state] =~ /Long.20-.*/) (set LED2 RGB ff0000)
define Licht_Kueche_FARB6 DOIF ([Taster2_Btn_01:state] =~ /Long.25-.*/) (set LED2 RGB 00ff00)
mit doif habe ich mich noch nicht beschäftigt. Es kommen mir Performance-bedenken - nicht bei deiner Implementierung, aber wenn ich das im großen Stil nutzen will. Ausserdem ist mir nicht klar, warum du nicht doelsif nutzt. Beleibt zu hoffen, das die Implementierung hier inteligent arbeitet. Notify hat - wenn man es richtig einsetzt - performanceaspekte beachtet.
Aber das ist nicht das Thema. In deinem Trace sehe ich trigger des Device
Zitat2015-04-06_20:55:57 Taster2 Taster2_Btn_01 Long
nicht aber des Buttons. Der sollte auch kommen - tut es so bei mir. was hast du gefiltert? Es müsste ein
2015-04-06_20:55:57 Taster2_Btn_01 Long 2_3
2015-04-06_20:55:xx Taster2_Btn_01 Long 3_3
...
kommen - das ist dein trigger, nicht das Device.
mit "_" sollte es klappen - klar.
Zitatdefine Licht_Kueche_FARB1 DOIF ([Taster2_Btn_01:state] =~ /Long.1_.*/) (set LED2 RGB 0080ff)
define Licht_Kueche_FARB2 DOIF ([Taster2_Btn_01:state] =~ /Long.5_.*/) (set LED2 RGB ff4800)
define Licht_Kueche_FARB3 DOIF ([Taster2_Btn_01:state] =~ /Long.10_.*/) (set LED2 RGB ff004b)
define Licht_Kueche_FARB4 DOIF ([Taster2_Btn_01:state] =~ /Long.15_.*/) (set LED2 RGB 0000ff)
define Licht_Kueche_FARB5 DOIF ([Taster2_Btn_01:state] =~ /Long.20_.*/) (set LED2 RGB ff0000)
define Licht_Kueche_FARB6 DOIF ([Taster2_Btn_01:state] =~ /Long.25_.*/) (set LED2 RGB 00ff00)
Ich hätte es wohl so gebaut
define x notify Taster2_Btn_01.Long.* {my ($a,$b) = $EVENT =~ m/(\d+).(\d+)/;;\
if($a == 1) {fhem "set LED2 RGB 0080ff"}\
if($a == 5) {fhem "set LED2 RGB ff4800"}\
if($a ==10) {fhem "set LED2 RGB ff004b"}\
if($a ==15) {fhem "set LED2 RGB 0000ff"}\
if($a ==20) {fhem "set LED2 RGB ff0000"}\
if($a ==25) {fhem "set LED2 RGB 00ff00"}}
den 2. Wert $b brauchst du nicht...
der Unterschied von 1 nach 5 ist nicht symetrisch - du könntest also auch
define x notify Taster2_Btn_01.Long.* {my ($a,$b) = $EVENT =~ m/(\d+).(\d+)/;\
if($a%5 == 1){$a=int($a/5);;\
if($a ==0) {fhem "set LED2 RGB 0080ff"}\
if($a ==1) {fhem "set LED2 RGB ff4800"}\
if($a ==2) {fhem "set LED2 RGB ff004b"}\
if($a ==3) {fhem "set LED2 RGB 0000ff"}\
if($a ==4) {fhem "set LED2 RGB ff0000"}\
if($a ==5) {fhem "set LED2 RGB 00ff00"}}}
Nebenbei: Du hast event-on-change-reading nicht gesetzt. Absicht?
Ich mag mich vertun, aber kann es sein, dass früher immer bei den Events immer noch das Device vor den Buttons stand?
Also so etwas wie:
Zitat2015-04-20 23:53:59 CUL_HM 6erTaster01 6erTaster01_Btn1 Long
2015-04-20 23:53:59 CUL_HM 6erTaster01 6erTaster01_Btn1 Long 5_98 (to VirtuellerAktor)
2015-04-20 23:53:59 CUL_HM 6erTaster01 6erTaster01_Btn1 trigger: Long_98
2015-04-20 23:53:59 CUL_HM 6erTaster01 6erTaster01_Btn1 trigger_cnt: 98
2015-04-20 23:53:59 CUL_HM 6erTaster01 battery: ok
statt dem jetzigen:
Zitat2015-04-20 23:53:59 CUL_HM 6erTaster01 6erTaster01_Btn1 Long
2015-04-20 23:53:59 CUL_HM 6erTaster01_Btn1 Long 5_98 (to VirtuellerAktor)
2015-04-20 23:53:59 CUL_HM 6erTaster01_Btn1 trigger: Long_98
2015-04-20 23:53:59 CUL_HM 6erTaster01_Btn1 trigger_cnt: 98
2015-04-20 23:53:59 CUL_HM 6erTaster01 battery: ok
Das fett gedruckte fehlt ja jetzt. Daher sind auch alle meine EVTPARTS plötzlich im eimer, weil sie natuerlich völlig falsche Sachen beinhalten.
if($EVTPART0 eq "6erTaster01_Btn1"){
if($EVTPART1 eq "Short"){fhem("set HUEDevice4 toggle");}
if($EVTPART1 eq "Long"){
if($EVTPART2 eq "1_.*"){fhem("set LED_Treppe toggle");}
}
}Und auch mein FileLog sieht aus wie das was Merlin1 gepostet hat. Da nicht mehr das Device vorangestellt wird, landet natuerlich immer nur die erste Zeile des obigen Beispiels im log und damit auch nicht mehr die Long-Counter.
korrekt. Der Triggerzähler müssen beim Button stehen, sonst sind sie nicht in den Readings sichtbar.
Das Device zeigt den Letzten Trigger an - eigentlich auch nicht konform - aber wohl ok.
Du kannst dir natürlich alle events dr Kanäle in das Device schreiben.
Wobei dein notify funktionieren sollte
2015-04-20 23:53:59 CUL_HM 6erTaster01 6erTaster01_Btn1 Long
gibt es doch noch.
Hallo,
ich habe Probleme mit den Meldungen eines HM-RC-P1 und dem damit verbundenen event.
Seit ein paar Wochen haben sich die beim Tastendruck übertragenen Daten geändert!
Als Rückmeldung bei gedrückter Taste kam immer "Btn1 offLong x-nnnn-"
X waren die Sekunden die der Taster gedrückt gehalten wurde und den habe ich genutzt um nach z.B. 5 Sekunden ein Event zu triggern.
Bis zum 12.03.2015 sah das LOG des Senders immer so aus.
2015-03-12_16:37:22 HM_Notruf_1 trigger_cnt: 23
2015-03-12_16:37:22 HM_Notruf_1 trigger: Long_23
2015-03-12_16:37:22 HM_Notruf_1 battery: ok
2015-03-12_16:37:22 HM_Notruf_1 Btn1 offLong 1-8440- (to broadcast)
2015-03-12_16:37:23 HM_Notruf_1 trigger_cnt: 23
2015-03-12_16:37:23 HM_Notruf_1 trigger: Long_23
2015-03-12_16:37:23 HM_Notruf_1 battery: ok
2015-03-12_16:37:23 HM_Notruf_1 Btn1 offLong 2-8440- (to broadcast)
2015-03-12_16:37:23 HM_Notruf_1 trigger_cnt: 23
2015-03-12_16:37:23 HM_Notruf_1 trigger: Long_23
2015-03-12_16:37:23 HM_Notruf_1 battery: ok
2015-03-12_16:37:23 HM_Notruf_1 Btn1 offLong 3-8440- (to broadcast)
Jetzt fehlt die Zeile mit "offLong" komplett
Bei kurzen Tastendruck erscheint jetzt "Btn1 Short" und bei langem nur noch "Btn65 Long" und einen counter für jeden Tastendruck.
2015-04-12_12:43:59 HM_Notruf_1 battery: ok
2015-04-12_12:43:59 HM_Notruf_1 Btn65 Long
2015-04-12_12:43:59 HM_Notruf_1 trigger: Long_25
2015-04-12_12:43:59 HM_Notruf_1 trigger_cnt: 25
2015-04-12_12:44:00 HM_Notruf_1 battery: ok
2015-04-12_12:44:00 HM_Notruf_1 Btn65 Long
2015-04-12_12:44:00 HM_Notruf_1 trigger: Long_25
2015-04-12_12:44:00 HM_Notruf_1 trigger_cnt: 25
So sieht die Definition aus:
define HM_Notruf_1 CUL_HM 1DED7F
attr HM_Notruf_1 IODev HMLAN1
attr HM_Notruf_1 autoReadReg 4_reqStatus
attr HM_Notruf_1 expert 2_full
attr HM_Notruf_1 firmware 1.3
attr HM_Notruf_1 model HM-RC-P1
attr HM_Notruf_1 peerIDs 00000000,
attr HM_Notruf_1 room CUL_HM
attr HM_Notruf_1 serialNr JEQ0648279
attr HM_Notruf_1 subType remote
define FileLog_HM_Notruf_1 FileLog ./log/HM_Notruf_1-%Y.log HM_Notruf_1
attr FileLog_HM_Notruf_1 logtype text
attr FileLog_HM_Notruf_1 room CUL_HM
define EV_RC1 notify HM_Notruf_1.Btn1.offLong.5\-.* { myFBCallr(......) }
Was muss ich umbauen um ein Event zu bekommen / auszulösen wenn die Taste z.B. 5 Sekunden gedrückt wird?
Vielen Dank schonmal
Hermann
Was fuer trigger kommen fuer btn1 und btn65 ?
@martin
sorry, helf mir mal mit Deiner Frage...so tief bin ich wohl noch nicht im Thema ;)
Alle Infos die ich habe bzw kenne sind in der Nachricht aufgelistet.....
zum ersten rate ich wie immer dazu, duplicate trigger zu unterdrücken
attr HM_Notruf_1 event-on-change-reading .*
oder eigentlich - das führe ich in jedem restart im post-init-config aus
attr TYPE=CUL_HM event-on-change-reading .*
HM_Notruf_1 Btn65 Long
das Device ist HM_Notruf_1, der Channel(Button) Btn65
Es sollte also auch trigger vom Button 65 geben - oder hast du die Kanäle nicht angelegt?
Ja, so muss es wohl sein.
Beheben werde ich den falschen Buttonnamen:
HM_Notruf_1 Btn65 Long
wird zu
HM_Notruf_1 Btn1 Long
Wenn du die Buttons alle anlegt, also ein
define HM_Notruf_1_Btn1 CUL_HM <hmId>01
werden auch die Trigger der Kanäle kommen:
HM_Notruf_1_Btn1 Long 16_16 (to xxx)
...
sowie
HM_Notruf_1_Btn1 Long 1_16 (to xxx)
HM_Notruf_1_Btn1 trigger: Long_16
wenn dann alle Buttons definiert sind
define HM_Notruf_1_Btn1 CUL_HM <hmId>01
define HM_Notruf_1_Btn2 CUL_HM <hmId>02
define HM_Notruf_1_Btn3 CUL_HM <hmId>03
...
sollte
define EV_RC1 notify HM_Notruf_1.Btn..Long.5\-.* { myFBCallr(......) }
beim 5. Trigger eines jeden Buttons auslösen
oder
define EV_RC1 notify HM_Notruf_1.Btn1.Long.5\-.* { myFBCallr(......) }
nur bei Button 1
Das Define für den Button war die Lösung...
define HM_Notruf_1_Btn1 CUL_HM <hmId>01
Damit kommen jetzt die Infos wie lange die Taste gedrückt wird.
2015-04-27_11:42:24 HM_Notruf_1_Btn1 Long 5_240 (to broadcast)
Hast Du ne Idee warum das Verhalten ab Zeitpunkt x sich so verändert hat? Es hat lange so funktioniert wie in meiner Anfrage geschrieben.
Dieses zusätzliche define war vorher nicht erforderlich. Und die Meldung sah auch anders aus.
Interessiert mich nur, weil ich sonst alle meine Feature und Devices durchtesten muss :-((
Auf jeden Fall many thanks für die Hilfe!!!
Hermann
Das betrifft nur taster mit mehreren buttons. Wie oben beschrieben ist der code aufgeraeumt worden. Das haette ich schon lange machen sollen, gleich zu anfang. Sorry, dass es so spaet war.
Der code war eine seltsame variation des ueblichen. On und off waren irrefuehrend.
Will man alles in einer entity sehen, kann man das mit userreadings jederzeit tun