Hallo Leute,
ich brauche Eure Hilfe. Ich habe seit mehr als einem Jahr einen HM-MOD-EM-8 als Sensor für Tasten im Gebrauch. Aktuell sind weitere angeschlossene Tasten dazu gekommen und ich habe die Definition in der fhem.cfg überarbeitet. Bisher war das Gerät als model ACTIONDETECTOR mit subType virtual definiert. Das funktionierte zwar, aber das Gerät hat immer mal wieder herumgezickt. Mit der neuen Definition als model HM-MOD-EM-8 und subType virtual funktioniert das Gerät, aber das WeCmd press short oder "set Garage_8Input_Btn1 press short" und ebenso press long führen zu einem Fehler.
Es kommt die Fehlermeldung:
Unknown argument press, choose one of regBulk peerBulk sign:off,noArg,on trgEventS getRegRaw .....
Jetzt habe ich so definiert:
define Garage_8Input CUL_HM 3D6555
setuuid Garage_8Input 5f81b180-f33f-5cd7-0c94-550769363e
attr Garage_8Input .mId no
attr Garage_8Input IODev HMLAN2
attr Garage_8Input autoReadReg 4_reqStatus
attr Garage_8Input expert defReg,rawReg
attr Garage_8Input group Sensoren
attr Garage_8Input model HM-MOD-EM-8
attr Garage_8Input subType remote
attr Garage_8Input webCmd getConfig:clear msgEvents
#
define Garage_8Input_Btn1 CUL_HM 3D655501
setuuid Garage_8Input_Btn1 5f81abdb-f33f-5cd7-74a0-966c77ae2b7
attr Garage_8Input_Btn1 model HM-MOD-EM-8
attr Garage_8Input_Btn1 event-on-change-reading .*
attr Garage_8Input_Btn1 peerIDs 00000000,
attr Garage_8Input_Btn1 room Devices
attr Garage_8Input_Btn1 webCmd press short:press long
#
define Btn2 ... Bnt8
Die Buttons 2-8 sind analog Btn1 definiert.
Was mache ich falsch?
Viele Grüße
Klaus
Update: Ich glaube jetzt verstanden zu haben, dass press long und press short nur bei Aktoren möglich ist, nicht bei Sensoren aka Tasten. Mein Fehler.
Komischerweise hatte es aber funktioniert, als das Gerät mit Model ACTIONDETECTOR definiert war. Weiter ist komisch, dass es einen Unterschied macht ob ich fhem von der Kommandline restarte oder ob ich das Kommand rereadcfg gebe.
$ sudo service fhem restart
> list Garage_8Input
Internals:
CFGFN garage.cfg
DEF 3D6564
FUUID 5f81b180-f33f-5cd7-0c94-550769363e960f32
IODev HMLAN2
NAME Garage_8Input
NOTIFYDEV global
NR 714
NTFY_ORDER 50-Garage_8Input
STATE CMDs_done
TYPE CUL_HM
channel_01 Garage_8Input_Btn1
channel_02 Garage_8Input_Btn2
channel_03 Garage_8Input_Btn3
channel_04 Garage_8Input_Btn4
channel_05 Garage_8Input_Btn5
channel_06 Garage_8Input_Btn6
channel_07 Garage_8Input_Btn7
channel_08 Garage_8Input_Btn8
READINGS:
2020-10-13 12:40:49 D-firmware 1.1
2020-10-13 12:40:49 D-serialNr MEQ0782077
2020-10-14 10:41:24 PairedTo invalid: not supported by FW version
2020-10-13 12:07:53 R-pairCentral 0xF11234
2020-10-14 10:41:24 RegL_00. 00:00
2020-10-13 18:41:08 alive yes
2020-10-14 10:46:10 battery ok
2020-10-14 10:41:34 cfgState ok
2020-10-15 12:00:57 commState CMDs_done
2020-10-13 18:41:08 powerOn 2020-10-13 18:41:08
2020-10-13 18:41:08 recentStateType info
2020-10-15 12:00:57 state CMDs_done
2020-10-15 12:00:57 trigger Long_18
2020-10-15 12:00:14 triggerTo_ServerSchrank.4act1 Short_6_ack
2020-10-15 12:00:57 trigger_cnt 18
helper:
HM_CMDNR 237
mId 0000
peerFriend
peerOpt -:-
regLst
rxType 1
cmds:
TmplKey :no:1602758599.21878
TmplTs 1602758599.21878
cmdKey 0:1:1::Garage_8Input::01:
cmdLst:
assignHmKey noArg
clear (readings|all)
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
raw -data- [...]
reset noArg
tplSet_0 -tplChan-
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
listDevice [({all}|alive|unknown|dead|notAlive)]
param -param-
status noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
IODev HMLAN2
expert defReg,rawReg
group Sensoren
model ACTIONDETECTOR
room Devices
subType virtual
webCmd getConfig:clear msgEvents
und zum Vergleich nach einem rereadcfg:
> list Garage_8Input
Internals:
CFGFN garage.cfg
DEF 3D6564
FUUID 5f81b180-f33f-5cd7-0c94-550769363e960f32
IODev HMLAN2
NAME Garage_8Input
NOTIFYDEV global
NR 714
STATE CMDs_done
TYPE CUL_HM
channel_01 Garage_8Input_Btn1
channel_02 Garage_8Input_Btn2
channel_03 Garage_8Input_Btn3
channel_04 Garage_8Input_Btn4
channel_05 Garage_8Input_Btn5
channel_06 Garage_8Input_Btn6
channel_07 Garage_8Input_Btn7
channel_08 Garage_8Input_Btn8
READINGS:
2020-10-13 12:40:49 D-firmware 1.1
2020-10-13 12:40:49 D-serialNr MEQ0782077
2020-10-14 10:41:24 PairedTo invalid: not supported by FW version
2020-10-13 12:07:53 R-pairCentral 0xF11234
2020-10-14 10:41:24 RegL_00. 00:00
2020-10-13 18:41:08 alive yes
2020-10-14 10:46:10 battery ok
2020-10-14 10:41:34 cfgState ok
2020-10-15 12:00:57 commState CMDs_done
2020-10-13 18:41:08 powerOn 2020-10-13 18:41:08
2020-10-13 18:41:08 recentStateType info
2020-10-15 12:00:57 state CMDs_done
2020-10-15 12:00:57 trigger Long_18
2020-10-15 12:00:14 triggerTo_ServerSchrank.4act1 Short_6_ack
2020-10-15 12:00:57 trigger_cnt 18
helper:
HM_CMDNR 7
mId 00D9
peerFriend
peerOpt -:remote
regLst 0
rxType 16
cmds:
TmplKey :no:1602758750.89665
TmplTs 1602758750.89665
cmdKey 0:1:0::Garage_8Input:00D9:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition closed,open
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3D6564,00,00,00
prefIO
rxt 2
vccu
p:
3D6564
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf 02,03,04,05,06,07,08
qReqStat
role:
dev 1
tmpl:
Attributes:
IODev HMLAN2
autoReadReg 4_reqStatus
expert defReg,rawReg
group Sensoren
model HM-MOD-EM-8
room Devices
subType remote
webCmd getConfig:clear msgEvents
Beim Neustart ist das Gerät ein Model ACTIONDETECTOR mit subType virtual und nach rereadcfg ist es ein Model list Garage_8Input mit subType remote. Die Definition nach dem rereadcfg entspricht der Definition in der Konfig-Datei. Ich verstehe das nicht. Was mache ich falsch? Kennt sich da jemand aus und kann helfen?
Viele Grüße
Klaus
Hallo Klaus,
Du solltest das in Homematic Board verschieben, es ist eine spezielle Frage.
Da sind Kommentare in der cfg, die hast Du also per Hand bearbeitet. Mir klingt das Verhalten, als ob die cfg dabei einen "Fehler" abbekommen hat.
Ein Neustart ist anders in der Abarbeitung als ein rereadcfg. War hier mal beschrieben:
https://forum.fhem.de/index.php?topic=100161.0
Gruß Otto
Hallo Otto,
ich danke Dir für Deine Antwort und den Hinweis. Die Verschiebung ins Homematic Forum habe ich gemacht.
Den von Dir zitierten Thread habe ich gelesen. Ich verstehe, dass es einen Unterschied zwischen Restart von fhem und rereadcfg gibt. Für mich ist ein rereadcfg schneller und fühlt sich unkomplizierter an, wenn man die Seiteneffekte kennt und beherrschen kann. Das sind neben den in Artikel beschriebenen auch, dass nicht gesicherte Änderungen überschrieben werden können. Ist mir schon passiert ;) Bisher dachte ich immer, dass im Zweifel dann immer noch ein Restart hilft um das System vollständig neu zu starten. Aber hier beginnt mein Problem. Die Frage ist warum bei einem Restart von fhem das Device HM-MOD-EM-8 als ein anderes Modell angelegt wird als es in der Config definiert ist. Das ist mir zu hoch.
Viele Grüße
Klaus
Wenn du den Unterschied zwischen reread und restart beherrscht, gut. Bist du dir sicher?
Ich würde am Ende IMMER einen restart testen. Der MUSS funktionieren, sonst besteht ein Problem.
Ein em8 sollte nicht als actiondetector angelegt werden. Macht keinerlei Sinn. Du solltest anlernen drücken, dann erkennt fhem den aktor und legt ihn korrekt an. Bei allem anderen erlischt der Support! ;)
Bei sensor Kanälen gibt es trgPress. Der Ablauf unterscheidet sich.
Virtuelle devices (wie auch der actiondetector einer ist) können sensor und aktor simulieren. Daher sind sonderabläufe implementiert. Beim actiondetector sollte ich es sperren.
Moin,
ZitatDie Frage ist warum bei einem Restart von fhem das Device HM-MOD-EM-8 als ein anderes Modell angelegt wird als es in der Config definiert ist.
Ich würde denken, weil die config irgendwie kaputt ist.
Mach Dir eine zweite (oder temporärer) Instanz zum testen, wie Martin schon sagt, lass das Device von FHEM erzeugen.
Gruß Otto
Ich danke Euch beiden!
In der Definition des Gerätes war einiges falsch. Keine Ahnung warum. Ich paire Geräte immer zuerst mit dem FHEM Server. Dabei erzeugt FHEM die Definition des Geräts. Für das HM-MOD-EM-8 ist das schon gut 1 Jahr her und ich kann mich nicht erinnern ob damals etwas nicht geklappt hatte. Ich habe jetzt das Gerät gelöscht & zurückgesetzt. Danach habe ich alles neu angelegt: Pairing mit FHEM, Peerings der Kanäle ... und Erfolg! Jetzt ist nach einem Restart von FHEM das Device wieder normal als HM-MOD-EM-8 vorhanden. :)
Wenn ich jetzt zwischen der Definition vorher und jetzt die beiden Listings vergleiche fallen mir viele Fehler auf.
.mId no
PairedTo invalid: not supported by FW version
...
trgPress werde ich mir anschauen.
Viele Grüße
Klaus
Ich habe dazu ein paar Verständnisfragen zu trgPress(S|L). Ich verstehe, dass für trgPress die Geräte gepeert sein müssen. Die relevanten Kanäle des HM-MOD-EM-8 sind mit den virtuellen Buttens der VCCU gepeered. Das war schon so, damit die Nachrichten der Buttons direkt zur VCCU gehen. Ich hatte dazu peerChan verwendent und den HM-MOD-EM-8 als Sensor vorne angeben. Ich hatte den HM-MOD-EM-8 als Sensor vorne angeben, weil er den Tastendruck der VCCU senden soll. Ist das richtig oder würde man das anders machen?
Hier mein Befehl dazu:
FHEM> set Garage_8Input_Btn3 peerChan 0 VCCU_Btn1 single set both
Nach getConfig sehe ich, dass bei beiden Geräten sich gegenseitig als peerIDs eingetragen haben. Der VCC_Btn3 hat damit in seiner Befehlsliste auch trgPress(S|L) und ich kann den Peer Garage_8Input_Btn3 aus der Liste auswählen. Garage_8Input_Btn3 kennt zwar auch die trgPress(S|L) Kommandos, aber die Peerliste zur Auswahl ist leer. Was mache ich falsch?
Viele Grüße
Klaus
1) virtuelle Kanäle
Diese können Aktoren oder Sensoren sein. Die Realisierung ist also nicht sauber. Man müsste eigentlich unterscheiden. Da es nicht der Fall ist werden aktor und sensor Kommandos vermischt. Tatsächlich kann ein Kanal beides gleichzeitig sein.
In deinem Fall sollte er die Rolle des Aktors einnehmen.
2) peeren
Das Kommando ist schon korrekt. Generell ist es eine Katastrophe. Ich empfehle peerSmart. Ist eleganter und letztlich verständlicher. Ich nutze peerChan garnicht mehr.
3) trgPress
Ist dazu gedacht eine aktor zu stimulieren. Der aktor arbeitet dann da Programm ab welches eingestellt ist.
Virtuelle Kanäle haben keine Programmierung. Die kannst du einfach mit einem notify anregen.
Da es keinen Sinn macht ist es nicht eingebaut. Virtuelle kanäle werden also nicht über trgPress angesprochen.
Was hättest du als Reaktion erwartet?
Danke für Deine Erklärungen. Ich verwende peerChan weil ich es in https://fhem.de/Heimautomatisierung-mit-fhem.pdf gelesen hatte. Ist peerSmart neuer als das Dokument? Ich hatte peerSmart in der CommandRef gesehen aber noch nie verwendet. Deshalb meine Frage ob ich das richtige Kommando verwende: peerChan, peerSmart oder peerIODev. Manchmal führen verschiede Wege zum Ziel.
Die peerChan Sytax ist:
set <senChan> peerChan 0 <aktChan> single|dual set|unset actor|remote|both
Ich hatte mir überlegt, dass hier der virtuelle Kanal der Aktor sein sollte. Danke für Deine Bestätigung.
Bei trgPress muss ich mich korrigieren. Wie in der CommandRef beschrieben haben beide Kanäle: der Sensor - der Button des HM-MOD-EM-8 und und der virtuelle Actor VCCU_Btn1 im GUI für 'set' die Befehle 'trpPress(S|L)' und in der Auswahlliste die Peers . Ich hatte beim falschen Gerät geschaut.
Wenn ich das set Kommando per GUI oder im CLI ausführe bekomme ich eine Fehlermeldung.
FHEM> set Garage_8Input_Btn1 trgPressS VCCU_Btn1
no target peer found
Der gleiche Fehler kommt mit ausgewähltem Peer oder mit 'all'. Mein Notify für den Button wird nicht getriggert.
Ich habe einen Notify für die Buttons des HM-MOD-EM-8, der nach Long und Short unterscheidet und verschieden Aktionen auslöst. Der Notify funktioniert wenn ich die am HM-MOD-EM-8 angeschlossenen Tasten betätige mit Short und Long. Ich versuche die gleiche Funkion mit Long und Short als webCmd zu bauen. Dann kann ich aus dem GUI heraus die gleiche Aktion auslösen ohne den Notify nachbauen zu müssen.
Viele Grüße
Klaus
PeerSmart ist deutlich neuer. Beide funktionieren.
Smart ist ... smart. Es schlägt sinnvolle peers vor. Keine weiteren Optionen. Kann vom aktor oder sensor ausgeführt werden. Also immer both und single.
Das macht es m.E. für den Anwender einfacher. Es wird schlicht gepeert.
Sinnvoll hierzu ist die anschließende Programmierung mittels template. Also eine abstrakte Definition des gewünschten Verhaltens. Bei Sensoren ist das wenig. Bei aktoren sehr interessant.
Bei trgPress werde ich wohl überlege müssen, wie ich mit virtuellen Aktoren umgehen muss. Da sie aktuell ignoriert werden erscheint er nicht in der dropdown Liste und ist für das Kommando nicht zulässig.
Der virtuelle Aktor ist bei mir in der dropdown Liste. Ich hatte beim ersten Test beim falschen Device geschaut. Der virtuelle Aktor wird beim Kommando ignoriert.