Ausgabe beim Long-Befehl wurde zum Unterstrich (vorher Bindestrich)

[Dr. Smag]

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?

[LuckyDay]

von was sprichst du hier, mach lieber ein beispiel des Events vorher-nacher

[Dr. Smag]

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:

Code Auswählen Erweitern


define AusserHaus_l notify SW1_Btn_02.Long.1-.* {\
  fhem('set PwrStatus 0');;\
  fhem('set Heizungen_Alle off');;\
}


Jetzt:

Code Auswählen Erweitern


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ß.

[LuckyDay]

Ich bezweifle das das Absicht ist,

Martin wird bestimmt etwas dazu sagen, aber die Thread Übeschrift würde ich ändern

[Dr. Smag]

Du hast Recht. Es war nicht nett formuliert. 

[marvin78]

Ein

Code Auswählen Erweitern

attr SCHALTER event-on-change-reading state

und  dann ein Umbau des notifys auf

Code Auswählen Erweitern


SW1_Btn_02.Long.* {
  fhem('set PwrStatus 0');
  fhem('set Heizungen_Alle off');
}


macht dich unabhängig von solchen Änderungen

[Dr. Smag]

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.

[LuckyDay]

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

[martinp876]

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:

Code Auswählen Erweitern

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"

Code Auswählen Erweitern

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?

[vbs]

Wie wäre es, wenn man den Zähler vorne mit Nullen auffüllen würde? Also anfangen bei 01 oder 001?

[martinp876]

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?

[Dr. Smag]

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?

[martinp876]

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

[Merlin1]

Ich hatte auch Probleme nach einem Update kamen die Long-States nicht mehr wie gewohnt an...

statt:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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.

[martinp876]

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