Hallo miteinander,
habe heute die neue 4 Tasten Fernbedienung bekommen. Gibt es dazu schon eine HMConfig.pm und wenn ja, wo ist sie zu finden?
Interessant wäre auch eine Anleitung, wie man neue Geräte in die HMConfig.pm einbindet.
Gruß,
Kunibert
Hallo Kunibert,
nein, diese FBs habe ich noch nicht gesehen.
Anleitungen zum code-schreiben in FHEM kenne ich kaum welche, auch hier nicht.
In diesem speziellen Fall habe ich aber eine Beschreibung der zu setzenden Eintraege in den model-hash in den code geschrieben.
Die Daten des Models musst du natuerlich irgendwo her bekommen - beispielsweise aus der Anlern-Message des Device. Die musst du loggen und auswerten.
Du solltest dann noch pruefen welche Register unterstuetzt werden und welche Funktionen und kommandos anzuwenden sind.
Es gibt immer nur ein HMConfig.pm, das neuste in SVN
Gruss
Martin
Hallo Martin,
vielen Dank für Deine Antwort.
es handelt sich um nur eine Fernbedienung, ähnlich der HM-RC-4, HM-RC-Key4, HM-RC-Sec4.
Da ich mich erst wenige Tage mit dem Thema beschäftige, werde ich noch etwas brauchen, bis ich die Internas verstehe.
Ok. Die aktuellste HMConfig.pm wird immer im Rahmen von update aktualisiert. Habe ich gefunden. Sie enthält noch nicht HM-RC-4-2 .... Eventuell ist die Implementierung aber ja wie bei HM-RC-4 ....
Meine Garagentorsteuerung habe ich aber auch so zum Laufen gebracht.
Meine Gerätekonfiguration:
Hörmann Garagentor
Fritzbox 7270
HM-LAN Konfigurator
HM-RC-4-2 FB (Fernbedienung)
HM-LC-SW1-BA-PCB Schalter
Ich habe keinen Weg gefunden, die FB mit Tasterfunktion direkt mit dem Schalter zu peeren. Deshalb habe ich folgendes realisiert:
1. FB und Schalter mit dem Konfigurator gepairt
2. Button 1 der FB mit dem Schalter in FHEM gepeert und mit notify ein "on-for-timer 0.5" an den Schalter geschickt. Funktioniert tadellos.
3. Button 4 der FB nicht in FHEM gepeert und mit notify ein "on-for-timer 0.5" an den Schalter geschickt. Funktioniert ebenfalls tadellos.
4. Schalter auch direkt über FHEM mit "attr Garagentor webCmd on-for-timer 1:off:statusRequest" bedienbar.
Nun meine Fragen:
1. Gibt es einen Weg, Schalter und FB mit Tasterfunktion direkt zu peeren? Mit Schalterfunktion funktioniert es.
2. Da ich mit notify auch ohne peering in FHEM Befehle von der FB an den Schalter schicken kann (es sei denn, ich habe irgendetwas übersehen), warum peering in FHEM überhaupt?
Wenn ich mir die Ausgabe im Event Monitor anschaue, gibt es nur den Unterschied, dass Button 1 an Garagentor sendet und Button 4 an HMLAN1.
Events:
2013-05-31 11:25:42 CUL_HM Handsender_1_Btn1 Short (to Garagentor)
2013-05-31 11:25:42 CUL_HM Handsender_1_Btn1 trigger: Short_79
2013-05-31 11:25:42 CUL_HM Handsender_1 battery: ok
2013-05-31 11:25:42 CUL_HM Handsender_1 Handsender_1_Btn1 Short (to Garagentor)
2013-05-31 11:25:42 CUL_HM Garagentor level: 100 %
2013-05-31 11:25:42 CUL_HM Garagentor deviceMsg: on (to HMLAN1)
2013-05-31 11:25:42 CUL_HM Garagentor on
2013-05-31 11:25:42 CUL_HM Garagentor battery: ok
2013-05-31 11:25:43 CUL_HM Garagentor level: 100 %
2013-05-31 11:25:43 CUL_HM Garagentor deviceMsg: on (to HMLAN1)
2013-05-31 11:25:43 CUL_HM Garagentor on
2013-05-31 11:25:43 CUL_HM Garagentor battery: ok
2013-05-31 11:25:47 CUL_HM Garagentor level: 0 %
2013-05-31 11:25:47 CUL_HM Garagentor deviceMsg: off (to HMLAN1)
2013-05-31 11:25:47 CUL_HM Garagentor off
2013-05-31 11:25:47 CUL_HM Garagentor battery: ok
2013-05-31 11:25:57 CUL_HM Handsender_1_Btn4 Short (to HMLAN1)
2013-05-31 11:25:57 CUL_HM Handsender_1_Btn4 trigger: Short_52
2013-05-31 11:25:57 CUL_HM Handsender_1 battery: ok
2013-05-31 11:25:57 CUL_HM Handsender_1 Handsender_1_Btn4 Short (to HMLAN1)
2013-05-31 11:25:58 CUL_HM Garagentor level: 100 %
2013-05-31 11:25:58 CUL_HM Garagentor deviceMsg: on (to HMLAN1)
2013-05-31 11:25:58 CUL_HM Garagentor on
2013-05-31 11:25:58 CUL_HM Garagentor battery: ok
2013-05-31 11:25:58 CUL_HM Garagentor level: 100 %
2013-05-31 11:25:58 CUL_HM Garagentor deviceMsg: on (to HMLAN1)
2013-05-31 11:25:58 CUL_HM Garagentor on
2013-05-31 11:25:58 CUL_HM Garagentor battery: ok
2013-05-31 11:26:01 CUL_HM Garagentor level: 0 %
2013-05-31 11:26:01 CUL_HM Garagentor deviceMsg: off (to HMLAN1)
2013-05-31 11:26:01 CUL_HM Garagentor off
2013-05-31 11:26:01 CUL_HM Garagentor battery: ok
Gruß,
Kunibert
Hallo Kunibert
ZitatSie enthält noch nicht HM-RC-4-2 .... Eventuell ist die Implementierung aber ja wie bei HM-RC-4 ....
korrekt .... ist zu erwarten.
Evtl hat das sec device ein paar Besonderheiten...
Im Wesentlichen musst du einmal die Anlernmessage im Rohformat posten, dann koennen wir die Zeile definieren. Danach sollten auch schon alle Kommandos funktionieren. Eigentlich auch das peeren.
ZitatIch habe keinen Weg gefunden, die FB mit Tasterfunktion direkt mit dem Schalter zu peeren. Deshalb habe ich folgendes realisiert:
wie steht es mit
set Handsender_1_Btn1 peerChan 0 Garagentor single Zitat1. FB und Schalter mit dem Konfigurator gepairt
Die HMID der Zentrals ist gleich der im konfigurator. Jedenfalls muss alles mit der HMID von FHEM gepairt werden!
Zitat2. Button 1 der FB mit dem Schalter in FHEM gepeert und mit notify ein "on-for-timer 0.5" an den Schalter geschickt. Funktioniert tadellos.
das ist doppelt verarbeitet oder falsch verstanden. Wenn du Btn1 und schalter gepeert hast, reden die ohne FHEM miteinander. Dann solltest du kein Notify mehr machen, das schaltet ja noch einmal.
Zitat3. Button 4 der FB nicht in FHEM gepeert und mit notify ein "on-for-timer 0.5" an den Schalter geschickt. Funktioniert ebenfalls tadellos.
das ist ok.
Zitat4. Schalter auch direkt über FHEM mit "attr Garagentor webCmd on-for-timer 1:off:statusRequest" bedienbar.
sowieso ;-)
Zitat1. Gibt es einen Weg, Schalter und FB mit Tasterfunktion direkt zu peeren? Mit Schalterfunktion funktioniert es.
Hier must du den HM Grundsatz verinnerlichen: HM sensoren (auch remotes) schicken nur trigger. Die koennen "short" oder "Long" sein. Long wird alle .5sec wiederholt bis du loss laesst. Was der Aktor daraus macht legt einzig der Aktor fest.
Ich nehme einmal an, dass dein Garagentor ueber eine puls gesteuert wird. Der SW1 soll also, wenn ein trigger einer Taste kommt .5sec auf 'on' gehen und dann wieder auf 'off'. Wird klassisch als Treppenhausschalter bezeichnet, oder Pulsgeber.
Lese einmal alles aus dem Schalter aus
dann schalte alles sichtbar
set Garagentor getConfig
attr Garagentor expert 2
Warten bis fertig gelesen
list Garagentor
Jetzt solltest du sehen
- welche Buttons mit deinem Tor gepeert sind
- den Registersatz, der dem jeweiligen Link (channel<-> Button peering) zu Grunde Liegt
Und jetzt kannst du spielen:
set Garagentor regSet shOnTime 0.5 Handsender_1_Btn1 # halbe sec on
set Garagentor regSet shSwJtDlyOff dlyOn Handsender_1_Btn1
set Garagentor regSet shSwJtOn no Handsender_1_Btn1 # kein retrigger
set Garagentor regSet shActionType jmpToTarget Handsender_1_Btn1
set Garagentor regSet lgActionType jmpToTarget Handsender_1_Btn1
set Garagentor regSet lgOnTime 0.5 Handsender_1_Btn1 # halbe sec on
set Garagentor regSet lgSwJtDlyOff dlyOn Handsender_1_Btn1
set Garagentor regSet lgSwJtOn no Handsender_1_Btn1 # kein retrigger
set Garagentor regSet lgMultiExec off Handsender_1_Btn1 # kein retriggerStelle sicher, dass dein Button als 'single' gepeert wurde.
Gruss Martin
Hallo Martin,
ZitatIm Wesentlichen musst du einmal die Anlernmessage im Rohformat posten, dann koennen wir die Zeile definieren. Danach sollten auch schon alle Kommandos
funktionieren. Eigentlich auch das peeren.
Ich habe noch einmal alles zurückgesetzt und die Anlernmessage unten aufgeführt. Da die Channel nicht automatisch erzeugt werden, habe ich sie manuell in der fhem.cfg hinzugefügt.
Anmeldeinfo von HM-RC-4-2
Internals:
DEF 212145
EVENTS 35
HMLAN1_MSGCNT 38
HMLAN1_RAWMSG R0038F0A5,0001,00DC143C,FF,FFC4,0EA0102121451E9C2E0202010A1E0B9C0C2E18000000
HMLAN1_RSSI -60
HMLAN1_TIME 2013-06-01 16:51:39
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 38
NAME Handsender_1
NR 52
NTFY_TRIGGERTIME 2013-06-01 16:55:21
STATE CMDs_processing...
TYPE CUL_HM
channel_01 Handsender_1_Btn1
channel_02 Handsender_1_Btn2
channel_03 Handsender_1_Btn3
channel_04 Handsender_1_Btn4
lastMsg No:0E - t:10 s:212145 d:1E9C2E 0202010A1E0B9C0C2E18000000
protCmdDel 0
protCmdPend 0 CMDs pending
protLastRcv 2013-06-01 16:51:39
protResnd 16 last_at:2013-06-01 16:55:35
protResndFail 3 last_at:2013-06-01 16:54:06
protSnd 26 last_at:2013-06-01 16:55:21
protState CMDs_processing...
rssi_at_HMLAN1 avg:-57.39 min:-65 max:-44 lst:-60 cnt:38
Readings:
2013-06-01 16:51:38 CommandAccepted yes
2013-06-01 16:51:39 PairedTo 0x1E9C2E
2013-06-01 16:51:39 R-intKeyVisib invisib
2013-06-01 16:51:39 R-pairCentral 0x1E9C2E
2013-06-01 16:43:21 noReceiver src:212145 A240 0202
2013-06-01 16:40:09 powerOn -
2013-06-01 16:55:21 state CMDs_processing...
Regl_00::
VAL
cmdStack:
Helper:
burstEvtCnt 19
rxType 1
Respwait:
PendCmd As1010A0011E9C2E21214500040000000000
Pending RegisterRead
PendingRsend 4
forChn 00
forList 00
forPeer
Role:
dev 1
Rssi:
At_hmlan1:
avg -57.3947368421053
cnt 38
lst -60
max -44
min -65
Shadowreg:
Attributes:
expert 2
firmware 1.0
model unknown
peerIDs
room Garage
serialNr KEQ0111214
subType
webCmd getConfig
PeerChan hatte ich bei meinem letzten Versuch ohne "single" durchgeführt. Mir war nicht bewußt, dass damit die FB direkt mit dem Aktor gepeert wird. Ich dachte, dass dies nur in FHEM geschieht.
ZitatDie HMID der Zentrals ist gleich der im Konfigurator. Jedenfalls muss alles mit der HMID von FHEM gepairt werden!
Hatte ich schon beachtet und richtig.
ZitatHier must du den HM Grundsatz verinnerlichen: HM sensoren (auch remotes) schicken nur trigger. Die koennen "short" oder "Long" sein. Long wird alle .5sec wiederholt bis du loss laesst. Was der Aktor daraus macht legt einzig der Aktor fest.
Das war mir schon klar, aber ich dachte, ich müsste dies über ein Notify an den Aktor schicken.
Wenn ich dem Aktor also ein
set Garagentor regSet shOnTime 0.5 Handsender_1_Btn1schicke, speichert er dies dauerhaft in einem Register ab (wie z.B. bei Batterie Low), so dass ich das Register nur einmal setzen muss, oder muss ich dies bei jedem FHEM-Start durchführen?
ZitatIch nehme einmal an, dass dein Garagentor ueber eine puls gesteuert wird. Der SW1 soll also, wenn ein trigger einer Taste kommt .5sec auf 'on' gehen und dann wieder auf 'off'. Wird klassisch als Treppenhausschalter bezeichnet, oder Pulsgeber.
Ja, mein Garagentor wird über einen Puls gesteuert.
ZitatLese einmal alles aus dem Schalter aus
Damit habe ich momentan ein Problem. Ich bekomme nach einem getConfig immer ein RESPONSE TIMEOUT:RegisterRead zurück. Deshalb konnte ich auch noch nicht "spielen", da für die anderen Registerzugriffe ein fehlerloses getConfig vorausgesetzt wird und es immer Fehlermeldungen gibt. Die shOnTime konnte ich zwar ohne Fehlermeldung setzen, aber bei der Bedienung über die FB hat der Aktor dies noch nicht beachtet.
Bei der FB habe ich auch schon ein RESPONSE TIMEOUT:RegisterRead gehabt. Was könnte die Ursache sein? HMLAN Konfigurator, Schalter und FB befinden sich in einem Raum, alle ca. einen halben Meter auseinander. Ist die Entfernung zu gering, dass es dadurch Störungen geben kann?
Gruß,
Dietmar
Hallo Dietmar,
ZitatIch habe noch einmal alles zurückgesetzt und die Anlernmessage unten aufgeführt. Da die Channel nicht automatisch erzeugt werden, habe ich sie manuell in der fhem.cfg hinzugefügt.
das sollte nicht sein.
Wie ich sehe ist 'model' und 'subType' nicht gesetze. Entwerder hat FHEM die Anlernmessage nicht erhalten oder nict verstanden.
Zitat...aber ich dachte, ich müsste dies über ein Notify an den Aktor schicken.
können ja, muessen nein
schicke, speichert er dies dauerhaft in einem Register ab (wie z.B. bei Batterie Low), so dass ich das Register nur einmal setzen muss, oder muss ich dies bei jedem FHEM-Start durchführen?
HM devices speichern Register permanent. Also nur einmal schicken, nicht in fhem.cfg.
Zitat...ein RESPONSE TIMEOUT:RegisterRead
a) das Fehlen von model und subtype stört mich. Kannst du mir die Anlernmessage noch einmal aufnehmen?
b) logge auch einmal die rohmessages wenn es zu einem timeout kommt - und sage mir, von welchem model dies kommt.
Gruss Martin
Ich bin hier auch grade mit dieser neuen Fernbedienung am verzweifeln. Wenn mir jemand kurz auf die Sprünge hilft, wie man die Anmeldemessage loggen kann, werde ich gerne mithelfen, das Theme voranzubringen. Grundsätzlich sieht das Ergebnis nach dem autocreate ähnlich aus - auch ohne model und subtype.
Internals:
CFGFN
DEF 2123FC
EVENTS 23
HMLAN_MSGCNT 22
HMLAN_RAWMSG E2123FC,0000,2B762897,FF,FFB9,0084102123FC00000006000000
HMLAN_RSSI -71
HMLAN_TIME 2013-06-02 20:12:20
IODev HMLAN
LASTInputDev HMLAN
MSGCNT 22
NAME HMFB01
NR 341
NTFY_TRIGGERTIME 2013-06-02 20:12:20
STATE ???
TYPE CUL_HM
lastMsg No:00 - t:10 s:2123FC d:000000 06000000
protLastRcv 2013-06-02 20:12:20
protSnd 12 last_at:2013-06-02 20:07:10
protState CMDs_done
rssi_at_CUL_HM_ID_00A0_2123FC avg:0 min:0 max:0 lst:0 cnt:1
rssi_at_HMLAN avg:-67.22 min:-81 max:-60 lst:-71 cnt:22
Readings:
2013-06-02 20:07:10 CommandAccepted yes
2013-06-02 20:00:12 R-intKeyVisib set_invisib
2013-06-02 19:59:44 R-pairCentral set_0x9601BD
2013-06-02 20:01:47 noReceiver src:2123FC A240 0201
2013-06-02 20:12:20 powerOn -
Helper:
rxType 1
Respwait:
Role:
chn 1
dev 1
Rssi:
At_cul_hm_id_00a0_2123fc:
avg
cnt 1
lst
max
min
At_hmlan:
avg -67.2272727272727
cnt 22
lst -71
max -60
min -81
Shadowreg:
RegL_00: 02:01 0A:96 0B:01 0C:BD
Attributes:
expert 2_full
firmware 1.0
model unknown
peerIDs
room CUL_HM
serialNr KEQ0111919
subType
Ich habe einfach die Zeile der HM-RC-4-B kopiert und darin die ID 00A0 verwendet :)
"00A0" => {name=>"HM-RC-4-2" ,st=>'remote' ,cyc=>'' ,rxt=>'c' ,lst=>'1,4' ,chn=>"Btn:1:4",},
Damit werden beim Anlernen der Fernbedienung automatisch die 4 Buttons mit autocreate angelegt.
Internals:
CFGFN
DEF 2123FC
EVENTS 8
HMLAN_MSGCNT 10
HMLAN_RAWMSG E2123FC,0040,2BAB3B5B,01,FFBD,04A2402123FC9601BD0200
HMLAN_RSSI -67
HMLAN_TIME 2013-06-02 21:10:19
IODev HMLAN
LASTInputDev HMLAN
MSGCNT 10
NAME CUL_HM_HM_RC_4_2_2123FC
NR 336
NTFY_TRIGGERTIME 2013-06-02 21:14:33
STATE CMDs_pending
TYPE CUL_HM
channel_01 CUL_HM_HM_RC_4_2_2123FC_Btn_01
channel_02 CUL_HM_HM_RC_4_2_2123FC_Btn_02
channel_03 CUL_HM_HM_RC_4_2_2123FC_Btn_03
channel_04 CUL_HM_HM_RC_4_2_2123FC_Btn_04
lastMsg No:04 - t:40 s:2123FC d:9601BD 0200
protCmdPend 9 CMDs_pending
protLastRcv 2013-06-02 21:10:19
protSnd 3 last_at:2013-06-02 21:09:35
protState CMDs_pending
rssi_at_CUL_HM_HM_RC_4_2_2123FC avg:0 min:0 max:0 lst:0 cnt:1
rssi_at_HMLAN avg:-68.5 min:-74 max:-64 lst:-67 cnt:10
Readings:
2013-06-02 21:09:35 CommandAccepted yes
2013-06-02 21:09:34 R-pairCentral set_0x9601BD
2013-06-02 21:10:17 battery ok
2013-06-02 21:14:33 state CMDs_pending
cmdStack:
++A0019601BD2123FC00040000000000
++A0019601BD2123FC01040000000001
++A0019601BD2123FC0103
++A0019601BD2123FC02040000000001
++A0019601BD2123FC0203
++A0019601BD2123FC03040000000001
++A0019601BD2123FC0303
++A0019601BD2123FC04040000000001
++A0019601BD2123FC0403
Helper:
addVal 2
mId 00A0
rxType 4
Respwait:
Role:
dev 1
Rssi:
At_cul_hm_hm_rc_4_2_2123fc:
avg
cnt 1
lst
max
min
At_hmlan:
avg -68.5
cnt 10
lst -67
max -64
min -74
Shadowreg:
Attributes:
expert 2_full
firmware 1.0
model HM-RC-4-2
peerIDs
room CUL_HM
serialNr KEQ0111919
subType remote
webCmd getConfig
Allerdings läuft dabei irgendwie die Konsole mit Fehlermeldungen aus der 10_CUL_HM.pm über.
Use of uninitialized value $id in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 147.
substr outside of string at ./FHEM/10_CUL_HM.pm line 147.
Use of uninitialized value $id in string ne at ./FHEM/10_CUL_HM.pm line 149.
Use of uninitialized value $dst in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 1549.
Use of uninitialized value $dst in substr at ./FHEM/10_CUL_HM.pm line 1551.
Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 1577.
Use of uninitialized value $devName in hash element at ./FHEM/10_CUL_HM.pm line 1579.
Use of uninitialized value $dst in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 1549.
Use of uninitialized value $dst in substr at ./FHEM/10_CUL_HM.pm line 1551.
Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 1577.
Use of uninitialized value $devName in hash element at ./FHEM/10_CUL_HM.pm line 1579.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3816.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3816.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3816.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3816.
Hallo betateilchen,
ich glaube, dies habe ich bei meinen vielen Versuchen auch schon gemacht, aber Kanäle habe ich nicht gesehen, die habe ich per Hand in der fhem.cfg eingetragen. Erst danach erschienen sie beim List. Nur hatte ich dabei nicht auf die Ausgaben in der Konsole geachtet.
Wenn ich ohne Änderung der HMConfig eine Anmeldung mache, sehen die Anmeldeinfos wie folgt aus:
Internals:
CFGFN
CHANGED
DEF 212145
EVENTS 7
HMLAN1_MSGCNT 8
HMLAN1_RAWMSG R065AC746,0021,006083EB,00,FFCC,0680022121451E9C2E000C376FFF
HMLAN1_RSSI -52
HMLAN1_TIME 2013-06-02 21:26:20
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 8
NAME CUL_HM_ID_00A0_212145
NR 165
NTFY_TRIGGERTIME 2013-06-02 21:26:16
STATE ???
TYPE CUL_HM
lastMsg No:06 - t:02 s:212145 d:1E9C2E 000C376FFF
protLastRcv 2013-06-02 21:26:20
protResnd 1 last_at:2013-06-02 21:26:18
protSnd 3 last_at:2013-06-02 21:26:19
protState CMDs_done_events:1
rssi_at_CUL_HM_ID_00A0_212145 avg:0 min:0 max:0 lst:0 cnt:1
rssi_at_HMLAN1 avg:-51.12 min:-56 max:-47 lst:-52 cnt:8
Readings:
2013-06-02 21:26:20 CommandAccepted yes
2013-06-02 21:26:16 R-pairCentral set_0x1E9C2E
Helper:
burstEvtCnt 1
rxType 1
Respwait:
Role:
chn 1
dev 1
Rssi:
At_cul_hm_id_00a0_212145:
avg
cnt 1
lst
max
min
At_hmlan1:
avg -51.125
cnt 8
lst -52
max -47
min -56
Shadowreg:
Attributes:
expert 2_full
firmware 1.0
model unknown
peerIDs
room CUL_HM
serialNr KEQ0111214
subType
in der Konsole habe ich die folgenden Ausgaben:
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3816.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3816.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3816.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3816.
Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 2590.Use of uninitialized value in concatenation (.) or string at ./FHEM/10_CUL_HM.pm
line 2625.
Use of uninitialized value $val in substitution (s///) at fhem.pl line 1141.Use of uninitialized value $val in substitution (s///) at fhem.pl line 1142.
Use of uninitialized value $val in concatenation (.) or string at fhem.pl line 1143.
Hallo Martin,
hier ist ein RESPONSE TIMEOUT:RegisterRead von der FB. Kommt jetzt bei jedem getConfig. Die Anmeldeinfo der FB habe ich in meiner vorherigen Mail geschickt.
Internals:
DEF 212145
IODev HMLAN1
NAME Handsender_1
NR 52
NTFY_TRIGGERTIME 2013-06-02 22:33:35
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 Handsender_1_Btn1
channel_02 Handsender_1_Btn2
channel_03 Handsender_1_Btn3
channel_04 Handsender_1_Btn4
protCmdDel 0
protResnd 4 last_at:2013-06-02 22:33:30
protResndFail 1 last_at:2013-06-02 22:33:35
protSnd 1 last_at:2013-06-02 22:33:09
protState CMDs_done_events:5
Readings:
2013-06-02 22:33:35 state RESPONSE TIMEOUT:RegisterRead
Regl_00::
VAL
Helper:
burstEvtCnt 5
rxType 1
Respwait:
Role:
dev 1
Attributes:
expert 2_full
firmware 1.0
model unknown
peerIDs
room Garage
serialNr KEQ0111214
subType 1
webCmd getConfig
Gruß,
Dietmar
Hi betateilchen,
die Zeile
"00A0" => {name=>"HM-RC-4-2" ,st=>'remote' ,cyc=>'' ,rxt=>'c' ,lst=>'1,4' ,chn=>"Btn:1:4",},
sollte korrekt sein, wenn du das 00A0 aus der Anlernmessage genommen hast (hast du offensichtlich)
Aufzeichnen sollte man rohmessages mit
attr global verbose 1
attr <hmlan> loglevel 1
Die Logs stehen dann im hauptlogfile.
Zu den Fehlern - irgend etwas in deinen definitionen scheint nicht zu stimmen.
Ich gehe davon aus, dass alle Buttons angelegt sind und eine HMid haben
Hast du sonst noch devices anglegt? Haben alle ein model?
mache doch einmal ein
define hm HMinfo
set hm param model subType DEF
Hi Dietmar,
bei dir habe ich noch nicht die Anlernmessage um den Code herauszulesen. Danach sollten einige Dinge besser laufen. Aktuell kann fhem dein Device nicht einordnen.
Siehe die Anlietung oben - oder setze
attr <hmlan> hmProtocolEvents 3
Gruss
Martin
Zitat von: martinp876 schrieb am Mo, 03 Juni 2013 08:00Zu den Fehlern - irgend etwas in deinen definitionen scheint nicht zu stimmen.
Ich gehe davon aus, dass alle Buttons angelegt sind und eine HMid haben
Hast du sonst noch devices anglegt? Haben alle ein model?
Hallo Martin,
ich habe die Devices gar nicht selbst angelegt, das ist alles per autocreate entstanden. Ich werde heute abend nachschauen und die gewünschten Informationen nachliefern.
Die Fehler treten definitiv erst seit gestern Abend auf, nachdem die Fernbedienung ins Spiel kam. Interessanterweise bin ich ja nicht der einzige mit diesen Fehlermeldungen ;)
Prinzipiell kann ich die Fernbedienung schon so nutzen wie ich möchte, ich kann die 4 Tasten auswerten und den Trigger nach Short und Long selektieren.
Das Einzige was noch nicht funktioniert, ist die Rückmeldung an die Fernbedienung nach einem Tastendruck. Und genau wegen dieser Rückmeldung habe ich die Fernbedienung eigentlich gekauft.
Aber ich bin zuversichtlich, dass wir das alles noch richtig gelöst bekommen.
Ja, die 00A0 habe ich aus dem Anlernen übernommen, da stand diese ID ja drin.
Viele Grüße
Udo
Hi Udo,
Die Fehlermeldung kommt in der Definitionsphase, wenn ich die Parameter durchcheck - so etwa 5 sec nach dem Define.
Jeder Entity aus CUL_HM sollte eine HMId 6 oder 8 stellig zugewiesen sein. Irgend eine scheint nicht da zu sein.
Wenn du alle korrekt eingetragen hast (ist ja automatisch passiert) dann sollte es kein Problem sein.
Zitatdie Rückmeldung an die Fernbedienung nach einem Tastendruck.
nicht ganz klar: Die FB sendet einen Trigger. Abhaengig ob der Button gepairt ist wird erwartet die FB ein ACK oder eben nicht.
Die Rueckmeldung kommt also von Aktor, nicht von der FB. Falls du nicht direkt peeren willst kannst du einen virtuellen Aktor in FHEM nutzen.
Gruss
Martin
Zitat von: martinp876 schrieb am Mo, 03 Juni 2013 11:09Jeder Entity aus CUL_HM sollte eine HMId 6 oder 8 stellig zugewiesen sein. Irgend eine scheint nicht da zu sein.
Checke ich heute Abend nochmal. Aber die Buttons haben, wenn ich mich recht erinnere, alle die 6-stellige ID der Fernbedienung + 2stelligen Anhang.
Zitat von: martinp876 schrieb am Mo, 03 Juni 2013 11:09Wenn du alle korrekt eingetragen hast (ist ja automatisch passiert) dann sollte es kein Problem sein.
Und wo kommen dann die Fehlermeldungen her?
Zitat von: martinp876 schrieb am Mo, 03 Juni 2013 11:09Die Rueckmeldung kommt also von Aktor, nicht von der FB.
Das hatte ich schon verstanden, dass die Rückmeldung AN die Fernbedienung erfolgen muss und dann von dieser nur signalisiert wird. Meine Hoffnung war einfach, dass FHEM als Empfänger diese Rückmeldung liefern kann, wenn ein Knopfdruck registriert wurde.
Zitat von: martinp876 schrieb am Mo, 03 Juni 2013 11:09Falls du nicht direkt peeren willst kannst du einen virtuellen Aktor in FHEM nutzen.
Ich habe keine physischen Aktoren, die ich mit der Fernbedienung verknüpfen könnte. Es wird also wohl auf virtuelle Aktoren hinauslaufen müssen.
Hallo Udo,
ZitatUnd wo kommen dann die Fehlermeldungen her?
wenn die Daten alle stimmen kann es noch sein, dass ich nicht lange genug warte, und die Attribute noch nicht bereitstehen. Die HMID ist aber eigentlich kein Attribut... wir werden sehen.
ZitatMeine Hoffnung war einfach, dass FHEM als Empfänger diese Rückmeldung liefern kann, wenn ein Knopfdruck registriert wurde.
prinzipiell korrekt. Im Detail:
1) wenn kein Aktor gepeert ist wird die FB kein Ack anfordern sondern nur an Broadcast senden. Meist leuchtet dann die LED gelb: keine Bestaetigung abgefordert
2) zur besseren Steuerung haben wir virtuelle Aktoren. Die FB wird also nicht mit FHEM oder HMLAN gepeert sondern mit einem virtuellen Aktor
define va CUL_HM 112233
set va virtual 1 # nur ein Channel erstellt, kann als aktor oder Button verwendet werden
set Handsender_1_Btn1 peerChan 0 va_Btn1 single
nach dem peeren solltest du ein save machen. Die HM devices speichern zwar alle Settings (peers und register) im flash, aber der virtuelle Aktor/Button eben nur in attributen.
Jetzt sollte die FB bei Button 1 gruen leuchten, bei 'keine antwort' rot.
Der va_Btn1 setzt bei jedem Trigger auch ein paar Readings....
Gruss Martin
Zitat von: martinp876 schrieb am Mo, 03 Juni 2013 08:00Zu den Fehlern - irgend etwas in deinen definitionen scheint nicht zu stimmen.
Ich gehe davon aus, dass alle Buttons angelegt sind und eine HMid haben
Hast du sonst noch devices anglegt? Haben alle ein model?
mache doch einmal ein
define hm HMinfo
set hm param model subType DEF
na da schauen wir mal, was da rauskommt :)
param list
HMFB01 : HM-RC-4-2 |remote |2123FC
HMFB01_01 : HM-RC-4-2 |remote |2123FC01
HMFB01_02 : HM-RC-4-2 |remote |2123FC02
HMFB01_03 : HM-RC-4-2 |remote |2123FC03
HMFB01_04 : HM-RC-4-2 |remote |2123FC04
Melder_Balkon : HM-SEC-RHS |threeStateSensor |1F10D8
Melder_Eingang : HM-SEC-SC |threeStateSensor |1E7BA8
wz_FHT : HM-CC-TC |thermostat |1D919A
wz_FHT_Climate : HM-CC-TC |thermostat |1D919A02
wz_FHT_Weather : HM-CC-TC |thermostat |1D919A01
wz_FHT_WindowRec : HM-CC-TC |thermostat |1D919A03
Ich bin offensichtlich zu doof für HomeMatic. Weder habe ich es heute abend geschafft, die Sache mit dem virtuellen Aktor zum Laufen zu bringen, noch habe ich es geschafft, einen Rauchmelder vernünftig in Betrieb zu nehmen, obwohl ich sämtliche Anleitungen hier im Forum gelesen und das Ding kreuz und quer und auch mit sich selbst gepaired habe.
Gute Nacht :(
Hallo Martin,
hier sind die Anlernmessages:
2013.06.04 00:14:42 1: Including fhem.cfg
2013.06.04 00:14:48 1: Including ./log/fhem.save
2013.06.04 00:14:48 1: usb create starting
2013.06.04 00:14:49 1: usb create end
2013.06.04 00:14:49 0: Server started with 9 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3226 2013-05-29 10:58:17Z rudolfkoenig $, pid 2481)
2013.06.04 00:14:49 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,1E9C2E,002E9ED2,0000
I00,00,00,00
I00,00,00,00
I00,00,00,00
I00,00,00,00
2013.06.04 00:14:49 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:1E9C2E t:002E9ED2 IDcnt:0000
2013.06.04 00:15:08 1: HMLAN_Send: HMLAN1 I:K
2013.06.04 00:15:08 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,AD15A4,002F007E,0000
2013.06.04 00:15:08 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:AD15A4 t:002F007E IDcnt:0000
2013.06.04 00:15:08 1: HMLAN setting owner to 1E9C2E from AD15A4
2013.06.04 00:15:08 1: HMLAN_Send: HMLAN1 I:A1E9C2E
2013.06.04 00:15:33 1: HMLAN_Send: HMLAN1 I:K
2013.06.04 00:15:33 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,1E9C2E,002F6236,0000
2013.06.04 00:15:33 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:1E9C2E t:002F6236 IDcnt:0000
2013.06.04 00:15:58 1: HMLAN_Send: HMLAN1 I:K
2013.06.04 00:15:58 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,1E9C2E,002FC3ED,0000
2013.06.04 00:15:58 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:1E9C2E t:002FC3ED IDcnt:0000
2013.06.04 00:16:23 1: HMLAN_Send: HMLAN1 I:K
2013.06.04 00:16:23 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,1E9C2E,003025A3,0000
2013.06.04 00:16:23 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:1E9C2E t:003025A3 IDcnt:0000
2013.06.04 00:16:48 1: HMLAN_Send: HMLAN1 I:K
2013.06.04 00:16:48 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,1E9C2E,00308758,0000
2013.06.04 00:16:48 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:1E9C2E t:00308758 IDcnt:0000
2013.06.04 00:17:13 1: HMLAN_Send: HMLAN1 I:K
2013.06.04 00:17:13 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,1E9C2E,0030E919,0000
2013.06.04 00:17:13 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:1E9C2E t:0030E919 IDcnt:0000
2013.06.04 00:17:38 1: HMLAN_Send: HMLAN1 I:K
2013.06.04 00:17:38 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,1E9C2E,00314AD9,0000
2013.06.04 00:17:38 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:1E9C2E t:00314AD9 IDcnt:0000
2013.06.04 00:18:03 1: HMLAN_Send: HMLAN1 I:K
2013.06.04 00:18:03 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,1E9C2E,0031AC8F,0000
2013.06.04 00:18:03 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:1E9C2E t:0031AC8F IDcnt:0000
2013.06.04 00:18:13 1: HMLAN/RAW: /E212145,0000,0031D0BB,FF,FFC9,37A2002121451E9C2E1000A04B45513031313132313440040000
2013.06.04 00:18:13 1: HMLAN_Parse: HMLAN1 R:E212145 stat:0000 t:0031D0BB d:FF r:FFC9 m:37 A200 212145 1E9C2E 1000A04B45513031313132313440040000
2013.06.04 00:18:13 1: HMLAN_Send: HMLAN1 I:+212145,00,00,
2013.06.04 00:18:13 1: HMLAN_Send: HMLAN1 S:S0C1E826F stat: 00 t:00000000 d:01 r:0C1E826F m:01 A001 1E9C2E 212145 00050000000000
2013.06.04 00:18:13 1: SND L:10 N:01 F:A0 CMD:01 SRC:1E9C2E DST:CUL_HM_ID_00A0_212145 00050000000000 (CONFIG_START CHANNEL:0x00 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x00) (,BIDI,RPTEN)
2013.06.04 00:18:13 1: HMLAN/RAW: /E212145,0000,0031D1B5,FF,FFCC,37A2002121451E9C2E1000A04B45513031313132313440040000
2013.06.04 00:18:13 1: HMLAN_Parse: HMLAN1 R:E212145 stat:0000 t:0031D1B5 d:FF r:FFCC m:37 A200 212145 1E9C2E 1000A04B45513031313132313440040000
2013.06.04 00:18:13 1: HMLAN/RAW: /R0C1E826F,0001,0031D1BA,FF,FFCC,37A2002121451E9C2E1000A04B45513031313132313440040000
2013.06.04 00:18:13 1: HMLAN_Parse: HMLAN1 R:R0C1E826F stat:0001 t:0031D1BA d:FF r:FFCC m:37 A200 212145 1E9C2E 1000A04B45513031313132313440040000
2013.06.04 00:18:15 1: HMLAN_Send: HMLAN1 S:S0C1E89BA stat: 00 t:00000000 d:01 r:0C1E89BA m:01 A001 1E9C2E 212145 00050000000000
2013.06.04 00:18:15 1: HMLAN/RAW: /E212145,0100,0031D920,FF,FFC7,01A0022121451E9C2E0469602EEB696000
2013.06.04 00:18:15 1: HMLAN_Parse: HMLAN1 R:E212145 stat:0100 t:0031D920 d:FF r:FFC7 m:01 A002 212145 1E9C2E 0469602EEB696000
2013.06.04 00:18:15 1: RCV L:11 N:01 F:A0 CMD:02 SRC:CUL_HM_ID_00A0_212145 DST:1E9C2E 0469602EEB696000 (ACK-proc Para1:0x6960 Para2:0x2EEB Para3:0x6960 Para4:0x00) (,BIDI,RPTEN)
2013.06.04 00:18:15 1: HMLAN: Skip ACK
2013.06.04 00:18:15 1: SND L:0A N:01 F:80 CMD:02 SRC:1E9C2E DST:CUL_HM_ID_00A0_212145 00 (ACK) (,RPTEN)
2013.06.04 00:18:15 1: HMLAN_Send: HMLAN1 S:S0C1E8AB7 stat: 00 t:00000000 d:01 r:0C1E8AB7 m:02 A001 1E9C2E 212145 000802010A1E0B9C0C2E
2013.06.04 00:18:15 1: HMLAN_Delay: HMLAN1 msg delayed 212145 S0C1E8AB7,00,00000000,01,0C1E8AB7,02A0011E9C2E212145000802010A1E0B9C0C2E
2013.06.04 00:18:15 1: SND L:13 N:02 F:A0 CMD:01 SRC:1E9C2E DST:CUL_HM_ID_00A0_212145 000802010A1E0B9C0C2E (CONFIG_WRITE_INDEX CHANNEL:0x00 DATA: 02:01 0A:1E 0B:9C 0C:2E) (,BIDI,RPTEN)
2013.06.04 00:18:15 1: HMLAN/RAW: /R0C1E89BA,0021,0031D925,00,FFC8,0180022121451E9C2E005DEBE054
2013.06.04 00:18:15 1: HMLAN_Parse: HMLAN1 R:R0C1E89BA stat:0021 t:0031D925 d:00 r:FFC8 m:01 8002 212145 1E9C2E 005DEBE054
2013.06.04 00:18:15 1: HMLAN_SdDly: HMLAN1 212145 S0C1E8AB7,00,00000000,01,0C1E8AB7,02A0011E9C2E212145000802010A1E0B9C0C2E
2013.06.04 00:18:15 1: HMLAN_Send: HMLAN1 S:S0C1E8AB7 stat: 00 t:00000000 d:01 r:0C1E8AB7 m:02 A001 1E9C2E 212145 000802010A1E0B9C0C2E
2013.06.04 00:18:15 1: RCV L:0E N:01 F:80 CMD:02 SRC:CUL_HM_ID_00A0_212145 DST:1E9C2E 005DEBE054 (ACK) (,RPTEN)
2013.06.04 00:18:15 1: HMLAN/RAW: /E212145,0100,0031DBAF,FF,FFC8,02A0022121451E9C2E04ED44B271ED4400
2013.06.04 00:18:15 1: HMLAN_Parse: HMLAN1 R:E212145 stat:0100 t:0031DBAF d:FF r:FFC8 m:02 A002 212145 1E9C2E 04ED44B271ED4400
2013.06.04 00:18:15 1: RCV L:11 N:02 F:A0 CMD:02 SRC:CUL_HM_ID_00A0_212145 DST:1E9C2E 04ED44B271ED4400 (ACK-proc Para1:0xED44 Para2:0xB271 Para3:0xED44 Para4:0x00) (,BIDI,RPTEN)
2013.06.04 00:18:15 1: HMLAN: Skip ACK
2013.06.04 00:18:15 1: SND L:0A N:02 F:80 CMD:02 SRC:1E9C2E DST:CUL_HM_ID_00A0_212145 00 (ACK) (,RPTEN)
2013.06.04 00:18:15 1: HMLAN_Send: HMLAN1 S:S0C1E8D47 stat: 00 t:00000000 d:01 r:0C1E8D47 m:03 A001 1E9C2E 212145 0006
2013.06.04 00:18:15 1: HMLAN_Delay: HMLAN1 msg delayed 212145 S0C1E8D47,00,00000000,01,0C1E8D47,03A0011E9C2E2121450006
2013.06.04 00:18:15 1: SND L:0B N:03 F:A0 CMD:01 SRC:1E9C2E DST:CUL_HM_ID_00A0_212145 0006 (CONFIG_END CHANNEL:0x00) (,BIDI,RPTEN)
2013.06.04 00:18:16 1: HMLAN/RAW: /R0C1E8AB7,0021,0031DBB5,00,FFC8,0280022121451E9C2E00FF0A9B48
2013.06.04 00:18:16 1: HMLAN_Parse: HMLAN1 R:R0C1E8AB7 stat:0021 t:0031DBB5 d:00 r:FFC8 m:02 8002 212145 1E9C2E 00FF0A9B48
2013.06.04 00:18:16 1: HMLAN_SdDly: HMLAN1 212145 S0C1E8D47,00,00000000,01,0C1E8D47,03A0011E9C2E2121450006
2013.06.04 00:18:16 1: HMLAN_Send: HMLAN1 S:S0C1E8D47 stat: 00 t:00000000 d:01 r:0C1E8D47 m:03 A001 1E9C2E 212145 0006
2013.06.04 00:18:16 1: RCV L:0E N:02 F:80 CMD:02 SRC:CUL_HM_ID_00A0_212145 DST:1E9C2E 00FF0A9B48 (ACK) (,RPTEN)
2013.06.04 00:18:16 1: HMLAN/RAW: /E212145,0100,0031DE40,FF,FFC7,03A0022121451E9C2E046DC532F16DC500
2013.06.04 00:18:16 1: HMLAN_Parse: HMLAN1 R:E212145 stat:0100 t:0031DE40 d:FF r:FFC7 m:03 A002 212145 1E9C2E 046DC532F16DC500
2013.06.04 00:18:16 1: RCV L:11 N:03 F:A0 CMD:02 SRC:CUL_HM_ID_00A0_212145 DST:1E9C2E 046DC532F16DC500 (ACK-proc Para1:0x6DC5 Para2:0x32F1 Para3:0x6DC5 Para4:0x00) (,BIDI,RPTEN)
2013.06.04 00:18:16 1: HMLAN: Skip ACK
2013.06.04 00:18:16 1: SND L:0A N:03 F:80 CMD:02 SRC:1E9C2E DST:CUL_HM_ID_00A0_212145 00 (ACK) (,RPTEN)
2013.06.04 00:18:16 1: HMLAN/RAW: /R0C1E8D47,0021,0031DE45,00,FFC7,0380022121451E9C2E004D9FEE5A
2013.06.04 00:18:16 1: HMLAN_Parse: HMLAN1 R:R0C1E8D47 stat:0021 t:0031DE45 d:00 r:FFC7 m:03 8002 212145 1E9C2E 004D9FEE5A
2013.06.04 00:18:16 1: RCV L:0E N:03 F:80 CMD:02 SRC:CUL_HM_ID_00A0_212145 DST:1E9C2E 004D9FEE5A (ACK) (,RPTEN)
2013.06.04 00:18:28 1: HMLAN_Send: HMLAN1 I:K
2013.06.04 00:18:28 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707691,1E9C2E,1E9C2E,00320E3A,0001
2013.06.04 00:18:28 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707691 d:1E9C2E O:1E9C2E t:00320E3A IDcnt:0001
Gruß,
Dietmar
Hallo Udo,
Die HMIds sehen gut aus.
Evtl kannst du mir einmal das fhem.cfg mailen, dann kann ich es einmal probieren.
Weder habe ich es heute abend geschafft, die Sache mit dem virtuellen Aktor zum Laufen zu bringen, noch habe ich es geschafft, einen Rauchmelder vernünftig in Betrieb zu nehmen, obwohl ich sämtliche Anleitungen hier im Forum gelesen und das Ding kreuz und quer und auch mit sich selbst gepaired habe.
Was hast du denn gemacht? Und was hat nicht funktioniert?
Virtuellen Aktor erstellen :
define va CUL_HM 112233 # die HMid muss einzig im System sein, kannst du frei waehlen
attr va virtual 1 # wie viele Channels du definierst ist deine Sache, Min einen
Jetzt hast du einen Channel "va_Btn1" der ist dein Aktor-channel. Met dem musst du arbeiten
Pairen solltest du eine virtuellen Aktor nie, nur peeren.
set HMFB01_01 peerChan 0 va_Btn1 single set
Lass hoeren, was nicht klappt.
Gruss Martin
Was nicht klappt? Ich bekomme keine grüne Bestätigung :(
Ich habe die Anleitung von Dir gestern genau so befolgt wie Du sie geschrieben hast. Mein Problem ist: ich muss verstehen, was ich da tue, blosses Abschreiben bringt mir nicht viel. Aber grundsätzlich hab ich schon verstanden, worum es geht: Eine logische Verknüpfung zwischen dem Knopf auf der Fernbedienung und einem Kanal des virtuellen Aktors herzustellen.
Wieso schreibst Du einmal (gestern)
set <...> peerChan 0 va_Btn1 single
und einmal (heute)
set <...> peerChan 0 va_Btn1 single set
Was bewirkt das set am Ende?
Was die Fernbedienung an sich angeht: Ich kann Dir meine gerne für Tests/Analysen ein paar Tage zukommen lassen, um den Fehlern in der Konsole auf die Spur zu kommen.
Hi Dietmar,
erst einmal solltes du auch die Definition des schalters einbauen wie Udo. Nehme die Datei aus dem Anhang, Freigabe mache ich spaeter
Offensichtlich hast du den gleichen Schalter (waren ja 3 zur auswahl)
Dein HM-RC-4-2 ist wohl auf AES eingestellt.
In dem Ausschnitt, den du gepostet hast scheint das pairing funktioniert zu haben. FHEM hat alles einmal wiederholen muessen, kann aber an der Verzoegerung durch AES gelegen haben. Hier sollte aber kein timeout aufgetreten sein.
Hast du AES selbst gesetzt? Es ist doch der RC4 und nicht einer seiner Key oder Sec varianten?
Gruss Martin
Von dem AES habe ich in meiner Konfiguration der Fernbedienung auch schonmal irgendwo etwas gesehen/gelesen (ich glaube nach dem peeren mit dem va)
Kann es sein, dass die neue FB das standardmäßig verwendet?
Kann ich nicht ausschliessen, dass AES ein ist.
Bei einer FB musst du unterscheiden zwischen AES zur Zentrale und AES zu den peers.
AES fordert immer der Empfaenger (meist Aktor) an und der Sender (button) muss es korrekt beantworten.
Wenn die Zentrale Parameter in der remote setzen will ist also die remote der Empfaenger und die Zentrale der Sender. Ansonsten ist es anders herum.
Wenn du einmal alle Register ausliest kann ich einmal versuchen zu deuten ;-)
Am besten Zeichnest du gleich die rohmessages auf.
Gruss Martin
Hallo Martin,
vielen Dank für Deine Unterstützung.
Zitat von: martinp876 schrieb am Di, 04 Juni 2013 10:43Virtuellen Aktor erstellen :
define va CUL_HM 112233
attr va virtual 1
set HMFB01_01 peerChan 0 va_Btn1 single set
Das hab ich jetzt alles gemacht (abgesehen davon, dass es "SET va virtual 1" muss) und ich habe nun folgende Ergebnisse:
Internals:
DEF 2123FC01
NAME HMFB01_01
NR 328
NTFY_TRIGGERTIME 2013-06-04 19:27:09
STATE Short (to HMLAN)
TYPE CUL_HM
chanNo 01
device HMFB01
Readings:
2013-06-04 19:27:09 state Short (to HMLAN)
2013-06-04 19:27:09 trigger Short_19
Helper:
Role:
chn 1
Shadowreg:
RegL_04:va_Btn1 01:00
Attributes:
group HM-RC-4-2
model HM-RC-4-2
peerIDs
room 60_Fernbedienung
und beim va:
Internals:
CFGFN
DEF 11223301
NAME va_Btn1
NR 368
STATE ???
TYPE CUL_HM
chanNo 01
device va
Readings:
2013-06-04 19:24:27 peerList HMFB01_01,
Helper:
Role:
chn 1
vrt 1
Attributes:
model virtual_1
peerIDs 2123FC01,
room CUL_HM
webCmd press short:press long
Jetzt kommt meine Verständnisfrage: Wie bekommt die Fernbedienung eigentlich etwas davon mit, dass sie nun mit dem va verbunden ist? Genauer: Wann bekommt sie das mit?
Der Eintrag in der Konfiguration ist ja erstmal nur "virtuell" und nicht wie beim physikalischen Anlernen mit den Anlerntasten durch eine "erzwungene" Kommunikation.
Müsste bei "peerIDs" vom HMFB01_01 nicht die ID des va auftauchen?
Viele Grüße
Udo
-----------
Nachtrag:
2013-06-04 19:51:07 HMLAN HMLAN RCV L:0B N:66 F:A2 CMD:40 SRC:HMFB01 DST:9601BD 0127 (REMOTE BUTTON:1 LONG:0 LOWBAT:0 COUNTER:0x27) (,WAKEMEUP,BIDI,RPTEN)
2013-06-04 19:51:07 HMLAN HMLAN SND L:0D N:66 F:80 CMD:02 SRC:9601BD DST:HMFB01 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013-06-04 19:51:07 CUL_HM HMFB01_01 Short (to HMLAN)
2013-06-04 19:51:07 CUL_HM HMFB01_01 trigger: Short_39
2013-06-04 19:51:07 CUL_HM HMFB01 battery: ok
2013-06-04 19:51:07 CUL_HM HMFB01 HMFB01_01 Short (to HMLAN)
Wenn ich das richtig sehe, ist vom va da nix zu sehen.
Die Fernbedienung kommt über ein RESPONSE TIMEOUT nicht hinaus.
Internals:
DEF 2123FC
IODev HMLAN
NAME HMFB01
NR 322
NTFY_TRIGGERTIME 2013-06-04 21:53:34
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 HMFB01_01
channel_02 HMFB01_02
channel_03 HMFB01_03
channel_04 HMFB01_04
protCmdDel 0
protResnd 4 last_at:2013-06-04 21:53:28
protResndFail 1 last_at:2013-06-04 21:53:34
protSnd 1 last_at:2013-06-04 21:53:10
protState CMDs_done_events:5
Readings:
2013-06-04 19:39:49 CommandAccepted yes
2013-06-04 19:39:48 R-intKeyVisib set_invisib
2013-06-04 19:39:48 R-pairCentral set_0x9601BD
2013-06-04 21:08:57 battery ok
2013-06-04 19:42:30 noReceiver src:2123FC A240 0121
2013-06-04 21:53:34 state RESPONSE TIMEOUT:RegisterRead
Regl_00::
VAL
Helper:
burstEvtCnt 5
rxType 1
Respwait:
Role:
dev 1
Attributes:
expert 2_full
firmware 1.0
group HM-RC-4-2
model HM-RC-4-2
peerIDs
room 60_Fernbedienung
serialNr KEQ0111919
subType remote
webCmd getConfig
Und der va nicht über ein MISSING ACK
Internals:
DEF 112233
IODev HMLAN
NAME va
NR 329
STATE MISSING ACK
TYPE CUL_HM
channel_01 va_Btn1
Readings:
2013-06-04 19:43:44 state MISSING ACK
Helper:
rxType 1
Role:
dev 1
vrt 1
Attributes:
expert 2_full
group FB_test
model virtual_1
peerIDs
room CUL_HM
subType virtual
webCmd press short:press long
Und der Channel des va selbst weiss auch nichts über seine eigene Identität
Internals:
DEF 11223301
NAME va_Btn1
NR 330
STATE set_?
TYPE CUL_HM
chanNo 01
device va
Readings:
2013-06-04 21:30:46 peerList HMFB01_01,
2013-06-04 19:45:19 state set_?
Helper:
Role:
chn 1
vrt 1
Attributes:
expert 2_full
group FB_test
model virtual_1
peerIDs 2123FC01,
room CUL_HM
webCmd press short:press long
Hallo Udo,
du siehst es richtig, der va_Btn1 muss auch in der remote auftauchen.
Die remote bekommt es uebermittelt mit peerChan.
Aktuell sehe ich nicht, dass das peering oder auch das pairing funktioniert hat.
R-pairCentral set_0x9601BD besagtm dass du die FHEM Zentrale anlernen wolltest, aber eben nicht ob es funktioniert hat.
Versuche das peeren noch einmal. Evtl mit allen 3 methoden
set HMLAN pairSerial KEQ0111919
set HMFB01 pair
set HMFB01 getConfig
#=> Daten werden uebertragen, sobald du anlernen kurz drueckst (lang ist reset!)
Gruss Martin
In der HomeMatic Konfigurationssoftware 1.506 wird die Fernbedienung übrigens als HM-RC-X und ohne Bild ausgewiesen. Ich vermute, dass diese neue Fernbedienung selbst dort noch nicht vollständig bekannt ist. Immerhin werden die 4 Channels angezeigt und man hat die Möglichkeit, Tastendrücke in ihrer Dauer zu konfigurieren.
Das pairen und peeren teste ich heute abend nochmal.
Das sollte korrekt sein. Sie ist auch nicht in der Version 1.508 vorhanden (sonst heatte ich es schon eingebaut). Und eine neuere ist auf der eQ3 Seite nicht zu sehen.
Ich habe noch nichtmal die 1.508 irgendwo gefunden.
edit: 1.508 scheint es nur für CCU zu geben, nicht für den LAN Adapter.
Ich habe nun die Fernbedienung nochmal komplett gelöscht und auf Werkeinstellungen zurückgesetzt. Danach ein erneutes Pairing mit FHEM über den HM LAN Adapter.
2013-06-05 19:13:22 HMLAN HMLAN hmPairForSec 120
2013-06-05 19:13:30 CUL_HM CUL_HM_HM_RC_4_2_2123FC R-pairCentral: set_0x9601BD
2013-06-05 19:13:30 HMLAN HMLAN SND L:10 N:01 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00050000000000 (CONFIG_START CHANNEL:0x00 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x00) (,BIDI,RPTEN)
2013-06-05 19:13:30 Global global UNDEFINED CUL_HM_HM_RC_4_2_2123FC CUL_HM 2123FC A1A0084002123FC0000001000A04B45513031313139313940040000
2013-06-05 19:13:30 Global global DEFINED CUL_HM_HM_RC_4_2_2123FC
2013-06-05 19:13:30 Global global DEFINED FileLog_CUL_HM_HM_RC_4_2_2123FC
2013-06-05 19:13:30 Global global SAVE
2013-06-05 19:13:30 HMLAN HMLAN RCV L:0A N:01 F:80 CMD:02 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 00 (ACK) (,RPTEN)
2013-06-05 19:13:31 HMLAN HMLAN SND L:13 N:02 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 000802010A960B010CBD (CONFIG_WRITE_INDEX CHANNEL:0x00 DATA: 02:01 0A:96 0B:01 0C:BD) (,BIDI,RPTEN)
2013-06-05 19:13:31 HMLAN HMLAN RCV L:0A N:02 F:80 CMD:02 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 00 (ACK) (,RPTEN)
2013-06-05 19:13:31 HMLAN HMLAN SND L:0B N:03 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 0006 (CONFIG_END CHANNEL:0x00) (,BIDI,RPTEN)
2013-06-05 19:13:31 Global global UNDEFINED CUL_HM_HM_RC_4_2_2123FC_Btn_01 CUL_HM 2123FC01
2013-06-05 19:13:31 Global global DEFINED CUL_HM_HM_RC_4_2_2123FC_Btn_01
2013-06-05 19:13:31 Global global DEFINED FileLog_CUL_HM_HM_RC_4_2_2123FC_Btn_01
2013-06-05 19:13:31 Global global SAVE
2013-06-05 19:13:31 HMLAN HMLAN RCV L:0A N:03 F:80 CMD:02 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 00 (ACK) (,RPTEN)
2013-06-05 19:13:31 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_done
2013-06-05 19:13:32 Global global UNDEFINED CUL_HM_HM_RC_4_2_2123FC_Btn_02 CUL_HM 2123FC02
2013-06-05 19:13:32 Global global DEFINED CUL_HM_HM_RC_4_2_2123FC_Btn_02
2013-06-05 19:13:32 Global global DEFINED FileLog_CUL_HM_HM_RC_4_2_2123FC_Btn_02
2013-06-05 19:13:32 Global global SAVE
2013-06-05 19:13:33 Global global UNDEFINED CUL_HM_HM_RC_4_2_2123FC_Btn_03 CUL_HM 2123FC03
2013-06-05 19:13:33 Global global DEFINED CUL_HM_HM_RC_4_2_2123FC_Btn_03
2013-06-05 19:13:33 Global global DEFINED FileLog_CUL_HM_HM_RC_4_2_2123FC_Btn_03
2013-06-05 19:13:33 Global global SAVE
2013-06-05 19:13:34 Global global UNDEFINED CUL_HM_HM_RC_4_2_2123FC_Btn_04 CUL_HM 2123FC04
2013-06-05 19:13:34 Global global DEFINED CUL_HM_HM_RC_4_2_2123FC_Btn_04
2013-06-05 19:13:34 Global global DEFINED FileLog_CUL_HM_HM_RC_4_2_2123FC_Btn_04
2013-06-05 19:13:34 Global global SAVE
Die Fernbedienung signalisiert das Ende mit grün.
Auf der Konsole passiert dabei folgendes:
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3821.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3821.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3821.
Use of uninitialized value in multiplication (*) at ./FHEM/10_CUL_HM.pm line 3821.
Und ein anschließendes getConfig ergibt 9 CMDs pending:
2013-06-05 19:15:57 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_pending
2013-06-05 19:15:57 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_pending
2013-06-05 19:15:57 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_pending
2013-06-05 19:15:57 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_pending
2013-06-05 19:15:57 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_pending
2013-06-05 19:15:57 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_pending
2013-06-05 19:15:58 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_pending
2013-06-05 19:15:58 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_pending
2013-06-05 19:15:58 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_pending
Wenn ich danach den Anlernen-Knopf an der Fernbedienung nochmal drücke, passiert folgendes:
2013-06-05 19:20:26 HMLAN HMLAN RCV L:1A N:01 F:A2 CMD:00 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 1000A04B45513031313139313940040000 (DEVICE_INFO FIRMWARE:0x10 TYPE:0x00A0 SERIALNO:KEQ0111919 CLASS:0x40 PEER_CHANNEL_A:0x04 PEER_CHANNEL_B:0x00 UNKNOWN:0x00) (,WAKEMEUP,BIDI,RPTEN)
2013-06-05 19:20:26 HMLAN HMLAN SND L:10 N:02 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00040000000000 (CONFIG_PARAM_REQ CHANNEL:0x00 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x00) (,BIDI,RPTEN)
2013-06-05 19:20:26 HMLAN HMLAN SND L:0A N:01 F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:26 HMLAN HMLAN RCV L:16 N:02 F:A0 CMD:10 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 0202010A960B010CBD18000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x02010A960B010CBD18000000) (,BIDI,RPTEN)
2013-06-05 19:20:26 HMLAN HMLAN SND L:0A N:02 F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:26 HMLAN HMLAN SND L:10 N:03 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 01040000000001 (CONFIG_PARAM_REQ CHANNEL:0x01 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013-06-05 19:20:27 HMLAN HMLAN RCV L:12 N:03 F:A0 CMD:10 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 020410080009000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x0410080009000000) (,BIDI,RPTEN)
2013-06-05 19:20:27 HMLAN HMLAN SND L:0A N:03 F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:27 HMLAN HMLAN SND L:0B N:04 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 0103 (CONFIG_PEER_LIST_REQ CHANNEL:0x01) (,BIDI,RPTEN)
2013-06-05 19:20:27 HMLAN HMLAN RCV L:0E N:04 F:A0 CMD:10 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 0100000000 (INFO_PEER_LIST PEER1:broadcast) (,BIDI,RPTEN)
2013-06-05 19:20:27 HMLAN HMLAN SND L:0A N:04 F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:28 HMLAN HMLAN SND L:10 N:05 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 02040000000001 (CONFIG_PARAM_REQ CHANNEL:0x02 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013-06-05 19:20:28 HMLAN HMLAN RCV L:12 N:05 F:A0 CMD:10 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 020410080009000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x0410080009000000) (,BIDI,RPTEN)
2013-06-05 19:20:28 HMLAN HMLAN SND L:0A N:05 F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:28 HMLAN HMLAN SND L:0B N:06 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 0203 (CONFIG_PEER_LIST_REQ CHANNEL:0x02) (,BIDI,RPTEN)
2013-06-05 19:20:29 HMLAN HMLAN RCV L:0E N:06 F:A0 CMD:10 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 0100000000 (INFO_PEER_LIST PEER1:broadcast) (,BIDI,RPTEN)
2013-06-05 19:20:29 HMLAN HMLAN SND L:0A N:06 F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:29 HMLAN HMLAN SND L:10 N:07 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 03040000000001 (CONFIG_PARAM_REQ CHANNEL:0x03 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013-06-05 19:20:30 FHT bd_FHT actuator: 0%
2013-06-05 19:20:30 HMLAN HMLAN RCV L:12 N:07 F:A0 CMD:10 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 020410080009000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x0410080009000000) (,BIDI,RPTEN)
2013-06-05 19:20:30 HMLAN HMLAN SND L:0A N:07 F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:30 HMLAN HMLAN SND L:0B N:08 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 0303 (CONFIG_PEER_LIST_REQ CHANNEL:0x03) (,BIDI,RPTEN)
2013-06-05 19:20:31 HMLAN HMLAN RCV L:0E N:08 F:A0 CMD:10 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 0100000000 (INFO_PEER_LIST PEER1:broadcast) (,BIDI,RPTEN)
2013-06-05 19:20:31 HMLAN HMLAN SND L:0A N:08 F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:31 HMLAN HMLAN SND L:10 N:09 F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 04040000000001 (CONFIG_PARAM_REQ CHANNEL:0x04 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013-06-05 19:20:31 HMLAN HMLAN RCV L:12 N:09 F:A0 CMD:10 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 020410080009000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x0410080009000000) (,BIDI,RPTEN)
2013-06-05 19:20:31 HMLAN HMLAN SND L:0A N:09 F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:31 HMLAN HMLAN SND L:0B N:0A F:A0 CMD:01 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 0403 (CONFIG_PEER_LIST_REQ CHANNEL:0x04) (,BIDI,RPTEN)
2013-06-05 19:20:32 HMLAN HMLAN RCV L:0E N:0A F:A0 CMD:10 SRC:CUL_HM_HM_RC_4_2_2123FC DST:9601BD 0100000000 (INFO_PEER_LIST PEER1:broadcast) (,BIDI,RPTEN)
2013-06-05 19:20:32 HMLAN HMLAN SND L:0A N:0A F:80 CMD:02 SRC:9601BD DST:CUL_HM_HM_RC_4_2_2123FC 00 (ACK) (,RPTEN)
2013-06-05 19:20:32 CUL_HM CUL_HM_HM_RC_4_2_2123FC CMDs_done
Ein anschließendes getConfig ergibt wieder 9 pending CMDs.
Es geschehen noch Zeichen und Wunder :) Endlich eine grüne Bestätigung beim Knopfdrücken!
2013-06-05 19:28:12 HMLAN HMLAN RCV L:0B N:04 F:A4 CMD:40 SRC:HMFB01 DST:va 0101 (REMOTE BUTTON:1 LONG:0 LOWBAT:0 COUNTER:0x01) (,CFG,BIDI,RPTEN)
2013-06-05 19:28:12 HMLAN HMLAN SND L:0D N:04 F:80 CMD:02 SRC:va DST:HMFB01 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013-06-05 19:28:12 CUL_HM HMFB01_01 Short (to va)
2013-06-05 19:28:12 CUL_HM HMFB01_01 trigger: Short_1
2013-06-05 19:28:12 CUL_HM va_Btn1 ON
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActState: ON
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-05 19:28:12 CUL_HM va_Btn1 virtActTrigNo: 1
2013-06-05 19:28:12 CUL_HM HMFB01 battery: ok
Aber die Peer-ID taucht beim Button immer noch nicht auf: (ist mir aber jetzt fast egal...)
Internals:
CFGFN
DEF 2123FC01
NAME HMFB01_01
NR 338
NTFY_TRIGGERTIME 2013-06-05 19:28:12
STATE Short (to va)
TYPE CUL_HM
chanNo 01
device HMFB01
Readings:
2013-06-05 19:27:07 R-dblPress 0 s
2013-06-05 19:27:07 R-longPress 0.4 s
2013-06-05 19:27:07 R-sign off
2013-06-05 19:26:38 R-va_Btn1-expectAES set_off
2013-06-05 19:26:38 R-va_Btn1-peerNeedsBurst set_off
2013-06-05 19:27:07 RegL_01: 04:10 08:00 09:00 00:00
2013-06-05 19:28:12 state Short (to va)
2013-06-05 19:28:12 trigger Short_1
Helper:
peerIDsRaw ,00000000
Role:
chn 1
Shadowreg:
RegL_04:va_Btn1 01:00
Attributes:
model HM-RC-4-2
peerIDs 00000000,
room CUL_HM
Die Rückmeldung ist sehr unzuverlässig. Oft meldet die Fernbedienung nach einem Tastendruck rot und erst nach dem dritten oder vierten Versuch kommt ein Grün. Das Schlimme daran ist, dass die gepeerte Aktion vom virtuellen Aktor aber trotzdem ausgeführt wird, auch wenn eine "rote" Rückmeldung kommt.
Für mich sieht das irgendwie nach Timing-Problemen aus.
Hi,
Line 3821 ist bekannt, unkritisch (RSSI berechnung), wird behoben.
ZitatUnd ein anschließendes getConfig ergibt 9 CMDs pending:
ist auch ok. Die Kommandos werden ja erst in die Queue gesteckt und muessen dort auf Anlernen warten - bei einer Remote.
Du kannst in FHEM ueber event-on-change einstellen, ob diese Meldungen nur bei Statusaeunderung kommen sollen. Siehe auch event-on-update
ZitatEin anschließendes getConfig ergibt wieder 9 pending CMDs.
auch logisch - oder? Wird immer kommen, wenn du commandos an die remote richtest - also alle Devices, die eben nicht sofort bedient werden koennen.
ZitatEs geschehen noch Zeichen und Wunder :) Endlich eine grüne Bestätigung beim Knopfdrücken!
na das ist ja schon einmal gut.
ZitatDie Rückmeldung ist sehr unzuverlässig...
Für mich sieht das irgendwie nach Timing-Problemen aus.
moeglich (warscheinlich), oder der Empfangspegel.
Schaue dir doch einmal die RSSI werden an.
Und jetzt das timing, setze :
attr global mseclog 1
attr global verbose 1
attr HMLAN loglevel 1
dann zeichne einige der Aktionen auf und schreibe dazu, wann die LED rot oder gruen war.
Gruss Martin
Zitat von: martinp876 schrieb am Do, 06 Juni 2013 09:24Line 3821 ist bekannt, unkritisch
hab ich nach einem Blick in den Sourcecode auch so interpretiert :)
Zitat von: martinp876 schrieb am Do, 06 Juni 2013 09:24ist auch ok.
[...]
auch logisch - oder?
ich sag mal so: Ja, es ist logisch, wenn man die Philosophie von HomeMatic so genau kennt und so tief drinsteckt wie Du.
Für mein Verständnis hat mir bis gestern folgende wichtige Information gefehlt, die Du dann hier - nach meiner grundlegenden Verständnisfrage - gegeben hast:
Zitatset HMFB01 getConfig
#=> Daten werden uebertragen, sobald du anlernen kurz drueckst
Mit der commandref habe ich immer wieder mal das Problem, dass diese wohl von Entwicklern erstellt ist, die bei den Beschreibungen immer von ihrem vollständigen eigenen Hintergrundwissen ausgehen. Das ist zwar sachlich dann alles richtig beschrieben, aber es bedeutet nicht automatisch, dass damit jeder Anwender zurechtkommt. Da ich selbst meine Brötchen als Softwareentwickler verdiene (wenn auch in einem völlig anderen Fachbereich) kenne ich dieses "Problem" nur zu gut. Deshalb schreibe ich für von mir erstellte Programme schon seit ca. 10 Jahren keinerlei Anwenderdokumentationen mehr selbst, sondern überlasse das den technischen Redakteuren bei uns in der Firma, die den ganzen Tag nix anderes machen :)
Zitat von: martinp876 schrieb am Do, 06 Juni 2013 09:24moeglich (warscheinlich), oder der Empfangspegel.
Schaue dir doch einmal die RSSI werden an.
Empfangspegel schließe ich erstmal aus. Drei Meter Entfernung und freie Sicht zwischen HMLAN und Fernbedienung sollten keine Probleme machen.
Zitat von: martinp876 schrieb am Do, 06 Juni 2013 09:24Und jetzt das timing, setze :
attr global mseclog 1
attr global verbose 1
attr HMLAN loglevel 1
dann zeichne einige der Aktionen auf und schreibe dazu, wann die LED rot oder gruen war.
Werde ich heute abend machen und die Ergebnisse mitteilen.
Danke & Gruß
Udo
grün:
2013-06-06 18:05:21.525 CUL_HM HMFB01_02 Short (to va)
2013-06-06 18:05:21.525 CUL_HM HMFB01_02 trigger: Short_16
2013-06-06 18:05:21.623 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.672 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.720 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.768 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.816 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.864 dummy wz_FHT_Soll 16
2013-06-06 18:05:21.866 CUL_HM va_Btn2 ON
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActState: ON
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActTrigger: HMFB01_02
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActTrigType: short_Release
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActTrigRpt: 1
2013-06-06 18:05:21.866 CUL_HM va_Btn2 virtActTrigNo: 16
2013-06-06 18:05:21.912 CUL_HM HMFB01 battery: ok
2013-06-06 18:05:21.912 CUL_HM HMFB01 HMFB01_02 Short (to va)
rot:
2013-06-06 18:06:16.797 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:06:16.797 CUL_HM HMFB01_01 trigger: Short_18
2013-06-06 18:06:16.892 dummy wz_FHT_Soll 18
2013-06-06 18:06:16.941 dummy wz_FHT_Soll 18
2013-06-06 18:06:16.990 dummy wz_FHT_Soll 18
2013-06-06 18:06:17.038 dummy wz_FHT_Soll 18
2013-06-06 18:06:17.086 dummy wz_FHT_Soll 18
2013-06-06 18:06:17.134 dummy wz_FHT_Soll 18
2013-06-06 18:06:17.137 CUL_HM va_Btn1 OFF
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActState: OFF
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:06:17.137 CUL_HM va_Btn1 virtActTrigNo: 18
2013-06-06 18:06:17.183 CUL_HM HMFB01 battery: ok
2013-06-06 18:06:17.183 CUL_HM HMFB01 HMFB01_01 Short (to va)
rot:
2013-06-06 18:07:46.814 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:07:46.814 CUL_HM HMFB01_01 trigger: Short_20
2013-06-06 18:07:46.909 dummy wz_FHT_Soll 19
2013-06-06 18:07:46.958 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.007 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.054 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.102 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.150 dummy wz_FHT_Soll 19
2013-06-06 18:07:47.153 CUL_HM va_Btn1 OFF
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActState: OFF
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:07:47.153 CUL_HM va_Btn1 virtActTrigNo: 20
2013-06-06 18:07:47.199 CUL_HM HMFB01 battery: ok
2013-06-06 18:07:47.199 CUL_HM HMFB01 HMFB01_01 Short (to va)
rot:
2013-06-06 18:08:18.147 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:08:18.147 CUL_HM HMFB01_01 trigger: Short_21
2013-06-06 18:08:18.245 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.294 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.343 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.391 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.440 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.489 dummy wz_FHT_Soll 19
2013-06-06 18:08:18.492 CUL_HM va_Btn1 ON
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActState: ON
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:08:18.492 CUL_HM va_Btn1 virtActTrigNo: 21
2013-06-06 18:08:18.538 CUL_HM HMFB01 battery: ok
2013-06-06 18:08:18.538 CUL_HM HMFB01 HMFB01_01 Short (to va)
grün:
2013-06-06 18:08:21.527 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:08:21.527 CUL_HM HMFB01_01 trigger: Short_22
2013-06-06 18:08:21.622 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.670 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.718 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.766 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.814 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.862 dummy wz_FHT_Soll 19
2013-06-06 18:08:21.865 CUL_HM va_Btn1 OFF
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActState: OFF
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:08:21.865 CUL_HM va_Btn1 virtActTrigNo: 22
2013-06-06 18:08:21.912 CUL_HM HMFB01 battery: ok
2013-06-06 18:08:21.912 CUL_HM HMFB01 HMFB01_01 Short (to va)
grün:
2013-06-06 18:09:40.581 CUL_HM HMFB01_01 Short (to va)
2013-06-06 18:09:40.581 CUL_HM HMFB01_01 trigger: Short_23
2013-06-06 18:09:40.676 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.724 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.772 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.820 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.868 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.916 dummy wz_FHT_Soll 20
2013-06-06 18:09:40.919 CUL_HM va_Btn1 ON
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActState: ON
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActTrigger: HMFB01_01
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActTrigType: short_Release
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActTrigRpt: 1
2013-06-06 18:09:40.919 CUL_HM va_Btn1 virtActTrigNo: 23
2013-06-06 18:09:40.964 CUL_HM HMFB01 battery: ok
2013-06-06 18:09:40.964 CUL_HM HMFB01 HMFB01_01 Short (to va)
Protokolldatei im Anhang.
Hallo Udo,
Die Doku kann man sicher verbessern. Das Commandref sehe ich aber dennoch nicht als Referenz, nicht als Dokumentation im Sinne von Einfuehrung, Grundlagen Philosophie oder Archektur, weder FHEM noch HM. Daher habe ich anfaenglich den Anhang zum Einsteigerdoc fuer HM geschrieben - der sollte den HM Aspekt aus FHEM sicht darstellen. Ich empfehle jedem, es einmal zu ueberfliegen, zumindest wenn er etwas mehr machen will.
Verbessern kann man das sicher noch, einen technischen Redakteur habe ich leider nicht.
Wiki ist ein 2. Ansatz, beinhaltet aber mehr praktische Details und beantwortet m.E. keine Fragen zur Architektur. Hier habe ich die Hoffnung, dass die User genau aus ihrer Sicht beschreiben, quasi als technische Redakteure.
Deine Logs
Zum einen sind mehr Aktionen im Log als du auf gefuehrt hast, ist ok.
Timing: ist aus FHEM sicht ok und Praezise, leider nicht echtzeitfaehig.
Die Details (falls du etwas an der Tiefen interresse hast):
FHEM antwortet nach 100ms - ist beabsichtigt, man darf nicht zu schnell sein...
Wenn ich jetzt die von HMLAN gelieferten Zeitstempel umrechne ist zu sehen, dass FHEM einen mit einer Varianz von bis zu 75ms addiert. In diene Logs kann man sehr schoen sehen, dass delays bis 29ms erfolgreich beantwortet wurden. Der Delay mit 39 ms und hoeher ging schief.
Nachdenklich stimmt mich noch mehr, dass die Wiederhohlung der remote (praezise nach 250ms gesendet) mit ~350ms Verspaetung eintrifft. Deren Beantwortung ist demnach sinnlos, den zu diesen Zeitpunkt hat deine remote schon die 2. Wiederholung ins Feld geschickt.
Die 2. Wiederholung kommt dann mit nur noch ~80ms delay daher.
Das ganze ist zu erklaeren, da FHEM die erste Meldung komplett parsed und eine Antwort schickt. Das Parsen und die Anzahl der Notifes (auch fileLogs) sind verantwortlich fuer den Delay. Da die 2. Message nicht mehr geparst wird und somit auch keine Notifies abgeprueft werden geht alles viel schneller, wir holen wieder auf.
So, viel Hintergrund.
Du kannst einmal die wartezeit von 100ms reduzieren
00_HMLAN.pm zeile 330:
$hash->{helper}{nextSend}{$src} = gettimeofday() + 0.100;
auf
$hash->{helper}{nextSend}{$src} = gettimeofday() + 0.070;
Generell hatte ich mit kuerzeren Zeiten Probleme, es ist also keine generelle Loesung. Ich muss also versuchen, den Zeitstempel des HMLAN zu nutzen, um den ethernet/IO-delay zu eliminieren. Das kostet aber etwas Aufwand, dauert also.
Gruss
Martin
Hallo Martin,
bitte nicht falsch verstehen: Meine Aussage zu commandref etc war keine Kritik an irgendjemandem persönlich, der sich die Mühe macht und die Zeit investiert, das überhaupt zu pflegen. Ganz im Gegenteil.
Und Deinen HomeMatic-Anhang werde ich mir in einer ruhigen Stunde noch einmal zu Gemüte führen. Irgendwie hatte ich den Einsteigerleitfaden mehr oder weniger bisher nur überflogen.
Ich habe jetzt testweise die von Dir vorgeschlagene Änderung im Timing eingebaut und bisher hatte ich keine rote Rückmeldung an der Fernbedienung mehr. Danke für diesen Vorschlag!
Ob es dadurch jetzt irgendwelche Auffälligkeiten an anderen hier eingesetzen HM-Komponenten gibt, werde ich beobachten.
Für mich funktioniert die neue Fernbedienung jedenfalls jetzt so wie ihr Einsatz auch geplant war und ich habe dabei viel gelernt.
Dann kann ich mich also in Kürze der nächsten HM-Baustelle (Rauchmelder) widmen.
Hallo Udo,
konstruktive Kritik ist nie schlecht, ich denke ich habe es schon richtig verstanden. Ich wollte auch nur den Anspruch der Dokumentation klarlegen, jedenfalls meine Sicht der Level.
Das veraenderte Timing (reduzieren der 100ms) hat mir schon Probleme bereitet, werde ich also nicht generell einbauen. Das Timing aus dem HMLAN zu nehmen waere besser, aber leider ist ist es nicht ganz einfach eine Korrelation zum FHEMclock (sysTime) herzustellen. Ausserdem laufen die Uhren auseinander, wie ich in alten Logs gesehen habe. Wird eine Bastelei...
Gruss Martin
Ich habe jetzt das Eiscafe-Wetter genutzt und mir bei einem leckeren Nussbecher Deine Homematic-Beschreibung nochmal zu Gemüte geführt. In der Kombination aus den Erfahrungen bei der FB-Inbetriebnahme und dieser Doku wurden mir dann doch noch einige Zusammenhänge klarer.
Eine Frage hab ich aber im Moment doch noch: Was verbirgt sich hinter der peerID 000000, die mir in den Attributen jedes Fernbedienungs-Channels zusätzlich zur peerID des va_Channels angezeigt wird?
Inzwischen hatte ich schon wieder ein paar rote Rückmeldungen, meistens dann, wenn die Fernbedienung länger nicht benutzt wurde und dann wieder einer der Buttons gedrückt wurde.
Moin !
Ich kann das Problem mit dem nicht/schlecht verarbeiteten ACK bei dieser Verbedienung
auch mit einem CUL und einem CUNO nachvollziehen. Der ACK wird nur innerhalb eines
ganz engen Radius von der FB erkannt/verarbeitet, wobei es beim CUL besser klappt als
beim CUNO.
2013.06.08 00:09:30.329 1: CUNO1: A0D8A800211223321237F01010000 -67.5
2013.06.08 00:09:30.341 1: CUNO1: A0B8AA04021237F1122330167 -59.5
2013.06.08 00:09:30.349 1: CUNO1: A0B8AA04021237F1122330167 -59.5
2013.06.08 00:09:33.709 1: CUNO1: A0B8BA44021237F1122330168 -54
2013.06.08 00:09:33.717 1: CUNO1: A0D8B800211223321237F0101C800 -67.5
2013.06.08 00:09:33.725 1: CUNO1: A0B8BA04021237F1122330168 -54
2013.06.08 00:09:33.745 1: CUNO1: A0B8BA04021237F1122330168 -54
2013.06.08 00:09:37.225 1: CUNO1: A0B8CA44021237F1122330169 -52
2013.06.08 00:09:37.233 1: CUNO1: A0D8C800211223321237F01010000 -64
2013.06.08 00:09:37.241 1: CUNO1: A0B8CA04021237F1122330169 -52
2013.06.08 00:09:37.249 1: CUNO1: A0CAE86701CCD3D00000000BC3C -41.5
2013.06.08 00:09:37.909 1: CUNO1: A0B8CA04021237F1122330169 -51.5
2013.06.08 00:09:40.885 1: CUNO1: A0B8DA44021237F112233016A -53.5
2013.06.08 00:09:40.893 1: CUNO1: A0D8D800211223321237F0101C800 -64
2013.06.08 00:09:40.901 1: CUNO1: A0B8DA04021237F112233016A -53.5
2013.06.08 00:09:40.985 1: CUNO1: A0B8DA04021237F112233016A -54
2013.06.08 00:09:44.785 1: CUNO1: A0B8EA44021237F112233016B -53.5
2013.06.08 00:09:44.793 1: CUNO1: A0D8E800211223321237F01010000 -64.5
2013.06.08 00:09:44.805 1: CUNO1: A0B8EA04021237F112233016B -52.5
2013.06.08 00:09:44.809 1: CUNO1: A0B8EA04021237F112233016B -50
2013.06.08 00:09:48.465 1: CUNO1: A0B8FA44021237F112233016C -58
2013.06.08 00:09:48.469 1: CUNO1: A0D8F800211223321237F0101C800 -65
2013.06.08 00:09:48.481 1: CUNO1: A0B8FA04021237F112233016C -59
2013.06.08 00:09:48.501 1: CUNO1: A0B8FA04021237F112233016C -59
2013.06.08 00:09:52.209 1: CUNO1: A0B90A44021237F112233016D -63.5
2013.06.08 00:09:52.217 1: CUNO1: A0D90800211223321237F01010000 -63.5
2013.06.08 00:09:52.229 1: CUNO1: A0B90A04021237F112233016D -63.5
2013.06.08 00:09:52.249 1: CUNO1: A0B90A04021237F112233016D -63.5
2013.06.08 00:09:55.801 1: CUNO1: A0B91A44021237F112233016E -65
2013.06.08 00:09:55.809 1: CUNO1: A0D91800211223321237F0101C800 -63.5
2013.06.08 00:09:55.817 1: CUNO1: A0B91A04021237F112233016E -65
2013.06.08 00:09:55.825 1: CUNO1: A0B91A04021237F112233016E -65
2013.06.08 00:09:59.433 1: CUNO1: A0B92A44021237F112233016F -63.5
2013.06.08 00:09:59.441 1: CUNO1: A0D92800211223321237F01010000 -66
2013.06.08 00:09:59.449 1: CUNO1: A0B92A04021237F112233016F -61.5
2013.06.08 00:09:59.469 1: CUNO1: A0B92A04021237F112233016F -61.5
2013.06.08 00:10:03.017 1: CUNO1: A0B93A44021237F1122330170 -51.5
2013.06.08 00:10:03.025 1: CUNO1: A0D93800211223321237F0101C800 -66
2013.06.08 00:10:03.033 1: CUNO1: A0B93A04021237F1122330170 -48
2013.06.08 00:10:03.041 1: CUNO1: A0B93A04021237F1122330170 -45.5
2013.06.08 00:10:47.153 1: CUNO1: A0C2F86701AC26A00000000CA3E -59.5
Gruß, Marc
Hi !
Ich habe den zweiten Button der FB eben noch einmal mit einem realen Schalter gepeert (
HM-LC-Sw1PBU-FM). Hier klappt es wunderbar. Scheint also wirklich ein Timingproblem
mit FHEM zu sein. Da ich Devices aber eh direkt schalten will und FHEM an dieser
Stelle nur nutze, um das Peering zu definieren, bin ich glücklich :-)
Gruß, Marc
Hallo,
ich hab mir auch einen HM-RC-4-2 besorgt und diesen mit auto-create in FHEM eingebunden:
define CUL_HM_ID_00A0_212322 CUL_HM 212322
attr CUL_HM_ID_00A0_212322 .devInfo 040000
attr CUL_HM_ID_00A0_212322 .stc 40
attr CUL_HM_ID_00A0_212322 firmware 1.0
attr CUL_HM_ID_00A0_212322 model unknown
attr CUL_HM_ID_00A0_212322 room CUL_HM
attr CUL_HM_ID_00A0_212322 serialNr KEQ0111704
attr CUL_HM_ID_00A0_212322 subType
define FileLog_CUL_HM_ID_00A0_212322 FileLog ./log/CUL_HM_ID_00A0_212322-%Y.log CUL_HM_ID_00A0_212322
attr FileLog_CUL_HM_ID_00A0_212322 logtype text
attr FileLog_CUL_HM_ID_00A0_212322 room CUL_HM
Jedoch funktioniert der Handsender in FHEM dann nicht :-(
Wie hast du den Handsender in FHEM angelegt?
LG. Dextha
Hallo Dextha !
Hast Du den Rest des Threads gelesen ? Offensichtlich hast Du die Erweiterung in der HMConfig.pm
nicht vorgenommen und deswegen kann FHEM mit der FB nichts anfangen:
attr CUL_HM_ID_00A0_212322 model unknown
Der HM-RC-4-2 ist recht neu, Martin hat die Änderung nocht nicht im SVN eigecheckt. Wird er sicher
bald tun. Bis dahin musst Du die eine Zeile von Hand in die HCMConfig.pm eintragen, FHEM neu starten
und die FB neu mit FHEM pairen.
Gruß, Mar
Wie werde ich denn nach den vielen Experimenten hier im Thread diese vielen Logeinträge wieder los:
2013.06.08 20:23:31 1: HMLAN_Send: ...
2013.06.08 20:23:31 1: HMLAN_Parse: ...
Welchen loglevel oder welchen verbose muss ich da anpacken?
Jetzt gings.... hatte die Zeile scheinbar an der falschen Stelle oder falsch drin....
Danke!
Zitat von: betateilchen schrieb am Sa, 08 Juni 2013 20:27Wie werde ich denn nach den vielen Experimenten hier im Thread diese vielen Logeinträge wieder los:
ich hab das loglevel-Attribut im HMLAN gelöscht - scheint zu wirken :)
Hi,
die HMID 000000 wird ist ein Dummy. Sie wird als Zieladresse genutzt, wenn es ein Broadcast ist - also eben keine Adresse.
Ausserdem taucht sie auf um das ende einer Peerlist zu signalisieren - bei der Abfrage der peers eines Channels.
Und letztlich wird sich noch als adresse des action-detectors genutzt. Ist nur ein Notbehelf, da der ActiondDetector eine HM-instanz, um steuerbar sein zu koennen. Dass ich hier die '000000' verwendet habe ist Zufall (und aergert mich immer noch...)
Freut mich, wenn die Doku ein wenig weiterhilft. Es geht fuer einige relativ tief in die Steuerung hinein - daher ist es nur ein Versuch und eine Hilfestellung.
Einen Zusammenhang zwischen rote LED und länger nicht genutzt kann ich nicht herstellen. Kann es sein, dass dein FHEM controller in eine Art sleepmode fällt?
Gruss Martin
Hallo Martin,
der Raspberry auf dem (nur) FHEM läuft, ist dabei derartig aktiv, dass er zum Schlafen kaum kommt *g* Das Problem mit der roten Rückmeldung tritt definitiv nur bei der Fernbedienung auf. Alle anderen hier eingesetzten HM-Komponenten haben dieses Verhalten noch nicht gezeigt. Türöffner melden sofort grün - und die sind viel länger ungenutzt als die Fernbedienung. Ich tippe gefühlsmäßig eher auf einen Schlaf-Modus in der Fernbedienung selbst. Die läuft ja nur mit einer 1,5V Batterie, da dürfte Energiesparen oberstes Gebot sein.
Viele Grüße
Udo
Hallo Udo,
schlafen der FB kann ich mir schlecht vorstellen. Schliesslich wacht die FB auf und sendet den trigger. Sie sollte also hellwach sein, wenn die Antwort kommt.
Ansonsten waere es ein FW bug - Zeitstempel nicht korrekt in der Aufwach-Sequenz
Kannst du logs aufzeichnen?
Gruss Martin
Hallo Martin,
das ist ein Mitschnitt nach längerer Nichtnutzung der Fernbedienung.
Der erste Knopfdruck ergab eine rote Rückmeldung, der direkt darauf nochmal gedrückte gleiche Knopf erhielt eine grüne Rückmeldung.
Falls Du was anderes brauchst, sag mir bitte was und ich wie ich loggen soll.
2013.06.09 18:02:19 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0706699 d:1EA0BD O:9601BD t:19032D10 IDcnt:0000
2013.06.09 18:02:44 1: HMLAN_Send: HMLAN I:K
2013.06.09 18:02:44 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0706699 d:1EA0BD O:9601BD t:19038EC1 IDcnt:0000
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN R:E2123FC stat:0000 t:1903BB82 d:FF r:FFB8 m:40 A440 2123FC 112233 0108
2013.06.09 18:02:56 1: HMLAN_Send: HMLAN I:+2123FC,00,00,
2013.06.09 18:02:56 1: HMLAN_Send: HMLAN S:S29AD16AC stat: 00 t:00000000 d:01 r:29AD16AC m:40 8002 112233 2123FC 01010000
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN R:E2123FC stat:0000 t:1903BC7C d:FF r:FFB8 m:40 A040 2123FC 112233 0108
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN R:R29AD16AC stat:0002 t:00000000 d:FF r:7FFF m:40 8002 112233 2123FC 01010000
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN discard
2013.06.09 18:02:56 1: HMLAN_Parse: HMLAN R:E2123FC stat:0000 t:1903BD77 d:FF r:FFB8 m:40 A040 2123FC 112233 0108
2013.06.09 18:02:59 1: HMLAN_Parse: HMLAN R:E2123FC stat:0000 t:1903C955 d:FF r:FFB8 m:41 A440 2123FC 112233 0109
2013.06.09 18:02:59 1: HMLAN_Send: HMLAN S:S29AD2331 stat: 00 t:00000000 d:01 r:29AD2331 m:41 8002 112233 2123FC 0101C800
2013.06.09 18:02:59 1: HMLAN_Parse: HMLAN R:R29AD2331 stat:0002 t:00000000 d:FF r:7FFF m:41 8002 112233 2123FC 0101C800
2013.06.09 18:02:59 1: HMLAN_Parse: HMLAN discard
2013.06.09 18:03:09 1: HMLAN_Send: HMLAN I:K
2013.06.09 18:03:09 1: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0706699 d:1EA0BD O:9601BD t:1903F075 IDcnt:0001
Hi,
hm... die Antwort von FHEM ist korrekt. Koennte zu spät sein, aber leider war kein mseclog an.
Aber bei der Gelegenheit habe ich versucht, auf die beiden Wiederholungen zu reagieren. Die SW von gerade (3268) sollte das unterstützen.
Gruss Martin
Hallo Martin,
ich war einige Tage unterwegs, habe mich erst heute wieder mit dem Thema beschäftigen können, nochmals alles neu eingegeben und dann an mein Garagentor angeschlossen.
Bis auf das Problem des manchmal fehlenden oder nicht erkannten ACK und der roten LED funktioniert es nun.
ZitatDein HM-RC-4-2 ist wohl auf AES eingestellt.
Kann ich nicht mit Gewissheit bestätigen.
ZitatIn dem Ausschnitt, den du gepostet hast scheint das pairing funktioniert zu haben. FHEM hat alles einmal wiederholen muessen, kann aber an der Verzoegerung durch AES gelegen haben. Hier sollte aber kein timeout aufgetreten sein.
Ja, das pairing hatte funktioniert. Ein Timeout ist mir jetzt nicht mehr aufgefallen.
ZitatHast du AES selbst gesetzt?
Wurde von mir, zumindest nicht wissentlich eingestellt. Vorsichtshalber habe ich es jetzt definitiv abgeschaltet.
ZitatEs ist doch der RC4 und nicht einer seiner Key oder Sec varianten?
Ich habe eindeutig den HM-RC-4-2. Ursprünglich dachte ich, dass die FB für die anderen Funktionen konfigurierbar ist, da ja auch die Bedienungsanleitung für alle 3 FBs ist.
Nochmals vielen Dank für Deine Hilfe. Ich werde das Thema selbstverständlich weiterverfolgen. Vielleicht findet ja noch jemand heraus, wo das Problem liegt. Mir ist aufgefallen, dass es bei den Device-Attributen eine Angabe der Firmware gibt. Gibt es vom Hersteller bei Problemen auch Updates für Devices und wenn ja, wie kann man sie einspielen?
Gruß,
Dietmar
Hallo Dietmar,
keine Ahnung, wie der FW update funktioniert. Offensichtlich kann man es den Haendler gegen Gebuehr machen lassen. Ob es das Funkinterface auch hergeben wuerde ist nicht klar...
Gruss
Martin
Zitat von: martinp876 schrieb am So, 09 Juni 2013 20:27die Antwort von FHEM ist korrekt. Koennte zu spät sein, aber leider war kein mseclog an.
Das mit den Millisekunden kann ich gerne nachholen, ich weiß ja, wie ich das Verhalten reproduzieren kann :)
Zitat von: martinp876 schrieb am So, 09 Juni 2013 20:27Die SW von gerade (3268) sollte das unterstützen.
Die krieg ich einfach mit einem update?
ja, ab heute sollte es per Update klappen
Hier nochmal der gleiche Vorgang mit Millisekunden (ich habe noch kein Softwareupdate gestartet)
Erster Tastendruck ergibt rot, zweiter Tastendruck danach ergibt grün.
2013.06.10 18:52:49.543 1: HMLAN_Parse: HMLAN R:E2123FC stat:0000 t:1E57F6C0 d:FF r:FFB9 m:54 A440 2123FC 112233 0110
2013.06.10 18:52:49.614 1: HMLAN_Send: HMLAN S:S2F011E52 stat: 00 t:00000000 d:01 r:2F011E52 m:54 8002 112233 2123FC 01010000
2013.06.10 18:52:49.986 1: HMLAN_Parse: HMLAN R:R2F011E52 stat:0002 t:00000000 d:FF r:7FFF m:54 8002 112233 2123FC 01010000
2013.06.10 18:52:49.987 1: HMLAN_Parse: HMLAN discard
2013.06.10 18:52:49.988 1: HMLAN_Parse: HMLAN R:E2123FC stat:0000 t:1E57F7BA d:FF r:FFBD m:54 A040 2123FC 112233 0110
2013.06.10 18:52:49.993 1: HMLAN_Parse: HMLAN R:E2123FC stat:0000 t:1E57F8B5 d:FF r:FFC0 m:54 A040 2123FC 112233 0110
2013.06.10 18:52:52.770 1: HMLAN_Parse: HMLAN R:E2123FC stat:0000 t:1E5803C2 d:FF r:FFBB m:55 A440 2123FC 112233 0111
2013.06.10 18:52:52.841 1: HMLAN_Send: HMLAN S:S2F012AEC stat: 00 t:00000000 d:01 r:2F012AEC m:55 8002 112233 2123FC 0101C800
2013.06.10 18:52:52.996 1: HMLAN_Parse: HMLAN R:R2F012AEC stat:0002 t:00000000 d:FF r:7FFF m:55 8002 112233 2123FC 0101C800
2013.06.10 18:52:52.996 1: HMLAN_Parse: HMLAN discard
----
Nachtrag: Wenn ich ein "update check" mache, wird mir nichts von HM-irgendwas angezeigt:
List of new / modified files since last update:
UPD FHEM/00_FBAHA.pm
UPD FHEM/01_FHEMWEB.pm
UPD FHEM/DevIo.pm
Hallo Martin,
das FHEM interne update hängt ja immer etwas hinterher. Im SVN Log (//fhem.de/SVNLOG)
sieht man die Updates ja aber eigentlich sofort. Aber auch dort ist nichts zu sehen.
Gruß, Marc
Marc, Udo,
ich habe die Version 3262 und 3268 am Sonntag eingebracht und 3272 gestern.
Nach Rudi werden die Files immer am Morgen des naechsten Tages in den Update eingebaut, macht ein batch-job von Rudi...
Lasst mich wissen, wenn es wieder nicht da ist.
Zu den Zeitstempeln: Sehr knapp "Ausgeschnitten", da habe ich kaum Zeit-referenzen. (ich weiss, ich bin mit nichts zufrieden).
HMLAN setzt eine Zeitmarke vond er ich annehme, dass es die korrekte Sendezeit ist, also die Zeitmarke, zu der die Nachricht an den HMLAN-IP-stack uebergeben wird. In FHEM kommt alles recht spaet an - falls es jemanden interessiert, hier die Details:
Trigger 1 gesendet T=0, geparsed T= 100ms => 100ms delay
repeat 1 gesendet T=250, geparsed T= 540ms => 290ms delay
repeat 2 gesendet T=500, geparsed T= 550ms => 50ms delay
Trigger 2 0ms delay
Trigger 2 kann ich also ohne Probleme bestaetigen. Bei Trigger 1 kommen jetzt mehrere Probleme zum Tragen:
- repeat1 und 2 werden nicht beantwortet. Das sollte ab Version 3268 behoben sein.
- Repeat1 kommt so spaet dass er garnicht zeitgerecht beantwortet werden kann, da ist sogar schon der 2. Repeat draussen. Grund ist, dass Trigger1 "komplett" in CUL_HM geparst wird. Das verarbeiten aller Notifies und Prozeduren kostet offensichtlich so viel Zeit.
- Repeat2 kommt dann wieder schneller. Grund ist, dass CUL_HM die doppelte Nachricht erkennt und ein erneutes Parsen verhindert.
=> FHEM "Nachbearbeitung" nach CUL_HM dauert etwa 200ms!
Ab Version 3268 sollte CUL_HM/HMLAN also in der Lagen sein den 2. repeat zu beantworten (den Ersten auch, aber leider zu spaet)
Wenn HMLAN nicht gewartet haette (70ms), haette es der erste Trigger noch schaffen koennen. Aber ein Ack sollte min 100ms nach dem Kommando kommen.... dan haette ggf. der 2. Trigger ein Problem....
Ich versuche, die Wartezeit dynamisch zu errechnen.... ist nicht ganz einfach da sich staendig alles verschiebt. Mein HMLAN arbeitet mit einer Genauigkeit von 100ppm - nicht sehr viel.
Wen die Details nicht interessieren: mit Version 3268 sollte es weitgehend funktionieren. Eine weitere Verbesserung dauert noch ein Bisschen
Gruss
Martin
Zu den Updates: Heute morgen gab es immer noch keine Updates, die HM betreffen.
Zitat von: martinp876 schrieb am Di, 11 Juni 2013 09:22Zu den Zeitstempeln: Sehr knapp "Ausgeschnitten", da habe ich kaum Zeit-referenzen. (ich weiss, ich bin mit nichts zufrieden).
Ich bin davon ausgegangen, dass Du nur den Teil mit den beiden Tastendrücken brauchst, und da gab es nicht mehr Inhalt im Log.
Zitat von: martinp876 schrieb am Di, 11 Juni 2013 09:22falls es jemanden interessiert, hier die Details:
Ja, interessiert mich schon, und ich hab das auch soweit verstanden. Für mich bleibt aber die Frage, warum das NUR bei der Fernbedienung auftritt und z.B. bei den Tür-/Fensterkontakten nicht. Dort habe ich noch nie eine rote Rückmeldung erhalten.
Ich nehme an, dass die Tuer und Fensterkontakte auch mit FHEM gepeert sind (virtueller Aktor). Ansonsten ist der Vergleich nicht fair ;-)
Das gesamte TimingBild habe ich nicht, auch nicht, wer welche Verzoegerung macht.
FB->HMLAN->FHEM
oder SW (grob)
FB->HMLAN-RF->HMLANprocessing->HMLANStacketh->Zentrale ETH/IPstack->FHEM-IO->FHEM-HMLAN
Die FB ist sauer, wenn ihre Timingvorgaben uebergangen werden. Diese sind: Antwort 100ms nach dem Senden(empirisch ermittelt...) aber nicht spaeter als 250ms danach (kann man daran festmachen, dass dann ein repeat kommt).
Da ich nicht messen kann (ok, wireshark schon...) habe ich nur Stempel von HMLANpocessing (beginn oder Ende) und FHEM-HMLAN.
Bei HMLAN bin ich guter Dinge, es ist nicht viel los, da kann so eine kleine CPU sehr einfach sehr genau arbeiten - auch sehr schnell (ist sicher kein Perl :-) )
Ein Linux Rechner (Fritzbox,...) ist da schon ein komplexeres Gebilde. Aber die Verarbeitung von FB und Fensterkontakt sollte identische Wege gehen. Ob ein Fensterkontakt ein laxeres Timing hat kann ich nicht Sagen.
Wenn du mir ein vergleichbares log schickst kann ich einmal reinsehen. Mit ein paar Zeitstempeln drumrum, da mit ich mir ein TimingBild bauen kann
Gruss Martin
hm...
Einen virtuellen Aktor für die Eingangstür habe ich nie definiert, trotzdem bekommt der irgendwo eine grüne Rückmeldung her. Der Türkontakt wird nur per notify abgearbeitet.
Der Türkontakt an der Balkontür hängt irgendwie noch mit dem HM-TC-CC zusammen, aber in WindowsRec ist der noch nie aufgetaucht (da stehen immer nur Fragezeichen), obwohl die komplette Heizungssteuerung im Modus Cent korrekt funktioniert (also inkl. Absenkung bei Tür-auf)
hm...
klingt nicht glaubwuerdig :-)
Also zum einen haben wir das Problem nur, wenn die Zentrale beteiligt ist. Die Verzoegerung kommt nicht von den HM bauteilen, da bin ich mir eigentlich sicher.
Wenn der TC auf die Tuer reagiert sollte er die auch irgendwo her kennen. Das muss wohl gepeert sein, wenn du es nicht ueber die Zentrale machst.
Das Leuchtdiodenverhalten ist hoffentlich bei allen Devices gleich und alle koennen rot/gelb/gruen. (Ich fuer meinen Teil habe Probleme gelb und gelb auseinander zu halten... moegliche Fehlerquelle...).
Kannst du ein getConfig auf deinen TC machen (also nicht Climate sondern Device) und auch auf den Tuerkontakt? Wuerde mich interessieren.
Mein TC musst du nur warten, beim Tuerkontakt musst du evtl anlernen druecken um das Kommando abzuarbeiten.
Roh-messages waeren "all inclusiv".
p.s. evtl habe ich eine Loesung fuer den Delay - incl Info, wie schnell/langsam FHEM reagiert. Muss noch testen.
Gruss
Martin
Zitat von: martinp876 schrieb am Di, 11 Juni 2013 12:13Ich fuer meinen Teil habe Probleme gelb und gelb auseinander zu halten
ich auch *g* sieht ALLES so gelb aus zwischen gelb und gelb ...
Zitat von: martinp876 schrieb am Di, 11 Juni 2013 12:13Also zum einen haben wir das Problem nur, wenn die Zentrale beteiligt ist. Die Verzoegerung kommt nicht von den HM bauteilen, da bin ich mir eigentlich sicher.
Wenn der TC auf die Tuer reagiert sollte er die auch irgendwo her kennen. Das muss wohl gepeert sein, wenn du es nicht ueber die Zentrale machst.
Das Leuchtdiodenverhalten ist hoffentlich bei allen Devices gleich und alle koennen rot/gelb/gruen.
Ja, die können alle rot-gelb-grün und wir reden von zwei Türmeldern ;) Einer am Eingang und einer an der Balkontür (das ist der mit Verbindung zum Thermostaten).
Die getConfig werde ich heute abend mal machen.
Die getConfigs habe ich gestern zeitlich nicht mehr geschafft. Aber ich habe ein update gestartet und dabei kamen auch ein paar HM*-Dateien mit.
Heute morgen hatte ich beim ersten Tastendruck auf der Fernbedienung direkt grün. Ich weiß aber noch nicht, ob das Zufall war oder mit den Updates zusammenhängt.
Seit den letzten Änderungen in den HM-Komponenten von FHEM ist das Problem mit der roten Rückmeldung offenbar vollständig gelöst. Zumindest habe ich schon lange keine rote LED mehr an der Fernbedienung gesehen.
Danke für die tolle Unterstützung!
Jetzt habe ich die Fernbedienung mittels hmland und HM-CFG-USB gepaired, die Tasten den virtuellen Buttons wieder zugeordnet - und nun sehe ich wieder nur rote Rückmeldungen (http://www.smiliesuche.de/smileys/kopf-gegen-wand/kopf-gegen-wand-smilies-0005.gif)
Hi,
Zitat von: betateilchen schrieb am Do, 04 Juli 2013 23:32Jetzt habe ich die Fernbedienung mittels hmland und HM-CFG-USB gepaired, die Tasten den virtuellen Buttons wieder zugeordnet - und nun sehe ich wieder nur rote Rückmeldungen (http://www.smiliesuche.de/smileys/kopf-gegen-wand/kopf-gegen-wand-smilies-0005.gif)
Ich nehme mal an, dass der HM-CFG-USB noch am Raspberry hängt? Da ist das leider zu erwarten, da dort USB-Interrupt-Transfers an Low-Latency-Endpoints in bestimmten Konstellationen um mehrere 100ms verzögert werden. Probiers mal mit dem FIQ-SPLIT-Kernel, da ist es besser:
# BRANCH=fiq_split rpi-update
...
$ uname -a
Linux rpi 3.8.13+ #460 PREEMPT Fri May 31 13:09:02 BST 2013 armv6l GNU/Linux
Andere Hardware (wie z.B. ein Beaglebone Black oder ein TL-MR3020) haben diese Latency-Probleme nicht. Bleibt nur zu hoffen, dass man die auf dem Raspberry auch irgendwann in den Griff bekommt. Ich hab auch schon versucht auf dem Raspberry andere Transferarten mit dem HM-CFG-USB zu benutzen (HID SET_REPORT), das mag aber der Stick nicht...
Gruß
Michael
Hallo Michael,
ja, der Stick hängt am Raspberry und dort soll er auch bleiben. Sämtliche HM-Komponenten funktionieren einwandfrei, inklusive korrekter Rückmeldungen. Nur diese mistige Fernbedienung macht immer wieder Ärger. Insofern sehe ich eher in dieser Fernbedienung einen Schuldigen als in der ansteuernden Hardware. Ich sehe ja auch das Betätigen der Buttons an der Fernbedienung sofort und ohne Verzögerung im Event Monitor. 100ms Verzögerung würden selbst da schon auffallen, das ist immerhin eine Zehntelsekunde.
Hallo,
Zitat von: betateilchen schrieb am Fr, 05 Juli 2013 10:50Ich sehe ja auch das Betätigen der Buttons an der Fernbedienung sofort und ohne Verzögerung im Event Monitor. 100ms Verzögerung würden selbst da schon auffallen, das ist immerhin eine Zehntelsekunde.
Das betrifft nur OUT-Transfers, also wenn Daten ans Gerät gesendet werden. Ich hab mal schnell eine Zeitmessung reingehackt und geschaut, wie lange das Senden an den Stick auf einem RPi dauert. Die zwei Pakete pro Befehl sollten in jeweils einem USB-Frame (1ms) versendet werden, das kann man auf anderer HW auch so beobachten. Auf meinem RPi dauert das aber zwischen 1ms und 1038ms(!). Da kann Fhem das Ack gar nicht schnell genug absenden, damit die FB grün leuchtet.
Praktischerweise hat der RPi jetzt gerade nicht mehr rebootet, weswegen ich die Zeitmessung erst heute Abend pushen kann, wenn ich ihn resettet habe.
Evtl. hilft ein 3.3.8er Kern, siehe
hier.
Gruß
Michael
Hallo Michael,
das habe ich alles verstanden.
Was ich aber nicht verstehe: alle Fensterkontakte und anderen HM-Komponenten bekommen die Rückmeldung (vom gleichen HM-USB-Stick am gleichen Raspberry!) rechtzeitig und signalisieren das mit grün. Nur bei der Fernbedienung scheitert diese Kommunikation regelmäßig.
Hallo Betateilchen,
Zitat von: betateilchen schrieb am Fr, 05 Juli 2013 13:35Was ich aber nicht verstehe: alle Fensterkontakte und anderen HM-Komponenten bekommen die Rückmeldung (vom gleichen HM-USB-Stick am gleichen Raspberry!) rechtzeitig und signalisieren das mit grün. Nur bei der Fernbedienung scheitert diese Kommunikation regelmäßig.
Achso, jetzt sehe ich, warum Du die USB-Latenz ausgeschlossen hast.
Der Unterschied zwischen der Fernbedienung und den anderen Komponenten ist, dass bei der Fernbedienung der virtuelle Aktor (also Fhem bzw. 10_CUL_HM.pm) das Ack generiert und absendet. Die anderen Komponenten werden einmalig (pro TCP-Sitzung) im Stick registriert (+HMID) und dann generiert dieser die ACKs automatisch, ohne dass sich Fhem drum kümmern muss bzw. dies auch nur beeinflussen kann. Bei diesen automatischen ACKs gibt es auch keinen USB-Traffic.
Edit: Achja, wenn ich es nicht vergesse, probiere ich heute Abend/Nacht mal den 3.3.8er Kernel aus und schreibe dann, ob es damit besser ist.
Gruß
Michael
doofe Frage: Warum kann der Stick nicht auch die Fernbedienung automatisch quittieren, so wie bei den anderen Komponenten auch? Die Aktionen, die mit der Fernbedienung ausgelöst werden, funktionieren ja auch bei der roten Rückmeldung völlig problemlos, nur die Rückmeldung ist halt falsch.
Hallo Betateilchen,
Zitat von: betateilchen schrieb am Fr, 05 Juli 2013 14:00Warum kann der Stick nicht auch die Fernbedienung automatisch quittieren, so wie bei den anderen Komponenten auch?
Weil in diesem Fall nicht die Zentrale der Empfänger ist, sondern der virtuelle Aktor.
Der HM-CFG-USB erzeugt nur automatische ACKs auf Pakete, die an seine hmId gerichtet sind. Die hmId wird beim Verbindungsaufbau mit dem A-Kommando gesetzt, wobei ein nochmaliges A die ID ändert und keine neue hinzufügt.
Der virtuelle Aktor hat eine eigene hmId, deswegen muss sich hier Fhem um alles kümmern.
Gruß
Michael
*grübel*
Aber die gepairte Fernbedienung schickt doch keine unadressierten Pakete. Die sind doch an den USB-Stick gerichtet. Und wenn es gar keinen virtuellen Aktor gibt? Ich habe inzwischen das Pairing aufgehoben und den virtAktor gelöscht. Derzeit werte ich direkt die Buttons der Fernbedienung aus. Da bekomme ich zwar gar keine Rückmeldung mehr, was mir nicht gefällt, aber immer noch besser ist, als eine falsche Rückmeldung bei einer durchaus korrekt angekommenen Nachricht an FHEM.
Warum ist das alles nur bei der Fernbedienung so kompliziert? Es kommen doch eindeutige Nachrichten für jeden Button, sogar mit short oder long.
Könnte man über einen (vermutlich neu zu schaffenden) Parameter/Attribut/was-auch-immer eine Möglichkeit schaffen, einfach eine Bestätigung an eine eingehende ID zurückzuschicken? Gerade bei Fernbedienungen ist es doch oft so, dass man einfach einen Button auf der Fernbedienung per notify auswerten möchte, um irgendwie zu reagieren.
Mir schwebt da gedanklich etwas in der Art vor:
attr hmcfgusb forceAck 0x112233 <<< 112233 = HMID der Fernbedienung (oder des Channels, dann eben 8-stellig), immer wenn was von dieser ID kommt, einfach ein GRÜN schicken, damit der Empfang des Knopfdrucks bestätigt wird.
Ich weiß, es ist noch nicht Weihnachten, aber Wünsche darf man ja haben. Ich habe die Fernbedienung einzig und allein aus dem Grund angeschafft, eine zuverlässige optische Rückmeldung zu erhalten, wenn ich einen Knopf drücke, um zu wissen, dass das Kommando bei FHEM angekommen ist. Dann könnte ich mir auch das ganze Rumgeeiere mit virtuellem Aktor etc. sparen.
Hallo Betateilchen,
Zitat von: betateilchen schriebAber die gepairte Fernbedienung schickt doch keine unadressierten Pakete. Die sind doch an den USB-Stick gerichtet.
Nein, die sind an den virtuellen Aktor gerichtet.
ZitatUnd wenn es gar keinen virtuellen Aktor gibt?
Dann gehen sie an die Broadcast-Adresse und die Fernbedienung erwartet gar keine Rückmeldung.
ZitatKönnte man über einen (vermutlich neu zu schaffenden) Parameter/Attribut/was-auch-immer eine Möglichkeit schaffen, einfach eine Bestätigung an eine eingehende ID zurückzuschicken? Gerade bei Fernbedienungen ist es doch oft so, dass man einfach einen Button auf der Fernbedienung per notify auswerten möchte, um irgendwie zu reagieren.
Ja, Du hast soeben den virtuellen Aktor neu erfunden ;-)
ZitatMir schwebt da gedanklich etwas in der Art vor:
attr hmcfgusb forceAck 0x112233 <<< 112233 = HMID der Fernbedienung (oder des Channels, dann eben 8-stellig), immer wenn was von dieser ID kommt, einfach ein GRÜN schicken, damit der Empfang des Knopfdrucks bestätigt wird.
Soweit bisher bekannt, kann man das der Firmware des Sticks/HMLAN nicht so beibringen. Die Antwortet _nur_ auf Pakete an die eigene Adresse, nicht auf alle Pakete einer bestimmten ID.
Btw: Der Kernel 3.3.8 bootet nicht mit meinem Raspbian, kann also leider nicht sagen, ob es damit besser waere...
Gruß
Michael
Hallo Michael,
Zitat von: mgernoth schrieb am Sa, 06 Juli 2013 12:34Hallo Betateilchen,
ZitatAber die gepairte Fernbedienung schickt doch keine unadressierten Pakete. Die sind doch an den USB-Stick gerichtet.
Nein, die sind an den virtuellen Aktor gerichtet.
ZitatUnd wenn es gar keinen virtuellen Aktor gibt?
Dann gehen sie an die Broadcast-Adresse und die Fernbedienung erwartet gar keine Rückmeldung.
Das ist aber komisch...
2013-07-06 17:52:28 CUL_HM HMFB01_03 Short (to HMUSB)
2013-07-06 17:52:28 CUL_HM HMFB01_03 trigger: Short_10
2013-07-06 17:52:28 CUL_HM HMFB01 battery: ok
2013-07-06 17:52:28 CUL_HM HMFB01 HMFB01_03 Short (to HMUSB)Da steht für mich doch eindeutig, dass Button 03 der Fernbedienung HMFB01 Short gedrückt wurde. Die Nachricht geht "to HMSUB" - das ist der USB-Stick, mit dem die Fernbedienung gepairt ist.
Wenn ich die Fernbedienungsbuttons mit einem virtuellen Aktor va peere, dann steht da in Klammer "to va"
Wenn ich die Fernbedienung mit gar nix verbinde (weder paire noch peere) geht die Meldung an "to broadcast"
Die Fernbedienung scheint also DOCH zu wissen, dass sie an den USB Stick adressieren muss - oder sie kennt zumindest drei verschiedene Adressierungsarten.
ZitatJa, Du hast soeben den virtuellen Aktor neu erfunden ;-)
Nein, meine Gedanken gingen in eine andere Richtung.
ZitatBtw: Der Kernel 3.3.8 bootet nicht mit meinem Raspbian, kann also leider nicht sagen, ob es damit besser waere...
nicht sehr verwunderlich.
Viele Grüße
Udo
Hallo Udo,
Zitat von: betateilchen schrieb am Sa, 06 Juli 2013 18:01Zitat von: mgernoth schrieb am Sa, 06 Juli 2013 12:34ZitatUnd wenn es gar keinen virtuellen Aktor gibt?
Dann gehen sie an die Broadcast-Adresse und die Fernbedienung erwartet gar keine Rückmeldung.
Das ist aber komisch...
2013-07-06 17:52:28 CUL_HM HMFB01_03 Short (to HMUSB)
2013-07-06 17:52:28 CUL_HM HMFB01_03 trigger: Short_10
2013-07-06 17:52:28 CUL_HM HMFB01 battery: ok
2013-07-06 17:52:28 CUL_HM HMFB01 HMFB01_03 Short (to HMUSB)
Ok, das ist interessant.
Bei meiner RC-19 (gepairt, aber diese Taste nicht gepeert) sieht das so aus:
2013-07-06 23:30:02 CUL HM_CUL RCV L:0B N:3E F:84 CMD:40 SRC:RC_19_B DST:broadcast 0E01 (REMOTE BUTTON:14 LONG:0 LOWBAT:0 COUNTER:0x01) (,CFG,RPTEN)
2013-07-06 23:30:02 CUL_HM RC_19_B_Btn_14 Short (to broadcast)
2013-07-06 23:30:02 CUL_HM RC_19_B_Btn_14 trigger: Short_1
2013-07-06 23:30:02 CUL_HM RC_19_B battery: ok
2013-07-06 23:30:02 CUL_HM RC_19_B RC_19_B_Btn_14 Short (to broadcast)
ZitatDa steht für mich doch eindeutig, dass Button 03 der Fernbedienung HMFB01 Short gedrückt wurde. Die Nachricht geht "to HMSUB" - das ist der USB-Stick, mit dem die Fernbedienung gepairt ist.
Ja, in Deinem Fall geht das tatsächlich an den Stick.
Kannst Du mal dem Stick das Attribut hmProtocolEvents mit Wert >= 3 verpassen?
Dann siehst Du auch die Messageflags im Log (wie bei mir oben).
Falls da am Ende in der Klammer nicht nur CFG und RPTEN auftaucht, sondern zusätzlich noch BIDI, dann besteht die Chance der Fernbedienung den Tastendruck tatsächlich zu bestätigen. BIDI gibt an, dass der Sender hier ein ACK vom Empfänger haben will. Und wenn dieses Flag gesetzt ist und das Ziel die hmId des Sticks ist, dann sollte die Firmware das ACK generieren können.
ZitatNein, meine Gedanken gingen in eine andere Richtung.
Ja, mit dem Verhalten dieser Fernbedienung kann ich das nachvollziehen.
ZitatZitatBtw: Der Kernel 3.3.8 bootet nicht mit meinem Raspbian, kann also leider nicht sagen, ob es damit besser waere...
nicht sehr verwunderlich.
Eigentlich schon, da die Kernelconfig (die ich vorher durchgeschaut habe) kompatibel sein sollte (Ext4 und USB ist drin). Habe aber übersehen, dass dieser Kernel einen anderen Init-Pfad eingebaut hat. Jetzt hat er gebootet, die Latenz eines USB-Interrupttransfers bewegt sich aber immernoch im Bereich zwischen einer ms und einer Sekunde. Ist also auch unbrauchbar :-(
Gruß
Michael
Endlich versteht mich mal jemand... *g* Nur wegen eines anderen Gehäuses wird man diese neue Fernbedienung ja nicht entwickelt und auf den Markt gebracht haben.
Zitat von: mgernoth schrieb am Sa, 06 Juli 2013 23:50Kannst Du mal dem Stick das Attribut hmProtocolEvents mit Wert >= 3 verpassen?
Dann siehst Du auch die Messageflags im Log (wie bei mir oben).
nichts leichter als das...
2013-07-07 12:22:54 HMLAN HMUSB RCV L:0B N:1D F:A2 CMD:40 SRC:HMFB01 DST:AABBCC 0308 (REMOTE BUTTON:3 LONG:0 LOWBAT:0 COUNTER:0x08) (,WAKEMEUP,BIDI,RPTEN)
2013-07-07 12:22:54 CUL_HM HMFB01 CMDs_done_events:3
2013-07-07 12:22:54 HMLAN HMUSB SND L:0D N:1D F:80 CMD:02 SRC:AABBCC DST:HMFB01 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013-07-07 12:22:54 CUL_HM HMFB01_03 Short (to HMUSB)
2013-07-07 12:22:54 CUL_HM HMFB01_03 trigger: Short_8
2013-07-07 12:22:54 CUL_HM HMFB01 battery: ok
2013-07-07 12:22:54 CUL_HM HMFB01 HMFB01_03 Short (to HMUSB)
Zitat von: mgernoth schrieb am Sa, 06 Juli 2013 23:50Falls da am Ende in der Klammer nicht nur CFG und RPTEN auftaucht, sondern zusätzlich noch BIDI,
tja, wenn ich das richtig sehe, steht da unter anderem auch BIDI :)
Hallo Udo,
Zitat von: betateilchen schrieb am So, 07 Juli 2013 12:27
2013-07-07 12:22:54 HMLAN HMUSB RCV L:0B N:1D F:A2 CMD:40 SRC:HMFB01 DST:AABBCC 0308 (REMOTE BUTTON:3 LONG:0 LOWBAT:0 COUNTER:0x08) (,WAKEMEUP,BIDI,RPTEN)
Ok, hier wird das ACK angefordert.
Zitat
2013-07-07 12:22:54 HMLAN HMUSB SND L:0D N:1D F:80 CMD:02 SRC:AABBCC DST:HMFB01 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
Und hier ist das gesendete ACK. Ich nehme mal an, dass die LED gelb blieb? Dann wertet die Fernbedienung in diesem Zustand das ACK nicht als Bestätigung für den Tastendruck :-(
Man könnte (ganz grauenhaft) probieren, die Fernbedienung mit einem virtuellen Aktor zu paaren, der die gleiche ID hat wie der Stick. Evtl. funktioniert das und die Fernbedienung wertet das dann auch korrekt aus. Ich weiss aber nicht, ob das "High-Level" geht oder ob man sich die Sendesequenz selbst zusammenbauen muss.
Wenn es High-Level nicht geht, kann wahrscheinlich nur Martin helfen, da ich von dem Funkprotokoll selber relativ wenig Ahnung habe...
Gruß
Michael
Zitat von: mgernoth schrieb am So, 07 Juli 2013 15:04Man könnte (ganz grauenhaft) probieren, die Fernbedienung mit einem virtuellen Aktor zu paaren, der die gleiche ID hat wie der Stick
Diese Idee hatte ich gestern auch schon, aber irgendwie bin damit auch nicht weitergekommen.
Wie Du richtig vermutet hast, reagiert die Fernbedienung nicht weiter auf das ACK. Es kommt weder rot noch grün.
Aber vielleicht hat ja wirklich Martin noch eine Idee, er hat ja auch eine dieser neuen Fernbedienungen. Es wäre schon toll, wenn man die Anzeige einer Bestätigung ohne den unzuverlässigen Umweg über einen virtuellen Aktor lösen könnte.
ich habe jetzt einfach mal folgendes mit einem ansonsten nicht gepeerten Fernbedienungsbutton versucht:
set HMFB01_01 peerChan 0 HMUSB single set
Das wurde widerspruchslos ausgeführt und als peerId steht da nun 12700000
Internals:
DEF 2123FC01
NAME HMFB01_01
NR 340
NTFY_TRIGGERTIME 2013-07-08 01:41:21
STATE Short (to 127000)
TYPE CUL_HM
chanNo 01
device HMFB01
Readings:
2013-07-08 01:40:35 R-12700000-expectAES off
2013-07-08 01:40:35 R-12700000-peerNeedsBurst off
2013-07-08 01:40:34 R-dblPress 0 s
2013-07-08 01:40:34 R-longPress 0.4 s
2013-07-08 01:40:34 R-sign off
2013-07-08 01:40:34 RegL_01: 04:10 08:00 09:00 00:00
2013-07-08 01:40:35 RegL_04:12700000 01:00 00:00
2013-07-08 01:40:35 peerList 12700000,
2013-07-08 01:41:21 state Short (to 127000)
2013-07-08 01:41:21 trigger Short_15
Helper:
peerIDsRaw ,12700000,00000000
Role:
chn 1
Shadowreg:
RegL_04:127.0.00 01:00
Attributes:
group HM-RC-4-2
model HM-RC-4-2
peerIDs 00000000,12700000,
room 60_Fernbedienung
Wenn ich jetzt den Button 01 drücke, bekomme ich zumindest schonmal eine rote Rückmeldung, was wohl bedeutet, dass die Fernbedienung auf eine Quittung wartet.
2013-07-08 01:47:17 HMLAN HMUSB RCV L:0B N:86 F:A4 CMD:40 SRC:HMFB01 DST:127000 0110 (REMOTE BUTTON:1 LONG:0 LOWBAT:0 COUNTER:0x10) (,CFG,BIDI,RPTEN)
2013-07-08 01:47:17 CUL_HM HMFB01_01 Short (to 127000)
2013-07-08 01:47:17 CUL_HM HMFB01_01 trigger: Short_16
2013-07-08 01:47:17 CUL_HM HMFB01 battery: ok
2013-07-08 01:47:17 CUL_HM HMFB01 HMFB01_01 Short (to 127000)
Also war mein nächster Gedanke, dem HM-CFG-USB einfach mal die HM-Id 127000 zu verpassen.
Und nun rate mal, was passiert?
2013-07-08 01:52:51 HMLAN HMUSB RCV L:0B N:8A F:A4 CMD:40 SRC:HMFB01 DST:127000 0114 (REMOTE BUTTON:1 LONG:0 LOWBAT:0 COUNTER:0x14) (,CFG,BIDI,RPTEN)
2013-07-08 01:52:51 CUL_HM HMFB01 CMDs_done
2013-07-08 01:52:51 HMLAN HMUSB SND L:0D N:8A F:80 CMD:02 SRC:127000 DST:HMFB01 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013-07-08 01:52:51 HMLAN HMUSB SND L:0E N:1A F:A0 CMD:11 SRC:127000 DST:wz_Ventilator 0201C80000 (SET CHANNEL:0x01 VALUE:0xC8 RAMPTIME:2) (,BIDI,RPTEN)
2013-07-08 01:52:51 CUL_HM HMFB01_01 Short (to HMUSB)
2013-07-08 01:52:51 CUL_HM HMFB01_01 trigger: Short_20
2013-07-08 01:52:51 CUL_HM HMFB01 battery: ok
Und der Fernbedienungsbutton leuchtet fröhlich grün auf!
Ok, der Ventilator läßt sich nun nicht mehr einschalten. Aber das dürfte einfach daran liegen, dass der Unterputz-Aktor nun mit der neuen ID des HMUSB noch nix anfangen kann. Das bedeutet, ich werde jetzt alle meine Geräte noch einmal neu pairen müssen, damit sie die neue ID 127000 akzeptieren.
Nun bleibt natürlich die Frage, ob der USB Stick immer diese ID haben muss, oder ob sich das von Installation zu Installtation ändert?
Weitere Erfolgsmeldung!
Inzwischen habe ich alle 4 Buttons der Fernbedienung wie oben beschrieben mit HMUSB gepeert, den virtuellen Aktor wieder komplett gelöscht und den Schaltaktor für den Ventilator auf die neue Id gepaired. Nun macht die Fernbedienung endlich das, was ich seit Wochen möchte: sie leuchtet grün auf, wenn der Tastendruck von FHEM (genauer: dem Stick) empfangen wurde. Und auch der Ventilator läuft wieder munter los.
Jetzt steht mir nur noch die Fleißarbeit bevor, alle HM-Devices hier noch einmal neu zu pairen. Gibt es dafür nicht irgendeine "einfachere" Lösung, als alle erst mit unpair bzw. einem kompletten Reset umzufrickeln?
Vielleicht kann nochmal jemand testen, ob der HM-CFG-USB auch bei ihm die ID 127000 meldet, wenn man ein peerChan darauf absetzt. Dann könnte man irgendwo einen Hinweis in der Doku unterbringen, dass es Sinn machen kann, diese ID beim Einrichten des Sticks zu verwenden. Analog könnte man den Test auch mal bei einem LAN-Konfigurationsadapter machen (vielleicht mach ich das mal die Tage)
Gute Nacht!
Hallo Udo,
Zitat von: betateilchen schrieb am Mo, 08 Juli 2013 02:30Weitere Erfolgsmeldung!
Glückwunsch! :-)
ZitatVielleicht kann nochmal jemand testen, ob der HM-CFG-USB auch bei ihm die ID 127000 meldet, wenn man ein peerChan darauf absetzt. Dann könnte man irgendwo einen Hinweis in der Doku unterbringen, dass es Sinn machen kann, diese ID beim Einrichten des Sticks zu verwenden. Analog könnte man den Test auch mal bei einem LAN-Konfigurationsadapter machen (vielleicht mach ich das mal die Tage)
Die hmId ist einfach zu erklären. Das ist das erste Byte der IP-Adresse (127.0.0.1) und dann mit Nullen aufgefüllt. Kommt aus der Definition des Sticks.
Evtl. kann man beim peeren auch direkt eine hmId statt eines Namens angeben oder mit
define stick-va CUL_HM hmId
sich ein Gerät mit der gleichen ID wie das Attribut hmId am Stick basteln.
Gruß
Michael
Zitat von: mgernoth schrieb am Mo, 08 Juli 2013 09:24Evtl. kann man beim peeren auch direkt eine hmId statt eines Namens angeben
Na ob der Stick nun die Id 127000 hat oder (wie ursprünglich) AABBCC "heißt" ist mir eigentlich ziemlich egal, Hauptsache es funktioniert *g* Bei Gelegenheit kann ich ja mal testen, ob ich im peerChan auch hätte AABBCC angeben können.
Jetzt bleibt nur noch das ungelöste Problem mit dem nicht aktualisierten WindoRec beim HM-TC-CC, aber das ist eine völlig andere Baustelle.
Danke für Deine Unterstützung.
Martin,
was hast Du getan? Mit der 10_CUL_HM 3422 bekomme ich keine Rückmeldung mehr an die Fernbedienung, mit der 3378 funktioniert alles.
edit: jetzt funktioniert es auch mit der alten Version nicht mehr. Es ist zum Verzweifeln.
Hi !
Diese FB ist halt einfach schlicht schrott. Bei mir ist sie direkt mit den Aktoren gepairt.
Da aber offensichtlich die Empfangseigenschaften doch eher recht limitiert erscheinen,
darf ich mich nicht zu weit von Aktoren entfernen, wenn ich das ACK des Aktors noch als
grünes Licht auf der FB sehen möchte. Round about 10m im Gebäude mit maximal einer
Aussenwand und 30-40 im Freien (der Aktor befindet sich im Gartenhaus). Zum Vergleich,
mein CUNO hat hier immerhin einen RSSI Wert -60 (bei ebenfalls rund 10m und einer
Aussenwand). Man wird sich also an das organe Lämpchen gwöhnen müssen, wenn man diese
FB benutzt ...
Gruß, Marc
hm - schade.
Sicher hast du schon an einen repeater gedacht.
Das mit der geringen Reichweite kann ich nicht wirklich nachvollziehen. Ich wohne im zweiten Obergeschoß eines 80-er-Jahre Hauses mit viel Beton. Wenn ich zur Haustür reinkomme und die ersten 3 Stufen der Treppe hochgegangen bin, bekomme ich eine grüne Rückmeldung, wenn ich einen Knopf drücke. Die Fernbedienung ist übrigens direkt dem HM-CFG-USB2 gepeert.
Nachdem ich gestern abend noch ein paar ganz andere Homematic-Eigenarten feststellen mußte, habe ich noch folgende Schritte unternommen:
1. shutdown restart -> keine Abhilfe
2. den Raspberry neu gebootet -> keine Abhilfe
3. den Raspberry und den externen USB-Hub stromlos gemacht, gewartet, wieder angesteckt -> Erfolg!
Ich habe fast den HM-CFG-USB2 in Verdacht, dass der irgendwann "überläuft" und anfängt rumzuspinnen. Oder es ist eben doch der USB Bus des Raspberry eine Ursache. Ich werde die Sache mal weiter beobachten.
Einen Repeater, den ich früher als "Burstgenerator" genutzt habe,
hätte ich sogar noch. Aber bei der FB ist mir eigentlich nur
wichtig, dass der Aktor korrekt schaltet (das ist der Fall). Dass
diese komische FB das ACK des öfteren nicht mibekommt, ist nebensächlich.
Hauptsache der CUNO bekommt es mit und zeigt mir den richtigen Status
in der Weboberfläche an.
Gruß, Marc
Zitat von: marc2 schrieb am Mi, 17 Juli 2013 21:31Hauptsache der CUNO bekommt es mit und zeigt mir den richtigen Status in der Weboberfläche an.
Genau deshalb habe ich die Fernbedienung direkt mit dem HM-USB-CFG2 gepeert und nicht mit dem Aktor.
Hallo zusammen, vorallem betateilchen.
Ich habe auch eine RC-4-2 jedoch bekomme ich das mit der Rückmeldung vom HMLAN nicht hin. Die Messages zeigen, dass er die Nachricht zum HMLAN schickt und meiner Meinung auch ein ACK kommt, jedoch leuchtet sie nicht grün. Und die einzelnen Buttons wurden zwar über set btn peerChan 0 HMLAN1 single set gepeert und mit anlernknopf/getConfig auf der FB bestätigt ... jedoch zeigt ein späteres list keine peerID auf den buttons.
Kann mir bitte einer den weg aufzeigen, dass die FB mir das ACK mit grün bestätigt?
list:
Internals:
CFGFN ./cfg/rc.cfg
DEF 2265D304
HMLAN1_MSGCNT 15
HMLAN1_RAWMSG E2265D3,0000,723E4039,FF,FFC1,26A2402265D31E9E590411
HMLAN1_RSSI -63
HMLAN1_TIME 2013-12-08 22:19:24
LASTInputDev HMLAN1
MSGCNT 15
NAME CUL_HM_HM_RC_4_2_2265D3_Btn_04
NR 282
STATE Short (to HMLAN1)
TYPE CUL_HM
chanNo 04
device CUL_HM_HM_RC_4_2_2265D3
Readings:
2013-10-28 17:26:42 R-dblPress 0 s
2013-10-28 17:26:42 R-longPress 1 s
2013-12-08 21:54:48 R-sign on
2013-12-08 22:19:23 state Short (to HMLAN1)
2013-12-08 22:19:23 trigger Short_17
Helper:
getCfgList all
getCfgListNo ,4
peerIDsRaw ,00000000
Role:
chn 1
Shadowreg:
RegL_04:1E9E5901 01:00
Attributes:
alias rc_Franka_Btn_04_Garage
expert 1
model HM-RC-4-2
peerIDs 00000000,
room CUL_HM
verbose 5
Messages:
fhem> HMLAN HMLAN1 RCV L:0B N:64 F:A2 CMD:40 SRC:CUL_HM_HM_RC_4_2_2265AE DST:1E9E59 0426 (REMOTE BUTTON:4 LONG:0 LOWBAT:0 COUNTER:0x26) (,WAKEMEUP,BIDI,RPTEN)
HMLAN HMLAN1 SND L:0D N:64 F:80 CMD:02 SRC:1E9E59 DST:CUL_HM_HM_RC_4_2_2265AE 01010000 (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
readingsGroup batteries CUL_HM_HM_RC_4_2_2265AE.battery: ok
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 set_start
HMLAN HMLAN1 SND L:10 N:80 F:A0 CMD:11 SRC:1E9E59 DST:CUL_HM_HM_LC_SW4_WM_1E47D3 0201C800000140 (SET CHANNEL:0x01 VALUE:0xC8 RAMPTIME:2 DURATION:2) (,BIDI,RPTEN)
structure struct_Tore LastDevice: dm_Garage
structure struct_Tore LastDevice_Abs: dm_Garage
structure struct_Tore auf
dummy dm_Garage hoch
CUL_HM CUL_HM_HM_RC_4_2_2265AE battery: ok
CUL_HM CUL_HM_HM_RC_4_2_2265AE CUL_HM_HM_RC_4_2_2265AE_Btn_04 Short (to HMLAN1)
CUL_HM CUL_HM_HM_RC_4_2_2265AE_Btn_04 Short (to HMLAN1)
CUL_HM CUL_HM_HM_RC_4_2_2265AE_Btn_04 trigger: Short_38
HMLAN HMLAN1 RCV L:0E N:80 F:80 CMD:02 SRC:CUL_HM_HM_LC_SW4_WM_1E47D3 DST:1E9E59 0101C8404E (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0 RSSI:-78) (,RPTEN)
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 level: 100 %
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 pct: 100
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 deviceMsg: on (to HMLAN1)
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 on
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 timedOn: running
HMLAN HMLAN1 RCV L:0D N:81 F:84 CMD:10 SRC:CUL_HM_HM_LC_SW4_WM_1E47D3 DST:broadcast 06010000 (INFO_ACTUATOR_STATUS) (,CFG,RPTEN)
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 level: 0 %
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 pct: 0
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 deviceMsg: off (to broadcast)
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 off
CUL_HM CUL_HM_HM_LC_SW4_WM_1E47D3_Sw_01 timedOn: off
danke und viele grüße
stefan
Hallo Stefan,
was ist "btn"?
offensichtlich hat das peeren nicht funktioniert.
i.a. wird mit einem virtuellen Aktor gepeert - dann sendet FHEM die entsprechenden Antworten.
Du musst deinen Button erst mit einem Channel peeren - HMLAN ist ein Device
Gruss Martin
hallo martinp876,
btn ist einfach nur ein platzhalter für einen button der rc-4-2 ... ich wollte, wie von betateilchen durchgeführt, die buttons direkt mit dem hmlan (er hat es glaube ich mit dem hmlan usb cfg gemacht) peeren und damit die rückmeldung erhalten, wenn der HMLAN das signal empfangen hat.
grüße
stefan
Hallo Stefan,
nun, eine Rückmeldung bekommst du auch mit virtuellen channels
define vb CUL_HM 654321
set vb virtual 1 # Anzahl der Kanäle nach deiner Wahl
# jetzt existiert vb_Btn1
set CUL_HM_HM_RC_4_2_2265D3_Btn_04 peerChan 0 vb_Btn1 single
# anlernen drücken bei der RC4
und weil es sinnvoll ist
rename CUL_HM_HM_RC_4_2_2265D3 fb
rename CUL_HM_HM_RC_4_2_2265D3_Btn_01 fb_b1
rename CUL_HM_HM_RC_4_2_2265D3_Btn_02 fb_b2
rename CUL_HM_HM_RC_4_2_2265D3_Btn_03 fb_b3
rename CUL_HM_HM_RC_4_2_2265D3_Btn_04 fb_b4
Wenn du direkt mit der HMId der CUL/HMLAN peerst kannst du weniger sehen.
Gruss Martin
Hallo Martin,
Ich habe genau nach dieser Anleitung meinen HM-RC-Key4-2 gepeert und funktioniert soweit. Ich bekomme bei kurzem Tastendruck eine grüne Led.
Zitat von: martinp876 am 09 Dezember 2013, 13:01:43
define vb CUL_HM 654321
set vb virtual 1 # Anzahl der Kanäle nach deiner Wahl
# jetzt existiert vb_Btn1
set CUL_HM_HM_RC_4_2_2265D3_Btn_04 peerChan 0 vb_Btn1 single
# anlernen drücken bei der RC4
Wenn ich aber lange drücke bekomme ich immer nur eine rote Led zurück.
2014-02-03_22:38:16 remote_thomas remote_thomas_02 LongRelease 3-A040- (to vb)
2014-02-03_22:38:26 remote_thomas battery: ok
2014-02-03_22:38:26 remote_thomas remote_thomas_01 Long 1-8440- (to vb)
2014-02-03_22:38:27 remote_thomas battery: ok
2014-02-03_22:38:27 remote_thomas remote_thomas_01 Long 2-8440- (to vb)
2014-02-03_22:38:27 remote_thomas battery: ok
2014-02-03_22:38:27 remote_thomas remote_thomas_01 LongRelease 3-A040- (to vb)
2014-02-04_06:40:13 remote_thomas battery: ok
2014-02-04_06:40:13 remote_thomas remote_thomas_01 Short (to vb)Muss man den langen Tastendruck extra peeren?
Hallo netbus,
nein, muss man nicht. Ich habe es gerade geteset - grün bei lang und kurz - RC4 button 1
Prüfe einmal das peering des Buttons (frisches getConfig) und des virtuellen Buttons. Wenn das alles stimmt bitte beides senden und die roh-messages für kurz und lang
Gruss Martin
peerXref done:
x-ref list
Kellerlicht =>Schalter.2
Kellerlicht =>self01
Schalter.2 =>Kellerlicht_chn:01
glocken_relais =>self01
remote_doris_01 =>vb_Btn2
remote_doris_02 =>vb_Btn2
remote_thomas_01 =>vb_Btn1
remote_thomas_02 =>vb_Btn1
vb_Btn1 =>remote_thomas_01
vb_Btn1 =>remote_thomas_02
vb_Btn2 =>remote_doris_01
vb_Btn2 =>remote_doris_02
Vom VB kann man kein getConfig machen
Unknown argument getConfig, choose one of clear:readings,register,rssi,msgEvents raw virtual:slider,1,1,40
Internals:
DEF 2292FE
HMLAN1_MSGCNT 16
HMLAN1_RAWMSG RFD6CCF0A,0001,096763AB,FF,FFB3,07A0102292FE23A5720201000000
HMLAN1_RSSI -77
HMLAN1_TIME 2014-02-04 16:03:23
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 16
NAME remote_thomas
NR 102
STATE CMDs_done
TYPE CUL_HM
channel_01 remote_thomas_01
channel_02 remote_thomas_02
lastMsg No:07 - t:10 s:2292FE d:23A572 0201000000
protLastRcv 2014-02-04 16:03:23
protSnd 15 last_at:2014-02-04 16:03:23
protState CMDs_done
rssi_at_HMLAN1 avg:-77.75 min:-82 max:-74 lst:-77 cnt:16
CHANGETIME:
Helper:
Dblog:
Battery:
Mydblog:
TIME 1391525777.04451
VALUE ok
State:
Mydblog:
TIME 1391525777.04451
VALUE remote_thomas_01 Short (to vb)
Readings:
2014-02-03 22:02:37 CommandAccepted yes
2014-02-04 16:03:19 PairedTo 0x23XXXX
2014-02-04 16:03:19 R-localResDis off
2014-02-04 16:03:19 R-pairCentral 0x23XXXX
2014-02-04 16:03:19 RegL_00: 02:01 0A:23 0B:A5 0C:72 18:00 00:00
2014-02-03 22:02:35 aesKeyNbr FF
2014-02-04 15:56:17 battery ok
2014-02-04 16:03:23 state CMDs_done
2014-02-03 21:43:43 trigger Long_24
Helper:
addVal 1
cSnd 0123A5722292FE02041512990104
mId 00A6
rxType 20
Io:
nextSend 1391526203.20675
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rpt:
IO HMLAN1
flg A
ts 1391526203.12848
ack:
HASH(0x110b868)
07800223A5722292FE00
Rssi:
At_hmlan1:
avg -77.75
cnt 16
lst -77
max -74
min -82
Shadowreg:
Attributes:
IODev HMLAN1
autoReadReg 0_off
expert 2_full
firmware 1.1
model HM-RC-Key4-2
peerIDs
room Alarmanlage
serialNr KEQ0XXXXX
subType remote
getConfig
2014.02.04 16:09:05.893 0: HMLAN_Send: HMLAN1 I:K
2014.02.04 16:09:05.901 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852244 d:23A572 O:23A572 t:096C9EDB IDcnt:0001
2014.02.04 16:09:21.517 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096CDBBA d:FF r:FFB5 m:14 A200 2292FE 23A572 1100A64B45513038313539313240040000
2014.02.04 16:09:21.532 0: HMLAN_Send: HMLAN1 I:+2292FE,00,00,
2014.02.04 16:09:21.538 0: HMLAN_Send: HMLAN1 S:SFD724844 stat: 00 t:00000000 d:01 r:FD724844 m:14 8002 23A572 2292FE 00
2014.02.04 16:09:21.585 0: HMLAN_Send: HMLAN1 S:SFD72484E stat: 00 t:00000000 d:01 r:FD72484E m:01 A001 23A572 2292FE 00040000000000
2014.02.04 16:09:21.600 0: HMLAN_Parse: HMLAN1 R:RFD724844 stat:0002 t:00000000 d:FF r:7FFF m:14 8002 23A572 2292FE 00
2014.02.04 16:09:21.968 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096CDD9C d:FF r:FFAF m:01 A010 2292FE 23A572 0202010A230BA50C7218000000
2014.02.04 16:09:22.083 0: HMLAN_Parse: HMLAN1 R:RFD72484E stat:0001 t:096CDDA1 d:FF r:FFAF m:01 A010 2292FE 23A572 0202010A230BA50C7218000000
2014.02.04 16:09:22.207 0: HMLAN_Send: HMLAN1 S:+2292FE,00,01,
2014.02.04 16:09:22.210 0: HMLAN_Send: HMLAN1 S:SFD724AE0 stat: 00 t:00000000 d:01 r:FD724AE0 m:02 A001 23A572 2292FE 01040000000001
2014.02.04 16:09:22.482 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096CDF9E d:FF r:FFBB m:02 A010 2292FE 23A572 020410080109000000
2014.02.04 16:09:22.600 0: HMLAN_Parse: HMLAN1 R:RFD724AE0 stat:0001 t:096CDFA3 d:FF r:FFBB m:02 A010 2292FE 23A572 020410080109000000
2014.02.04 16:09:22.715 0: HMLAN_Send: HMLAN1 S:SFD724CDD stat: 00 t:00000000 d:01 r:FD724CDD m:03 A001 23A572 2292FE 0103
2014.02.04 16:09:22.999 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096CE1A3 d:FF r:FFBC m:03 A010 2292FE 23A572 011512990100000000
2014.02.04 16:09:23.117 0: HMLAN_Parse: HMLAN1 R:RFD724CDD stat:0001 t:096CE1A8 d:FF r:FFBC m:03 A010 2292FE 23A572 011512990100000000
2014.02.04 16:09:23.231 0: HMLAN_Send: HMLAN1 S:+2292FE,00,01,
2014.02.04 16:09:23.234 0: HMLAN_Send: HMLAN1 S:SFD724EE0 stat: 00 t:00000000 d:01 r:FD724EE0 m:04 A001 23A572 2292FE 02040000000001
2014.02.04 16:09:23.516 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096CE3A8 d:FF r:FFBD m:04 A010 2292FE 23A572 020410080109000000
2014.02.04 16:09:23.634 0: HMLAN_Parse: HMLAN1 R:RFD724EE0 stat:0001 t:096CE3AD d:FF r:FFBD m:04 A010 2292FE 23A572 020410080109000000
2014.02.04 16:09:23.757 0: HMLAN_Send: HMLAN1 S:SFD7250EE stat: 00 t:00000000 d:01 r:FD7250EE m:05 A001 23A572 2292FE 0203
2014.02.04 16:09:24.033 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096CE5AD d:FF r:FFBD m:05 A010 2292FE 23A572 011512990100000000
2014.02.04 16:09:24.151 0: HMLAN_Parse: HMLAN1 R:RFD7250EE stat:0001 t:096CE5B2 d:FF r:FFBD m:05 A010 2292FE 23A572 011512990100000000
2014.02.04 16:09:24.264 0: HMLAN_Send: HMLAN1 S:+2292FE,00,01,
2014.02.04 16:09:24.267 0: HMLAN_Send: HMLAN1 S:SFD7252EA stat: 00 t:00000000 d:01 r:FD7252EA m:06 A001 23A572 2292FE 01041512990104
2014.02.04 16:09:24.547 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096CE7AF d:FF r:FFBC m:06 A010 2292FE 23A572 0201000000
2014.02.04 16:09:24.668 0: HMLAN_Parse: HMLAN1 R:RFD7252EA stat:0001 t:096CE7B4 d:FF r:FFBC m:06 A010 2292FE 23A572 0201000000
2014.02.04 16:09:24.779 0: HMLAN_Send: HMLAN1 S:+2292FE,00,01,
2014.02.04 16:09:24.783 0: HMLAN_Send: HMLAN1 S:SFD7254ED stat: 00 t:00000000 d:01 r:FD7254ED m:07 A001 23A572 2292FE 02041512990104
2014.02.04 16:09:25.064 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096CE9B4 d:FF r:FFBC m:07 A010 2292FE 23A572 0201000000
2014.02.04 16:09:25.185 0: HMLAN_Parse: HMLAN1 R:RFD7254ED stat:0001 t:096CE9B9 d:FF r:FFBC m:07 A010 2292FE 23A572 0201000000
2014.02.04 16:09:30.900 0: HMLAN_Send: HMLAN1 I:K
2014.02.04 16:09:30.908 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852244 d:23A572 O:23A572 t:096D008E IDcnt:0002
Kurz:
2014.02.04 16:11:43.030 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096F04B3 d:FF r:FFB3 m:18 A440 2292FE 151299 0146
2014.02.04 16:11:43.076 0: HMLAN_Send: HMLAN1 S:SFD747111 stat: 00 t:00000000 d:01 r:FD747111 m:18 8002 151299 2292FE 0101C800
2014.02.04 16:11:43.241 0: HMLAN_Parse: HMLAN1 R:RFD747111 stat:0002 t:00000000 d:FF r:7FFF m:18 8002 151299 2292FE 0101C800
Lang:
2014.02.04 16:12:43.993 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096FF2DF d:FF r:FFB3 m:2B 8440 2292FE 151299 414C
2014.02.04 16:12:44.243 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096FF3D9 d:FF r:FFB3 m:2C 8440 2292FE 151299 414C
2014.02.04 16:12:44.493 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096FF4D3 d:FF r:FFB3 m:2D 8440 2292FE 151299 414C
2014.02.04 16:12:44.743 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096FF5CD d:FF r:FFB4 m:2E 8440 2292FE 151299 414C
2014.02.04 16:12:44.993 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096FF6C7 d:FF r:FFB3 m:2F 8440 2292FE 151299 414C
2014.02.04 16:12:45.243 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096FF7C1 d:FF r:FFB1 m:30 8440 2292FE 151299 414C
2014.02.04 16:12:45.508 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:096FF8BB d:FF r:FFB2 m:31 A040 2292FE 151299 414C
2014.02.04 16:12:45.532 0: HMLAN_Send: HMLAN1 S:SFD75651E stat: 00 t:00000000 d:01 r:FD75651E m:31 8002 151299 2292FE 0101C800
2014.02.04 16:12:45.696 0: HMLAN_Parse: HMLAN1 R:RFD75651E stat:0002 t:00000000 d:FF r:7FFF m:31 8002 151299 2292FE 0101C800
2014.02.04 16:12:49.006 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:09700674 d:FF r:FFB4 m:32 8440 2292FE 151299 414D
2014.02.04 16:12:52.657 0: HMLAN_Send: HMLAN1 I:K
2014.02.04 16:12:52.668 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:0970076E d:FF r:FFB4 m:33 8440 2292FE 151299 414D
2014.02.04 16:12:52.840 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:09700868 d:FF r:FFB4 m:34 8440 2292FE 151299 414D
2014.02.04 16:12:53.051 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:09700962 d:FF r:FFB5 m:35 8440 2292FE 151299 414D
2014.02.04 16:12:53.307 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:09700A5C d:FF r:FFB5 m:36 8440 2292FE 151299 414D
2014.02.04 16:12:53.482 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:09700B56 d:FF r:FFB3 m:37 A040 2292FE 151299 414D
2014.02.04 16:12:53.507 0: HMLAN_Send: HMLAN1 S:SFD758445 stat: 00 t:00000000 d:01 r:FD758445 m:37 8002 151299 2292FE 01010000
2014.02.04 16:12:53.667 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:09700C50 d:FF r:FFB3 m:37 A040 2292FE 151299 414D
2014.02.04 16:12:53.679 0: HMLAN_Parse: HMLAN1 R:E2292FE stat:0000 t:09700D4A d:FF r:FFB3 m:37 A040 2292FE 151299 414D
2014.02.04 16:12:53.691 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852244 d:23A572 O:23A572 t:097014C5 IDcnt:0002
2014.02.04 16:12:53.698 0: HMLAN_Parse: HMLAN1 R:RFD758445 stat:0002 t:00000000 d:FF r:7FFF m:37 8002 151299 2292FE 01010000
Hi netbus
bei lang hast du 2-mal lang gedrückt - 4sec abstand. Das erste mal war alles ok, beim 2. Mal hat der RC4 die Antwort wohl nicht akzeptiert. Meiner macht hier keine Probleme.
151299 ist ein virtuellen oder das IO device?
Bei mir klappt es bei beiden.... immer grün.
2 Vorschläge: mache morgen einen update - es hat sich eine Kleinigkeit zum RC4 geändert - vielleicht hilft es. Man kann jetzt ein getConfig auch ausführen, wenn man einen button drückt. Der darf aber wohl nicht gepeert sein.
2. tausche einmal die Batterie - man weiss nie
Gruss Martin
Hallo,
folgendes habe ich noch nicht verstanden (und möchte es mangels "Undo Button" in FHEM ;) auch nicht ausprobieren):
Ich habe jetzt für die "Grüne Rückmeldung" einen Kanal der Fernbed. mit einem virtuellen Kanal gepeert. Die LED wird nach drücken der Taste wirklich grün. Sehr schön! :D
Sollte ich nun für die übrigen Fernbed.- Tasten jeweils einen weiteren virtuellen Kanal anlegen, oder reicht es alle Tasten auf den selben Kanal zu peeren um eine grüne Rückmeldung zu bekommen?
Viele Grüße
Frank
Hi Frank
Zitatund möchte es mangels "Undo Button" in FHEM ;) auch nicht ausprobieren
haben wir nicht? nun ja, keinen button, aber du kannst die Config eines jeden devices in ein file saven und das ggf wieder einspielen. Ist wie undo ;)
Es reicht ein virtueller Aktor. Mehrere machen nur sinn, wenn du etwas auswerten willst.
Gruss Martin
Hi Martin,
vielen Dank! Geht wie gedacht und gewünscht. :) Ich war mir nur unsicher, ob die peers auch im realen Taster gespeichert werden. Dann hätte ich im Falle von "Mist gebaut" die ja irgendwie wieder löschen müssen. Naja, bei HM muss ich noch viel lernen...
Aber dank deiner tollen Arbeit läuft immer alles out of the box perfekt. Erst wenn man mehr machen will, muss man sich einlesen. Toll!
Gruß
Frank