Nachdem ich das mit dem virtuellen Taster probiert habe,
(eigentlich geht es um das: https://wiki.fhem.de/wiki/HM-PB-6-WM55_6fach-Funk-Wandtaster) aber ich wollte erst mal aufräumen.
was nicht funktioniert hat, habe ich den 6 Fach Taster HM-PB-6-WM55 mit dem virtuellen Button der VCCU gepairt.
Devices gelöscht, neu angelernt, neu angelegt und viel probiert und nun scheint da viel Müll rumzufahren.
Der VCCU_Btn1 der VCCU ist nicht mehr gepaired, hat keine peerIDs mehr.
Aber:
Der Channel HM_67B628_Btn_01 ist noch gepaired mit 56162901,VCCU_Btn1, das sind zwei alte virtuelle DEFs, wobei es den ersten nicht mehr gibt und ein
get hm peerCheck
zeigt da auch etwas an:
peer not defined
HM_67B628_Btn_01 id:56162901
HM_67B628_Btn_02 id:56162901
peer not verified. Check that peer is set on both sides
HM_67B628_Btn_01 p:VCCU_Btn1
HM_67B628_Btn_02 p:VCCU_Btn1
Vact_Taster p:HM_67B628_Btn_01
Vact_Taster p:HM_67B628_Btn_02
Nun fleissig gelesen und versucht und das ausgeführt
set HM_67B628_Btn_01 peerBulk AFFECC01 unset (--> AFFECC01 ist die DEF von VCCU_Btn1)
oder
set HM_67B628_Btn_01 peerBulk VCCU_Btn1 unset
aber nix passiert.
auch das probiert:
set HM_67B628_Btn_01 peerChan 0 VCCU_Btn1 single unset
nix passiert.
Ich weiß nicht ob diese Altlasten-Peerings etwas ausmachen, aber ich wollte sie mal aufräumen.
Hi,
du verwechselst permanent pair und peer. Von was Du hier redest ist ausschließlich peer.
Hast Du nach dem set HM_67B628_Btn_01 peerBulk AFFECC01 unset auch den configtaster des HM_67B628 gedrückt um die Datenübertragung zu aktivieren?
Gruß Otto
Ja, korrekt. Peering. Kein Pairing. Bestätige.
Also mit Configtaster meinst Du die Pairing-Taste auf der Rückseite des Schalters oder?
Habe ich gerade noch mal gemacht, leider kein Unterschied.
Bisher habe ich das Peering vermieden, weil es mich zu sehr verwirrt, aber ich würde gerne die Rückmeldung am Schalter sehen mit grünem Licht.
Als ich den Schalter von der Wand genommen habe, habe ich gesehen, dass der olle VCCU_Btn1 auf den taster reagiert hat, also da scheint wirklich etwas ge-peert zu sein.
Readings
trigLast HM_67B628_Btn_02:short 2019-02-24 18:56:34
trig_HM_67B628_Btn_01 Short_15 2019-02-24 08:50:52
trig_HM_67B628_Btn_02 Short_20 2019-02-24 18:56:34
dabei habe ich auch gesehen, dass es der Einfach taster ist den ich da peere:
HM-PB-2-WM55
:-)
Das sollte aber kein Unterschied machen, wobei da in der Doku steht
https://wiki.fhem.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster
set virtueller_Aktor virtual 2
Bie dem 6 Fach Taster steht set virtueller_Aktor virtual 1
Ist das der Knackpunkt?
Wobei ich erst noch das Peering mit dem VCCU_Btn1 aufräumen wollte, bevor ich das richtige Peering mit dem Virtuellen Aktor mache.
Du kannst Deine Taste ja nennen wie Du willst, aber: Damit jeder jeden versteht, müssen wir uns auf eine gemeinsame Sprache einigen.
Der Taster auf der Rückseite ist die Anlerntaste, so steht es im Handbuch. Allgemein wird hier immer vom Configtaster gesprochen.
Das Wiki ist nicht die Doku!
Der peerBulk Befehl erzeugt eine Nachricht an den Taster, damit dieser die empfängt, verarbeitet und antwortet. Muss er aktiviert werden. Normalerweise mit der mit der Configtaste. Dabei bedeutet Configtaste drücken nicht einfach Taste drücken, sondern im Handbuch steht jeweils wir gedrückt werden muss! Im Falle des 6 fach Tasters ist es wirklich ein kurzer Druck.
Die Übertragung kann durch blinken der LED und durch die Nachrichten im Hauptgerät (Internal protState) überwacht werden. Auch hmInfo protoEvents hilft.
Solange der Peer existiert, kannst Du besser mit peerChan das unpeering machen.
set virtueller_Aktor virtual 2
erzeugt zwei virtuelle Kanäle.
set virtueller_Aktor virtual 1
erzeugt einen Virtuellen Kanal.
Gruß Otto
ok, habe nochmal die Anlerntaste / configtaste gedrückt nach dem senden von
set HM_67B628_Btn_01 peerChan 0 VCCU_Btn1 single unset
im
hmInfo protoEvents
ist:
Zitat
protoEvents send to devices done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
HM_653B50_SERVER : done | - | 11 | - # - | - | - | -
HM_6621B3_FRIDGE : done | - | 79 | - # - | - | - | -
HM_67B628 : pending | 5 pending| 60 | 7 # 99 | 1 | - | -
Leider verstehe ich nicht welche Aktionen ich aus dem Check ableiten kann / soll:
Zitatpeer not defined
HM_67B628_Btn_01 id:56162901
HM_67B628_Btn_02 id:56162901
peer not verified. Check that peer is set on both sides
HM_67B628_Btn_01 p:VCCU_Btn1
HM_67B628_Btn_02 p:VCCU_Btn1
Vact_Taster p:HM_67B628_Btn_01
Vact_Taster p:HM_67B628_Btn_02
ok, das eigentliche Problem aus dem Betreff ist gelöst. Der HM Peer Check ist leer, sieht gut aus.
Die Buttons HM_67B628_Btn_01 und HM_67B628_Btn_02 sind beidseitig mit Vact_taster ge-peered.
Man muss nur am Richtigen Schalter / Gerät den Configtaster drücken. Und man muss alle Peerings unsetten. Öh, Übersicht verloren ???
Unklar ist, ob das etwas zu bedeuten hat:
ZitatconfigCheck done:
missing register list
HM_67B628: RegL_00.
HM_67B628_Btn_01: RegL_01.,RegL_04.Vact_Taster
HM_67B628_Btn_02: RegL_01.,RegL_04.Vact_Taster
no IO device assigned
Vact_dev
Das funktioniert zwar immer noch nicht mit dem virtuellen Taster, dass man eine Rückmeldung bekommt.
Der
HM_67B628 steht auf
CMDs_pendingDaher versuche ich diese frage auf den Betreff einzuschränken.
Der
6Fach (HM-PB-6-WM55) und der
2Fach (HM-PB-2-WM55) Schalter von Homematic werden für ein Aus/An Tastenpaar irgendwie unterschiedlich behandelt:
https://wiki.fhem.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster
set LichtFlur1 peerChan 0 virtueller_Aktor_Btn1 single set
set LichtFlur2 peerChan 0 virtueller_Aktor_Btn2 single set
https://wiki.fhem.de/wiki/HM-PB-6-WM55_6fach-Funk-Wandtaster
set BA_Taster_Btn_01 peerChan 0 Vact_Taster single set
set BA_Taster_Btn_02 peerChan 0 Vact_Taster single set
Beim 6er werden zwei Tasten mit nur einem virtuellen Taster ge-peered
Beim 2er sind es zwei tasten des virtuellen Tasters.
ist das Absicht oder egal, kann man auch alles auf einen channel peeren? ich glaube das im Forum gelesen zu haben.
Ich habe auch den ersten virtuellen Channel wiedervendet, da nicht klar ist, ob man für jedes HM device ein neuer channel angelegt werden soll. Es steht nur da, dass man kein neues virtuelles device für jedes Hm Gerät benötigt.
Moin,
das peeren mit dem virtuellen Aktor erfüllt ja unter Umständen einen unterschiedlichen Zweck. Im Wiki schreiben auch unterschiedliche Leute. ;D
Für nur "grünes Licht" kann man alle mit einem virtuellen Channel peeren. Will man andere Dinge tun kann man jeden Taster mit jeweils einem virtuellen Channel peeren.
Vact_dev hat keinen IO das ist kritisch! Deshalb funktioniert der nicht. Da musst Du in den Attributen die IOgrp und IODev nachtragen.
Beim HM_67B628 reicht eventuell Configtaster drücken. Oder nochmal getConfig absetzen und dann Configtaster drücken oder set clear msgEvents dann getConfig und dann Taster drücken.
Gruß Otto
Guten morgen,
Also das mit dem IOgrp und IODev am Vact_dev mache ich mal SWM (sobald wie möglich).
Allerdings bin ich auch nur der Anleitung
https://wiki.fhem.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster Mit virtuellem Aktor verbinden
https://wiki.fhem.de/wiki/HM-PB-6-WM55_6fach-Funk-Wandtaster Mit virtuellem Aktor verbinden
gefolgt.
Ist da was bei mir schief gegangen oder sollte das von jemand mit dem notwendigen Detailwissen im Wiki ergänzt werden?
Dass da kein IO ist hatte ich mal bemerkt, aber davon steht ja auch nirgendwo etwas.
Grüße, Frood
Hallo Frood,
jein ::)
eigentlich sollte das automatisch beim define passieren. Aber aus irgendeinem Grund gibt es in letzter Zeit ein Problem mit IODev bei der Anlage von den virtuellen Geräten.
Das virtuelle Gerät (nur das Hauptgerät nicht der Channel) braucht ja einen IO sonst kann er nicht senden.
Gruß Otto
all right.
Also automatisch wird das nicht angelegt, ich habe die virtuellen Dinger ziemlich oft angelegt.
Beim Rauchmelder steht dabei dass man darauf achten soll dass das Attribut (attr) IODev bzw. IOgrp gesetzt ist.
https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder
Und IODEv kann [HMLAN/HMUSB/CUL] sein?
Oder was sollte man für einen virtuellen Taster eintragen?
Danke und Grüße, Frood
IODev wird automatisch (sollte vom FHEM System ...) eingetragen. Das ist der HMLAN usw...
Wenn Du ein VCCU hast reicht es IOgrp mit dem Namen der VCCU einzutragen. Die regelt alles weitere.
Den Nachtrag beim SEC-SD habe ich mal gemacht. Ich werde das in den beiden Wikis mal ergänzen, oder am Besten einen zentralen Eintrag machen.
Wie gesagt, eigentlich geht es automatisch. Aber Martin hat glaube ich relativ viele Baustellen...
Gruß Otto
Okay, das mit dem configCheck und peerCheck sieht jetzt super aus, das initiale problem ist gelöst.
IODev ist gesetzt beim Vact_dev nachdem ich die IOgrp eingetragen habe mit
attr <device> IOgrp VCCU:<PhysischesIO>
(wobei gar kein IOgrp mehr zu sehen ist.. leicht verwirrend um ehrlich zu sein)
Die Taster zeigen auch immer noch nicht grün nach Betätigung, aber das ist jetzt wohl ein anderes Kapitel.
Danke, Frood
Zitat von: Frood42 am 25 Februar 2019, 20:24:49
(wobei gar kein IOgrp mehr zu sehen ist.. leicht verwirrend um ehrlich zu sein)
Zeig dafür mal bitte ein komplettes list.
Gruß Otto
list Vact_dev
Zitat
Internals:
DEF 332211
FUUID 5c71d735-f33f-9562-2647-1b3de2c53bc248d3
IODev HMGW1
NAME Vact_dev
NOTIFYDEV global
NR 177
NTFY_ORDER 50-Vact_dev
STATE CMDs_done
TYPE CUL_HM
channel_01 Vact_Taster
channel_02 Vact_2Taster
protSnd 12 last_at:2019-02-25 18:07:52
protState CMDs_done
CHANGED:
CMDs_done
CHANGEDWITHSTATE:
READINGS:
2019-02-25 18:07:52 state CMDs_done
helper:
HM_CMDNR 94
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
io:
HMGW1:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
Attributes:
IODev HMGW1
expert 2_raw
model virtual_2
subType virtual
webCmd virtual
Und ein Taster davon gepeered:
list Vact_Taster
Zitat
Internals:
DEF 33221101
FUUID 5c71d740-f33f-9562-07b5-4ea4a22000fd21ee
NAME Vact_Taster
NOTIFYDEV global
NR 178
NTFY_ORDER 50-Vact_Taster
STATE ON
TYPE CUL_HM
chanNo 01
device Vact_dev
peerList HM_67B628_Btn_01,HM_67B628_Btn_02,
READINGS:
2019-02-25 17:56:14 peerList HM_67B628_Btn_01,HM_67B628_Btn_02,
2019-02-25 18:07:51 state ON
2019-02-25 18:07:51 trigLast HM_67B628_Btn_01:long
2019-02-25 18:07:51 trig_HM_67B628_Btn_01 Long_26
2019-02-25 17:58:00 trig_HM_67B628_Btn_02 Short_23
2019-02-25 18:07:51 virtActState ON
2019-02-25 18:07:51 virtActTrigNo 26
2019-02-25 18:07:51 virtActTrigRpt 1
2019-02-25 18:07:51 virtActTrigType long
2019-02-25 18:07:51 virtActTrigger HM_67B628_Btn_01
helper:
trgLgRpt 1
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
shadowReg:
tmpl:
Attributes:
model virtual_1
peerIDs 67B62801,67B62802,
webCmd press short:press long
Moin,
warum hast Du die list in Zitate und nicht in Codetgas gepackt?
Eigentlich sieht das nicht schlecht aus. Ein attr Vact_dev IOgrp VCCU
hattest Du gemacht? Und das ist verschwunden sagst Du? Wäre ja eigenartig.
Gruß Otto
Ich weiß nicht, das mit den CodeTags und Zitaten verwende ich immer irgendwie, dass es irgendwie strukturiert aussieht.
Ja, ein
attr <device> IOgrp VCCU:<PhysischesIO>
konkret
attr Vact_dev IOgrp VCCU:HMGW1
Hatte ich gemacht.
Kann sein, dass ich es einmal mit nur mit VCCU gemacht habe, nochmal gelöscht und dann nochmal mit VCCU:HMGW1 gemacht habe
Dadurch kam dann auch das IODev zu Tage, aber das "grp" war nie da.
Kann es nachher noch mal probieren / wiederholen.
Interessant. Nach wiederholung des o.g. commands nach dem Löschen des IODev Attributes steht das nun da:
Attributes:
IOgrp VCCU:HMGW1
Da ist ein deutlicher Unterschied.
Ich habe es auch so angelegt
attr Vact_dev IOgrp VCCU:HMGW1
und nicht nur so
attr Vact_dev IOgrp VCCU
Internals:
DEF 332211
FUUID 5c71d735-f33f-9562-2647-1b3de2c53bc248d3
IODev HMGW1
NAME Vact_dev
NOTIFYDEV global
NR 177
NTFY_ORDER 50-Vact_dev
STATE CMDs_done
TYPE CUL_HM
channel_01 Vact_Taster
channel_02 Vact_2Taster
protSnd 12 last_at:2019-02-25 18:07:52
protState CMDs_done
CHANGED:
CMDs_done
CHANGEDWITHSTATE:
READINGS:
2019-02-25 18:07:52 state CMDs_done
helper:
HM_CMDNR 94
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
vccu VCCU
prefIO:
HMGW1
mRssi:
mNo
io:
HMGW1:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
Attributes:
IOgrp VCCU:HMGW1
expert 2_raw
model virtual_2
subType virtual
webCmd virtual
Ein wichtiger Unterschied zwischen Code und Zitat Block ist dass der Code Block scrollt!
ZitatEin wichtiger Unterschied zwischen Code und Zitat Block ist dass der Code Block scrollt!
genau :)