Autor Thema: HM-MOD-EM-8 und WebCmd press long:press short  (Gelesen 476 mal)

Offline klausg

  • New Member
  • *
  • Beiträge: 22
HM-MOD-EM-8 und WebCmd press long:press short
« am: 14 Oktober 2020, 22:56:53 »
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
« Letzte Änderung: 15 Oktober 2020, 10:17:50 von klausg »

Offline klausg

  • New Member
  • *
  • Beiträge: 22
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #1 am: 15 Oktober 2020, 13:01:04 »
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

Online Otto123

  • Hero Member
  • *****
  • Beiträge: 16638
  • schon mal restore trainiert?
    • Otto's Technik Blog
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #2 am: 15 Oktober 2020, 19:08:40 »
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
« Letzte Änderung: 15 Oktober 2020, 19:11:15 von Otto123 »
Viele Grüße aus Leipzig
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7490+7412,WRT1900ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266

Offline klausg

  • New Member
  • *
  • Beiträge: 22
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #3 am: 15 Oktober 2020, 23:11:15 »
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

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10870
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #4 am: 16 Oktober 2020, 07:00:28 »
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.

Online Otto123

  • Hero Member
  • *****
  • Beiträge: 16638
  • schon mal restore trainiert?
    • Otto's Technik Blog
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #5 am: 16 Oktober 2020, 08:40:12 »
Moin,
Zitat
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.
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
Viele Grüße aus Leipzig
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7490+7412,WRT1900ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266

Offline klausg

  • New Member
  • *
  • Beiträge: 22
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #6 am: 16 Oktober 2020, 19:20:26 »
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

Offline klausg

  • New Member
  • *
  • Beiträge: 22
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #7 am: 17 Oktober 2020, 11:12:57 »
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

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10870
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #8 am: 17 Oktober 2020, 20:09:16 »
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?

Offline klausg

  • New Member
  • *
  • Beiträge: 22
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #9 am: 17 Oktober 2020, 23:49:56 »
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

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10870
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #10 am: 18 Oktober 2020, 09:44:20 »
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.

Offline klausg

  • New Member
  • *
  • Beiträge: 22
Antw:HM-MOD-EM-8 und WebCmd press long:press short
« Antwort #11 am: 18 Oktober 2020, 11:09:45 »
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.
« Letzte Änderung: 18 Oktober 2020, 12:26:02 von klausg »

 

decade-submarginal