Hallo HM-Freunde,
wie in "Eröffnugsthread" zu o.g. 6fach Taster erwähnt, habe ich mir diesen gekauft und will ihn ohne "klassische" Elektroinstallation im Bad einsetztn, welches Anfang Sept. renoviert wird. Die Idee ist folgende: Tasten 1 und 2 als Taster für 2x Licht ein/aus also toggle,
Tasten 3 und 4 Lüfter aus bzw. ein bei kurzem Drücken und ein für eine bestimmte Dauer bei langem Drücken, Tasten 5 und 6 Rola runter/stop bzw. hoch/stop bei kurzem Drücken und Anfahren bestimmter Positionen bei langem Drücken.
Ich bin z.Z. beim Experimentieren mit dem Rolaaktor ohne angeschlossenen Rola.
Der WM55 und der Rolaaktor sind mit HM gepaierd und den Rola kann ich über das Webinterface so bedienen wie meine anderen schon installierten.
WM55:
define BD_T6 CUL_HM 21028D
attr BD_T6 .devInfo 060000
attr BD_T6 .stc 40
attr BD_T6 actCycle 028:00
attr BD_T6 actStatus alive
attr BD_T6 event-on-change-reading .*
attr BD_T6 expert 2_full
attr BD_T6 firmware 1.0
attr BD_T6 model HM-PB-6-WM55
attr BD_T6 peerIDs
attr BD_T6 room 004Bad
attr BD_T6 serialNr KEQ0116770
attr BD_T6 subType remote
attr BD_T6 webCmd getConfig
define FileLog_BD_T6 FileLog ./log/BD_T6-%Y.log BD_T6
attr FileLog_BD_T6 logtype text
attr FileLog_BD_T6 room CUL_HM
...
define BD_T6_Btn_05 CUL_HM 21028D05
attr BD_T6_Btn_05 model HM-PB-6-WM55
attr BD_T6_Btn_05 peerIDs 00000000,
attr BD_T6_Btn_05 room CUL_HM
define FileLog_BD_T6_Btn_05 FileLog ./log/BD_T6_Btn_05-%Y.log BD_T6_Btn_05
attr FileLog_BD_T6_Btn_05 logtype text
attr FileLog_BD_T6_Btn_05 room CUL_HM
# -----------
define BD_T6_Btn_06 CUL_HM 21028D06
attr BD_T6_Btn_06 model HM-PB-6-WM55
attr BD_T6_Btn_06 peerIDs 00000000,
attr BD_T6_Btn_06 room CUL_HM
define FileLog_BD_T6_Btn_06 FileLog ./log/BD_T6_Btn_06-%Y.log BD_T6_Btn_06
attr FileLog_BD_T6_Btn_06 logtype text
attr FileLog_BD_T6_Btn_06 room CUL_HM
BD_Rola:
define BD_Rola CUL_HM 21599C
attr BD_Rola .devInfo 010100
attr BD_Rola .stc 30
attr BD_Rola actCycle 028:00
attr BD_Rola actStatus alive
attr BD_Rola autoReadReg 3_onChange
attr BD_Rola eventMap on:Auf off:Zu 45:SoSchu
attr BD_Rola expert 2_full
attr BD_Rola firmware 1.5
attr BD_Rola fp_ETW 80,576,2,
attr BD_Rola model HM-LC-BL1-FM
attr BD_Rola peerIDs 00000000,21028D06,
attr BD_Rola room 004Bad
attr BD_Rola serialNr KEQ0094699
attr BD_Rola subType blindActuator
attr BD_Rola webCmd Auf:stop:Zu
Jetzt soll die Bedienung so sein wie an den Tastern, die man am Aktor anschließen kann:
T5 kurz: zu -> stop -> zu usw.
T6 kurz: auf-> stop -> auf usw.
außerdem
T5 lang: Position SoSchu
T6 lang: Position Sischu - ist noch nicht definiert
Ich habe die Tasten und den Aktor noch nicht gepeert und mit folgendem Code passiert das: der Aktor zieht an, fällt nach ca. 0,5s ab und zieht dann wieder an und fährt dann den Rola runter.
Wenn ich beim Runterfahren T5 wieder drücke, so stoppt der Aktor nicht sondern er fällt ab, zieht an, fällt ab und zieht wieder an und die ursprüngliche Fahrt wird fortgesetzt.
define BD_Rola_runter notify BD_T6_Btn_05 {if (Value("BD_T6_Btn_05") =~ m"Short") {fhem "set BD_Rola Zu";;}}
Da der WM55 bei jedem Tastendruck zwei Events generiert, habe ich versucht das zu filtern, was mir aber nicht gelungen ist.
2013-07-27 12:17:29 CUL_HM BD_T6 CMDs_done
2013-07-27 12:17:29 CUL_HM BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 12:17:29 CUL_HM BD_T6_Btn_05 trigger: Short_41
2013-07-27 12:17:29 CUL_HM BD_T6 BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 12:17:29 CUL_HM BD_Rola set_Zu
2013-07-27 12:17:29 CUL_HM BD_Rola set_Zu
Muss T5 bzw. dann auch T6 mit dem Aktor gepeert werden oder muss der Zustand des Aktors in das Notify mit eingebaut werden, damit der gewünschte Ab -> Stop -> Ab Zyklus zustande kommt?
Zur Rückmeldung soll dann auch später die LED jeweils grün leuchten (z.Z. nur orange bei Tastendruck) - da habe ich schon mal im Wiki drübergelesen - das wäre dann das Tüpfelchen auf dem I.
Danke für einen Denkanstoß und ein nicht zu heißes WE
Uwe
Hallo Uwe,
du kannst Sensoren und Aktoren direkt peeren oder es über FHEM notify abwickeln. Das ist diene Sache. Wenn du dich entschieden hast und jemand drüber schauen soll musst du die Info schicken.
Beim direkt peeren solltest du alle Register und peers des Aktors schicken, expert auf 2!
Ansonsten die Notifies.
Solange nicht gepeert ist und keine notifies existieren sollte der Aktor auch nicht reagieren.
ZitatWenn ich beim Runterfahren T5 wieder drücke, so stoppt der Aktor nicht sondern er fällt ab, zieht an, fällt ab und zieht wieder an und die ursprüngliche Fahrt wird fortgesetzt.
Was ist "fällt ab"? Das Relais? Stoppt also? Bitte genauer
Gruss Martin
Hallo Martin,
ich will die Steuerung über fhem abwickeln ohne den Taster mit den Aktoren direkt zu peeren.
Beim Schalten fällt das Ralais im Aktor ab bzw. die LED geht aus.
Dieses "doppelte" Schalten ist meiner Meinung nach die erste Baustelle - denn sonst würde ja der "echte" Rola jedesmal anlaufen, stoppen und wieder anlaufen.
Ich habe mal den Eventmonitor laufen lassen:
18:16:43 habe ich T5 gedrückt: Aktor an -> aus -> an
18:16:51 T5 zum Stoppen gedrückt: Aktor aus -> an -> aus -> an
18:17:09 Endposition erreicht
Events:
2013-07-27 18:16:43 CUL_HM BD_T6 CMDs_done
2013-07-27 18:16:43 CUL_HM BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 18:16:43 CUL_HM BD_T6_Btn_05 trigger: Short_70
2013-07-27 18:16:43 CUL_HM BD_T6 BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 18:16:43 CUL_HM BD_Rola set_Zu
2013-07-27 18:16:43 CUL_HM BD_Rola set_Zu
2013-07-27 18:16:43 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 18:16:43 CUL_HM BD_Rola level: 100 %
2013-07-27 18:16:43 CUL_HM BD_Rola deviceMsg: Auf (to HMLAN1)
2013-07-27 18:16:43 CUL_HM BD_Rola Auf
2013-07-27 18:16:43 CUL_HM BD_Rola motor: stop:Auf
2013-07-27 18:16:43 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 18:16:43 CUL_HM BD_Rola level: 100 %
2013-07-27 18:16:43 CUL_HM BD_Rola deviceMsg: Auf (to HMLAN1)
2013-07-27 18:16:43 CUL_HM BD_Rola Auf
2013-07-27 18:16:43 CUL_HM BD_Rola motor: down:Auf
2013-07-27 18:16:44 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 18:16:44 CUL_HM BD_Rola level: 98 %
2013-07-27 18:16:44 CUL_HM BD_Rola deviceMsg: 98 % (to HMLAN1)
2013-07-27 18:16:44 CUL_HM BD_Rola 98 %
2013-07-27 18:16:44 CUL_HM BD_Rola motor: stop:98 %
2013-07-27 18:16:44 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 18:16:44 CUL_HM BD_Rola level: 98 %
2013-07-27 18:16:44 CUL_HM BD_Rola deviceMsg: 98 % (to HMLAN1)
2013-07-27 18:16:44 CUL_HM BD_Rola 98 %
2013-07-27 18:16:44 CUL_HM BD_Rola motor: down:98 %
2013-07-27 18:16:51 CUL_HM BD_T6 CMDs_done
2013-07-27 18:16:51 CUL_HM BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 18:16:51 CUL_HM BD_T6_Btn_05 trigger: Short_71
2013-07-27 18:16:52 CUL_HM BD_T6 BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 18:16:52 CUL_HM BD_Rola set_Zu
2013-07-27 18:16:52 CUL_HM BD_Rola set_Zu
2013-07-27 18:16:52 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 18:16:52 CUL_HM BD_Rola level: 60.5 %
2013-07-27 18:16:52 CUL_HM BD_Rola deviceMsg: 60.5 % (to HMLAN1)
2013-07-27 18:16:52 CUL_HM BD_Rola 60.5 %
2013-07-27 18:16:52 CUL_HM BD_Rola motor: stop:60.5 %
2013-07-27 18:16:52 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 18:16:52 CUL_HM BD_Rola level: 60.5 %
2013-07-27 18:16:52 CUL_HM BD_Rola deviceMsg: 60.5 % (to HMLAN1)
2013-07-27 18:16:52 CUL_HM BD_Rola 60.5 %
2013-07-27 18:16:52 CUL_HM BD_Rola motor: down:60.5 %
2013-07-27 18:16:52 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 18:16:52 CUL_HM BD_Rola level: 58.5 %
2013-07-27 18:16:52 CUL_HM BD_Rola deviceMsg: 58.5 % (to HMLAN1)
2013-07-27 18:16:52 CUL_HM BD_Rola 58.5 %
2013-07-27 18:16:52 CUL_HM BD_Rola motor: stop:58.5 %
2013-07-27 18:16:53 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 18:16:53 CUL_HM BD_Rola level: 58.5 %
2013-07-27 18:16:53 CUL_HM BD_Rola deviceMsg: 58.5 % (to HMLAN1)
2013-07-27 18:16:53 CUL_HM BD_Rola 58.5 %
2013-07-27 18:16:53 CUL_HM BD_Rola motor: down:58.5 %
2013-07-27 18:17:09 CUL_HM BD_Rola level: 0 %
2013-07-27 18:17:09 CUL_HM BD_Rola deviceMsg: Zu (to broadcast)
2013-07-27 18:17:09 CUL_HM BD_Rola Zu
2013-07-27 18:17:09 CUL_HM BD_Rola motor: stop:Zu
Mein notify sieht so aus:
define BD_Rola_runter notify BD_T6_Btn_05 {if ((Value("BD_T6_Btn_05") eq ~ m".Short") && (ReadingsVal("BD_Rola","motor","noak")=~ m".down")){fhem "set BD_Rola stop";;}else {fhem "set BD_Rola Zu";;}}
Das ist sicher zu kompliziert (try and error), die Abfrage des Motorstatus' soll eigentlich den Stopbefehl auslösen...was er bis jetzt nicht tut.
Oder ist es besser, den Zustand des Aktors in einer Variable zu spiegeln?
Die Auswertung der Triggeranzahl (gerade/ungerade - wird in einem anderen Thread empfohlen) erscheint mir nicht so zielführend, da ich schon bemerkt habe, dass nicht immer der Triggerwert um 1 hochgezählt wird.
Uwe
ich habe nur grob drüber geschaut, ich denke das Problem ist
Zitatdefine BD_Rola_runter notify BD_T6_Btn_05 ...
Das Notify wird bei jedem gemeldeten Event des Btn5 ausgewertet. Ein Tastendruck hat mehrere Events!!
Zitat2013-07-27 18:16:43 CUL_HM BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 18:16:43 CUL_HM BD_T6_Btn_05 trigger: Short_70
in deinem Fall nur 2, glück gehabt.
Filtere gleich zu beginn immer auf EIN event des Schalters.
define BD_Rola_runter notify BD_T6_Btn_05:trigger:Short.*also
define BD_Rola_runter notify BD_T6_Btn_05:trigger:Short.* {if ((ReadingsVal("BD_Rola","motor","")=~ m".down")){fhem "set BD_Rola stop";;}else {fhem "set BD_Rola Zu";;}}
besser?
Ich habe erstmal die einfache Variante genommen:
define BD_Rola_runter notify BD_T6_Btn_05:trigger:.Short.* set BD_Rola Zu
Und dabei noch einen Punkt eingefügt - jetzt wird beim Tasten der Aktor wie gewünscht nur eingeschaltet. Das das etwas mit den "reinkommenden" Events und deren Filterung zu tun hatte habe ich mir schon gedacht. Aber bei der Notation hat es dann bei mir aufgehört...
Nun soll der Rola beim nächsten Tastendruck wieder stoppen und beim übernächsten weiter schließen usw..
Beim 2. Tastendruck fällt der Aktor jetzt nur einmal ab und zieht dann wieder an (20:09:28).
2013-07-27 20:09:24 CUL_HM BD_T6 CMDs_done
2013-07-27 20:09:24 CUL_HM BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 20:09:24 CUL_HM BD_T6_Btn_05 trigger: Short_86
2013-07-27 20:09:24 CUL_HM BD_T6 BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 20:09:25 CUL_HM BD_Rola set_Zu
2013-07-27 20:09:25 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 20:09:25 CUL_HM BD_Rola level: 100 %
2013-07-27 20:09:25 CUL_HM BD_Rola deviceMsg: Auf (to HMLAN1)
2013-07-27 20:09:25 CUL_HM BD_Rola Auf
2013-07-27 20:09:25 CUL_HM BD_Rola motor: stop:Auf
2013-07-27 20:09:25 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 20:09:25 CUL_HM BD_Rola level: 100 %
2013-07-27 20:09:25 CUL_HM BD_Rola deviceMsg: Auf (to HMLAN1)
2013-07-27 20:09:25 CUL_HM BD_Rola Auf
2013-07-27 20:09:25 CUL_HM BD_Rola motor: down:Auf
2013-07-27 20:09:27 CUL_HM BD_T6 CMDs_done
2013-07-27 20:09:27 CUL_HM BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 20:09:27 CUL_HM BD_T6_Btn_05 trigger: Short_87
2013-07-27 20:09:27 CUL_HM BD_T6 BD_T6_Btn_05 Short (to HMLAN1)
2013-07-27 20:09:28 CUL_HM BD_Rola set_Zu
2013-07-27 20:09:28 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 20:09:28 CUL_HM BD_Rola level: 87 %
2013-07-27 20:09:28 CUL_HM BD_Rola deviceMsg: 87 % (to HMLAN1)
2013-07-27 20:09:28 CUL_HM BD_Rola 87 %
2013-07-27 20:09:28 CUL_HM BD_Rola motor: stop:87 %
2013-07-27 20:09:28 CUL_HM BD_Rola CommandAccepted: yes
2013-07-27 20:09:28 CUL_HM BD_Rola level: 87 %
2013-07-27 20:09:28 CUL_HM BD_Rola deviceMsg: 87 % (to HMLAN1)
2013-07-27 20:09:28 CUL_HM BD_Rola 87 %
2013-07-27 20:09:28 CUL_HM BD_Rola motor: down:87 %
2013-07-27 20:09:50 CUL_HM BD_Rola level: 0 %
2013-07-27 20:09:50 CUL_HM BD_Rola deviceMsg: Zu (to broadcast)
2013-07-27 20:09:50 CUL_HM BD_Rola Zu
2013-07-27 20:09:50 CUL_HM BD_Rola motor: stop:Zu
Jetzt kommt also die Verknüpfung mit dem Fahrstatus des Rola. Ich werde mal versuchen, das hin zu bekommen.
Auf Deutsch soll es so sein: Bei T5 und Rola = stop => Rola runter;
bei T5 und Rola fährt runter => stop.
Geht das in einem notify und ohne Speicherung des Rolastatus in einer extra Variable?
Ich werde mal morgen darüber grübeln und hoffe, etwas weiter zu kommen :-)
Für heute reich'ts erst mal - die Hitze...
Danke erstmal Martin
Uwe
nun du musst also nachsehen, ob der Motor fährt. So etwas hattest doch schon, im Notify das Reading motor abtesten.
Du musst immer beachten dass es, wenn du es in FHEM machst delays zu berücksichtigen sind. Das Device muss erst die Aenderung melden,... wenn du also schnell hintereinander drückst kann es sein, dass es nicht klappt.
Besser funktioniert es im Device, also mit direktem Peering. Da entscheidet das Device - und das ist immer aktuell.
Ansonsten baue das if ins notify mit der Abfrage aus motor "stop".
Oder was soll der Taster tun, wenn der Motor hoch fährt?
Gruss Martin
Guten Morgen Martin,
OT: hast Du noch ein Leben neben fhem bzw. HM?
Das notify sieht jetzt so aus und ich vermute, dass die Abfragesyntax nicht ganz astrein ist:
define BD_Rola_runter notify BD_T6_Btn_05:trigger:.Short.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") eq "stop:*")){fhem "set BD_Rola Zu";;}else {fhem "set BD_Rola stop";;}}
Der "Stop"-Befehl wird immer ausgeführt sowohl wenn der Rola hoch- als auch runter fährt und auch wenn er steht. D.H. ich habe die Abfrage noch nicht vollständig hinbekommen.
Im log kommen z.b. folgende Aussagen:
2013.07.28 11:17:29 1: Motor ist stop:57.5 %
2013.07.28 11:17:46 1: Motor ist up:65 %
Der Stopbefehl soll immer ausgeführt werden, egal ob der Rola gerade runter oder hoch fährt; der Fahrbefehl nur aus dem Stop heraus.
Für die Taste 6 will ich dann das gleiche für die Gegenrichtung programmieren.
Ich habe schon einige Abfragevarianten durchprobiert, aber am Ergebnis, dass der Fahrbefehl nicht ausgeführt wird hat sich nichts geändert.
Uwe
Ergänzung, ich habe das notify jetzt so und ... es funzt juhu!
define BD_Rola_runter notify BD_T6_Btn_05:trigger:.Short.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") =~ m /stop/)){fhem "set BD_Rola Zu";;}else {fhem "set BD_Rola stop";;}}
Intensive Suche im Forum brachte mich auf diese Abfrageart (bin nicht wirklich ein Regexpressions Experte). Vielleicht geht das noch einfacher - aber erstmal bin ich zufrieden, dass ich es mit Martins Hilfe geschafft habe.
Wie wäre denn eine direkte Verknüpfung - nach peering - von Rola und Taste, muss man da nicht in "allen" möglichen Registern Werte setzten bzw. dann abfragen? Ich glaube, dass das die "Hohe Schule" ist und ich das später evtl. angehen würde. Obwohl ein Vergleich beider Methoden bei der identischen Anwendung mal interessant wäre :-)
Ich werde jetzt noch die Taste 6 implementieren und die Taster 1 und 2 für das Licht angehen - ich denke mit dem o.g. notify bekomme ich das hin.
Schönen Sonntag, ich werde berichten (oder um Hilfe rufen).
Uwe
ja, mit den registern ist das so eine Sache. Daher arbeite ich an einer Vereinfachung - ich habe es templates genannt. Ich hoffe, dass User imlaufe der Zeit templates definieren und dokumentieren. evtl in wiki.
Standart für einen Rollo waere (bei mir so)
1 Button fährt noch
1 Button fährt runter
kurz druck fährt bis entanschlag
lang druck fährt bis loslassen
wenn der rollo fährt soll ein druck, egal welcher, die fahrt stoppen.
Ist dies was du willst? Da habe ich dann schon ein template, kann ich dir erklären (und werbung machen...)
Gruss Martin
Hallo Martin,
Du bist immer einen Schritt voraus :-)
Die Idee mit den Templates hat was - das wäre dann sozusagen die Verbindung von fhem zu den HM-Teilen und jedes Template hat eine bestimmte Funktion, man muss dann nur noch seine eigenen Bezeichnungen einsetzten - ich hoffe, dass ich das richtig interpretiere.
Deine Idee mit dem Rollotemplate wird sicher die meisten freuen und evtl. kann man daraus ja noch weitere ableiten?
Mein Ansatz für den seit gestern hier bearbeiteten Fall war ja etwas anders - aber da hat ja jeder so seine Vorstellungen:
T5kurz: runter/stop/runter
T6kurz: hoch/stop/hoch
T5lang: eine def. Position anfahren (bei mir SiSchu - ca. 10%)
T6lang: eine andere def. Pos. anfahren (SoSchu - ca. 50%)
Nebenbei habe ich die Steuerung "hinbekommen", allerdings hat sie noch einen "Schönheitsfehler": Wenn ich die T5 bzw. T6 für "Long" zu lange drücke, setzt so eine Art "Autorepeat" ein und es werden wieder mehrere Events generiert und der Aktor schaltet wieder mehrmals ein und aus bis er das Kommando ausführt und die jeweilige Position anfährt.
define BD_Rola_runter notify BD_T6_Btn_05:trigger:.Short.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") =~ m /stop/)){fhem "set BD_Rola Zu";;}else {fhem "set BD_Rola stop";;}}
attr BD_Rola_runter room 004Bad
define BD_Rola_hoch notify BD_T6_Btn_06:trigger:.Short.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") =~ m /stop/)){fhem "set BD_Rola Auf";;}else {fhem "set BD_Rola stop";;}}
attr BD_Rola_hoch room 004Bad
define BD_Rola_SoSchu notify BD_T6_Btn_06:trigger:.Long.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") =~ m /stop/)){fhem "set BD_Rola SoSchu";;}else {fhem "set BD_Rola stop";;}}
attr BD_Rola_SoSchu room 004Bad
define BD_Rola_SiSchu notify BD_T6_Btn_05:trigger:.Long.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") =~ m /stop/)){fhem "set BD_Rola SiSchu";;}else {fhem "set BD_Rola stop";;}}
attr BD_Rola_SiSchu room 004Bad
Das Pattern für die T5 und T6 "Long" ist ja wie bei den kurzen, deshalb bin ich davon ausgegangen, dass auch nur ein Event ausgewertet wird. Oder gibt es da Register, in denen dieser Autorepeat eingestellt werden kann?
Uwe
Hi,
templates sind in HMinfo vorgesehen, also einen Level über CUL_HM.
Also ein
define hm HMinfo
ich habe einmal einige wenige templates definiert. Die Idee ist, dass ich nicht alle templates definiere sondern der User eigene machen kann.
Es gibt folgende Funktionen
set hm templateList # alle aktuellen templates
set hm templateList <templateName> # zeigt an, was dieses Template aendern will
set hm templateDef ... # hier kann man templates selbst definieren oder auch templates löschen
set hm templateSet ... # programmiert ein Template in ein Device
set hm templateChk ... # prüft, ob ein device einem template entspricht
Allgemein: Templates programmieren nicht ein ganzes Device sondern nur einen Teil, der eben relevant ist. In den meisten Fällen wird man wohl die Funktion eines peers programmieren wollen. Hier kann man noch nach langen und Kurzem Tastendruck unterscheiden. Sprich man kann ein template anwenden auf channel->peer->lang oder channel->peer->kurz. Wenn man will das gleich template.
In deinem Fall brauchst du 4 templates
hoch Kurz
hoch lang
runter kurz
runter lang
Diese habe ich als eine der wenigen Beispiele schon im Code.
BlStopDnLg
BlStopDnSh
BlStopUpLg
BlStopUpSh
Also musst du
set hm templateSet BD_Rola BlStopDnLg BD_T6_Btn_05:long
set hm templateSet BD_Rola BlStopDnSh BD_T6_Btn_05:short
set hm templateSet BD_Rola BlStopUpLg BD_T6_Btn_06:long
set hm templateSet BD_Rola BlStopUpSh BD_T6_Btn_06:short
ausführen.
Achtung: Das Template übernimmt nicht das peering. Das musst du vorher machen.
Wie gesagt, die Idee ist, dass User gute Templates veröffentlichen (wiki) und andere diese dann einfach kopieren können.
Zu deinem "long": Das ist klar. Die Remote sendet den Trigger alle .4sec (oder so). Du musst als nur den Ersten nehmen.
BD_T6_Btn_05:trigger:.Long.1-.*
Gruss Martin
Der Vorschlag zum "Long" funzt nicht, ich habe noch etwas herumprobiert, z.B. ".-" nach der 1 weggelassen oder nur "-" weggelassen. Leider haut es noch nicht hin. Je nachdem kommt der "Autorepeat" immer noch oder es wird gar nichts mehr geschaltet.
Hast Du die Templates schon eingepflegt, oder muss man das eintippen? Dann muss ich aber in diesem Fall alle betroffenen Tasten mit den jeweiligen Aktoren peeren, oder?
OT: Weißt Du, wer das Wiki zu den beiden WM55 verfasst hat? Ich wollte die Rückmeldungsfunktion einbauen, habe es aber nicht geschafft, oder müssen dafür auch die Tasten mit den Aktoren gepeert sein? Im Wiki steht ja nur, dass man mit dem erstellten virtuellen Aktor peeren muss.
Uwe
ja, korrekt. Du must hier state nehmen, bei trigger ist der Zähler nicht drin. Also
define BD_Rola_SoSchu notify BD_T6_Btn_06:state:.Long.1-.*
state ist ein wenig andes, hier die Trigger.
FB2_Btn_03 Long 3-A240- (to LANIf1)
FB2_Btn_03 trigger: Long_40
Du musst '1-' nehmen sonst kann es, wenn man lange drückt - auch
FB2_Btn_03 Long 10-A240- (to LANIf1)
FB2_Btn_03 Long 11-A240- (to LANIf1)
auslösen...
templates:
wie gesagt, ich habe diese als Beispiele drin. Andere werden nicht so schnell kommen, dann würde ich dir es zusenden - oder jemand erarbeitet welche (eigentlich das Ziel).
Was drin ist kannst du nachsehen: templateList - und auch die Details, wenn du willst.
Wiki bin ich nur selten drin - kann ich nicht sagen merke es mir auch nicht wirklich :-(
Bei Templates habe ich heute noch etwas getunt.
Gruss Martin
Wg. des Wiki habe ich an Markus geschrieben.
Die Umstellung auf die Auswertung des state an Stelle des trigger hat leider nichts gebracht. Von der Logik her ist Dein Vorschlag für mich nachvollziehbar - aber offenbar nicht für das notify - hm.
Die templates nehme ich mir später vor, erst soll der lange Tastendruck mal funktionieren. Die templates wären sicher sowieso einen neuen Thread wert, damit es hier nicht unter geht (ist ja etwas OT).
Uwe
ja, state aus meiner sicht immer ein Problem, da das reading keinen trigger auslöst.
Ich stolpere jedesmal drüber...
Daher musst du auf den Inhalt triggern - in der hoffnung, dass es den so nicht noch einmal gibt. Geht in diesem Fall:
define BD_Rola_SoSchu notify BD_T6_Btn_06.Long.1-.*
das '-' macht es einzig und unterscheidet es von 'trigger'.
Gruss Martin
Guten Morgen,
ich habe jetzt beide notifys umgestellt, der T5 arbeitet wie gewünscht, aber der T6 lässt den Aktor immer noch anziehen -> abfallen -> anziehen. Beide notifys sind aber völlig identisch...
define BD_Rola_SoSchu notify BD_T6_Btn_06.Long.1-.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") =~ m /stop/)){fhem "set BD_Rola SoSchu";;}else {fhem "set BD_Rola stop";;}}
attr BD_Rola_SoSchu room 004Bad
define BD_Rola_SiSchu notify BD_T6_Btn_05.Long.1-.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") =~ m /stop/)){fhem "set BD_Rola SiSchu";;}else {fhem "set BD_Rola stop";;}}
attr BD_Rola_SiSchu room 004Bad
Ich habe auch mal die Zeit für longPress in beiden Registern auf 0.3 s gestellt - das dürfte aber damit nichts zu tun haben, oder?
Uwe
beim Sensor (remote) ist es die Rate mit der die Messages an den Aktor gesendet werden. Ist hier wurscht. Bei einem dimmer oder schlimmer Rollo ist das wichtig. Der Rollo soll bei einer ong message so lange fahren bis die nächste kommt. Wenn der also nur .3sec fährt und der Trigger alle 1 sec kommt wird es ruckeln. Wenn der trigger alle .3sec kommt und der Rollo 1 sec je triggerfährt, fahrt er nach dem loslassen noch 1 sec weiter. Die gewählen defaults von HM sind abgestimmt und sollten passen.
im Notify fällt mir jetzt nichts auf. Kannst du einmal aufzeichnen welchen events alle kommen und nachsehen, ob mehrfach getriggert wird? Wieviele logs werden denbei Button6 geschrieben?
Gruss Martin
Hier die Events:
T5:
2013-07-30 11:19:52 CUL_HM BD_T6_Btn_05 Long 1-8440- (to HMLAN1)
2013-07-30 11:19:52 CUL_HM BD_T6_Btn_05 trigger: Long_212
2013-07-30 11:19:53 CUL_HM BD_T6 BD_T6_Btn_05 Long 1-8440- (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_Rola level: SoSchu %
2013-07-30 11:19:53 CUL_HM BD_Rola deviceMsg: SoSchu % (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_Rola SoSchu %
2013-07-30 11:19:53 CUL_HM BD_Rola motor: stop:SoSchu %
2013-07-30 11:19:53 CUL_HM BD_T6_Btn_05 Long 2-A240- (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_T6_Btn_05 trigger: Long_212
2013-07-30 11:19:53 CUL_HM BD_T6 BD_T6_Btn_05 Long 2-A240- (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_Rola level: SoSchu %
2013-07-30 11:19:53 CUL_HM BD_Rola deviceMsg: SoSchu % (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_Rola SoSchu %
2013-07-30 11:19:53 CUL_HM BD_Rola motor: down:SoSchu %
2013-07-30 11:20:03 CUL_HM BD_Rola level: SiSchu %
2013-07-30 11:20:03 CUL_HM BD_Rola deviceMsg: SiSchu % (to broadcast)
2013-07-30 11:20:03 CUL_HM BD_Rola SiSchu %
2013-07-30 11:20:03 CUL_HM BD_Rola motor: stop:SiSchu %
T6:
2013-07-30 11:21:03 CUL_HM BD_T6_Btn_06 Long 1-8440- (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_T6_Btn_06 trigger: Long_8
2013-07-30 11:21:03 CUL_HM BD_T6 BD_T6_Btn_06 Long 1-8440- (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_Rola level: 9.5 %
2013-07-30 11:21:03 CUL_HM BD_Rola deviceMsg: 9.5 % (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_Rola 9.5 %
2013-07-30 11:21:03 CUL_HM BD_Rola motor: stop:9.5 %
2013-07-30 11:21:03 CUL_HM BD_T6_Btn_06 Long 2-A240- (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_T6_Btn_06 trigger: Long_8
2013-07-30 11:21:03 CUL_HM BD_T6 BD_T6_Btn_06 Long 2-A240- (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_Rola level: 9.5 %
2013-07-30 11:21:03 CUL_HM BD_Rola deviceMsg: 9.5 % (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_Rola 9.5 %
2013-07-30 11:21:03 CUL_HM BD_Rola motor: up:9.5 %
2013-07-30 11:21:13 CUL_HM BD_Rola level: SoSchu %
2013-07-30 11:21:13 CUL_HM BD_Rola deviceMsg: SoSchu % (to broadcast)
2013-07-30 11:21:13 CUL_HM BD_Rola SoSchu %
2013-07-30 11:21:13 CUL_HM BD_Rola motor: stop:SoSchu %
Ich kann keinen Unterschied erkennen.
da fällt mir nur ein, dass der Trigger zum Device und zum Button kommt. du kannst also
BD_Rola_SoSchu notify ^BD_T6_Btn_06.Long.1-.*
nutzen. Dann sollte er des Device nicht mehr kommen (falls es dies war)
Gruss Martin
Ich glaube, es klappt jetzt. Die Änderung mit "^" vor dem T6 hatte auch nichts am Verhalten geändert.
Dann habe ich mich nochmal mit den einzelnen Komponenten befasst und festgestellt, dass T6 und der BD_Rola "halb" gepeert waren, d.h. beim Rola war das Peering zur T6 eigetragen und bei T6 nichts - k.A. wie das kam, möglicherweise schon beim Anlernen irgendwie? Ich habe das Peering gelöscht und jetzt funzt auch T6 sowohl mit der Methode von jetzt als auch mit
define BD_Rola_SoSchu notify BD_T6_Btn_06.Long.1-.*
Habe jetzt wieder diesen Code für die beiden Taste drin. Dass das halbe Peering die Verständigung stört, obwohl ich ja keine direkte Funktion zwischen T6 und Rola programmiert habe ist aber komisch. Ich habe höchstens eine Erklärung in der Bedienungsanleitung S.20 gefunden: die Tasten sind für direktes Peering vorbelegt - T6 mit "Rola Hoch". Möglicherweise haben sich die Befehle über fhem mit der Werkseinstellung überlagert. Wenn ja, dann haben wir wieder was gelernt.-)
Danke für Deine Geduld und Hilfe, Martin, was würden wir ohne Dich machen.
Uwe
Hallo Uwe,
kleine Erklärung zum halben peering:
peeren kann man im Prinzip immer "einzeln", also Aktor und Sensor getrennt. In FHEM ist es ein Kommandos, aber intern2 getrennte Abläufe. FHEM erlaubt auch, dass man nur eine Seite ausführt (remote|actor|both).
Dem Aktor ist es egal ob der Sensor gepeert ist - wenn er gepeert ist und ein trigger vom Sensor kommt wird die Aktion gestartet.
Der sensor schickt immer seine Trigger, egal ob er gepeert ist oder nicht. Wenn er gepeert ist will er von JEDEM peer dieses Kanals ein ACK. Wenn er es nicht bekommt wird der trigger wiederholt - für jeden Aktor. Wenn er immer noch keinen bekommt leuchtet er rot, sonst Grün. Wenn er keinen Peer hat wird nichts wiederholt und er leuchtet orange.
Falls du beide gepeert hattest wird der peer bei reset gelöscht - aber nur in dem Device, das du resetest.
Die Peerliste rehältst du durch getConfig (oder autoReadReg) und eine Übersicht sowie ein crosscheck der Peers kannst du mit HMinfo machen
Gruss Martin
Hallo Martin, danke für die "aufklärenden" Worte. Da hat also der Taster auf ein ACK des Aktors gewartet und dann das Kommando wiederholt. Ich kann es jetzt nicht mehr nachvollziehen, da ich gestern das unerwünschte Peering gelöscht habe. Aber jetzt ist alles gut und es fehlen nur noch die Geräte an den Aktoren - dann ist es perfekt!
Also nochmals Danke!!
Uwe
ZitatDa hat also der Taster auf ein ACK des Aktors gewartet und dann das Kommando wiederholt
denke ich nicht.
Der Aktor war gepeert,der Taster evtl nicht (oder doch, kann sogar noch sein, musst du prüfen).
Der Taster sendet (egal, ob gepeert),der Aktor (gepeert!!) verarbeitet den Trigger.
Sollte der Taster wiederholen wird der Aktor NICHT noch einmal triggern,da dieser erkennt, dass es eine Wiederholung ist. Er würde nur das ACK wiederholen, nicht den Schaltvorgang.
Wichtiges Detail, wenn man den Mechanismus verstehen will
Gruss Martin
Nun mal was für's Auge:
Der in diesem Thread beschriebene 6-fach-Taster in Echt. Die Bilder habe ich aus den fhem-icons kopiert und skaliert.
Leider ist die Druckvorlage von eq3 zum Bedrucken nicht geeignet, sie hat das selbe Layout wie die beigelegten Vorlagen.
Ich habe die Felder vermessen und in der Tabellenkalkulation die Felder entsprechend eingestellt, dann die Bilder skaliert, angeordnet und dann in den Hintergrund verschoben und dann die Beschriftung in fett und 12-Punkt-Schrift.
Mir gefällt's.
Uwe