hallo,
ist eine pairen von HM-MOD-EM-8 mit HM-MOD-RE-8 möglich ?
wenn ja wie muss ich vorgehen?
gruß
wendelin
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
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
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ß
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.
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.
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.
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.
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...
Du bist ja wirklich schnell.
Hier die Auszüge aus dem config-file:
Der Sender und ein Kanal
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
#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
#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.
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
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.
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.
Hier die Lists
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.
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.
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.
ZitatDer 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 Sender
kanal, 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.
Zitat... 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.
define OG_Flur_on notify HM_S31:closed set HM_Empf51 on-for-timer 25;; set HM_Empf45 on-for-timer 30Daraus 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)
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:
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":
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:
set HM_Empf45 regSet shSwJtOn on HM_S31 <- bleibe bei Trigger an, wenn schon eingeschaltetVielleicht auch mal diesen Wiki-Artikel (https://wiki.fhem.de/wiki/HomeMatic_Register_programmieren) 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.
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
Zitatset 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
Moin,
ich habe eine ähnliche Konstellation bei mir, die Lösung mit den Registern ist im Prinzip identisch zu der vom Pfriemler vorgeschlagenen Lösung.
Vielleicht noch ein Hinweis zum peeren: Falls es sich um einen Testaufbau "auf dem Schreibtisch" handelt, unbedingt auf den Mindestabstand zwischen Sender und Empfänger achten. eQ3 gibt - glaube ich - 50 cm vor. Zusätzlich sollte man die Antennen vom Em8 und Re8 so ausrichten, dass die Drahtspitzen der Antennen auf das jeweils andere Gerät zeigen. Dann erreicht man eine maximal mögliche Entkopplung.
Der HM-MOD-Em-8 ist nach meiner Erfahrung beim Peeren etwas "zickig". Ich hatte machmal Erfolg, wenn ich den Eingang des Kanals von closed auf open gesetzt habe (oder umgekehrt, ich habe es mir leider nicht aufgeschrieben) .
Nicht den Mut aufgeben und mal rumprobieren... :)
Viel Erfolg
Bernd
Danke für den Hinweis.
Beide Module sitzen aktuell direkt nebeneinander. Da muss ich umbauen.
Zitat von: oldman am 19 Januar 2018, 15:30:41
Beide Module sitzen aktuell direkt nebeneinander. Da muss ich umbauen.
Das Sendemodul für die PIRs und das Helpermodul für die Eingangsdeaktivierung dürften zusammen bleiben, wenn sie nicht gepeert sind und daher in der Regel nicht gleichzeitig oder miteinander arbeiten sollen. Wenn das Lichtsteuermodul hingegen zu dicht sitzt, musst Du wirklich umbauen.
HALT HALT HALT HALT ...
Helpermodul bitte noch nicht entsorgen. Ich fürchte, ich liege mit bezüglich der Eingangsfilterung kapital falsch, geblendet von den HM-Bewegungsmeldern... :-[
Melde mich später mit Details.
Hallo Pfriemler,
das hast Du sauber hingepfriemelt. Kein kapitaler Fehler zu erkennen. Es funktioniert.
Nachdem ich mir ein bisschen Gefühl für die Befehle angelesen hatte, habe ich Schritt für Schritt deine Vorschläge eingetragen.
Das Peeren hat auch geklappt obwohl Sender und Empfänger nur 3cm Abstand haben. Habe ein Stahlblech zwischengeklemmt.
Es klappt auch mit EventFilterTime 250 und shOnTime 300 (Küche, Bad).
Die notifys habe ich gelöscht.
Aber die Helper-HW bleibt drin, schon deshalb weil ich nachts beim Gang auf die Toilette nicht geblendet werden will.
Von 1 bis 7 Uhr sind die Helper an, die helligkeitsabhängige Steuerung drumherum mache ich mit (korrigiertem) sunset und sunrise.
Nochmal besten Dank -- bin happy!
Nachtrag:
Sowohl Sender als auch Empfänger haben die Einstellungen vergessen, offensichtlich selbstätig 'entpeered'
'n Ahmd,
freut mich, dass ich nicht so falsch lag. Die Schaltverzögerung sollte jetzt deutlich kleiner sein.
Einstellungen /Peers vergessen? Kann ich mir nicht vorstellen. Versehentlicher Reset? getConfig probiert?
Mit eventFilterTime gibt es ein ernstes Problem. Das funktioniert nicht bei mir.
Details in diesem Thread (https://forum.fhem.de/index.php/topic,83073.0.html) bitte.
oldman,
kannst Du bitte mal im Gerät "HM_Sender3" das Register "ledMode" kontrollieren und ggf. auf "on" setzen:
set HM_Sender3 regSet ledMode on
dann leuchtet die LED auf dem Sendemodul bei jedem Sendevorgang (Du hast doch eine Dauerspeisung, nicht nur Batterie?) Damit kannst Du jeden Sendevorgang des Moduls perfekt kontrollieren, gelb und grün wenn die Quittung vom Re-8 kommt.
Dann siehst Du auch, ob die 250 Sekunden eventFilterTime funktionieren - wenn nicht, dann blinkert es fröhlich bei jeder Bewegung und triggert das Modul instantemente nach.
Du hast außerdem Firmware 1.1. Mein Modul hier zum Test hat 1.0. Dort kann ich eventFilterTime setzen wie ich will, es hat null Effekt, wie im oben zitierten Thread beschrieben.
Oldmann,
herzlichen Glückwunsch !
@Pfriemler... ich habe noch irgendwo ein HM-MOD-EM-8 mit FW 1.1 rumliegen, ich test mal.
Zitat von: pwlr am 23 Januar 2018, 22:29:34
@Pfriemler... ich habe noch irgendwo ein HM-MOD-EM-8 mit FW 1.1 rumliegen, ich test mal.
Siehe Update meines Beitrags im anderen Thread.
Ich habe nur im EventMonitor nachgesehen. Da herrscht nach 3 Sekunden Ruhe.
Deshalb bin ich davon ausgegangen, dass der Sender schweigt.
Es gibt auch trotz normaler Bewegungen keine hmUART Overload.
Was ich erkennen konnte war, dass zwei PIR offensichtlich einschwingen (closed-open-closed innerhalb der 3 Sekunden).
Die Leitungslänge ist hier 6 Meter.
ledMode ist on, das Problem ist nur, dass ich auf Grund der Topologie nicht gleichzeitig
PIR aktivieren und gucken kann, muss mal meine Holde aktivieren da reinzuschauen.
Melde mich.
Naja, der Eventmonitor ist genauso gut, da musste den Zirkus mit ledMode nicht unbedingt machen.
"Flackern" am Eingang ignoriert das Modul eh. Habe festgestellt, wenn man ein "closed" nur sehr kurz (<0,2s) unterbricht, hat das keinen Effekt. Vermutlich tastet das Modul die Eingänge auch nur begrenzt ab (beim SCI-3 ist es ca. 4x pro Sekunde für 250 µs).
So schnell ist das Sendelimit nicht erreicht.
Sollte sich das Prob nicht klären lassen, kannst Du genausogut auch das Helpermodul wieder benutzen und genauso peeren und in der Laufzeit einstellen, das kostet dann auch nicht mehr Funkzeit, es reicht m.W. ein Burst für beide.
Es passieren seltsame Dinge. Der EM8 hat sich entpaired. Steht auf 0x000000.
Im Log ist nichts zu finden. Ich hatte allerdings verbose auf 3. Am Liebsten würde ich das Sensibelchen rausschmeißen.
Wenn es für die Taster-Eingänge am Re8 auch solche Registersätze wie die beim Peeren mit einem Sensor angelegten geben würde wäre das ganz simpel.
Die gibt es aber nicht, oder?
Würde so etwas funktionieren?:
PIR über die Zusatz-HW an einen Helper-Re8-Kanal. Der geht auf 'on' und klemmt über die Zusatz-HW den PIR ab und schaltet den Licht-Re8-Kanal auf 'on'.
Ein notify reagiert darauf und setzt beide Kanäle auf passende 'on-for-timer'.
Da nichts gesendet wird sollte auch die Reaktionszeit so sein wie wenn ich den Licht-RE8 per Wand-Taster schalte, nämlich sofort.
Ich würde nicht so ... fragen, aber Ausprobieren ist ein erheblicher Eingriff und hat einen WAF der gegen Null geht.
Zitat von: oldman am 24 Januar 2018, 17:53:22
Es passieren seltsame Dinge. Der EM8 hat sich entpaired. Steht auf 0x000000.
Würde auch den Verlust des Peerings erklären. Mal versehentlich ein "set HM_Sender3 reset" abgeschickt (das ist nämlich kein einfacher reboot)? oder zweimal zu lange auf den kleinen Knopf oben gedrückt, eventuell beim Einbau, ...? Man kann den Dingern viel nachsagen, aber spontaner Selbstreset gehört nicht dazu.
Neu anlernen, neu programmieren. Was soll's.
ZitatWenn es für die Taster-Eingänge am Re8 auch solche Registersätze wie die beim Peeren mit einem Sensor angelegten geben würde wäre das ganz simpel.
Die gibt es aber nicht, oder?
Doch, gibt es. Die Tasten heißen self01 bis self08. Wie bei allen Aktoren gibt es keine sensorseitigen Konfigurationsmöglichkeiten, aber die ausgelöste Aktor-Funktion kann beeinflusst werden, inklusive zeitlich begrenzte Einschaltung (shOnTime), condition- und jump table.
Allerdings ist der Eingang fest auf "remote" festgelegt, d.h. short-Events, kein Sensorbetrieb. Longs wird er nicht auswerten können (das Register confBtnTime, mit dem man die Funktion der internen Tasten von kurz/Konfig auf kurz/lang umschalten kann, gibt es beim Re-8 nicht) , kritisch ist aber ein zu langes "Betätigen" der Tasten (>4 Sekunden), weil es zumindest auf dem Kanal 1 leicht zu einem Reset führen kann. Das längere Drücken auf die Tasten 2-8 leitet im Einzelbetrieb das Peering ein, aber bei angelernter Zentrale sollte es wirkungslos bleiben, wobei mir nicht klar ist, ob es dann wenigstens als Schaltbefehl interpretiert wird.
Wenn die PIR keine längeren EIN als 4 Sekunden liefern, wäre es egal.
ZitatWürde so etwas funktionieren?:
PIR über die Zusatz-HW an einen Helper-Re8-Kanal. Der geht auf 'on' und klemmt über die Zusatz-HW den PIR ab und schaltet den Licht-Re8-Kanal auf 'on'.
Ein notify reagiert darauf und setzt beide Kanäle auf passende 'on-for-timer'.
Da nichts gesendet wird sollte auch die Reaktionszeit so sein wie wenn ich den Licht-RE8 per Wand-Taster schalte, nämlich sofort.
Warum so kompliziert? Du könntest direkt an den Licht-Re-8 gehen. Allerdings wären dann PIR-Einschaltzeit und Wandtaster-Einschaltzeit nicht so leicht zu trennen und es gäbe am Wandtaster auch nur eine Nachtriggermöglichkeit - Taster und PIR wären ja praktisch parallel. Aber immerhin kannst Du den Helper als Hauptschalter für den PIR missbrauchen. Wenn Dich das nicht stört, siehe unten. Bei Deiner Lösung sähe ich auch das Problem: Du müsstest dem Helper-Re-8 beibringen, das Licht-Re-8 nur
einzuschalten, liefe letztlich auf meinen Vorschlag hinaus. Tja.
Wenn Du den Helper wie gehabt in die Logik eingreifen lässt und mit dieser den Licht-Re-8 direkt schaltest:
Deine Logik liefert doch m.W. schon ein Aktiv-Low, wenn ein PIR-Signal ankommt. Mit einer (Shottky)-Diode kannst Du den Tastereingang am Re-8 auf GND ziehen und hältst die Ausgangsspannung der Logik vom Tastereingang fern. (klappt übrigens auch beim EM-8, denke ich)
Die Programmierung wäre überschaulicher, der Lichtkanal ist bei Dir ja Kanal 5:
set HM_Empf4 intKeyVisib visib <- macht die internen Taster sichtbarNun erst mal ein "set HM_Empf4 getConfig", damit FHEM die internen peers auslesen kann.
set HM_Empf45 regSet shOnTime 300 self05 <- begrenzt die Einschaltzeit durch HM_S31 auf 300 Sekunden
set HM_Empf45 regSet shSwJtOn on self05 <- bleibe bei Trigger an, wenn schon eingeschaltetSchaltflanken stimmen schon (open->closed), gepeert ist auch schon, Filterzeit entfällt - Trigger können dann beliebig auf den Eingang einhämmern, ohne dass es zu erneuter Funkaussendung kommt, hab ich gerade mal an meinem Re-8 probiert.
Soweit dazu. Letztlich hat es doch Vorteile, wenn man die PIR über einen Sender an den Lichtempfänger koppelt - dann hat man quasi zwei Befehlseingänge für einen Lichtaktorkanal.
Das "set HM_Sender3 reset" habe ich tatsächlich mal abgesetzt weil stundenlang "commands pending" waren.
Da ist das peering verloren gegangen, sicher aber nicht das Pairing, das passiert doch mit "unpair", oder?.
Für Laien wie mich wäre ein "Are you sure?" bei set reset ganz hilfreich.
Also für das entpairen habe ich keine Erklärung. Werksreset habe ich jedenfalls nicht gemacht.
Interessanterweise funktioniert alles weiterhin, durch das peering klappt die Ansteuerung der Empfänger,
nur komme ich von der Zentrale nicht mehr auf den EM.
Wo kriegt man diese ganzen Geheiminfos alle her (self..)?
Im Pittner-Papier habe ich nichts gefunden.
Ein Link würde mir vllt. helfen; ich weiß z.B. nichts über condition- und Jumptables und was man damit anstellen kann.
Danke, mit Deinen Infos kann ich einiges an HM-Hardware zur Seite legen.
Ich probiere das erst einmal mit separatem Aufbau aus.
Nur die Leitungslängen von Wandtaster und PIR werde ich einbeziehen.
Die Zusatz-HW werde ich aus zwei Gründen drin lassen:
- zeit- und helligkeitsabhängige Sperre
- Verhindern einer Long-Ansteuerung.
Es sei denn auch dafür gibt es versteckte Registerbits.Den Vorteil, den Sender beizubehalten weil man einen zweiten Befehlseingang für den Lichtaktor hat sehe ich nicht.
Mir reicht der Zugang per Taster bzw PIR und der über die Zentrale ("Alexa:Küche an")
Einziges Problem: Die Wandtaster toggeln nicht mehr sondern wirken wie PIR, ist ja derselbe Eingang.
Aber in der Regel will ich das Licht nur wenn es Dunkel ist und dann sollten die PIR das erledigen (Wandtaster als Fallback).
Für Dauerlicht muss dann Alexa sorgen.
Das verstehe ich nicht:
ZitatWenn Du den Helper wie gehabt in die Logik eingreifen lässt und mit dieser den Licht-Re-8 direkt schaltest:
Deine Logik liefert doch m.W. schon ein Aktiv-Low, wenn ein PIR-Signal ankommt. Mit einer (Shottky)-Diode kannst Du den Tastereingang am Re-8 auf GND ziehen und hältst die Ausgangsspannung der Logik vom Tastereingang fern. (klappt übrigens auch beim EM-8, denke ich)
Nein, Reset ist wie Werksreset, inklusive Pairing. Dann wäre das geklärt.
Fürs Löschen des Kommandostacks ist "set xy clear msgEvents" da.
Der Aktor ist weiterhin auf den Sender dressiert und reagiert daher immer noch. Logisch alles richtig.
Eine Sicherheitsabfrage wäre gut, stimmt.
Martin hat die Statemachine schon sehr gut beschrieben, die Register folgen einer stringenden Logik - hat man die einmal begriffen, ist es recht einfach.
Wenn Dir der Wandtaster als PIR-Notersatz reicht, dann mach doch wie vorgeschlagen.
Bezüglich der Shottky: ich warnte ja vor ein paar Tagen davor, die Tastereingänge mit Fremdspannung zu beaufschlagen, wie es das NAND machen würde. Mit der Diode wird daraus quasi ein ungefährlicher OpenCollector.
Mein ganzes Wissen stammt zu einem bedeutenden Teil aus helfenden Beiträgen im Forum ...
ZitatMein ganzes Wissen stammt zu einem bedeutenden Teil aus helfenden Beiträgen im Forum ...
Wenn das ein dezenter Hinweis ist, mich erst einmal schlau zu machen, dann wünsche ich mir eine Finde-Funktion im Forum.
Die Suchfunktion taugt nichts. Habe gesucht ohne Erfolg.
Deshalb habe ich mich auch an einen passenden Thread gehängt in der Hoffnung,
so auch eine Antwort zu kriegen. Und ich habe sehr viele helfende Beiträge bekommen.
Das mit den Dioden habe jetzt ich verstanden.
Die Statemachine offensichtlich noch nicht.
Melde mich mit der finalen Lösung.
ZitatMartin hat die Statemachine schon sehr gut beschrieben, die Register folgen einer stringenten Logik - hat man die einmal begriffen, ist es recht einfach.
Nachdem mir klar wurde, dass Pittner Martin heißt habe ich weniger flüchtig in das Papier gesehen.
Jetzt kommt Licht ins Dunkel!
Ich hatte beim Kapitel
peeren aufgehört zu lesen, aber ab Seite 74 wird es spannend.
Ich mache mir jetzt erst einmal eine Excel-Tabelle um die etwas kryptischen Registernamen und Werte
anschaulicher zu machen. Und dann werden auch die Fragen konkreter falls ich noch überhaut noch welche habe.
Erst einmal Danke an Pfriemler und pwlr.
PS: Die aktuelle Schaltung (nur Licht-Re, Helper-Re und Blockier-HW) läuft im Versuchsaufbau jetzt stabil.
Den EM muss ich aber noch drin lassen zur Ansteuerung von FS20-Dimmern.
So, jetzt laufen 6 Kreise stabil. Habe eine Menge gelernt und auch Merkwürdiges festgestellt.
Zweimal ist es passiert, dass ein Aktorkanal neben dem zugeordneten Sensorkanal und dem self-Kanal
mit einem anderen Aktorkanaleines anderen Geräts gepeert war. Und dafür gibt es kein 'unset'.
Nachdem ich den störenden Kanal gelöscht hatte hat sich der Aktorkanal mit dem device gepeert.
Blieb mir nichts weiter übrig als das ganze Gerät zu löschen. Keine Erklärung.
Die eventFilterTime am Sensor funktioniert übrigens.
Nachdem ich die Einschaltdauer der Aktoren von 5 auf 2 Minuten geändert hatte stand ich im Dunkeln,
hatte die eventFilterTime auf 4 Minuten stehen lassen.
Grund für die Verkürzung: Stromsparen. Die Taster an der Wand schalten ja jetzt nur noch ein.