Langen Tastendruck bei HM-PBI-4-FM (Tasterschnittstelle 4fach) auswerten

[Zorin]

Hallo allerseits,

ich habe inzwischen einige HM-PBI-4-FM im Einsatz. Ich würde nun gerne den langen Tastendruck auswerten.
Das Log sieht dann z.B. folgendermaßen aus:
2013-01-13_13:46:01 BZ.Schalter1 BZ.Schalter1.CH2 Long 2-8440- (to broadcast)
2013-01-13_13:46:02 BZ.Schalter1 battery: ok
2013-01-13_13:46:02 BZ.Schalter1 BZ.Schalter1.CH2 Long 3-8440- (to broadcast)
2013-01-13_13:46:02 BZ.Schalter1 battery: ok
2013-01-13_13:46:02 BZ.Schalter1 BZ.Schalter1.CH2 Long 4-8440- (to broadcast)
2013-01-13_13:46:02 BZ.Schalter1 battery: ok
2013-01-13_13:46:02 BZ.Schalter1 BZ.Schalter1.CH2 Long 5-8440- (to broadcast)
2013-01-13_13:46:02 BZ.Schalter1 battery: ok
2013-01-13_13:46:02 BZ.Schalter1 BZ.Schalter1.CH2 Long 6-8440- (to broadcast)
2013-01-13_13:46:03 BZ.Schalter1 battery: ok
2013-01-13_13:46:03 BZ.Schalter1 BZ.Schalter1.CH2 Long 7-8440- (to broadcast)

Wie kann ich den Long Tastendruck z.B. mit einem Notify auswerten ?

Vielen Dank für die Hilfe...

Grüße,

Zorin

[PowerDiz]

Hallo,
der Log sieht bei mir für kurze und lange Tastenbedienung so aus:

2013-01-12_16:45:53 Alarm_RC_3 Alarm_RC_3_Btn_01 Short (to HMLAN1)
2013-01-12_16:48:10 Alarm_RC_3 battery: ok
2013-01-12_16:48:10 Alarm_RC_3 Alarm_RC_3_Btn_01 Long 2-8440- (to HMLAN1)
2013-01-12_16:48:10 Alarm_RC_3 battery: ok
2013-01-12_16:48:10 Alarm_RC_3 Alarm_RC_3_Btn_01 Long 3-8440- (to HMLAN1)
2013-01-12_16:48:10 Alarm_RC_3 battery: ok
2013-01-12_16:48:10 Alarm_RC_3 Alarm_RC_3_Btn_01 Long 4-8440- (to HMLAN1)
2013-01-12_16:48:11 Alarm_RC_3 battery: ok
2013-01-12_16:48:11 Alarm_RC_3 Alarm_RC_3_Btn_01 Long 5-8440- (to HMLAN1)
2013-01-12_16:48:11 Alarm_RC_3 battery: ok
2013-01-12_16:48:11 Alarm_RC_3 Alarm_RC_3_Btn_01 LongRelease 6-A040- (to HMLAN1)

Ich werte so aus:
define Alarm_RC_3Btn_1_short notify Alarm_RC_3:Alarm_RC_3_Btn_01.* {if ("%"  =~ "Short") {AlarmanlageOn("RC3")}}
define Alarm_RC_3Btn_1_long notify Alarm_RC_3:Alarm_RC_3_Btn_01.* {if ("%"  =~ "LongRelease") {AlarmanlageOff("RC3")}}


Dabei verwende ich nur das release nach einem langen Tastenruck, weil ich keine anderen zwischen Ereignisse benötige.
Man könnte auch in deinem Fall auf die "8440" im String suchen, wenn Du mehrere Ereignisse benötigst.

Ich hoffe das hilft was weiter.

Gruß,
Dieter

[Zorin]

Hallo Dieter, alle,

vielen Dank, das hat mir die richtige Richtung gezeigt.
Da ich lieber "in FHEM" blieben wollte, sieht meine Lösung jetzt so aus:

define BZ.Schalter1.CH2-AllOff notify BZ.Schalter1:BZ.Schalter1.CH2.Long.* set LAMPE_1 off

Ich bekomme übrigens gar nicht den LongRelease im Log.
Ich vermute aber, das liegt daran, dass ich den Schalter nicht mit meinem HMLAN gepairt habe.

Grüße,

Zorin

[snoop]

Hallo zusammen,

zum Thema langen und kurzen Tastendruck würde ich mich gerne einklinken.
Ich habe auch ein Taster und eine Fernbedienung und würde gerne folgendes realisieren:

Bei einen kurzen Tastendruck, wobei nach diversen Tests meine Definition für "ein kurzer Tastendruck" wie folgt aussieht:
Ein Status zwischen: "Btn_01 Short und Btn_01 Long 3-8440"
Ein langer Tastendruck: Alles was über Btn_01 Long 3-8440 liegt.

Kann mich jemand bei der Umsetzung unterstützen. Meine erste Idee ist den Status zu splitten (falls erforderlich den wert in INT Wert konvertieren) und dann in etwa folgende Abfrage generieren:

Wenn short und Long kleiner/gleich 3 dann schalte Lampe1 on
Wenn nicht short und Long größer 3 dann schalte Lampe1,Lampe2,Lampe3;Lampe4 on

Bei mir scheitert es momentan daran, dass ich in Perl noch nicht so fit bin.

Vielen Dank für eure Rückmeldungen im Voraus.

Grüße
Arthur

[snoop]

Hallo zusammen,

also ich habe ein wenig experimentiert und das ist das Ergebnis:

Die Lösung für die o.g. Lösung könnte so aussehen:

.*Taster_4_1:Taster_4_1_Btn_01.* {my @@a = split(" ", $value{Taster_4_1});;if ($a[0] eq "Taster_4_1_Btn_01" && $a[1] eq "Long" && int($a[2])==3){fhem"set GA_Tor_Sw_1_01 on-for-timer 3"}}

Meine Frage ist, ist das vom Grundsatz ok?
Zweitens: bei dem o.g. code gibt es noch ein Problem.(Ich bin neu in FHEM unterwegs, seit bitte nicht streng mit mir.)
Nun zur Erklärung:
Wenn ich den Taster drücke, sendet er permanent ein Signal an die Zentrale, sobald "Long" und "Count=3" erreicht ist geht die Lampe an.
Wenn ich nun die Taste länger als 3 counts gedrückt halte geht die Lampe dennoch an -> was nicht gewollt ist.

Gibt es eine Möglichkeit dies script technisch abzufangen?
Danke.

Viele Grüße
Arthur

[martinp876]

Hallo Arthur

Wenn ich nun die Taste länger als 3 counts gedrückt halte geht die Lampe dennoch an -> was nicht gewollt ist.

Gibt es eine Möglichkeit dies script technisch abzufangen?

denke schon. ist aber die Frage, was du willst - und es wird etwas kompliziert.
Du kannst ja auf 'Release' warten und nur schalten, wenn Release UND 3 im trigger steht.

Jetzt brauchst du also erst einmal Release, dass kommt nur, wenn dein remote-button mit einem Aktor gepeert ist (achtung Anfaengerfehler: pair ist nicht gleich peer! peers werden mit devicepair angelegt. hat nichts mit der Zentrale an sich zu tun).

Nachdem du aber nicht vor hast, deinen Aktor und den Button direkt zu peeren brauchst du also ein Plazebo. Hier wuerde  ich einen virtuellen Aktor nehmen, also eine FHEM-emulation.
Details zu den Befehlen im commandref nachlesen

1) anlegen eines Virtuellen Aktors
define va CUL_HM 200000
set va virtual 1
rename va_Btn1 vaAct1

2) peeren
set BZ.Schalter1.CH2 devicepair 0 vaAct1 single
=> config am BZ.Schalter1 ausloesen um die Kommandos abzuschicken

3) peering pruefen
set BZ.Schalter1 getconfig
=> config am BZ.Schalter1 ausloesen um die Kommandos abzuschicken
=> die readings peerList pruefen, das sollten die schalter eingebaut sein

===> jetzt sollte
- bei langem druecken ein 'release' kommen
- kein to broadcast sondern ein 'to vaAct1' kommen
- fhem den Trigger des BZ.Schalter quittieren
- ein pseudozustand des schalters in FHEM unter vaAct1 mitgefuehrt werden (readings...)

Nun sollte das parsen etwas einfacher sein, hoffe ich

Gruss
Martin

[snoop]

Hallo Martin,

danke für deine ausführliche Rückmeldung.
Ich denke, dass ich das vom Ansatz verstanden habe - Tests folgen.
Nein, richtig erkannt - möchte die Aktoren nicht an die Fernbedienung/Taster peeren - gut erkannt.

Eine Frage habe ich dazu: Mit welchen Einschränkungen - durch die Kaskade (nenne es einfach mal so) "virtueller Aktor" - muss ich rechnen.
Wie sieht es mit der Performance, von FHEM in verbindung mit HMLAN und FritzBox, aus?

Meine Idee ist es die 4 Tasten Fernbedienung mit möglichst vielen Funktionen auszustatten (soll natürlich noch nutzbar sein).
Das Vorhaben sieht wie folgt aus:

Btn1 (short/long aber nicht länger als 2/3 counts) = Fassadenbeleuchtung Strasse toggel
Btn2 (short/long aber nicht länger als 2/3 counts) = Fassadenbeleuchtung Eingang toggel
Btn3 (short/long aber nicht länger als 2/3 counts) = Fassadenbeleuchtung Terrasse toggel
Btn4 (short/long aber nicht länger als 2/3 counts) = Fassadenbeleuchtung Garten toggel

Btn1 (long länger als 2/3 counts) = Gesamte Fassadenbeleuchtung an
Btn2 (long länger als 2/3 counts) = Gesamte Fassadenbeleuchtung aus

Btn3 (long länger als 2/3 counts) = Fassadenbeleuchtung Terrasse an, Garagentor auf, Garagenbeleuchtung an
Btn4 (long länger als 2/3 counts) = Fassadenbeleuchtung Terrasse aus, Garagentor aus, Garagenbeleuchtung aus

Ich hoffe die Beschreibung hilft ein wenig bei der Einschätzung.

Vielen Dank.
Arthur

[snoop]

Hallo Martin,

ok, ich habe es getestet - das läuft soweit - jetzt habe ich aber das Thema, dass ich nicht weiss wann ein short_Release/long_Release erfolgt ist.

Mein Plan ist es zu definieren, dass nach 1-3 sek.(2/3Counts?) eine andere Aktion ausgeführt wird als bei einen Tastendruck unter den zuvor genannten Werten (also short und unter 1-3sek.(2/3Counts?).

P.S: Die Readings: state und virtActState verwirren mich auch - die Werte springen hin und her bei einem langen Tastendruck. Hatte gehofft, dass dieser bei "gedrückt" = on und beim loslassen "release" = off ist? Na,ja...

Danke
Viele Grüße
Arthur

[martinp876]

Hallo Arthur

jetzt habe ich aber das Thema, dass ich nicht weiss wann ein short_Release/long_Release erfolgt ist.

ein short-release gibt es nicht

Mein Plan ist es zu definieren, dass nach 1-3 sek.(2/3Counts?) eine andere Aktion ausgeführt wird als bei einen Tastendruck unter den zuvor genannten Werten (also short und unter 1-3sek.(2/3Counts?).

Wiederholungen gibt es nur be long - klar.
die Wiederholrate ist einstellbar in der remote. Ich denke default ist 0,4sec. damit solltest du rechnen koennen.
Die Einstellungen kannst du auslesen und aendern - musst aber config druecken.

P.S: Die Readings: state und virtActState verwirren mich auch - die Werte springen hin und her bei einem langen Tastendruck. Hatte gehofft, dass dieser bei "gedrückt" = on und beim loslassen "release" = off ist? Na,ja...

Da hast du recht. War ein quick and dirty - ein bischen zu viel dirty vielleicht? Mal sehen - evtl werte ich nur den release fuer den Status aus.

Gruss
Martin

[snoop]

Hallo Martin,

hmmm "short_Release" gibt es nicht? Bei dem virtuellen Aktor scheinbar schon?! (Siehe Screenshot) ... aber egal.

In der Config steht das hier: RegL_00:02:01 0A:D4 0B:96 0C:B0 00:00 - ist das das richtige?

Irgendwie komme ich aber so nicht weiter, oder habe ich irgendeine Info übersehen?
Danke.

Viele Grüße
Arthur

[snoop]

Hmmmm überlege grade....

was ich machen könnte ist ein notify mit min. 3-5er sleep (sek.).
Ohhh je... :o(

[martinp876]

upps - mein Fehler. Werde ich entfernen (short_release) damit es synchron zu den remotes ist

Du hast nur die register aus liste 0 geszeigt. Interessant ist liste 1 - und evtl liste 4. Wo sind die?

Zur Lesbarkeit gibt es "get name reg all" und "get name regList" - hast du dies schon durchgesehen?

was passiert jetzt, wenn du die PBI mit deinem virtuellen Actor pairst und dann 3 sec drueckst? Die logs habe ich nicht gesehen - hast du welche? In der "release" Nachricht solltest du jeweils das loslassen des Buttons sehen und damit die Dauer. Mit longPress solltest du die Zeit einstellen koennen, die ein langer Tastendruck dauert - und damit auch die wiederholrate des long-press-trigger. Das ist ein Kanal-parameter als in der regList des Channel, nicht des Device!

Eigentlich sollte das alles in den kommandos erklaaert sein:
set getConfig
get regList
get reg all

Channel und device beachten - da ist dann alles drin
Channels sauber definieren, am besten nicht von hand sonder durch anlernen - und dem System ueberlassen.

Gruss
Martin

[snoop]

Hallo Martin,

scheinbar klappt das ganze nicht - habe schon einiges mit dem Bewegungsmelder gemacht - aber mit dem Taster und der Fernbedienung scheint das ganze nicht zu funktionieren.

Ich habe verstanden, dass man nach einem "getConfig" kurz die Anlerntaste betätigen soll (damit die Werte eingelesen werden). Bei "getConfig" sehe ich dass 9 cmds in der queue liegen - sobald ich die Anlerntaste kurz drücke sehe ich das die cmds abgearbeitet werden und der Status nach kurzer Zeit in "cmds done" steht, ich sehe jedoch nur reglist 0.
Habe auch schon ein reset durchgeführt und neu angelernt etc.

get regList ergibt folgendes?!?!
____________________________________
list:         register | range              | peer     | description
   0: intKeyVisib      |   0 to 1           |          | visibility of internal channel options:visib,invisib
   0: pairCentral      |   0 to 16777215    |          | pairing to central

get reg all ergibt folgendes:
____________________________________
CUL_HM_pushButton_1XXYYB:pushButton -
list:peer   register         :value
   0:         intKeyVisib      :invisib
   0:         pairCentral      :0xD496B0

:o(

Gruß
Arthur

[snoop]

Ach, ja channel 01 hat folgende Werte:

RegL_01:04:10 08:00 09:00 00:00

Gruß
Arthur

[snoop]

Hallo Martin,

kann es sein, dass der PBI und die HM-RC-4 von Readings noch nicht soweit implementiert sind wie z.B. der HM-SEC-MDIR?
Kann man das in Angriff nehmen - kann da gerne unterstützen.

Ich könnte natürlich auch versuchen was in RAW Modus zu konfigurieren mir fehlen dazu allerdings die Register bzw. kurz gesagt das KnowHow.

Viele Grüße
Arthur

[martinp876]

HAllo Arthur

kann es sein, dass der PBI und die HM-RC-4 von Readings noch nicht soweit implementiert sind wie z.B. der HM-SEC-MDIR?
Kann man das in Angriff nehmen - kann da gerne unterstützen.

kann sein - aber was fehlt dir? Dann koennen wir es einbauen

Gruss
Martin

[snoop]

Hallo Martin,

mir fehlt zwar die intuitive Hanhabung - ist ein anderes Thema - aber die Möglichkeit Einstellungen vorzunhemen wie bei HM-SEC-MDIR wär schon mal ein Anfang.
Vorschlag:
Folgende Readings wären interessant:

- longPress
- LedColor (longPress/shortPress) - sofern möglich
- was sonst noch möglich ist... meintetwegen kann ich auch das eine oder andere Geräte zur Verfügung stellen (zusenden kann den PBI für ein paar Tage/Wochen entbähren)
- etc.

Viele Grüße
Arthur

[snoop]

Hallo Martin,

kleine Spezifikation: "zur Verfügung stellen!" allerdings nur beschränkt (an dich) :o).

Sorry - also noch einmal zu den Readings konkret:

- longPress -> klar nur bei HM-RC-4 (macht bei PBI keinen Sinn? - vielleicht sogar möglich, da beide Farben vorhanden - interessanter eher bei HM-RC-4)(Nur am rande laut Doku: "Montageart/ausserdem": http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen) besagt die Namenskonvention
B = schwarz
SW = weiss
ich habe beide -> bei B alles ok - das Gerät heißt "HM-RC-4-B" funktioniert soweit bei SW müsste es aber "HM-RC-4-SW" heißen - dem ist aber nicht so es heiß einfach nur HM-RC-4. Nur so am Rande... kannst du das fixen/bzw. soll man das fixen oder ist das so richtig? So weiter...
- LedColor (longPress/shortPress) - sofern möglich
- KeyPressInterval?
- was sonst noch möglich ist... kann das nicht abschätzen , muss du(einer) mir vielleciht sagen was ich machen muss , um heruaszufinden was geht - ich kann auch das eine oder andere Geräte zur Verfügung stellen (kann z.B. den PBI und HM-RC-4 für ein paar Tage/eher Wochen für die Implementierung entbähren)
- etc.

Viele Grüße
Arthur

[martinp876]

Hallo Arthur

- longPress -> klar nur bei HM-RC-4 (macht bei PBI keinen Sinn? - vielleicht sogar möglich, da beide Farben vorhanden - interessanter eher bei HM-RC-4)(Nur am rande laut Doku: "Montageart/ausserdem": http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen) besagt die Namenskonvention
B = schwarz
SW = weiss

nach XML hiessr das Device mit code 008 einfach nur RC-4. ein RC-4-B gibt es nicht. Die Konvention ist  nicht von HM sondern nur eine Interpretation. Ich wurde gerne beim eQ3 Namen bleiben

So weiter...
- LedColor (longPress/shortPress) - sofern möglich

redest du von der LED an der Fernbedienung? Diese LED Farben sind nicht zu steuern. Die hat HM festgelegt und zeigen uebertragungsfehler an. Wenn die RC gepeert ist und alle peers korrekt antworten kommt gruen, wenn die taste nicht gepeert ist orange, bei Fehlern rot. Das sollt alles schon funktionieren

- KeyPressInterval?

du kannst longPress einstellen sowie dblPress - oder nicht? welchen subtype hat deine RC?

- was sonst noch möglich ist... kann das nicht abschätzen , muss du(einer) mir vielleciht sagen was ich machen muss , um heruaszufinden was geht - ich kann auch das eine oder andere Geräte zur Verfügung stellen (kann z.B. den PBI und HM-RC-4 für ein paar Tage/eher Wochen für die Implementierung entbähren)
- etc.

ich nehme an du hast schon regList auf device und channel angewendet? Die Register sind eigentlich alle drin.

auch der mdir sollte komplett sein. der sen und der sec (ausser AES - da habe ich aktuell keine Ahnung)

Im allgemeinen haben remotes extrem wenig funktionen - Funktionen sind eigentlich in den Aktoren beheimatet.
Sensoren haben ein paar parameter.

Aktuell sehe ich nicht, was fehlt.

Gruss
Martin

[snoop]

Hallo Martin,

bin ein wenig verwirrt - muss mir das genaze mal in ruhe anschauen - scheinbar verstehe ich das System noch nicht ganz.
Ok, longPress sowie dblPress sehe ich nun, jedoch nicht in den Teadings wie bei dem Bewegungsmelder - aus rgendeinen Grund kann ich aber die werde nicht ändern.

set Fernbedienung_4_1 getConfig
set Fernbedienung_4_1 regSet dblPress 1.5
set Fernbedienung_4_1 longPress 1.8
get Fernbedienung_4_1 regList


#############
list:         register | range              | peer     | description
   0: intKeyVisib      |   0 to 1           |          | visibility of internal channel options:visib,invisib
   0: pairCentral      |   0 to 16777215    |          | pairing to central
   1: dblPress         |   0 to 1.5s        |          | time to detect double press
   1: longPress        |   0 to 1.8s        |          | time to detect key long press
   4: expectAES        |   0 to 1           | required | expect AES options:on,off
   4: peerNeedsBurst   |   0 to 1           | required | peer expects burst options:on,off
##############

Medlung:
Unknown argument longPress, choose one of actiondetect clear devicepair getConfig getRegRaw getdevicepair getpair pair peerBulk raw regBulk regRaw regSet reset sign statusRequest unpair virtual


Sonst habe ich ein Screenshot beigefügt.
Viele Grüße
Arthur

P.S: Ob, ich nun mit den 1.8 Sec auskomme, um mein Vorhaben umszusetzen muss ich dann mal schauen - kann man auch höhere werte als die 1,8 sec einstellen?

[Zorin]

Hallo,

jetzt muß ich mich auch mal wieder "reindrängeln".

Ich denke, ich habe ein ähnliches Anliegen wie snoop:
Ich will dem 4-fach Taster (HM-PBI-4-FM) in meinem Fall, soviele Funktionen wie möglich entlocken.

Im Detail (und in Abweichung zu snoop) geht es mir um folgendes:
1) Die Short(-Tastendrücke) sollen immer direkt mit eienm Aktor gepairt sein, sozusagen die "Basisfunktionalität" auch ohne FHEM.
 -Erledigt

2) Die Long(-Tastendrücke) sind bei mir das "FHEM-Sahnehäubchen" und führen Spezialaktionen aus, z.B. bestimmte Lampen zu bestimmten Zeitpunkten.
 Das Notify habe ich (dank diese Threads) soweit fertig. Nur leider geht immernoch die "Basisfunktionalität" parallel mit an (d.h. bei "Long" wird auch das "Short" mit ausgeführt.
 Kann man das irgendwie vermeiden ?
 Ich habe schon einiges mit getConfig, reg all etc. rumgespielt und bekomme da folgendes für den Kanal:

RegL_01:
   04:10 08:00 09:00 00:00   2013-01-21 11:03:24
RegL_04:va_SchalterBZ1.CH2_Btn1
   01:00 00:00

fhem> get BZ.Schalter1.CH2 regList
list:         register | range                | peer     | description

Danke schonmal für die Hilfe

[martinp876]

Hallo Zusammen

1)
longPress ist ein register, kein Kommando
also
set Fernbedienung_4_1 regSet longPress 1.8
hast du bei dblPress doch auch gemacht.

das ganze wird bei den meisten Remotes erst ausgeführt, wenn einmal anlernen gedrückt wurde.

2)
a) pairen kann man nur channels, nicht deren Funktionen. Also einen Button oder Sensor mit einem Aktor-channel. Nur short oder long gehen nicht
b) remotes senden nur einen trigger. Short /long, evtl noch einen level (nur manche Sensoren). Aktionen werden NIE von einer remote festgelegt sondern IMMER vom empfangenden Aktor channel
c) du kannst im Aktor festlegen was zu tun ist. Wenn er bei 'long' nichts tun soll, sag es ihm. Viele habe ein lgActionType... und shActionType..  der lässt sich meist auch auf "off" setzen. Einfach mal schauen, was dein Aktor können sollte
d) unabhängig was du gepeert hast kannst du IMMER Aktionen zusaetzlich über FHEM definieren

Gruss
Martin

[snoop]

Hallo Martin,

mit 1) bin wohl ich gemeint:
Ja, sorry ist mir auch schon aufgefallen - DANKE.

(falsch) set Fernbedienung_4_1 longPress 1.8
(richtig)set Fernbedienung_4_1 regSet longPress 1.8
Anlerntaste für die Übertragung der CMD queue -> "KLAR".

Bin schon eine Weile am testen - scheint so als wenn es funktionieren würde, zumindest das was ich vor habe.

Folgende Fragen sind bei den Tests aufgekommen:
   Ich bin ein wenig verunsichert, welche Vorteile ich bei einem virtuellen Adapter den ich mit PBI/Remote gepairt habe.
   Für einen Leihen: - Pro: ACK wird grün gemeldet/signalisiert
                     - Kontra: Kaskade über den Virtual Adapter -> Performance?
                     - Mehr coding Aufwand
   Hast du eine Empfehlung: Wie gesagt - mein Anwendungsfall ist ein Einfamilienhaus (Keine wirklich kritischen Anwendungsfälle und      
   Komponenten halten sich in Rahmen (ein/zwei Hände voll)), Komplexität (Includes/Definitions = gering bis mittel)

Der Vollständigkeitshalber bin ich dir auf deine Anmerkung noch ein paar Antworten schuldig (Sorry, habe grade etwas mehr Zeit):

- Die Einschränkungen bei Remotes sind mir nun klar.
- Namenskovnention: ok, verstanden! Gibt es noch weitere Komponenten die eine SW&B Unterscheidung haben: Bei Remote gibt es nur RC-4 (White) RC-4-B (Black) mMn müsste dann die SW Unterschgeidung raus - Bsp: Ein HM-SEC-MDIR ist auch weiss und wird nicht explizit gekennzeichnet. Ich finde das verwirrt - will da nicht drauf rum reiten - ist nur eine Anmerkung - habe im Moment andere Herausforderungen als mich mit den Namen (Schall und Rauch) zu beschäftigen.
- MDIR ist (nachdem ich mich ein wenig damit beschäftigt habe) sehr gut implementiert (obwohl ich auch hier auch ein paar Fragen/Anregungen habe - da komme ich aber in ein paar Tagen/Woche drauf zurück, wenn ich Zeit habe). Meine Frage dazu ist - warum ist(vielleicht lässt sich das technisch nicht) der PBI und Remote mit den Registern (in Readings) nicht implementiert. Zeitmangel? geht nicht? Ich finde, dass es einfacher/schöne/übersichtlicher ist das direkt im Device zu sehen - daher zvor die Frage, ob "PBI und Remote noch nicht vollständig implementiert ist/sind?!!"

Zu 2)
da ich auch ein PBI habe hätte ich auch noch ein paar Fragen - schaffe es aber Zeitlich nicht - vielleicht die Tage.

"Dake" und bis Bald/die Tage.

Viele Grüße
Arthur

[martinp876]

Arthur,

ein virtueller Aktor bietet nur bedingt funktionen, wie du richtig erkannt hast. Der Aufwand zum Implementieren war ueberschaubar und mache wollen es.

Anwendung ist wohl in erster linie
- gruene LED => Bestaetigung  des Kommandos. Komplexe ablaeufe sind machbar ueber die Zentrale und man hat die LED
- simulationen und tests moeglich

Ich wuerde immer ein direktes peering bevorzugen, wenn es die Funktion  der komponenten hergibt.
>weniger traffic in der luft
>Ausfallsicherheit

es gibt nochmehr komponenten mit farben (RC12, RC19,...). Ich verwende die Bezeichnung aus XML, wie gesagt. Funktional ist es kein unterscheid - schade dass HM dies ueberhaupt im code unterscheidet...

Darstellung der Register in readings:
nein, kein Zeitmangle. Ich kann die Darstellung fuer jeden wert sofort aendern - ist nur ein Tabelleneintrag.
Das Problem ist, den User nicht mit werten zu ueberfahren. Ich wollte nur operationell wichtige Werte direkt anzeigen. Mittlerweile gibt es einen expert mode von Rudi, damit koennte man etwas steuern... aber damit bin ich noch nicht glücklich - da muss ich alle Register umbenennen....

zum PBI: gut - so viel Zeit habe ich ja auch nicht ;-)
Aber Frage nur... damit wir es stabil bekommen

Gruss
Martin

[snoop]

Hallo zusammen,

ok, verstanden, direktes peering ist zu bevorzugen - check! - Sieht die Welt für mich zwar nun anders aus als ich urprünglich dachte - ja, macht auch Sinn, die wichtigen Dinge sollen auch "nur mit Strom funktionieren-> sofern welches da ist" Die FritzBox läuft erstaunlich gut - nach eine dekade Erfahrung. Aber mit FHEM habe ich seid ein paar Wochen Kontakt (positiv).
Nun die ultimative Frage: Ich versuche die Frage von Zorin, anders zu formulieren - interessiert mich auch -
"Um:
- weniger traffic und viel wichtiger
- Ausfallsicherheit (Falls FHEM nicht verfügbar ist - Router/andere FHEM fähige Komponetenten "rauchen ab")
zu gewährleisten.
!!! Ist es möglich ein gepeete(n) Aktor(en) so zu konfigurieren, dass es erkennt, dass FHEM nicht da ist nur die peer Aktion ausführen soll! Ist FHEM hingegen verfügbr, sollen zuerst die FHEM notify's geprüft und zuerst ausgeführt werden. Also eine Art Priorisierung. !!!
Ich merke die Fragestellung ist auch nicht ganz korrekt, hoffe jedoch, dass dies verständlich ist - ich befürchte auch, dass ich auch schon die Antwort kenne (Daher auch keine Rückmeldung von Zorin dazu - er hat's verstanden) :o(

Danke und Viele Grüße
Arthur

[Martin Thomas Schrott]

Hallo Arthur,

>- MDIR ist (nachdem ich mich ein wenig damit beschäftigt habe) sehr gut implementiert
>(obwohl ich auch hier auch ein paar Fragen/Anregungen habe - da komme ich aber in
>ein paar Tagen/Woche drauf zurück, wenn ich Zeit habe).

Bitte frag doch gleich jetzt und hier, ich bin gerade noch am Testen der Bewegungsmelder und kann dann deine Anregungen / Wünsche gleich berücksichtigen. (Anmerkung: Die Beschreibungen im command ref für die md sind momentan vermutlich nicht ganz korrekt, aber teilweise schon korregiert für ein update)
Liebe Grüße
Martin

[snoop]

Hallo Martin,

danke für das Anbgebot/den Hinweis - ich habe auch ein paar von den Bewegungsmelder hier stehen und habe einige Anforderungen/Ideen was ich damit machen möchte - mangels Zeit komme ich aber nicht dazu die Komponenten final einzurichten.
Aus diesem Grund kann ich derzeit und kurzfristig keine sinvollen/verwertbaren Input liefern.

Danke und viele Grüße
Arthur

P.S: Nur so am Rande - was mir nur aufgefallen ist, ist das ich mit der Reaktionszeit des MDIRs nicht ganz zufrieden bin (dazu gibt es bereits einige Diskussionen) - kann im Moment aber nicht abschätzen, ob das an der definierten Konfiguration liegt und ob dies bei meinem Anwendungsfall zum Tragen kommt - dazu wollte ich noch ein paar Tests durchführen.

[Martin Thomas Schrott]

Hallo!
>der Reaktionszeit
>des MDIRs nicht ganz zufrieden

Meinst du wirklich die Reaktionszeit oder meinst du das delay bis er wieder reagiert?

Das Delay lässt sich einstellen, die Sekunden Angaben in FHEM stimmen derzeit aber noch nicht. Ich bin noch am austesten, wie lange die Verzögerungen wirklich sind.
Die normale Reaktionszeit ist eigentlich kaum merkbar. Also er reagiert sofort auf Bewegungen, außer du hast die Einstellungen geändert. Hier sind die Werte von evtFltr* zuständig. Wenn du diese auf 1 lässt ist alles flott.

Nähere details zu den Einstellungen gibt es im command ref bzw. bei regList sobald ich meine Tests abgeschlossen habe.

Liebe Grüße
Martin

[snoop]

Hallo Martin,

es ging - meine ich - um das Thema "minInterval" (ist schon ein paar Wochen her).
Aber wie gesagt da möchte ich mir noch ein wenig Zeit nehmen und mich im detail einarbeiten.

Viele Grüße
Arthur

P.S.: ;o) Falls du Zeit hast das zu verifizieren: Die möglichen Werte für "Wahl des Sendeabstandes - dynamisch" soll ja bei 15,20,60,120 Sekunden liegen - wenn ich als Wert 0 eingebe erscheint im Reading (nach Abarbeitung der CMDs) R-minInterval=set_0 - ich weiß nicht ob das so richtig ist? Wie gesagt nur wenn du Zeit hast?! Ferner habe ich noch nicht verstanden (sorry bin noch dran mir die Infos zu erlesen) warum bei dem MDIR die Readings mit R-* anfangen und bei den anderen Komponenten kein R-* davor steht? Idee Vorschlag wäre das einheitlich zu handhaben - wie gesagt es kann ja sein das das erstmal gewollt ist?

[martinp876]

Die möglichen Werte für "Wahl des Sendeabstandes - dynamisch" soll ja bei 15,20,60,120 Sekunden liegen

hat sich geaendert. Martin hat die Werte ausgemessen. Es liegt jetzt bei 15,30...240

- wenn ich als Wert 0 eingebe erscheint im Reading (nach Abarbeitung der CMDs) R-minInterval=set_0 - ich weiß nicht ob das so richtig ist?

das ist korrekt. Ich bin vielleicht ein bisschen paranoid  - aber ich will den Unterschied zwischen abgeschickt und gelesen sehen. also ein "set_" bedeutet immer dass ein kommando in Bearbeitung ist. Kann in der queue haengen oder schon gesendet sein... Wenn eine explizite bestaetigung kommt verschwindet das set_. Also beim Licht einschalten kommt ein set_on und sobald das ack da ist wird auf "on" gesetzt.
Bei Registern kann ich erst mit Sicherheit das 'set_' zurücknehmen wenn der Wert wieder gelesen wurde. Also nach getConfig beispielsweise.

[snoop]

Hallo Martin,

ich hatte nun ein wenig Zeit mein Vorhaben mit der Fernbedienung (HM-RC-4) zu implementieren und zu testen.
Das ganze funktioniert so wie ich mir das vorstelle, bin jedoch auf ein Problem gestossen und Zwar:

Meine fhem.cfg beinhaltet diverse includes (Autocreate.cfg, Fernbedienungen.cfg etc.) bzw. die gesamte fhem config basiert auf cfg Dateien. Jetzt habe ich das Problem das meine HM-RC-4, die mit einem virtuellen Adapter gepeert ist, nach einen FHEM restart (vorher werden alle meine cfg inkl. der fhem.cfg hineinkopiert) die peerinformationen verliert und ich die Fernbedieung erneut peeren muss.

Kannst du mir sagen wie ich peering Informationen deklarieren kann sodass diese auch einen FHEM Neustart überleben.

Vielen Dank.
Grüße
Arthur

[martinp876]

Artur,

dein RC verliert das peering hoffentlich nicht, sondern nur die "kopie" die in FHEM gehalten wird.

Ich gehe also davon aus, dass du die Werte in FHEM weiter sehen willst und dir ein getConfig nach einem neustart zu bloed ist (Fernbedienungen kann man ja nicht automatisch Fragen...)

Die Peers stehen im Attribut "peerIDs" - und zwar als 8 stellige IDs (4-stellig hex, also HMID + channelNo)

Die lesbare Form "peerList" in readings wird daraus generiert.

Wo du es so sagst - ich denke peerList wird nach dem restart nicht neu generiert. Das muss ich einmal einbauen - ist nicht ganz straight Forward.

Gruss
Martin

[Martin Thomas Schrott]

@Martin
Danke, jetzt versteh ich auch warum die list bei mir immer auf cleared steht ;-)
lG
Martin

[snoop]

Hallo Martin,
Genau so ist es, die peering Informationen scheinen noch da zu sei.
Der vituelle Aktor/Channel hat nur keine Informationen mehr.

Was mich ein wenig wundert ist - warum funktioniert mein notify noch - bedient sich dieser der Informationen aus dem HMLAN?

Viele Grüße
Arthur

[martinp876]

Hallo Artur

a) ich werde das Reading 'peerList' nach Neustart auf den Stand des Attributes peerIDs angleichen. Das wird mit etwas Verzoegerung datgestellt, da es vom "Feature" autoReadReg mitbedient wird.

b) das Handling attr->peerIDs und readings->peerList habe aus verscheidenen Gruenden so implementiert.
- Attribute werden besser 'gesichert' (bei save beispielsweise) also readings
- programmiertechnisch sind IDs das mass der Dinge, Usertechnisch die Namen
- das Konzept solle 'hardened' gegen renames aller Art sein - so auch renames im config-file

=> die peerList ist eigentlich nur eine "Darstellung" fuer den User. Hier ist alles "human-readable". Programmtechnische Nutzung dieses eintrages ist aufwaendig, umstaendlich und unsicher(er).
=> die eigentliche Info ist in peerIDs, wird bei save mitgespeichert und bleibt somit erhalten
??> wenn punkt a) erledigt ist (heute Abend?) sollte die (hoffentliche) letzte Luecke geschlossen sein - peerIDs und peerList sind dann inhaltlich identisch

c) notifies
- keine Ahnung, wie dein notify aussieht...
- dein virtueller channel aggiert als Aktor oder Button?
- gepeerte virtuelle Channels bekommen immer ihre Peers im Attribut peerIDs eingetragen. Wenn du ohne save restartest ist IMMER alles was du virtuell gemacht hast weg -> und mehr... eben alles was in FHEM ist und nicht in HM-devices
==> ich gehe also davon aus, dass du einen Stand gesaved hattest, und die peerIDs somit nach Neustart immer wieder gesetzt werden (die peerList -noch- nicht)
==> damit sollte alles funktionieren: Nachrichten werden immer aufgrund der ID gesendet/empfangen/geparst/notifiziet und die entsprechenden events repostet.

d) grundsaetzlich zu Namen und HMId in CUL_HM
wie oben erwaehnt funktioniert das System eigentlich nur auf Basis der ID. Namen sind programmtechnisch hinderlich/stoerend/fehleranfaellig und dienen nur dem Zweck dem User das Leben zu erleichtern (mir auch...).
Ein nicht unerheblicher Teil des Codes besteht darin diese zu konvertieren fuer devices, channels, device ohne channel, virtuelle-HM channel, virtuelle-FHEMentities

e) ich empfehle nach dieser Erklaerung nicht, das Attribut "peerIDs" zu editieren. Kann man natuerlich, sollte aber wissen, was man tut.

So viel getippt - hoffentlich etwas Hintergrund verbreitet.
=> wenn du konkrete Fragen hast muss du die notofies und die attribute deiner virtuellen Entity mit der Frage posten

Gruss
Martin

[snoop]

Hallo Martin,

c) notifies
- keine Ahnung, wie dein notify aussieht...
- dein virtueller channel aggiert als Aktor oder Button?
- gepeerte virtuelle Channels bekommen immer ihre Peers im Attribut peerIDs eingetragen. Wenn du ohne save restartest ist IMMER alles was du virtuell gemacht hast weg -> und mehr... eben alles was in FHEM ist und nicht in HM-devices
==> ich gehe also davon aus, dass du einen Stand gesaved hattest, und die peerIDs somit nach Neustart immer wieder gesetzt werden (die peerList -noch- nicht)
==> damit sollte alles funktionieren: Nachrichten werden immer aufgrund der ID gesendet/empfangen/geparst/notifiziet und die entsprechenden events repostet.

=> wenn du konkrete Fragen hast muss du die notofies und die attribute deiner virtuellen Entity mit der Frage posten

Gruss
Martin

1) Meine notifys sehen wie folgt aus:
define Fernbedienung_4_1_Btn_01_on notify .*Fernbedienung_4_1_Btn_01.* {if(ReadingsVal("vaRemote_4_1_Btn_01","virtActTrigType","") eq "short_Release") {fhem "set GA_Tor_Sw_1_01 on"} else {fhem "set GA_Beleuchtung_Sw_1_02,GA_Tor_Sw_1_01 on"}}
define Fernbedienung_4_1_Btn_02_off notify .*Fernbedienung_4_1_Btn_02.* {if(ReadingsVal("vaRemote_4_1_Btn_02","virtActTrigType","") eq "short_Release") {fhem "set GA_Tor_Sw_1_01 off"} else {fhem "set GA_Beleuchtung_Sw_1_02,GA_Tor_Sw_1_01 off"}}
define Fernbedienung_4_1_Btn_03_on notify .*Fernbedienung_4_1_Btn_03.* {if(ReadingsVal("vaRemote_4_1_Btn_03","virtActTrigType","") eq "short_Release") {fhem "set GA_Beleuchtung_Sw_1_02 on"} else {fhem "set GA_Beleuchtung_Sw_1_02,GA_Tor_Sw_1_01 on"}}
define Fernbedienung_4_1_Btn_04_off notify .*Fernbedienung_4_1_Btn_04.* {if(ReadingsVal("vaRemote_4_1_Btn_04","virtActTrigType","") eq "short_Release") {fhem "set GA_Beleuchtung_Sw_1_02 off"} else {fhem "set GA_Beleuchtung_Sw_1_02,GA_Tor_Sw_1_01 off"}}

2) Mein virtueller channel aggiert als Button?
define vaRemote_4_1 CUL_HM 200000
set vaRemote_4_1 virtual 1
set vaRemote_4_1 virtual 2
set vaRemote_4_1 virtual 3
set vaRemote_4_1 virtual 4
rename vaRemote_4_1_Btn1 vaRemote_4_1_Btn_01
rename vaRemote_4_1_Btn2 vaRemote_4_1_Btn_02
rename vaRemote_4_1_Btn3 vaRemote_4_1_Btn_03
rename vaRemote_4_1_Btn4 vaRemote_4_1_Btn_04

set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 single
set Fernbedienung_4_1_Btn_02 devicepair 1 vaRemote_4_1_Btn_02 single
set Fernbedienung_4_1_Btn_03 devicepair 2 vaRemote_4_1_Btn_03 single
set Fernbedienung_4_1_Btn_04 devicepair 3 vaRemote_4_1_Btn_04 single

Wie der virtuelle Button nach einen FHEM Neustasrt aussieht kannst du aus dem angehängtem Screenshot entnehmen.

Konkrete Frage habe ich nicht, mich hat nur gewundert, dass trotz der fehlenden peerings (bzw. der fehlenden Informationen) der notify funktioniert hat, obwohl das hier "{if(ReadingsVal("vaRemote_4_1_Btn_03","virtActTrigType","") eq "short_Release")..." hätte nicht funktionieren können, da der "vaRemote_4_1_Btn_03" ein virtueller Button ist der den ReadingsVal - virtActTrigType garnicht hat (siehe screenshot).

Ansonsten warte ich auf das was da kommt. ;o)
Viele Grüße
Arthur

[martinp876]

Hallo Artur,

das mit deinen Settings sollte so funktionieren (tut es ja auch nach  habe ich verstanden)

Ich kommentiere einfach einmal deine Einstellungen. Du kannst es auch ignorieren, kein Problem:

Du hast eine FB mit 4 Buttons, ein Tor und ein Licht.
Dein virtual aggiert als Aktor: Die FB sendet an den VirtualAktor und will eine Antwort.
FHEM beobachtet das ganze und triggert (ueber die Notifies) das Tor und das Licht.

Ich nehme an, dass das devicepair nur einmal ausgeführt wird und nicht im config steht. also entweder
- set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 single actor
=> damit wird kein Kommando in die command-queue der FB geschrieben - ist unschön
oder
- nach den devicepair ein "save". Die vaRemote_4_1_Btn_0x erhalten dann ein Attribut über das peering und gut ist es.

Das Ganze funktioniert gut für short_Release.

Bei 'Long' passiert folgendes:
so lange du drückst werden trigger von der FB geschickt, alle 0,4sec, alle mit 'long'. Somit wird unnötig zu den Aktoren (tor und Licht) mehrfach 'auf' oder 'zu' gesendet. Das solltest du vermeiden. Du solltest somit nur reagieren wenn ein 'Release' im reading ist - oder das notify umstrukturieren.


---------------------------------
Mein Ansatz waere ein direktes peeren (ok - nicht jedermanns Sache, aber eigentlich HM Philosophy, so meine ich). Das spart alle virtuellen Aktoren. koennte so aussehen (tipfehler vorbehalten):

#---peer 4 buttons zum tor, je 2 auf und 2 zu---
set Fernbedienung_4_1_Btn_01 devicepair 0 GA_Tor_Sw_1_01
set Fernbedienung_4_1_Btn_03 devicepair 0 GA_Tor_Sw_1_01
#---peer 4 buttons zum Licht, je 2 auf und 2 zu---
set Fernbedienung_4_1_Btn_01 devicepair 0 GA_Beleuchtung_Sw_1_02
set Fernbedienung_4_1_Btn_03 devicepair 0 GA_Beleuchtung_Sw_1_02
#---keine reaktion beim Tor fuer short Buttons 3 oder 4---
set GA_Tor_Sw_1_01 regSet shActionType off Fernbedienung_4_1_Btn_03
set GA_Tor_Sw_1_01 regSet shActionType off Fernbedienung_4_1_Btn_04
#---keine reaktion beim Tor fuer short Buttons 1 oder 2---
set GA_Beleuchtung_Sw_1_02 regSet shActionType off Fernbedienung_4_1_Btn_01
set GA_Beleuchtung_Sw_1_02 regSet shActionType off Fernbedienung_4_1_Btn_02

# nur eine reaktion auf einen longPress (kann man evtl auch weglassen
set GA_Tor_Sw_1_01 regSet lgMultiExec off Fernbedienung_4_1_Btn_01
set GA_Tor_Sw_1_01 regSet lgMultiExec off Fernbedienung_4_1_Btn_02
set GA_Tor_Sw_1_01 regSet lgMultiExec off Fernbedienung_4_1_Btn_03
set GA_Tor_Sw_1_01 regSet lgMultiExec off Fernbedienung_4_1_Btn_04
set GA_Beleuchtung_Sw_1_02 regSet lgMultiExec off Fernbedienung_4_1_Btn_01
set GA_Beleuchtung_Sw_1_02 regSet lgMultiExec off Fernbedienung_4_1_Btn_02
set GA_Beleuchtung_Sw_1_02 regSet lgMultiExec off Fernbedienung_4_1_Btn_03
set GA_Beleuchtung_Sw_1_02 regSet lgMultiExec off Fernbedienung_4_1_Btn_04

# Und nicht vergessen die FM zu entpaaren, aufraeumen
set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 dual unset remote
set Fernbedienung_4_1_Btn_03 devicepair 0 vaRemote_4_1_Btn_01 dual unset remote
delete vaRemote_4_1

==> jetzt anlernen an der remote drücken - dann werden alle peers gesetzt und gelöscht - an der FB

dann noch (je nachdem ob es eines oder 2 devices sind)
attr <devicetor> autoReadReg 1
attr <devicelicht> autoReadReg 1

wenn du das durch hast funktioniert alles ohne die Zentrale, aber alles sichtbar sein

Gruss
Martin

[snoop]

Hallo Martin,

ja, das Thema direktes peeren zu FHEM Variante hatten wir schon diskutiert.
Die Variante mir dem virtuellen Aktor gefällt mir wenn ich erhlich bin nicht so. Ich habe 4 Fernbedienungen da kommen so einige virtuelle Komponenten ins Spiel (4 Aktoren mit je 4 Channels) was einiges an komplexität mit sich bringt :o( und ich muss bei jedem FHEM Update bangen, dass etwas davon plötzlich nicht mehr funktioniert - von daher ist der HM Ansatz grundsätlich ok.

Danke für die ausführliche Erklärung - die Variante wie du die Komponenten konfigurierst, insbesondere "segSet lgMultiExec" und "regSet shActionType" ist mir neu - eröffnet aber auch neue Möglichkeiten - ich teste das ganze.

set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 dual unset remote

Habe ich auch schon gesucht und nicht gefunden - also was dazugelernt.

Ich nehme an, dass das devicepair nur einmal ausgeführt wird und nicht im config steht. also entweder
- set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 single actor
=> damit wird kein Kommando in die command-queue der FB geschrieben - ist unschön
oder

Ja, richtig nur einmal.

- nach den devicepair ein "save". Die vaRemote_4_1_Btn_0x erhalten dann ein Attribut über das peering und gut ist es.

Kann ich ein save aus einer Konfig heraus triggern? Wie? Einfach nur save?

Bei 'Long' passiert folgendes:
so lange du drückst werden trigger von der FB geschickt, alle 0,4sec, alle mit 'long'. Somit wird unnötig zu den Aktoren (tor und Licht) mehrfach 'auf' oder 'zu' gesendet. Das solltest du vermeiden. Du solltest somit nur reagieren wenn ein 'Release' im reading ist - oder das notify umstrukturieren.

Ja, richtig ist mir auch schon aufgefallen.

Abschließend ist noch zu sagen - dass die bisherige Implementierung nur die 1/2 Miete ist, da die Idee ja wie folgt aussieht:

- 3 Aktoren (Switch) je 2 Kanal
- 4 Remotes

1)
Remote#1/2/3/4 Taste1 (short)-> Aktor #1 Kanal 1 on
Remote#1/2/3/4 Taste2 (short)-> Aktor #1 Kanal 2 on
Remote#1/2/3/4 Taste3 (short)-> Aktor #2 Kanal 1 on
Remote#1/2/3/4 Taste4 (short)-> Aktor #2 Kanal 2 on
2)
Remote#1/2/3/4 Taste1 (long): Aktor #1/2 jeweils Kanal 1 und 2 on
Remote#1/2/3/4 Taste2 (long): Aktor #1/2 jeweils Kanal 1 und 2 off
3)
Remote#1/2/3/4 Taste3 (long)-> Aktor #3 Kanal 1 on und ggf. abhängig von der Uhrzeit: Aktor #1 Kanal 1, Aktor #3 Kanal 2 on
Remote#1/2/3/4 Taste4 (long)-> Aktor #3 Kanal 1 off und ggf. abhängig von der Uhrzeit: Aktor #1 Kanal 1, Aktor #3 Kanal 2 off

Ich denke/hoffe dass ich mit den Boardmitteln (sprich devicepair) 1) und 2) realisieren kann?!?
Mit FHEM werde ich wohl 3) realisieren?!

Ach ja, longPress habe ich übrigens auf 1.2 sek. gestellt.

So jetzt aber mal testen angesagt.
Danke und Viele Grüße
Arthur

[martinp876]

Hallo Arthur,

insbesondere "segSet lgMultiExec"

das ist kosmetik - bei einem Schalter dessen link nicht auf "toggel" programmiert ist sollte es eigentlich egal sein

set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 dual unset remote

Habe ich auch schon gesucht und nicht gefunden - also was dazugelernt.

oh - sollte im commandref stehen - schlecht erklärt?

- nach den devicepair ein "save". Die vaRemote_4_1_Btn_0x erhalten dann ein Attribut über das peering und gut ist es.
Kann ich ein save aus einer Konfig heraus triggern? Wie? Einfach nur save?

aus der config heraus nicht - macht auch keinen Sinn. Aber aus dem terminalfenster. also wenn du alles eingestellt hast im FHEM dann ein save. Der speichert die aktuellen defines und attribute.
Beachte: natürlich nicht die Einstellungen IN HM, aber quasi alles aus FHEM (auch keine readings, sind ja keine Einstellungen).
HM speichern kannst du mit "get... configSave" - siehe commandref. Somit lassen sich die Einstellungen den HM-devices sichern. ist auch beschrieben, wie du sie wieder einspielen kannst.

- 3 Aktoren (Switch) je 2 Kanal
- 4 Remotes

=> also 6 schalterKanaele
=> also 16 tasten

1)
Remote#1/2/3/4 Taste1 (short)-> Aktor1Kanal1 on
Remote#1/2/3/4 Taste2 (short)-> Aktor1Kanal2 on
Remote#1/2/3/4 Taste3 (short)-> Aktor2Kanal1 on
Remote#1/2/3/4 Taste4 (short)-> Aktor2Kanal2 on
2)
Remote#1/2/3/4 Taste1 (long): Aktor1 Aktor2 jeweils Kanal 1 und 2 on
Remote#1/2/3/4 Taste2 (long): Aktor1 Aktor2 jeweils Kanal 1 und 2 off
3)
Remote#1/2/3/4 Taste3 (long)-> Aktor #3 Kanal 1 on und ggf. abhängig von der Uhrzeit: Aktor #1 Kanal 1, Aktor #3 Kanal 2 on
Remote#1/2/3/4 Taste4 (long)-> Aktor #3 Kanal 1 off und ggf. abhängig von der Uhrzeit: Aktor #1 Kanal 1, Aktor #3 Kanal 2 off

dann noch ein Versuch:
Beachte die HM defaults im AKTOR:
bei devicepair dual wird ein ein button fuer 'on' und einer für 'off' programmiert
bei devicepair single wird ein ein button fuer 'toggle' programmiert
=> also in deinem Fall immer dual nehmen, das macht weniger Arbeit. Sonst musst du die register im Aktor alle selbst umsetzen.

default ist dual/set/both, es wird immer short und long gesetzt
also erst die Basics fuer Akt1_1:

set rm1_1 devicepair 0 Akt1_1
set rm2_1 devicepair 0 Akt1_1
set rm3_1 devicepair 0 Akt1_1
set rm4_1 devicepair 0 Akt1_1
### jetzt reagiert Akt1_1 auf alle 4 remotes Button 1 UND 2 long UND short
### also short ausschalten fuer Taste 2
set Akt1_1 regSet shActionType off rm1_2
set Akt1_1 regSet shActionType off rm2_2
set Akt1_1 regSet shActionType off rm3_2
set Akt1_1 regSet shActionType off rm4_2
###--- da mit sind erledigt:
### Remote#1/2/3/4 Taste1 (long): Aktor1 Kanal 1 on
### Remote#1/2/3/4 Taste2 (long): Aktor1 Kanal 1 off

Wenn Akt1_2 fertig ist würde ich den kompletten Aktor 1 einmal sichern. Also
set Akt1 getConfig  # liest auch die channels 1 und 2 in einem!
get Akt1 configSave <filname>

Den Punkt3 - speziell das Uhrzeitabhängige schalten - geht nicht direkt aus HM.

Ich denke/hoffe dass ich mit den Boardmitteln (sprich devicepair) 1) und 2) realisieren kann?!?
Mit FHEM werde ich wohl 3) realisieren?!

richtig, jedenfalls den Uhrzeitabhängigen Teil
Gruss
Martin

[snoop]

Hallo Martin,

so, jetzt bin ich an den Punkt angelangt wo ich das ganze aufgebe - drehe mich im Kreis.

Entegen deinen Vorschlag habe ich die Komponenten wie folgt gepairt (!wow! schon erstaunlich welche Verzögerung über FHEM einhergeht - direktpairing ist da schon das was mir zusagen würde):

Ist nur ein Beispiel zum testen:

set Fernbedienung_4_1_Btn_01 devicepair 0 GA_Tor_Sw_1_01 single set
set Fernbedienung_4_1_Btn_02 devicepair 0 GA_Beleuchtung_Sw_1_02 single set

Also als single um zu toggeln (Also je Remote pro Taste ein Channel in Toggel modus das ganze "short").
Funktioniert soweit alles mit "short".
Da ich den Remotes für "long" eine andere Funktion geben möchte, laufe ich in das Problem, dass bei einem "long" zuerst ein short ausgeführt wird. Somit benötige ich wie bei dem virtual Aktor ein "short_Release" und ein "long_Release"

Ich denke dass ich ohne den va mein Vorhaben nicht realisieren kann :o( schade.
Hat sich zum Thema peerList und peerIDs was getan? Wäre super dann  könnte ich das mal doch noch ausprobieren und es ankommen lassen dass ohne FHEM nichts geht - sind keine kritischen Komponenten die ich schalten möchte. Direktpairen kann ich ja immer noch falls ich unzufrieden bin.

Viele Grüße
Arthur

[martinp876]

Hallo Artur

Entegen deinen Vorschlag

es gibt unendlich viele wege - und darunter einige Gute...;-)

Da ich den Remotes für "long" eine andere Funktion geben möchte, laufe ich in das Problem, dass bei einem "long" zuerst ein short ausgeführt wird.

sollte eigentlich nicht sein. Der Aktor kann es von Beginn an unterscheiden.

Du musst dir vorstellen, dass in einem Aktor (ich wiederhole mich - hoffentlich nicht langweilig...)
- je gepeerten Button (besser channel) ein peer eingetragen wird. HM spricht von einem "link"
- je link die Aktionen und Reaktionen einstellbar sind.
- im Aktor ein default erstellt wird, wenn gepeert wird. Im allgemeinen gibt es 3 defaults
  + beim pairen 'single' wird ein Link erstellt der toggelt
  + beim pairen 'dual' werden 2 Links erstellt, einer mit 'on', einer mit 'off' funktion
- alle Links reagiere erst einmal auf "long" und "short"


so das war der default, den macht HM nach peeren. Jetzt kannst du ueber die Register alles steuern, aus allem ein 'toggle' machen, ein 'on' einen treppenhausschalter und mehr.

Auf der 'link' ebene - also alle Register eines peers hast du eigentilch 2 datensaetze, einen fuer "long" und einen fuer "short". Diese sind vom registerumfang nahezu identisch (long hat immer noch den multiexec...) - vom Inhalt nicht.

Du musst jetzt also entscheiden, welcher Link auf short oder long reagieren soll und welcher nicht.

Wenn ich mich recht erinnere sollen alle auf "long" reagieren, nicht alle auf short.
also
set <licht> regSet shActionType off <button-name>
=> auf short wird nicht mehr reagiert.

Programiere doch einmal dein Licht und schicke die Register - im expert mode, dass ich alle habe.
Dann logge einmal die messages von dem, was nicht geht.

Und letztlich noch die Frage: welchen remote hast du? Die kann hoffentlich long und short. Meine taster koennen dies alle - aber ich habe keine mit 4 Button

Gruss
Martin

[snoop]

Hallo Martin,

zunächst danke für deine Geduld.

Also ich sehe nun mit
get GA_Tor_Sw_1_01 (ein Channel eines Aktors) reg all alle möglichen Einstellungsmöglichkeiten:

    3:Fernbedienung_4_1_Btn_03   lgActionType     :jmpToTarget
   3:Fernbedienung_4_1_Btn_03   lgCtDlyOff       :geLo
   3:Fernbedienung_4_1_Btn_03   lgCtDlyOn        :geLo
   3:Fernbedienung_4_1_Btn_03   lgCtOff          :geLo
   3:Fernbedienung_4_1_Btn_03   lgCtOn           :geLo
   3:Fernbedienung_4_1_Btn_03   lgMultiExec      :off
   3:Fernbedienung_4_1_Btn_03   lgOffDly         :0 s
   3:Fernbedienung_4_1_Btn_03   lgOffTime        :111600 s
   3:Fernbedienung_4_1_Btn_03   lgOffTimeMode    :absolut
   3:Fernbedienung_4_1_Btn_03   lgOnDly          :0 s
   3:Fernbedienung_4_1_Btn_03   lgOnTime         :111600 s
   3:Fernbedienung_4_1_Btn_03   lgOnTimeMode     :absolut
   3:Fernbedienung_4_1_Btn_03   lgSwJtDlyOff     :off
   3:Fernbedienung_4_1_Btn_03   lgSwJtDlyOn      :on
   3:Fernbedienung_4_1_Btn_03   lgSwJtOff        :onDly
   3:Fernbedienung_4_1_Btn_03   lgSwJtOn         :dlyOff

   3:Fernbedienung_4_1_Btn_03   shActionType     :jmpToTarget
   3:Fernbedienung_4_1_Btn_03   shCtDlyOff       :geLo
   3:Fernbedienung_4_1_Btn_03   shCtDlyOn        :geLo
   3:Fernbedienung_4_1_Btn_03   shCtOff          :geLo
   3:Fernbedienung_4_1_Btn_03   shCtOn           :geLo
   3:Fernbedienung_4_1_Btn_03   shOffDly         :0 s
   3:Fernbedienung_4_1_Btn_03   shOffTime        :111600 s
   3:Fernbedienung_4_1_Btn_03   shOffTimeMode    :absolut
   3:Fernbedienung_4_1_Btn_03   shOnDly          :0 s
   3:Fernbedienung_4_1_Btn_03   shOnTime         :111600 s
   3:Fernbedienung_4_1_Btn_03   shOnTimeMode     :absolut
   3:Fernbedienung_4_1_Btn_03   shSwJtDlyOff     :off
   3:Fernbedienung_4_1_Btn_03   shSwJtDlyOn      :on
   3:Fernbedienung_4_1_Btn_03   shSwJtOff        :onDly
   3:Fernbedienung_4_1_Btn_03   shSwJtOn         :dlyOff
Meine Frage: was bedeuten die ganzen Register/Values - gibt es von HM eine Beschreibung dazu? Ich denke nicht.

Ist Register 3 nun ein Link auf die Fernbedienung Btn 3? Den Link kann ich nun konfigurieren wie ich möchte richtig? Was heißt den sh und was ist lg. Du siehst schon irgendwie Fragen über Fragen.

Programiere doch einmal dein Licht und schicke die Register - im expert mode, dass ich alle habe.
Dann logge einmal die messages von dem, was nicht geht.

Ok, einen Schritt zurück - "im expert mode" ? Bin ich überfragt - was genau muss ich da tun.

Ich habe einen PBI-4 und einen HM-RC-4 testen tue ich derzeit mit dem RC.

Ach so, reagieren soll der Aktor schon auf "short" bzw. "short_Release" aber nicht auf "long" bzw. wenn ein "long" dann tue bei "short" (das vor long kommt) nichts. Also ist die default Einstellung erstmal ok = ein "devicepair single" reagiert auf short.

Viele Grüße
Arthur

[snoop]

Hallo Martin,

kleiner Nachtrag:

Wenn ich mich recht erinnere sollen alle auf "long" reagieren, nicht alle auf short.
also
set <licht> regSet shActionType off <button-name>
=> auf short wird nicht mehr reagiert.

Das habe ich ausprobiert - genau das ist es allerdings andersrum - also wie im vorherigen Beitrag beschrieben.

Womit ich mir noch schwer tue ist, was hat "shActionType off" damit zu tun, dass der Button nur noch auf long reagiert? Sorry das habe ich noch nicht verstanden. Muss ich dann für mein Fall ein "shActionType on" konfigurieren? Irgendiwe macht das für mich keinen Sinn?!

Viele Grüße
Arthur

[Martin Thomas Schrott]

Hi Arthur,

zwar der andere Martin, aber etwas Abwechslung bringt doch meh Schwung in die Sache? *smile*
du hast z.B.
3:Fernbedienung_4_1_Btn_03   lgActionType :jmpToTarget

Die 3er register sind die von den gepairten Geräten, also die, die dich interessieren. 3 hat nichts mit den Namen zu tun.

Die Fernbedienung hier ist:
Fernbedienung_4_1
und der Button z.B. 3 = Btn_03

Soweit zu dem was verbunden ist.

Du scheinst auch noch nicht ganz versanden zu haben, was du hier wo und wie einstellen kannst.

ein devicepair single hat nichts mit sort oder long zu tun! short und long sind immer aktiviert, wenn du neu gepaired hast.

sh steht für sort.
lg für long!

Was du nun machen kannst ist, dass du für bestimmte Geräte short oder long deaktivierst.

Ich nehme ein abstraktes kurzes beispiel!

Du hast einen button auf deiner Fernbedienung nr. 1 dieser soll zwei lampen einschalten, innen und außen.
Aber du willst innen mit short schalten und außen mit long.

Jetzt musst du alles mal pairen.
also devicepair mit innen und fb. Und devicepair außen und fb.

wenn du außen nicht mit short schalten willst musst du nun im kanal der außen lampe den register für deine fb für den btn_03 suchen der sh deaktiviert.
also sowas wie
3: fb1_Btn_03 shActionType
und den auf off stellen.
Bei der innen Lampe den lgActionType ausschalten.

Sonst schalten beide bei short und long.

Macht das so Sinn für dich?

lG
Martin

[Martin Thomas Schrott]

Hi nochmal,

nein kein shActionType on
das lässt du dann auf jumpToTarget!
Aber dafür setzt du lgActionType auf off.

Aber nur bei dem Kanal, der wirklich auf long nicht reagieren soll, nicht bei allen! Sonst schalten alle nur noch bei short!
logisch ? ?

[snoop]

Hallo Martin (der andere) ;o)

ok, deine (im nachhinein auch die von dem original :o) Martin) Erklärung macht für mich nun absolut sinn und ist soweit nachvollziehbar.

Ich hab das ganze ausprobiert es funktioniert so wie ich es brauche.
Mein Fehler bzw. was ich nicht wusste war:

sh steht für sort.
lg für long!

und die Tatsache das der Aktor per default auf beide events short/long reagiert. Ich dachte der Aktor reagiert auf short obwohl er auf long reagiert hat. Das hat aber (der original? ;o) Martin ja schon geschrieben - ich habe es irgendwie verdrängt.

Super, danke euch für eure Geduld jetzt bin ich 10 Schritte weiter.
Aber eine Frage ist noch nicht beantwortet:
"Wie kommt man an die Register und deren Bedeutung/Funktion?!" Andere Komponenten würden mich auch interessieren - für den HM-SEC-MDIR habe ich mir das auch mühsellig aus den google groups herausgefischt - ich meine man kann es auch mal ausprobieren, dafür muss man aber auch Zeit haben ;o).

Danke und Viele Grüße
Arthur

[martinp876]

Die Daten stehen in einem XML file.
in HM bekommest du eine erklaerung mir

get <device> regList - siehe Unten

a) zu beachten ist, dass die Register für die Entity ausgegeben werden. Also ein Device hat andere als ein Channel.Und die von Channels koennen unterschiedlich sein.
 Beispiel: ein 2-fach schalter hat ein device und 2 channels. Die Register der Channel sind identisch, die vom Device sind andere
 Bei einem TC sind alle 3 Channels unterschiedlich.
 Ob Channels andere Register haben kann man in der Regel an deren Unterscheidlichen Aufgaben sehen (rc19 mit 16 Buttons und einem Display...)

b) die Beschreibung ist kurz - und die Bedeutung ist auch in XML nicht beschrieben. Hier ist man auf externe Docu und sein Gefühl angewiesen.

c) Du kannst nur registerListen von devices ausgeben, die du definiert hast. Das ist aber kein Problem, definiere es einfach, lese aus und lösche wieder
define tst CUL_HM 333333
attr tst model HM-SEC-MDIR
attr tst subType motionDetector
get tst regList
define tst1 CUL_HM 33333301
get tst1 regList
define tst2 CUL_HM 33333302
get tst2 regList
delete tst  # alles wieder weg

d) zu beachten ist, das die register die aktuell dekodierten sind. Ich bemühe mich, viel einzubauen. Bei manchen kann aber auch etwas fehlen... MDIR sollte komplett sein

e) einige Register sind "literals" - man muss also den Inhalt als Namen angeben - die möglichkeiten stehen in options in der Beschreibung

f) die aktuellen Register werden mit
get device reg all
ausgegeben und muessen vorher mit
set device getConfig
dem device entlockt werden

Viel Spass


hier ein Beispiel eines Switch-Aktor channels - device hat andere Register



list:         register | range              | peer     |exp| description
   3: lgActionType     |   - to -           | required |   |  options:toggleToCntInv,off,toggleToCnt,jmpToTarget
   3: lgCtDlyOff       |   - to -           | required |exp| Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
   3: lgCtDlyOn        |   - to -           | required |exp| Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
   3: lgCtOff          |   - to -           | required |exp| Jmp on condition from Off options:geLo,between,outside,ltLo,geHi,ltHi
   3: lgCtOn           |   - to -           | required |exp| Jmp on condition from On options:geLo,between,outside,ltLo,geHi,ltHi
   3: lgCtValHi        |   0 to 255         | required |exp| Condition value high for CT table
   3: lgCtValLo        |   0 to 255         | required |exp| Condition value low for CT table
   3: lgMultiExec      |   - to -           | required |   | multiple execution per repeat of long trigger options:on,off
   3: lgOffDly         |   0 to 111600s     | required |exp| off delay
   3: lgOffTime        |   0 to 111600s     | required |exp| off time
   3: lgOffTimeMode    |   - to -           | required |exp| off time mode options:minimal,absolut
   3: lgOnDly          |   0 to 111600s     | required |exp| on delay
   3: lgOnTime         |   0 to 111600s     | required |exp| on time
   3: lgOnTimeMode     |   - to -           | required |exp| on time mode options:minimal,absolut
   3: lgSwJtDlyOff     |   - to -           | required |exp| Jump from delayOff options:on,off,dlyOn,no,dlyOff
   3: lgSwJtDlyOn      |   - to -           | required |exp| Jump from delayOn options:on,off,dlyOn,no,dlyOff
   3: lgSwJtOff        |   - to -           | required |exp| Jump from Off options:on,off,dlyOn,no,dlyOff
   3: lgSwJtOn         |   - to -           | required |exp| Jump from On options:on,off,dlyOn,no,dlyOff
   3: shActionType     |   - to -           | required |   |  options:toggleToCntInv,off,toggleToCnt,jmpToTarget
   3: shCtDlyOff       |   - to -           | required |exp| Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
   3: shCtDlyOn        |   - to -           | required |exp| Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
   3: shCtOff          |   - to -           | required |exp| Jmp on condition from Off options:geLo,between,outside,ltLo,geHi,ltHi
   3: shCtOn           |   - to -           | required |exp| Jmp on condition from On options:geLo,between,outside,ltLo,geHi,ltHi
   3: shCtValHi        |   0 to 255         | required |exp| Condition value high for CT table
   3: shCtValLo        |   0 to 255         | required |exp| Condition value low for CT table
   3: shOffDly         |   0 to 111600s     | required |exp| off delay
   3: shOffTime        |   0 to 111600s     | required |exp| off time
   3: shOffTimeMode    |   - to -           | required |exp| off time mode options:minimal,absolut
   3: shOnDly          |   0 to 111600s     | required |exp| on delay
   3: shOnTime         |   0 to 111600s     | required |exp| on time
   3: shOnTimeMode     |   - to -           | required |exp| on time mode options:minimal,absolut
   3: shSwJtDlyOff     |   - to -           | required |exp| Jump from delayOff options:on,off,dlyOn,no,dlyOff
   3: shSwJtDlyOn      |   - to -           | required |exp| Jump from delayOn options:on,off,dlyOn,no,dlyOff
   3: shSwJtOff        |   - to -           | required |exp| Jump from Off options:on,off,dlyOn,no,dlyOff
   3: shSwJtOn         |   - to -           | required |exp| Jump from On options:on,off,dlyOn,no,dlyOff

[Martin Thomas Schrott]

Hi auch nochmal,

am besten immer im wiki zuerst nachsehen, oft hat sich schon jemand die Mühe gemacht und alles verdeutscht.
Beim mdir bin ich miten im Testen aberdie Zeit arbeitet gegen mich. Daher ist dort noch nicht alles richtig erklärt - auch in der regList nicht.
Du hast gemeint du hast dir das erarbeitet / gesucht, kannst du mir deine Erkenntnisse und Erklärungen senden? Ev. spar ich mir dann ein paar zusätzliche Tests.Wäre super.

lG
Martin

[snoop]

Hallo zusammen,

eine kurze Zusammenfassung um den Thread abzuschließen und falls jemand lußt hat das nachzubauen:

Meine Idee ist es/war es die 4 Tasten Fernbedienung mit möglichst vielen Funktionen auszustatten (Es geht noch mehr aber es soll natürlich noch nutzbar sein).

#########################################
## Genutzte Komponenten:
#########################################
- 2 x Aktoren (HM-LC-SW2-FM) je 2 Kanal
- 1 x Fernbedienung (HM-RC-4)

#########################################
## Belegung der Tasten: Soll Zustand
#########################################
# Wird über Direkt pairing realsiert
Btn1 (short) = Fassadenbeleuchtung Strasse toggel
Btn2 (short) = Fassadenbeleuchtung Eingang toggel
Btn3 (short) = Fassadenbeleuchtung Terrasse toggel
Btn4 (short) = Fassadenbeleuchtung Garten toggel

# Wird mit FHEM Boardmitteln realisiert
Btn3 (long) = Gesamte Fassadenbeleuchtung aus
Btn4 (long) = Gesamte Fassadenbeleuchtung an

#########################################################################
##
## HIER NUN DER CODE
##
#########################################################################

#########################################################################
##  
##  Zweck.........: 1. Aktor für Fassadenbeleuchtung (Strassenseite -S- und Terasse -T-)
##  Standort......: Dachgeschoss
##  Typ...........:  
##  Installation..: 30.12.2012
##  Besonderheiten:
##                  
#########################################################################
define FD_ST_Beleuchtung_1 CUL_HM XXXXXX
attr FD_ST_Beleuchtung_1 devInfo 020100
attr FD_ST_Beleuchtung_1 firmware 1.9
attr FD_ST_Beleuchtung_1 hmClass receiver
attr FD_ST_Beleuchtung_1 model HM-LC-SW2-FM
attr FD_ST_Beleuchtung_1 room Aussenbeleuchtung
attr FD_ST_Beleuchtung_1 serialNr XXXXXXXXX
attr FD_ST_Beleuchtung_1 subType switch
#########################################################################
##  eigenes Log
#########################################################################
define FileLog_FD_ST_Beleuchtung_1 FileLog ./log/FD_ST_Beleuchtung_1-%Y.log FD_ST_Beleuchtung_1
attr FileLog_FD_ST_Beleuchtung_1 logtype text
attr FileLog_FD_ST_Beleuchtung_1 room Server

#########################################################################
##  Channel 01
#########################################################################
define FD_S_Beleuchtung_1_Sw_01 CUL_HM XXXXXX01
attr FD_S_Beleuchtung_1_Sw_01 eventMap on:An off:Aus
attr FD_S_Beleuchtung_1_Sw_01 model HM-LC-SW2-FM
attr FD_S_Beleuchtung_1_Sw_01 peerIDs YYYXXX01,XXXYYY01,
attr FD_S_Beleuchtung_1_Sw_01 room Aussenbeleuchtung
attr FD_S_Beleuchtung_1_Sw_01 subType switch
#########################################################################
##  eigenes Log
#########################################################################
define FileLog_FD_S_Beleuchtung_1_Sw_01 FileLog ./log/FD_S_Beleuchtung_1_Sw_01-%Y.log FD_S_Beleuchtung_1_Sw_01
attr FileLog_FD_S_Beleuchtung_1_Sw_01 logtype text
attr FileLog_FD_S_Beleuchtung_1_Sw_01 room Server

#########################################################################
##  Channel 02
#########################################################################
define FD_T_Beleuchtung_1_Sw_02 CUL_HM XXXXXX02
attr FD_T_Beleuchtung_1_Sw_02 eventMap on:An off:Aus
attr FD_T_Beleuchtung_1_Sw_02 model HM-LC-SW2-FM
attr FD_T_Beleuchtung_1_Sw_02 peerIDs YYYXXX03,XXXYYY03,
attr FD_T_Beleuchtung_1_Sw_02 room Aussenbeleuchtung
attr FD_T_Beleuchtung_1_Sw_02 subType switch
#########################################################################
##  eigenes Log
#########################################################################
define FileLog_FD_T_Beleuchtung_1_Sw_02 FileLog ./log/FD_T_Beleuchtung_1_Sw_02-%Y.log FD_T_Beleuchtung_1_Sw_02
attr FileLog_FD_T_Beleuchtung_1_Sw_02 logtype text
attr FileLog_FD_T_Beleuchtung_1_Sw_02 room Server

#########################################################################
##  
##  Zweck.........: 2. Aktor für Fassadenbeleuchtung (Eingangsbereich -E- und Garten -G-)
##  Standort......: Dachgeschoss
##  Typ...........:  
##  Installation..: 30.12.2012
##  Besonderheiten:
##                  
#########################################################################
define FD_EG_Beleuchtung_1 CUL_HM YYYYYY
attr FD_EG_Beleuchtung_1 devInfo 020100
attr FD_EG_Beleuchtung_1 firmware 1.9
attr FD_EG_Beleuchtung_1 hmClass receiver
attr FD_EG_Beleuchtung_1 model HM-LC-SW2-FM
attr FD_EG_Beleuchtung_1 room Aussenbeleuchtung
attr FD_EG_Beleuchtung_1 serialNr XXXXXXXXX
attr FD_EG_Beleuchtung_1 subType switch
#########################################################################
##  eigenes Log
#########################################################################
define FileLog_FD_EG_Beleuchtung_1 FileLog ./log/FD_EG_Beleuchtung_1-%Y.log FD_EG_Beleuchtung_1
attr FileLog_FD_EG_Beleuchtung_1 logtype text
attr FileLog_FD_EG_Beleuchtung_1 room Server

#########################################################################
##  Channel 01
#########################################################################
define FD_E_Beleuchtung_1_Sw_01 CUL_HM YYYYYY01
attr FD_E_Beleuchtung_1_Sw_01 eventMap on:An off:Aus
attr FD_E_Beleuchtung_1_Sw_01 model HM-LC-SW2-FM
attr FD_E_Beleuchtung_1_Sw_01 peerIDs YYYXXX02,XXXYYY02,
attr FD_E_Beleuchtung_1_Sw_01 room Aussenbeleuchtung
attr FD_E_Beleuchtung_1_Sw_01 subType switch
#########################################################################
##  eigenes Log
#########################################################################
define FileLog_FD_E_Beleuchtung_1_Sw_01 FileLog ./log/FD_E_Beleuchtung_1_Sw_01-%Y.log FD_E_Beleuchtung_1_Sw_01
attr FileLog_FD_E_Beleuchtung_1_Sw_01 logtype text
attr FileLog_FD_E_Beleuchtung_1_Sw_01 room Server

#########################################################################
##  Channel 02
#########################################################################
define FD_G_Beleuchtung_1_Sw_02 CUL_HM YYYYYY02
attr FD_G_Beleuchtung_1_Sw_02 eventMap on:An off:Aus
attr FD_G_Beleuchtung_1_Sw_02 model HM-LC-SW2-FM
attr FD_G_Beleuchtung_1_Sw_02 peerIDs YYYXXX04,XXXYYY04,
attr FD_G_Beleuchtung_1_Sw_02 room Aussenbeleuchtung
attr FD_G_Beleuchtung_1_Sw_02 subType switch
#########################################################################
##  eigenes Log
#########################################################################
define FileLog_FD_G_Beleuchtung_1_Sw_02 FileLog ./log/FD_G_Beleuchtung_1_Sw_02-%Y.log FD_G_Beleuchtung_1_Sw_02
attr FileLog_FD_G_Beleuchtung_1_Sw_02 logtype text
attr FileLog_FD_G_Beleuchtung_1_Sw_02 room Server

#########################################################################
#########################################################################
##  4-Tasten Fernbedienung
##  Zweck.........: Aussenbeläuchtung
##
##  Standort......: Wohnzimmer
##  Typ...........: HM-RC-4 (Weiß)
##  Installation..: 07.01.2013 4-Tasten-Fernbedienung
##  Besonderheiten:
#########################################################################

define FB_4_3 CUL_HM XXXXXX
attr FB_4_3 devInfo 040000
attr FB_4_3 firmware 1.3
attr FB_4_3 hmClass sender
attr FB_4_3 model HM-RC-4
attr FB_4_3 room Fernbedienungen
attr FB_4_3 serialNr XXXXXXXXXXX
attr FB_4_3 subType remote

#########################################################################
##  eigenes Log
#########################################################################
define FileLog_FB_4_3 FileLog ./log/FB_4_3-%Y.log FB_4_3
attr FileLog_FB_4_3 logtype text
attr FileLog_FB_4_3 room Server

#########################################################################
## rechter Button Reihe 1 OFF/LINKS
## Funktion......: Rollladen hoch im Wohnzimmer
## Besonderheiten: ACHTUNG, on und off sind im Wohnzimmer vertauscht
##                 wegen der Tasten auf dem Taster an dem Aktuator
#########################################################################
define FB_4_3_Btn_01 CUL_HM XXXXXX01
attr FB_4_3_Btn_01 model HM-RC-4
attr FB_4_3_Btn_01 peerIDs
attr FB_4_3_Btn_01 room Fernbedienungen

#########################################################################
## rechter Button Reihe 1 ON/RECHTS
## Funktion......: Rollladen hoch im Wohnzimmer
## Besonderheiten: ACHTUNG, on und off sind im Wohnzimmer vertauscht
##                 wegen der Tasten auf dem Taster an dem Aktuator
#########################################################################
define FB_4_3_Btn_02 CUL_HM 1C08F402
attr FB_4_3_Btn_02 model HM-RC-4
attr FB_4_3_Btn_02 peerIDs
attr FB_4_3_Btn_02 room Fernbedienungen

#########################################################################
## rechter Button Reihe 2 OFF/LINKS
## Funktion......: Rollladen hoch im Gästezimmer
## Besonderheiten: on=runter off=hoch
#########################################################################
define FB_4_3_Btn_03 CUL_HM 1C08F403
attr FB_4_3_Btn_03 model HM-RC-4
attr FB_4_3_Btn_03 room Fernbedienungen

define FB_4_3_Btn_03_offLong notify FB_4_3:FB_4_3_Btn_03.LongRelease.* set FD_S_Beleuchtung_1_Sw_01,FD_E_Beleuchtung_1_Sw_01,FD_T_Beleuchtung_1_Sw_02,FD_G_Beleuchtung_1_Sw_02 off
attr FB_4_3_Btn_03_offLong room Fernbedienungen

#########################################################################
## rechter Button Reihe 2 ON/RECHTS
## Funktion......: Rollladen hoch im Gästezimmer
## Besonderheiten: on=runter off=hoch
#########################################################################
define FB_4_3_Btn_04 CUL_HM 1C08F404
attr FB_4_3_Btn_04 model HM-RC-4
attr FB_4_3_Btn_04 room Fernbedienungen

define FB_4_3_Btn_04_onLong notify FB_4_3:FB_4_3_Btn_04.LongRelease.* set FD_S_Beleuchtung_1_Sw_01,FD_E_Beleuchtung_1_Sw_01,FD_T_Beleuchtung_1_Sw_02,FD_G_Beleuchtung_1_Sw_02 on
attr FB_4_3_Btn_04_onLong room Fernbedienungen

##########################################################
# Muss manuell ausgeführt werden also in der CMD Box
##########################################################
# Button 1
###################
#set FB_4_3_Btn_01 devicepair 0 FD_S_Beleuchtung_1_Sw_01 single set #Device pair single=toggel
#set FD_S_Beleuchtung_1_Sw_01 regSet lgActionType off FB_4_3_Btn_01 #Deaktiviere LongPress
###################
# Button 2
###################
#set FB_4_3_Btn_02 devicepair 0 FD_E_Beleuchtung_1_Sw_01 single set #Device pair single=toggel
#set FD_E_Beleuchtung_1_Sw_01 regSet lgActionType off FB_4_3_Btn_02 #Deaktiviere LongPress
###################
# Button 3
###################
#set FB_4_3_Btn_03 devicepair 0 FD_T_Beleuchtung_1_Sw_02 single set #Device pair single=toggel
#set FD_T_Beleuchtung_1_Sw_02 regSet lgActionType off FB_4_3_Btn_03 #Deaktiviere LongPress
###################
# Button 4
###################
#set FB_4_3_Btn_04 devicepair 0 FD_G_Beleuchtung_1_Sw_02 single set #Device pair single=toggel
#set FD_G_Beleuchtung_1_Sw_02 regSet lgActionType off FB_4_3_Btn_04 #Deaktiviere LongPress
#
#Abschließend:    set FD_ST_Beleuchtung_1 getConfig
#             set FD_EG_Beleuchtung_1 getConfig
##########################################################

#########################################
## Konfiguration der Fernbedienung: Änderung der longPress Werte
#########################################
set FB_4_3_Btn_01 getConfig
set FB_4_3_Btn_01 regSet longPress 1.2
#get FB_4_3_Btn_01 regList (optional)
#get FB_4_3_Btn_01 reg all (optional)

set FB_4_3_Btn_02 getConfig
set FB_4_3_Btn_02 regSet longPress 1.2
#get FB_4_3_Btn_02 regList (optional)
#get FB_4_3_Btn_02 reg all (optional)

set FB_4_3_Btn_03 getConfig
set FB_4_3_Btn_03 regSet longPress 1.2
#get FB_4_3_Btn_03 regList (optional)
#get FB_4_3_Btn_03 reg all (optional)

set FB_4_3_Btn_04 getConfig
set FB_4_3_Btn_04 regSet longPress 1.2
#get FB_4_3_Btn_04 regList (optional)
#get FB_4_3_Btn_04 reg all (optional)

#Jetzt die Anlerntaste(Resettaste auf der Rückseite) betätigen.

[martinp876]

Hallo Snoop,

super dass es klappt.

ein paar Anmerkungen udn Anregungen - nur damit niemand stolpert:

Attribute der Devices sollte man immer fhem setzen lassen. Damit meine ich
 - model
 - subtype
 - serial
 - firmware
 - devInfo
 - hmClass
das kommt alles beim druecken von Anlernen.

Sonstige attribute:
 - peerIDs  => sollte man immer von FHEM setzen lassen - also mit devicepair
 - subType ist fuer channels nicht notwendig
 - hmClass wird zu (fast) nichts gebraucht - werden ich evtl abschaffen, da es quasi nutzlos ist

Richtig ist natuerlich, dass die attribute in fhem.cfg gespeichert werden und man sie dort bearbeiten koennte.
Wenn du es so schreibst koennte jemand den Eindruck gewinnen, dass man durch setzen des
attr peerIDs
ein peering erstellen koennte. Das ist natuerlich schmarrn, da braucht man devicepair.

Empfehlen kann ich bei deinen switches ein
attr autoRegRead 1
zu setzen. Wie in der Anleitung beschrieben sollte es nur am device stehen, nicht an den Kanaelen

Logfiles solltest du (meine Meinung ) nur die anlegen, die dich auch interessieren. Die kosten Performance und machen nur sinn, wenn du sie auch nutzen willst. Sinnvoll ist m.E. auch, logfiles zusammenzufassen, also Gruppen von Schaltern sinnvoll in ein File zu schreiben. FHEM kann nicht sinnvoll einteilen, daher werden alle entities separat angelegt. Sollte der User ueberdenken.

Gruss
Martin