Pairen von HM-MOD-EM-8 mit HM-MOD-RE-8

[wendeling]

hallo,
ist eine pairen von HM-MOD-EM-8 mit HM-MOD-RE-8 möglich ?
wenn ja wie muss ich vorgehen?


gruß
wendelin

[KernSani]

Ich gehe mal davon aus, dass du diese Frage nicht stellen würdest, wenn du es nicht schon auf den normalen Wegen versucht hättest. Das wiederum verleitet mich zu der Annahme, dass die Frage im Homematic-Subforum besser aufgehoben wäre (verschieben über Button ganz unten links)
P.S.: Ich denke du meinst peeren, nicht pairen

[Pfriemler]

Da eine gewisse Sauberkeit in der Begriffssprache unabdingbar ist: ein Pairen der beiden ist nicht möglich.

Peeren aber wohl. Und wie genau vorzugehen ist, hängt von den gewünschten Gegebenheiten ab. Für eine 1:1-Spiegelung (die Aktorkanäle folgen genau dem Schaltzustand an den Eingängen des Sensors) sind eine Reihe Handgriffe mehr nötig als bspw. für das Toggeln (Impuls am Eingang ändert Schaltzustand am Aktor).
Aber prinzipiell sind die beiden ohne Kopfstände, mit FHEM-Bordmitteln, zu "verheiraten".
Details gegen Details!

Gesendet von meinem SM-G900FD mit Tapatalk

[oldman]

Hallo Pfriemler,
ich habe Interesse daran, die Kanäle zu peeren. Hoffe, dass dann das Aufwecken der Empfänger
etwas schneller geht. Habe das auf verschiedenen Wegen erfolglos probiert.
Gerne Details falls die Message entdeckt wird.
Gruß

[Pfriemler]

So, wieder ein Fall von Threadkapern ... aber was solls...

oldman, was genau willst du mit welchen Geräten erreichen?

Das Aufwecken des Empfängers (Re-8) geht nicht schneller als sonst, wie auch. Es ist ein Burst-Device, also es muss ein Burst gesendet werden, das dauert. Das kann man auch nicht abkürzen. Einzige Möglichkeit: Wenn man mehrere Kanäle eines RE-8 immer gleichzeitig schalten will, kann man sie alle mit einem Sensor pairen - ich hatte hier schon irgendwo mal beschrieben, wie ich das mit einem Re-8 und einem virtuellen Button gelöst habe... finde es aber gerade nicht.

[oldman]

Ich habe an den Sendereingängen Bewegungsmelder. Die Eingänge laufen im Sensormode.
Wird ein 'closed' erkannt, werden per notify zwei Empfängerkanäle aktiviert (on-for-timer).
Einer schaltet die entsprechende Beleuchtung, der andere sperrt  den Sendereingang mit separater Hardware
für eine etwas kürzere Zeit ab. Das verhindert Duty Cycle-Probleme.
Im Differenzzeitfenster kann ein Nachtriggern erfolgen. Das hat mit FS20 einwandfrei funktioniert.

Jetzt bin ich auf Homematic umgestiegen wegen der höheren Sicherheit und weil FS20 nicht mehr produziert wird.

Ergebnis: ich bin aus dem zu beleuchtenden Bereich wieder raus, wenn das Licht angeht.

Dein Versuch bei ELV, ein Registerbit zu spendieren, das den Schlafmode bei Netzbetrieb verhindert, war ja leider
nicht erfolgreich, wenn ich das richtig verstanden habe.

Frage: wie lange dauert es, bis ein Empfangskanal wieder einschläft. Wenn es im Minutenbereich wäre, könnte man
eventuell mit einem Ping den Empfänger wach halten.
Ansonsten bin ich ziemlich ratlos.

[Pfriemler]

So, jetzt macht das langsam Sinn.

Erstens: Für eine regelmäßige (also mehrmalige tägliche) Benutzung von Aktoren würde ich nur in Ausnahmefällen den Re-8 nehmen, vor allem wenn ohnehin Dauerstromversorung existiert. Die Bursts sind weniger aus funktechnischer Sicht ein Problem, sondern mehr aus funkhygienischer Sicht: Ein Burst weckt immer alle batterieversorgten Geräte auf, also auch jeden Heizkörper- und Wand-Thermostaten, jeden anderen Batterie-Aktor, auch diese nette mechanische Statusanzeige, und was es noch alles so gibt. Das reduziert die Lebensdauer der Batterien nicht unerheblich. Eventuell wäre der 4-fach Relaisaktor (HM-LC-Sw4-PCB/WM (oder so ähnlich) hierfür besser geeignet.

Zweitens: Was ist "kürzere Zeit"? Das EM-8 kennt das Register "eventFilterTime" in jedem Kanal (von 0 bis 7620 Sekunden, also weit mehr als 2 Stunden), in der erneute Aktivierung der Eingänge nicht zu einer erneuten Sendung führt. Du könntest dieses Register nutzen und die Hardwaredeaktivierung auf diese Weise komplett umgehen, das spart schon mal einen Aktorkanal. Jeder normale Homematic-Bewegungsmelder arbeitet ohnehin so, dass er nach einer Bewegungserkennung default 4 Minuten lang keine erneute Bewegung per Funk sendet (erkennen tut er sie wohl).

Drittens: Zur Zeitminimierung wäre das direkte Peeren des EM-8 mit dem Aktor quasi Pflicht. Danach wird der Aktor bei jedem erneuten Trigger erst einmal toggeln (d.h. bei erneuter Bewegung ausschalten), aber das kann man mit der Statemachine leicht korrigieren, indem am Aktor (für die Beleuchtung) shSwJtOn von (default) "dlyOff" auf "on" geändert wird, mit shOnTime legt man die gewünschte Einschaltdauer fest, beides speziell für den Peer (also den Sensorkanal vom EM-8). Die Verzögerung sollte dann nicht größer als 0,5 Sekunden sein.

Viertens: Der Empfänger schläft quasi sofort wieder ein, ich denke er wird unmittelbar nach dem Absenden der Quittung an den Sender abegschaltet und nur Sekunden später geht auch der Prozessor wieder schlafen, wenn er nichts weiter zu tun hat.

[oldman]

Danke für die ausführliche Info. Alles Neuland (obwohl Pflichtliteratur gelesen).

Das muss ich jetzt erst einmal verdauen. Ein 70 Jahre altes Hirn arbeitet langsam.
Wo findet man die interessanten Daten über die Interna der Register?
Wiki ist sehr spartanisch und die ELV-Anleitung bietet noch weniger.

Deine Bemerkung 'Drittens' wird mir weiterhelfen, vorausgesetzt du beantwortest meine Eingangsfrage
wie das Peeren EM-Re bewerkstelligt wird. Ich habe das nicht hinbekommen.

Unklar ist mir, wieso ohne die beschriebene HW (zwei NANDs), die den EM-Eingang sofort nach Ansprechen wieder auf 'open'
bringt mein Raspi unentwegt auf das notify PIR:closed reagiert und den HM-MOD-UART schnell in Überlast bringt.
Manchmal so extrem, dass sich die VCCU nicht mehr initialisieren lässt, nicht mal durch Restart von fhem, nicht durch shutdown -r,
nur durch Stromlosmachen des Raspi.

Zum Thema Funkhygiene: bis auf die nette Statusanzeige, die ich zum Aktivieren des Henningschen Alarmmoduls verwende und die
Li-Akku-Rauchmelder hängt alles an Netzteilen.

[Pfriemler]

Also oldman ist offenbar keine fake.  Dann wollen wir mal von hinten:

Bursts: Die Li-Funkmelder brauchen besondere Bursts, die werden also m.W. bei "normalen" Bursts, wie sie die Batterie-Aktoren benötigen, nicht so sehr belastet. Ich vergaß aber zu erwähnen, dass die Bursts auch fremde Systeme, also bspw. HomeMatic bei einem Nachbarn, belasten. Das nur am Rande.

Vieles zu den Registern und wie man sie liest und setzt findet sich im Homematic-Anhang des "Einsteiger-Doc"-PDFs. Das muss man ca. 10x lesen bis man es halbwegs verstanden hat. Ich habe zwar etwa 20 Jahre weniger auf der Uhr, aber auch da geht das nicht mehr so schnell. Ich habe etwa zwei Jahre gebraucht für ein grundlegendes Verständnis wie was funktioniert.

Das erste peering ist das schwerste. Dewegen und in dem Zusammenhang mit der notify-Auslösung gib uns doch bitte mal (fein säuberlich in code-Tags) die lists von notify und einem Sensor-Aktor-Pärchen, vielleicht auch eine Handskizze der Schaltung. Das Problem der Funklast liegt irgendwo dort. Normalerweis erzeugt das keine Probleme.
Mit den Namen der Geräte kann ich Dir auch mal die Befehle vorbuchstabieren an einem konkreten Beispiel. Nur bitte etwas Geduld, ich muss nebenbei noch ein bisschen arbeiten...

[oldman]

Du bist ja wirklich schnell.
Hier die Auszüge aus dem config-file:
Der Sender und ein Kanal

Code Auswählen Erweitern

define OG_Flur_on notify HM_S31:closed set HM_Empf51 on-for-timer 25;; set HM_Empf45 on-for-timer 30
attr OG_Flur_on room Licht_OG

#Achtfachsender HM-MOD-Em-8
define HM_Sender3 CUL_HM 541F89
attr HM_Sender3 IODev myHmUART
attr HM_Sender3 IOgrp vccu:myHmUART
attr HM_Sender3 autoReadReg 4_reqStatus
attr HM_Sender3 expert 2_raw
attr HM_Sender3 firmware 1.1
attr HM_Sender3 group Sender
attr HM_Sender3 model HM-MOD-Em-8
attr HM_Sender3 room HM
attr HM_Sender3 serialNr OEQ0176494
attr HM_Sender3 subType remote
attr HM_Sender3 webCmd getConfig:clear msgEvents

#Kanal 1
define HM_S31 CUL_HM 541F8901
attr HM_S31 alias 31Flur
attr HM_S31 devStateIcon closed:general_an@green open:general_aus@red
attr HM_S31 group MotionSensor,Sender
attr HM_S31 icon IR@orange
attr HM_S31 model HM-MOD-Em-8
attr HM_S31 peerIDs 00000000,
attr HM_S31 room HM,Licht_OG


Der Empfänger und der Helper-Kanal

Code Auswählen Erweitern



#Achtfachempfänger HM-MOD-Re-8
define HM_Empf5 CUL_HM 56DC1C
attr HM_Empf5 IODev myHmUART
attr HM_Empf5 IOgrp vccu:myHmUART
attr HM_Empf5 autoReadReg 4_reqStatus
attr HM_Empf5 expert 2_raw
attr HM_Empf5 firmware 1.2
attr HM_Empf5 group Empfänger
attr HM_Empf5 model HM-MOD-Re-8
attr HM_Empf5 msgRepeat 1
attr HM_Empf5 room HM
attr HM_Empf5 serialNr OEQ0209190
attr HM_Empf5 subType switch
attr HM_Empf5 webCmd getConfig:clear msgEvents

#Kanal 1
define HM_Empf51 CUL_HM 56DC1C01
attr HM_Empf51 alias 51FlurHelper
attr HM_Empf51 group Empfänger,Helper
attr HM_Empf51 model HM-MOD-Re-8
attr HM_Empf51 peerIDs 00000000,
attr HM_Empf51 room HM,Licht_OG
attr HM_Empf51 webCmd on:off


Der Empfänger und der Lichtschalt-Kanal

Code Auswählen Erweitern



#Achtfachempfänger HM-MOD-Re-8
define HM_Empf4 CUL_HM 56E0D1
attr HM_Empf4 IODev myHmUART
attr HM_Empf4 autoReadReg 4_reqStatus
attr HM_Empf4 expert 2_raw
attr HM_Empf4 firmware 1.2
attr HM_Empf4 group Empfänger
attr HM_Empf4 model HM-MOD-Re-8
attr HM_Empf4 msgRepeat 1
attr HM_Empf4 room HM
attr HM_Empf4 serialNr OEQ0208001
attr HM_Empf4 subType switch
attr HM_Empf4 webCmd getConfig:clear msgEvents

#Kanal 5
define HM_Empf45 CUL_HM 56E0D105
attr HM_Empf45 alias 45Flur
attr HM_Empf45 group Empfänger,Licht_OG
attr HM_Empf45 icon light_off-for-timer@yellow
attr HM_Empf45 model HM-MOD-Re-8
attr HM_Empf45 peerIDs 00000000,
attr HM_Empf45 room HM,Licht_OG,Übersicht
attr HM_Empf45 webCmd on:off


Und hier noch ein Bildchen der Zusatz-HW (ohne Pullup-Widerstände)
Die verwendeten PIR sind 1Euro-Teile aus China mit Open Collector,
ähnlich wie PIR13 von ELV, nur billiger.

[Pfriemler]

Das hilft schon mal beim Verstehen. Leider fehlen noch die derzeitig steuernden Notifys, die hätte ich aber gern zwecks Bestimmung der Mehrfachauslösung, Einschaltdauern etc. Die kopierten raw definitions (bzw. die gleichlautenden Teile aus der fhem.cfg) sind nur bedingt hilfreich. Viel hilfreicher sind die kompletten list-Ausgaben. Der Senderkanal beispielsweise ist dann wohl "HM_S31", als Kanal 1 des Gerätes "HM_Sender3". Also "list HM_S31" in die Eingabezeile und das Ergebnis aus dem Browser per copy&paste in die Codetags. In diesen Lists sind dann nämlich auch die aktuell bekannten Eigenschaften des Gerätes enthalten, Klarschriftnamen der peers, sowie - und das ist hier das Wichtige - aktuelle Registerwerte. So möchte ich bspw. kontrollieren, ob am Sender pairCentral korrekt ist (das wäre unter "list HM_Sender3" zu sehen) und in welchem genauen Modus die Kanäle stehen.

Im konkreten Beispiel ist also HM_S31 der Sender für den Bewegungsmelder. Ich vermute nun ein Notify, welches bei Aktivierung Kanal 1 des HM_Empf5 für eine bestimmte Zeit einschaltet und damit den PIR vom HM_S31 "abklemmt". Eingang des ersten NAND (Inverter) normal H, PIR bei Auslösung auf L, Ausgang H. Ist der Ausgang des Re-8 nicht aktiv, ergeben beide H zusammen L am Ausgang - ist der am EM-8 an einem Spannungseingang oder an einem Tastereingang angeschlossen? Am Tastereingang wäre aktuell nicht gut, wenn die NAND mit mehr als 3 Volt gespeist sind, da der keine Fremdspeisung verträgt. Am Spannungseingang würde das H hingegen eine dauerhafte Aktivierung auslösen - schadet nichts, wenn Versorgungsspannung dauerhaft da ist, aber die Logik wäre andersherum - das ist wichtig für die richtige Zusatzprogrammierung beim Peeren.
Der aktivierte Helper kippt dann den Ausgang des zweiten NAND, wenn ich das richtig verstanden habe, und sorgt dafür, dass erneute PIR-Impulse nicht mehr "durchkommen"

Diese Konstruktion halte ich für komplett ersetzbar, indem man den open-collector-Ausgang des PIR direkt an den Tastereingang (TA1) anschließt und die Filterzeit des Eingangs passend setzt. Wenn also der Helperkanal bspw. den PIR für 30 Sekunden deaktiviert, so erreicht man mit

Code Auswählen Erweitern

set HM_S31 regSet eventFilterTime 30
das gleiche Verhalten - nach einer übermittelten Änderung wird der Eingang für 30 Sekunden ignoriert. Helperkanal und die NANDs wären obsolet.

Zweitens, wichtig!: Welche Impulse sendet der PIR? pulst er bei jeder erkannten Bewegung kürzer als 2 Sekunden oder bleibt er bei erkannter Bewegung länger eingeschaltet? In erstem Fall könnte die Betriebsart "remote" mit einer Verlängerung des longPress-Zeitraums auf 2 Sekunden helfen - alles was den Eingang kürzer aktiviert, ist dann ein kurzer Trigger (short) beim Senden - die Aktoren unterscheiden ja kurze und lange Tastendrücke und reagieren anders. Bleibt der Ausgang des PIR länger aktiv, so muss der Sensoreingang am EM-8 zwingend in die Betriebsart "sensor" gebracht werden, den aktuellen Wert verrät das Register "triggerMode". Feinheiten zu den drei Betriebsarten im Wiki beim EM-8.

Hier könnte auch ein Funkproblem lauern: wenn der Eingang des EM-8 noch auf "button" steht, so funkt das Modul wiederholt long-Trigger bis der Helperkanal abschaltet. Auch das kostet anständig Funklast, besonders wenn das Notify auch hier brav jeden Impuls pariert.

Drittens: Das Notify muss das Ereignis genau abfassen, ideal ist Reaktion auf das Register "contact". Eine Statusänderung liefert bei unpassender Notify-Definition bis zu 10 Trigger mit entsprechend häufiger Auslösung. Dass da das Sendelimit schnell erreicht ist, liegt auf der Hand. Aber wir wollen ja eh komplett vom Notify weg...

Also: ich hätte gern die Lists von HM_S31 und HM_Sender3 sowie die aller derzeit die Trigger verarbeitenden Notifys (hier reicht dann aber wirklich der Teil aus dem Kasten bei der DEF oder die "RAW definition"). Außerdem eine Antwort auf die Frage, ob der PIR kurzfristig direkt an das EM-8 gepinnt werden kann (die Leitungslängen sollten maximal 3 Meter sein, sonst wären zusätzliche Kniffs nötig). Wenn die NANDs drin bleiben sollen (wo sie auch ohne den Helperkanal kein Hindernis darstellen), dann die Info ob der Ausgang des NANDs an "TA1" oder "IN1" angeschlossen ist.
Ich denke dann hätte ich alle nötigen Infos, um mal einen Satz regSets zusammenzustellen.

edit: Der Verbeib der NANDs ist wie gesagt nicht hinderlich, evtl. sogar nützlich. Sollte später das Auslösen des PIR bewusst unterbunden werden (etwa helligkeitsbedingt), so ließe sich der Helperkanal weiterhin aus FHEM als "Hauptschalter" benutzen - er muss dann nur nicht bei jedem Schaltvorgang mitlaufen.

[oldman]

Mann bist Du fleißig! Respekt.

Die Helper sind an die TA-Eingänge geklemmt. Das mit der Fremdspannung war mir nicht bekannt.
Ich habe erst mal das Bord mit der Zusatz-HW abgesteckt. Soll ja nichts kaputt gehen.
Es gibt noch Wandtaster für jede Lampe als Fallback, die direkt an den jeweiligen Re-Eingang gehen.
Ich habe also Zeit beim Versuch, eine Lösung zu finden.
Wenn ich die Spannungseingänge nutze, dann muss ich noch einen Inverter nachschalten, wenn ich das richtig verstanden habe.
Also dann wäre mir der komplette Wegfall der Zusatz-HW sympatischer.

Die PIR pulsen nicht, sie senden was sie empfangen. Wenn man  sich im Raum bewegt pulst das auch schon mal, aber eher 'long'.
Die Kanäle befinden sich im Sensor-Mode. Das war ja im WIKI beschrieben.

Es gibt nur ein steuerndes Notify, das steht in meinen Lists ganz oben. Es wertet den STATE aus (closed).
Hast Du vllt bei dem Wust der redundanten Informationen übersehen.
Ich übe jetzt erst einmal um die gewünschten Infos einzusammeln. Kann dauern, aber wie gesagt - es ist nicht eilig.

[oldman]

Hier die Lists

Code Auswählen Erweitern

Internals:
   DEF        541F8901
   NAME       HM_S31
   NOTIFYDEV  global
   NR         691
   NTFY_ORDER 50-HM_S31
   STATE      open
   TYPE       CUL_HM
   chanNo     01
   device     HM_Sender3
   READINGS:
     2018-01-12 18:08:41   R-sign          off
     2018-01-14 16:40:43   contact         open (to vccu)
     2018-01-14 16:40:43   state           open
     2018-01-12 18:05:42   trigger         Short_4
     2018-01-14 16:40:43   trigger_cnt     97
   helper:
     getCfgList all
     getCfgListNo ,4
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   alias      31Flur
   devStateIcon on.*:general_an@green off:general_aus@red
   group      MotionSensor,Sender
   icon       IR@orange
   model      HM-MOD-Em-8
   peerIDs    00000000,
   room       HM,Licht_OG

Der Sender ist gepaired, zeigt aber keine Register an, seltsam.

Code Auswählen Erweitern

Internals:
   DEF        541F89
   IODev      myHmUART
   NAME       HM_Sender3
   NOTIFYDEV  global
   NR         686
   NTFY_ORDER 50-HM_Sender3
   STATE      set_reset
   TYPE       CUL_HM
   channel_01 HM_S31
   channel_02 HM_S32
   channel_03 HM_S33
   channel_04 HM_S34
   channel_05 HM_S35
   channel_06 HM_S36
   channel_07 HM_S37
   channel_08 HM_S38
   protCmdPend 18 CMDs_pending
   protState  CMDs_pending
   READINGS:
     2018-01-12 18:27:09   CommandAccepted yes
     2018-01-12 18:27:07   D-firmware      1.1
     2018-01-12 18:27:07   D-serialNr      OEQ0176494
     2018-01-12 18:08:41   PairedTo        0x1A2B3C
     2018-01-12 18:08:41   R-pairCentral   0x1A2B3C
     2018-01-14 14:36:44   alive           yes
     2018-01-16 16:00:59   battery         ok
     2018-01-14 14:36:44   powerOn         2018-01-14 14:36:44
     2018-01-14 14:36:44   recentStateType info
     2018-01-17 16:58:25   state           set_reset
   cmdStack:
     ++A0011A2B3C541F8900040000000000
     ++A0011A2B3C541F8901040000000001
     ++A0011A2B3C541F890103
     ++A0011A2B3C541F8902040000000001
     ++A0011A2B3C541F890203
     ++A0011A2B3C541F8903040000000001
     ++A0011A2B3C541F890303
     ++A0011A2B3C541F8904040000000001
     ++A0011A2B3C541F890403
     ++A0011A2B3C541F8905040000000001
     ++A0011A2B3C541F890503
     ++A0011A2B3C541F8906040000000001
     ++A0011A2B3C541F890603
     ++A0011A2B3C541F8907040000000001
     ++A0011A2B3C541F890703
     ++A0011A2B3C541F8908040000000001
     ++A0011A2B3C541F890803
     ++A0111A2B3C541F890400
   helper:
     HM_CMDNR   121
     cfgChkResult No regs found for:HM_Sender3


     mId        00D9
     rxType     16
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +541F89,02,00,00
       rxt        2
       vccu       vccu
       p:
         541F89
         00
         00
         00
       prefIO:
         myHmUART
     mRssi:
       mNo
     prt:
       bErr       0
       sProc      2
     q:
       qReqConf
       qReqStat
     role:
       dev        1
     tmpl:
   nb:
     cnt        1
Attributes:
   IODev      myHmUART
   IOgrp      vccu:myHmUART
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   group      Sender
   model      HM-MOD-Em-8
   room       HM
   serialNr   OEQ0176494
   subType    remote
   webCmd     getConfig:clear msgEvents

Deshalb hier das Listing des Senders im Erdgeschoss (identische Konfiguration). Wir können auch damit spielen.

Code Auswählen Erweitern

Internals:
   CHANGED
   DEF        3D63CF
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     32
   NAME       HM_Sender1
   NOTIFYDEV  global
   NR         488
   NTFY_ORDER 50-HM_Sender1
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_S11
   channel_02 HM_S12
   channel_03 HM_S13
   channel_04 HM_S14
   channel_05 HM_S15
   channel_06 HM_S16
   channel_07 HM_S17
   channel_08 HM_S18
   lastMsg    No:00 - t:10 s:3D63CF d:1A2B3C 06000000
   myHmUART_MSGCNT 32
   myHmUART_RAWMSG 0501003400A6103D63CF1A2B3C06000000
   myHmUART_RSSI -52
   myHmUART_TIME 2018-01-17 16:46:09
   protLastRcv 2018-01-17 16:46:09
   protSnd    48 last_at:2018-01-17 16:46:09
   protState  CMDs_done
   rssi_at_myHmUART cnt:32 lst:-52 min:-59 avg:-50.78 max:-48
   READINGS:
     2018-01-17 14:07:03   CommandAccepted yes
     2018-01-17 14:07:30   D-firmware      1.1
     2018-01-17 14:07:30   D-serialNr      MEQ0782481
     2018-01-17 16:16:20   PairedTo        0x1A2B3C
     2018-01-17 14:07:31   R-pairCentral   0x1A2B3C
     2018-01-17 16:16:20   RegL_00.          02:01 05:00 0A:1A 0B:2B 0C:3C 12:00 14:03 18:00  00:00
     2018-01-17 16:46:09   alive           yes
     2018-01-17 16:46:09   battery         ok
     2018-01-17 16:46:09   powerOn         2018-01-17 16:46:09
     2018-01-17 16:46:09   recentStateType info
     2018-01-17 16:46:09   state           CMDs_done
   helper:
     HM_CMDNR   0
     PONtest    0
     cSnd       011A2B3C3D63CF08040000000001,011A2B3C3D63CF0803
     cfgChkResult No regs found for:

HM_Sender1 type:remote -
list:peer register         :value
   0:      ledMode          :off
   0:      localResDis      :off
   0:      lowBatLimitBA2   :0 V
   0:      pairCentral      :0x1A2B3C
   0:      transmDevTryMax  :3



     mId        00D9
     rxType     16
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3D63CF,00,00,00
       nextSend   1516203969.68948
       rxt        2
       vccu       vccu
       p:
         3D63CF
         00
         00
         00
       prefIO:
         myHmUART
     mRssi:
       mNo        00
       io:
         myHmUART   -50
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat
     role:
       dev        1
     rpt:
       IO         myHmUART
       flg        A
       ts         1516203969.39791
       ack:
         HASH(0x2859180)
         0080021A2B3C3D63CF00
     rssi:
       at_myHmUART:
         avg        -50.78125
         cnt        32
         lst        -52
         max        -48
         min        -59
     shadowReg:
     tmpl:
   nb:
     cnt        1
Attributes:
   IODev      myHmUART
   IOgrp      vccu:myHmUART
   autoReadReg 4_reqStatus
   event-on-change-reading 1
   expert     2_raw
   firmware   1.1
   group      Sender
   model      HM-MOD-Em-8
   room       HM
   serialNr   MEQ0782481
   subType    remote
   webCmd     getConfig:clear msgEvents

Und noch eine Antwort auf die Frage zum Direktanschluss der PIR an den EM: habe ich probiert weil ich dachte dass der Sensormode Funküberlast verhindert.
Hat er nicht, war relativ schnell Funkstille.
Die Leitungslängen der PIR sind teilweise deutlich länger als 3 Meter. Vielleicht schwingt das was. An welche Kniffs denkst Du? Kondensator?
Ich werde gelegentlich mal ein Oszi ranhängen.

[Pfriemler]

Der Sender ist gepaired, zeigt aber keine Register an, seltsam.

Nicht wirklich. Bitte das Attribut "expert" beachten, wenn man es auf "1_allRegs" setzt und anschließend nochmal ein "set <geraet> getConfig" ausführen lässt, wird die Liste schnell vollständiger.
Im ersten List hast Du einen Senderkanal, im dritten den des (anderen) Gerätes. triggerMode kann ich daher auch jetzt nicht prüfen, aber wenn Du "sensor" eingestellt hast, müsste das auch so zu lesen sein.

... Direktanschluss der PIR an den EM: habe ich probiert weil ich dachte dass der Sensormode Funküberlast verhindert.
Hat er nicht, war relativ schnell Funkstille.

Naja - wenn der PIR jede kleine erkannte Bewegung als mehr oder weniger langen Impuls liefert, wird das schon ein Funkfeuerwerk, wenn man sich in dem Bereich bewegt. Deswegen ist die Filterzeit mehr als sinnvoll.

Code Auswählen Erweitern

define OG_Flur_on notify HM_S31:closed set HM_Empf51 on-for-timer 25;; set HM_Empf45 on-for-timer 30
Daraus lese ich 25 s Filterzeit (effektiv sind es mehr, weil der Re-8 kein sauberes Timing hat, die Laufzeiten sind ca 1,3x länger.) Damit würde der schon von mir erwähnte Befehl fast genau passen.

Also: gesetzt den Fall, der PIR schließt den Tastereingang mit seinem open-collector. Dann erkennt der EM-8 auf "closed" bei erkannter Bewegung und sendet einen Trigger mit niedriger Wertangabe (ist nicht wirklich 0, spielt hier aber keine Rolle). Dafür muss eine Auslösebedingung beim Aktor geändert werden, außerdem soll die zweite Flanke des PIR-Signals nichts bewirken.

Vor dem Beginn des Programmierens müssen die Register vollständig vorhanden sein, also wie o.g. "set HM_S31 getConfig" und bitte den Taster auf dem Sendemodul drücken, was von einem hektischen gelben Blinken mit abschließendem Grün gefolgt werden sollte. 

Ungetestet und aus dem Kalten heraus mal diesen Satz probieren (<-- sind nur Erläuterungen, nicht mit eingeben)

Code Auswählen Erweitern


attr OG_Flur_on disable 1                    <- das deaktiviert das Notify, zur Reaktivierung 0 anhängen oder das Attribut löschen
set HM_S31 regSet triggerMode sensor         <- wenn nicht schon geschehen, Umschaltung auf Mode sensor am Sensormodul
set HM_S31 peerChan 0 HM_Empf45 single set   <- legt die Direktverknüpfung mit dem Lichtschaltkanal an

Spätestens jetzt ist es Zeit für einen Druck auf den Konfigurationsknopf am Sender. Die Befehle müssen abgearbeitet werden, dazu in "HM_Sender3" (also dem Gerät sehen ob der Status nicht bei "CMDs_processing" oder ähnlichem steht, sondern "CMDs_done".

Nun müssen wir noch ein paar Dinge anpassen. Das Zeitfenster zwischen der Einschaltzeit des Lichts und der Freigabe der Wiedererkennung von Bewegung liegt mit Deinem Notify bei nur 5 Sekunden, das ist arg knapp. Ich würde dort eher 10 Sekunden Zeit lassen, also Filterzeit auf 20 Sekunden verkürzen, ggf. noch eine längere Einschaltzeit vorsehen. Außerdem soll die Einschaltdauer der Lampe gesetzt werden:

Code Auswählen Erweitern

set HM_S31 regSet eventFilterTime 20         <- Filterzeit am Sender auf 20 Sekunden setzen (solange werden keine Bewegungen gesendet)
set HM_Empf45 regSet shOnTime 30 HM_S31      <- begrenzt die Einschaltzeit durch HM_S31 auf 30 Sekunden


Damit der Aktor auch auf die richtigen Signale reagiert, nun die Anpassung auf Auslösung bei "closed":

Code Auswählen Erweitern

set HM_Empf45 regSet shCtOff ltLo HM_S31     <- Aktor reagiert auf Übergang "open">"closed" (also erste Flanke des PIR-Signals)
set HM_Empf45 regSet shCtOn ltLo HM_S31      <- ... dito, also für beide Schaltzustände, führt zum "Nachtriggern" des noch eingeschalteten Lichts


Sollen die NANDs und der Helperkanal zur Maskierung aus FHEM beibehalten werden (wobei es dann keinen zusätzlichen Inverter bräuchte), gäbe es auch die Möglichkeit, den Ausgang statt an TA1 an IN1 zu setzen. Dann ist der Normalzustand "closed" und wird bei Bewegung "open". In diesem Fall wären die beiden letzten Programmierungen shCtOn bzw ~off NICHT auszuführen.

Nun bedarf es noch eines kleinen Eingriffs, um das Schaltverhalten anzupassen: bei "single set" sorgen die Trigger für ein wechselseitiges Ein- und Ausschalten, der Aktor soll aber bei einem Trigger (also erkannter Bewegung) immer einschalten. Also sagen wir dem Aktor, dass er sich, wenn schon eingeschaltet, nicht aus-, sondern nochmal einschalten soll:

Code Auswählen Erweitern

set HM_Empf45 regSet shSwJtOn on HM_S31      <- bleibe bei Trigger an, wenn schon eingeschaltet

Vielleicht auch mal diesen Wiki-Artikel vorweg lesen, um eine dürftige Einführung in die Materie zu bekommen...

Bliebe das mit den Leitungslängen ... kleiner (Entstör-)Kondensator könnte helfen, alternativ ein zusätzlicher Pullup auf max. 3V, etwa mit einem Spannungsteiler von der Versorgung her. Oszi wird nicht viel bringen, weil es ja eher um die Vermeidung von Fehlauslösungen durch unvorhersehbare Störereignisse geht. Das wäre dann schon Zufall, gerade so einen Spike zu erwischen.

Eine Unsauberheit bliebt noch: die normalerweise auf 0 Sekunden getimten Zwischenzustände dlyOn und dlyOff müssten mit berücksichtigt werden - aber vielleicht übergeht der Aktor diese Zwischenzustände bei 0 komplett und ordnet Trigger immer dem Folgezustand zu.

So, wenn ich was übersehen habe, bitte Hinweis.

[oldman]

Erst einmal vielen Dank für die spendierte Zeit.
Also ich gehe davon aus, dass Dir das Spaß macht - sonst hätte ich ein schlechtes Gewissen.

Da ist viel Futter, auch weil mir die vielen regsets mit den resultierenden Möglichkeiten nicht bekannt sind.
Schön wäre hier eine Übersicht über den Zauberkasten.
Ich werde also erst einmal den Wiki-Artikel und den Homematic-Anhang im Maas-pdf studieren und versuchen, das zu verstehen.

Dann erst teste ich Deine Vorschläge, die so erst einmal sehr plausibel klingen. Zum Beispiel das Ausfiltern der Flanken und
programmierbare Sperrzeiten eröffnen einfache Lösungen. Ich bin da sehr neugierig.

Mit dem Pairen der Sender hatte ich große Probleme, meist blieb es beim set_pairing oder es
kommt pairedTo aber regTable ist leer. Alle Kombinationen von hmPairForSecond, getconfig und Knöpfchen drücken probiert,
Das Ergebnis ist schlicht nicht nachvollziehbar. Ich war immer nur happy, wenn aus den set-Pairing ein pairedTo wurde.

Und wenn das peeren so simpel ist wie beschrieben

set HM_S31 peerChan 0 HM_Empf45 single set   <- legt die Direktverknüpfung mit dem Lichtschaltkanal an

dann wird alles gut.

Also jetzt herrscht erst einmal Funkstille, damit hier nichts unnütz pingpong läuft.
Melde mich erst bei Erfolg oder zu hohen Hürden.

Gruß -- Rolf