Wie hier beschrieben habe ich für meinen Taster einen virtuellen Aktor eingerichtet....
https://wiki.fhem.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster (https://wiki.fhem.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster)
Die hmID des virtuellen Aktors ist ungleich der meines HMUARTLGW. Ist das korrekt? Das hatte ich irgendwo gelesen das das so sein muss.
Leider scheint der virtuelle Aktor kein ACK zu senden, die Tastendrücke werden stets mit einer roten LED quitiert.
Hier die Events....
2017-02-10 18:53:45 CUL_HM WandTaster_01 battery: ok
2017-02-10 18:53:45 CUL_HM WandTaster_01 CMDs_done
2017-02-10 18:53:45 CUL_HM WandTaster_01 WandTaster_01_Btn_01 Short
2017-02-10 18:53:45 CUL_HM WandTaster_01_Btn_01 Short (to virtueller_Aktor)
2017-02-10 18:53:45 CUL_HM WandTaster_01_Btn_01 trigger: Short_25
2017-02-10 18:53:45 CUL_HM WandTaster_01_Btn_01 triggerTo_virtueller_Aktor: Short_25
2017-02-10 18:53:45 CUL_HM WandTaster_01_Btn_01 trigger_cnt: 25
2017-02-10 18:53:45 CUL_HM virtueller_Aktor_Btn1 ON
2017-02-10 18:53:45 CUL_HM virtueller_Aktor_Btn1 trigLast: WandTaster_01_Btn_01:short
2017-02-10 18:53:45 CUL_HM virtueller_Aktor_Btn1 trig_WandTaster_01_Btn_01: Short_25
2017-02-10 18:53:45 CUL_HM virtueller_Aktor_Btn1 virtActState: ON
2017-02-10 18:53:45 CUL_HM virtueller_Aktor_Btn1 virtActTrigNo: 25
2017-02-10 18:53:45 CUL_HM virtueller_Aktor_Btn1 virtActTrigRpt: 1
2017-02-10 18:53:45 CUL_HM virtueller_Aktor_Btn1 virtActTrigType: short_Release
2017-02-10 18:53:45 CUL_HM virtueller_Aktor_Btn1 virtActTrigger: WandTaster_01_Btn_01
2017-02-10 18:53:45 CUL_HM WandTaster_01 CMDs_done
2017-02-10 18:53:45 CUL_HM WandTaster_01 CMDs_done
Ich habe gerade was in den logs gefunden....
2017.02.10 18:53:45 0: HMUARTLGW myHmUART: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!
Daher also das Problem...?
Hi,
die Fehlermeldung suggeriert, dass es mit einer VCCU funktionieren könnte.
...also mal damit probieren.
Gruß,
Thorsten
Hmm, jetzt habe ich ein VCCU eingerichtet,
sowohl der Taster als auch der virtuelle Aktor hat die IOgrp VCCU als attribut.
Event Monitor hat sich nicht geändert:
2017-02-11 16:13:04 CUL_HM WandTaster_01 battery: ok
2017-02-11 16:13:04 CUL_HM WandTaster_01 CMDs_done
2017-02-11 16:13:04 CUL_HM WandTaster_01 WandTaster_01_Btn_01 Short
2017-02-11 16:13:04 CUL_HM WandTaster_01_Btn_01 Short (to virtueller_Aktor)
2017-02-11 16:13:04 CUL_HM WandTaster_01_Btn_01 trigger: Short_37
2017-02-11 16:13:04 CUL_HM WandTaster_01_Btn_01 triggerTo_virtueller_Aktor: Short_37
2017-02-11 16:13:04 CUL_HM WandTaster_01_Btn_01 trigger_cnt: 37
2017-02-11 16:13:04 CUL_HM virtueller_Aktor_Btn1 OFF
2017-02-11 16:13:04 CUL_HM virtueller_Aktor_Btn1 trigLast: WandTaster_01_Btn_01:short
2017-02-11 16:13:04 CUL_HM virtueller_Aktor_Btn1 trig_WandTaster_01_Btn_01: Short_37
2017-02-11 16:13:04 CUL_HM virtueller_Aktor_Btn1 virtActState: OFF
2017-02-11 16:13:04 CUL_HM virtueller_Aktor_Btn1 virtActTrigNo: 37
2017-02-11 16:13:04 CUL_HM virtueller_Aktor_Btn1 virtActTrigRpt: 1
2017-02-11 16:13:04 CUL_HM virtueller_Aktor_Btn1 virtActTrigType: short_Release
2017-02-11 16:13:04 CUL_HM virtueller_Aktor_Btn1 virtActTrigger: WandTaster_01_Btn_01
2017-02-11 16:13:04 CUL_HM WandTaster_01 CMDs_done
2017-02-11 16:13:05 CUL_HM WandTaster_01 CMDs_done
Fehlermeldung im log auch nicht....
2017.02.11 16:13:04 0: HMUARTLGW myHmUART: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!
Das IO device ist das HomeMatic Modul für den raspberry pi (HM-MOD-UART)
Woran kann man denn sehen das der VCCU auch wirklich benutzt wird?
Ich habe den Taster jetzt auf Werkseinstellung zurückgesetzt und neu direkt mit der VCCU gepaired, den virtuellen Aktor gelöscht und neu angelegt, hilft alles nix, die Fehlermeldung über die Firmware und Empfehlung ein VCCU zu nehmen bleibt :-[
Hi,
gib mal bitte ein list myHmUART
Gruß Otto
Hier die Ausgabe, ich habe die Peers Liste und den hmKey rausgenommen
Internals:
AssignedPeerCnt 27
CNT 9
DEF /dev/ttyAMA0
DEVCNT 9
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 10
LastOpen 1486836038.53559
NAME myHmUART
NR 20
PARTIAL
RAWMSG 040244
RSSI -74
STATE opened
TYPE HMUARTLGW
XmitOpen 1
msgLoadCurrent 34
msgLoadHistory 1/0/0/1/0/1/1/3/-4/2/0/2
msgLoadHistoryAbs 20/19/19/19/18/18/17/16/13/17/15/15/13
owner 031965
owner_CCU VCCU
Helper:
CreditTimer 4026
FW 66561
Initialized 1
SendCnt 1221
Ackpending:
127:
cmd 02000000F48002031965465F9B0101C800
dst 1
frame FD0013017F02000000F48002031965465F9B0101C80052C0
time 1486895337.33359
168:
cmd 02000000F58002031965465F9B0101C800
dst 1
frame FD001301A802000000F58002031965465F9B0101C8000F48
time 1486895838.1306
17:
cmd 02000000F38002031965465F9B0101C800
dst 1
frame FD0013011102000000F38002031965465F9B0101C800730C
time 1486894312.37654
172:
cmd 02000000F68002031965465F9B0101C800
dst 1
frame FD001301AC02000000F68002031965465F9B0101C8005F9B
time 1486895839.38557
181:
cmd 02000000F78002031965465F9B0101C800
dst 1
frame FD001301B502000000F78002031965465F9B0101C80055EA
time 1486895895.53059
60:
cmd 020000005E80020319654E176F0101C800
dst 1
frame FD0013013C020000005E80020319654E176F0101C8003BE5
time 1486894632.09462
61:
cmd 020000005F80020319654E176F0101C800
dst 1
frame FD0013013D020000005F80020319654E176F0101C8005071
time 1486894637.59414
70:
cmd 020000006080020319654E176F0101C800
dst 1
frame FD00130146020000006080020319654E176F0101C8008085
time 1486894752.85399
73:
cmd 020000006180020319654E176F0101C800
dst 1
frame FD00130149020000006180020319654E176F0101C800B3CA
time 1486894764.85235
LastSendLen:
3
3
Log:
IDs:
PeerQueue:
PendingCMD:
Roundtrip:
Delay 0.00268101692199707
Loadlvl:
lastHistory 1486896346.83619
Peers:
....
Readings:
2017-02-11 19:00:49 D-HMIdAssigned 031965
2017-02-11 19:00:49 D-HMIdOriginal 45F94F
2017-02-11 19:00:49 D-firmware 1.4.1
2017-02-11 19:00:49 D-serialNr MEQ....
2017-02-11 19:00:38 D-type HM-MOD-UART
2017-02-11 19:00:49 cond ok
2017-02-12 11:47:21 load 34
2017-02-11 20:05:32 loadLvl low
2017-02-11 19:00:38 state opened
Helper:
Attributes:
....
Die Firmware Version sieht gut aus.
Ich habe momentan keine Idee.
Die vielen Ack Pending sehen nicht gut aus.
Gruß otto
Ja, für jeden Tastendruck kommt ein Ack Pending dazu. Vmtl. ist es besser den virtuellen Aktor wieder zu deaktivieren
Hi,
also wenn Otto nicht weiter weiß, dann solltest Du den Thread vielleicht nach Homematic verschieben.
Gruß,
Thorsten
Lösch doch man den virtuellen Aktor.
Du sagst die Tastendrücke werden rot quittiert? Gib mal bitte ein list von dem Taster.
Die Quittung sollte nämlich gelb sein, der ist bestimmt falsch/nicht gepairt oder hat einen falschen peer!
Gruß Otto
@Otto: Habe ich jetzt Deinen Ehrgeiz geweckt? :)
Zitat von: Thorsten Pferdekaemper am 12 Februar 2017, 17:17:15
@Otto: Habe ich jetzt Deinen Ehrgeiz geweckt? :)
Hi Thorsten,
Der ist immer hellwach, aber manchmal kommt ein Gedanke aus einer ganz anderen Ecke die man vorher nicht berücksichtigt hatte. 8)
Ich bin in die Frage eingestiegen wegen der Firmware Meldung, und erinnerte mich, dass ein paar Leute das RPI Modul zuerst mit der CCU2 Software am Laufen hatten und dabei eine für FHEM inkompatible Firmware geflasht wird. Jetzt habe ich nochmal den Anfang gelesen und Kaffee getrunken ;)
Gruß Otto
Hi hi,
das klingt sehr nach dem gleichen Problem was ich auch berichtet habe :-O
https://forum.fhem.de/index.php/topic,66932.0.html (https://forum.fhem.de/index.php/topic,66932.0.html)
Ich habe die Fehlermeldung auch im Log gefunden...
list WandTaster_01 ergibt:
Internals:
DEF 47..
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 75
NAME WandTaster_01
NOTIFYDEV global
NR 194
NTFY_ORDER 50-WandTaster_01
STATE WandTaster_01_Btn_02 LongRelease
TYPE CUL_HM
channel_01 WandTaster_01_Btn_01
channel_02 WandTaster_01_Btn_02
lastMsg No:E7 - t:40 s:47B8A8 d:123456 4256
myHmUART_MSGCNT 75
myHmUART_RAWMSG 05000042E7A04047B8A81234564256
myHmUART_RSSI -66
myHmUART_TIME 2017-02-14 15:44:04
protLastRcv 2017-02-14 15:44:04
rssi_at_myHmUART cnt:75 avg:-58.2 lst:-66 min:-71 max:-52
Readings:
2017-02-11 16:35:12 CommandAccepted yes
2017-02-11 16:35:16 D-firmware 1.4
2017-02-11 16:35:16 D-serialNr NAA.......
2017-02-11 16:35:17 PairedTo 0x031965
2017-02-11 16:35:17 R-pairCentral 0x031965
2017-02-11 16:35:17 RegL_00. 02:01 0A:03 0B:19 0C:65 00:00
2017-02-14 15:44:04 battery ok
2017-02-14 15:44:04 state WandTaster_01_Btn_02 LongRelease
Helper:
HM_CMDNR 231
mId 006B
rxType 28
supp_Pair_Rep 0
Ack:
123456 WandTaster_01_Btn_02:E7
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +47B8A8,00,01,00
nextSend 1487083445.11847
rxt 2
vccu VCCU
p:
47B8A8
00
01
00
prefIO:
myHmUART
Mrssi:
mNo E7
Io:
myHmUART -64
Prt:
bErr 0
sProc 0
sleeping 1
Q:
qReqConf 01,02
qReqStat
Role:
dev 1
Rssi:
At_myhmuart:
avg -58.2
cnt 75
lst -66
max -52
min -71
Attributes:
IODev myHmUART
IOgrp VCCU:myHmUART
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-PB-2-WM55
room Taster
serialNr NAA....
subType pushButton
webCmd getConfig:clear msgEvents
Unter dem Attribute peerIDs steht 00000000, den virtuellen Aktor habe ich gelöscht der hatte 123456.
gepairt ist er, wenn er keinen peer hat dann habe ich keine Ahnung warum er rot liefert.
Ordnungsgemäß oder gar nicht gepairt und nicht gepeert müsste gelb liefern.
Da wirst Du sniffen müssen und die ganzen Thread nach Homematic verschieben.
Gruß Otto
Hallo zusammen,
gibt es denn schon ein Update ? Ich bin auch am verzweifeln... Ich habe den normalen Wandtaster und den 6fach-Wandtaster im Einsatz. Mittlerweile habe ich ihn auf Werkseinstellungen zurück gesetzt und neu angelernt, dieses mal mit einem virtuellem Device gepaired und trotzdem bekomme ich nur rot. Mal zum Verständnis: muss ich den Aktor dann mit dem virtuellem Buttom pairen ? In jeder meiner Peer-ID Listen steht auch immer die 00000000 mit drin, welche ich nicht weg bekomme. Ist das korrekt ?!
VG,
Chris
Hallo Chris,
bitte nicht peeren und pairen durcheinanderhauen.
Das in der Peer-ID als default 00000000 drin steht ist ok. Dann hat er keinen anderen peer.
Du musst ihn nicht mit einem virtuellen Aktor peeren - was willst Du denn erreichen?
Was liefert der Taster nach Werkreset auf Betätigung einer Taste? orange oder rot?
Was liefert er wenn er an der Zentrale angelernt ist? Orange oder rot bei Betätigung?
Gruß Otto
Hi,
ich möchte einfach, nachdem das Licht eingeschalten ist, eine grüne Bestätigung der LED. Früher ging das, mit dem HMUARTLGW stand hier im Forum ich soll es an einen virtuellen Button eines virtuellen Devices pairen, damit es mir zum einen nicht die Fehlermeldung ins Log schreibt (ok - die ist auch weg...) und zum anderen die Bestätigung ankommt.
Nach dem Werksreset kam orange.
Nach dem Pairing kommt rot. Nach Peering auch. Aber Licht schalten geht schon mal wieder :)
Danke für die Hilfe,
Chris
Chris, wenn Du nicht aufhörst peeren und pairen falsch zu verwenden habe ich keine Lust mehr!
Was heißt früher ging das? Was hat das mit dem HMUARTLGW zu tun?
Da Du die Begriffe nicht aus einander halten willst: Was meinst Du damit genau?
ZitatNach dem Pairing kommt rot.
Gib bitte ein List von dem Taster.
Gruß Otto
Hi,
ich denke nicht dass ich es durcheinander bringe ? Nach dem Reset musste ich ihn doch neu pairen damit ihn Fhem überhaupt kennt. Danach ist ja kein Peer automatisch definiert - stehen nur die 00000000 drin. Also habe ich danach gepeert - und zwar an einen Button eines virtuellen Devices. Das ist doch generell erstmal korrekt, oder ?
Früher hatte ich einen anderen CUL, damit ging es problemlos.
Hier ein List:
Internals:
CFGFN
DEF 3B6XXX
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 53
NAME Kueche_Taster
NOTIFYDEV global
NR 4225
STATE Kueche_Taster_V2 Short
TYPE CUL_HM
channel_01 Kueche_Taster_V1
channel_02 Kueche_Taster_V2
lastMsg No:CA - t:40 s:3B6XXX d:1234AB 0218
myHmUART_MSGCNT 53
myHmUART_RAWMSG 0500003FCAA0403B6XXX1234AB0218
myHmUART_RSSI -63
myHmUART_TIME 2017-04-18 13:46:19
protCmdDel 3
protLastRcv 2017-04-18 13:46:19
protNack 1 last_at:2017-04-18 13:44:18
protSnd 40 last_at:2017-04-18 13:44:17
protState CMDs_done_Errors:1
rssi_at_myHmUART lst:-63 cnt:53 avg:-64.47 max:-55 min:-86
Readings:
2017-04-18 13:44:18 CommandAccepted no
2017-04-18 13:44:17 D-firmware 1.4
2017-04-18 13:44:17 D-serialNr MEQ0398XXX
2017-04-18 13:27:17 PairedTo 0x1C69XX
2017-04-18 13:27:17 R-pairCentral 0x1C69XX
2017-04-18 13:27:17 RegL_00. 02:01 0A:1C 0B:69 0C:5F 00:00
2017-04-18 13:46:18 battery ok
2017-04-18 13:46:18 state Kueche_Taster_V2 Short
Helper:
HM_CMDNR 202
cSnd 011C69XXXB6DE802041234AB0204,011C69XXXB6DE802020000000000
mId 006B
rxType 28
supp_Pair_Rep 0
Ack:
Kueche_Taster_virt Kueche_Taster_V2:CA
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newCh 1
newChn +3B6XXX,00,01,00
nextSend 1492515979.66128
prefIO
rxt 2
vccu
p:
3B6XXX
00
01
00
Mrssi:
mNo CA
Io:
myHmUART -61
Prt:
bErr 0
sProc 0
sleeping 1
try 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_myhmuart:
avg -64.4716981132075
cnt 53
lst -63
max -55
min -86
Shadowreg:
Tmpl:
Attributes:
IODev myHmUART
IOgrp VCCU:myHmUART
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
group Devices
model HM-PB-2-WM55
room Küche
serialNr MEQ0398XXX
subType pushButton
webCmd getConfig:clear msgEvents
lastMsg No:CA - t:40 s:3B6XXX d:1234AB 0218
Wem gehört die hmid 1234AB?
Das ist der virtuelle Taster den ich angelegt habe:
CFGFN
DEF 1234AB
IODev myHmUART
NAME Kueche_Taster_virt
NOTIFYDEV global
NR 4260
STATE ???
TYPE CUL_HM
channel_01 Kueche_Taster_virt_Btn1
channel_02 Kueche_Taster_virt_Btn2
Readings:
Helper:
HM_CMDNR 15
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +1234AB,00,00,00
prefIO
rxt 0
vccu
p:
1234AB
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Tmpl:
Attributes:
IODev myHmUART
autoReadReg 4_reqStatus
expert 2_raw
model virtual_2
subType virtual
Doch Du bringst es durcheinander: im Forum ich soll es an einen virtuellen Button eines virtuellen Devices pairen
Einen Knopf mit einem virtuellen Aktor verbinden heißt nun mal peeren. Pairen ist die Verbindung mit der Zentrale.
Soweit sieht alles gut aus. Was ist jetzt das Problem? Das peeren hat nicht geklappt? (Du könntest einen list beider gepeerter Channels liefern)
Aber nochmal, was hat das mit der Bemerkung früher ging das? Was betätigt denn der Taster im Endeffekt? Einen HM Aktor oder etwas anderes?
Gruß Otto
Guten Morgen,
generell schalte ich mit den Tastern einen HM-LC-SW1-FM. Früher hatte ich einen Raspi 1 mit einem CUL von Busware - da haben mir jegliche Taster alles grün quittiert. Jetzt bin ich auf einen Raspi 3 mit myHmUART umgestiegen, hier bekomme ich seitdem immer nur rot quittiert was ich halt komisch finde - obwohl die gewünschte Aktion ausgeführt wird. Ich habe jetzt also ein virtuelles Device mit 2 Buttons angelegt und den Taster darauf gepeert ( ? ). Beim Taster sehe ich die Peer ID korrekt - im virtuellen Device jedoch nicht ?! Liegt es daran ?
Nach dem Lesen bin ich völlig durcheinander :o
Was wird denn hier mit wem gepeert?
Zitatein virtuelles Device mit 2 Buttons angelegt und den Taster darauf gepeert
Für mich sind das beides "Sensoren", wozu die peeren und was ist mit dem Aktor HM-LC-SW1-FM?
Sollte nicht der Sensor (Button des virtuellen Device) mit dem Aktor HM-LC-SW1-FM gepeert werden und zusätzlich der Taster mit dem Aktor HM-LC-SW1-FM?
Wo ist am virtuellen Device eine LED für die Quittung? ;)
Sorry, aber dann ist doch die Geschichte mit den virtuellen Kanälen völlig Quark! Peere doch einfach den Taster und die Aktoren und dann hast Du grünes Licht.
Ich verstehe immer noch nicht was das mit "früher" und "heute" zu tun hat? Das muss doch vor und nach dem Umzug genauso gehen. Es gibt keinen logischen Unterschied zwischen den beiden HM IOs. Hättest Du den Umzug richtig gemacht wäre alles so geblieben. Ich vermute jetzt, Du hast versucht beim Umzug alles zu zerstören, neu anzufangen und es ist Dir nicht gelungen.
Die rote Quittung kommt, wenn entweder der Peer nicht antwortet oder die Zentrale keine Quittung schickt. Das list vom taster sieht so aus, als ob das pairing erfolgreich war. Allerdings sagst Du nach dem pairen kommt rot, da kann was nicht stimmen.
Ich denke Du solltest nochmal eine Runde über die Grundlagen fliegen und versuchen diese unklaren Informationen zu ordnen. Und bitte keine Screenshots >:(
Nach allem was Du sagst, scheint der Taster mit dem Aktor nach wie vor gepeert (die gewünschte Aktion wird ausgeführt) du hast nicht richtig gepairt (obwohl das list so aussieht) wahrscheinlich hat Dein myHmUART eine andere hmId und der alte CUL (hmId 0x1C69XX ) existiert nicht mehr.
Gruß Otto
Okay,
werde ich mal probieren - danke für den Tipp. Ich hab das übrigens nicht alles neu aufgesetzt, ich hab die alte CFG so gut es ging übernommen. Warum ich auf die Idee mit dem virtuellen Device kam ? Ich habe hier gelesen: https://forum.fhem.de/index.php?topic=54511.495 (https://forum.fhem.de/index.php?topic=54511.495)
ZitatDu benutzt einen virtuellen Aktor, der kein virtuelles Gerät der VCCU ist. Das geht wegen eines Firmwarebugs des Moduls nicht, Du musst ein virtuelles VCCU-Gerät stattdessen nehmen.
Vielleicht habe ich da was durcheinander gebracht...
Ich denke das ist ein Problem mit myHmUART (also dem HM Modul für raspberry pi) und FHEM.
Ich habe das aufgegeben weiter zu debuggen und meine Taster liefern jetzt halt orange. Stört nicht weiter da fest installiert mit guter Verbindung zur Basis.
Ich habe jetzt neue Taster und echte HW Actoren für eine andere Anwendung gekauft. D.h. hier werde ich mit einem echten Actor peeren, bin gespannt ob dann grünes Licht kommt. (Ich erwarte natürlich das das geht, weil die "peer" Verbindung nicht über FHEM läuft)
Aber Fhem bekommt dann trotzdem den Schaltzustand mit ?
Wenn ich mit einem Taster eine eigene Befehlsfolge auslösen möchte, bekomme ich somit nie grün... ? Das ist ja schade...
Ich weiß nicht von was hier so erzählt wird - das klingt alles nach Kaffeeklatsch.
@chem Die anderen Aktoren von denen Du geredet hast waren keine echten HM Aktoren? :-[
Und bitte beschäftige Dich mit den Grundlagen: Eine peer Verbindung von HM Geräten hat mit FHEM nichts zu tun.
Man kann HM Geräte ohne Zentrale "anlernen" -> "peeren" Das tun die Geräte untereinander wenn man die Anlerntaste drückt (was genau und wie steht im Handbuch beider Geräte).
Sind Geräte an einer Zentrale angelernt (gepairt) kann die Verbindung untereinander (peering) nur noch über die Zentrale eingerichtet werden. Das ist vor allem ein Sicherheitsfeature! Vorteil ist, dass man dabei wesentlich mehr einrichten kann als beim direkten Anlernen. Die Zentrale bekommt alle Aktionen der Geräte mit, auch wenn die "peer" Aktionen auch ohne Zentrale funktionieren.
Hat man HM Taster und will damit nur Aktionen durch FHEM steuern, bekommt man keine grüne Quittung sondern nur eine Orange. (Taster ist dann nicht gepeert) um das zu umgehen kann man den Taster mit einem virtuellen Kanal peeren. In beiden Fällen hat das nur wenig Einfluss darauf welche Aktionen in FHEM in Folge der Tasterbetätigung ausgeführt werden können.
Gruß Otto
Zitat von: Otto123 am 26 April 2017, 20:55:59
@chem Die anderen Aktoren von denen Du geredet hast waren keine echten HM Aktoren? :-[
Und bitte beschäftige Dich mit den Grundlagen: Eine peer Verbindung von HM Geräten hat mit FHEM nichts zu tun.
Nichts für ungut, du kannst ja nicht immer alles lesen....
Ursprünglich ging es um virtuelle Aktoren (steht ja auch im Betreff) die nicht gehen (und immer noch nicht gehen) und ich schrieb ja selber das ich erwarte das reale Aktoren funktionieren weil die nicht über FHEM gehen. Und sie funktionieren auch...
Moin chem,
hab nochmal alles gelesen. Sorry ich war der Meinung da war auch mal von Aktoren die Rede, da habe ich was durcheinander gebracht.
Ich habe auch ein HM Modul auf dem Raspberry und ich habe mehrere Taster (den 6 fach und zwei Handtaster) die ich mit Kanälen meiner VCCU gepeert habe, das läuft wie erwartet.
Genau genommen läuft die Quittierung so ab wenn ein Gerät gepairt ist:
Der IO (also zumindest das RPI Modul HMUART oder der HMLAN) quittiert den Empfang eigenständig ohne FHEM(nachdem er von FHEM initialisiert wurde) -> nur Orange + kein rot
Der IO ist nicht erreichbar -> orange dann rot
Der Peer quittiert -> orange(kurz) dann grün
Der peer ist nicht erreichbar -> orange dann rot
Also mit "nur orange" - weiß man der IO hat es bekommen, ob es FHEM bekommen hat ist damit nicht klar, allerdings sollte ja die Aktion von FHEM den sichtbaren Beweis liefern.
Gruß Otto