Verwendung von Templates

Begonnen von Hermann20, 12 Januar 2015, 18:06:51

Vorheriges Thema - Nächstes Thema

Hermann20

Guten Abend,

ich möchte gerne einen HM-Sen-MDIR-O-2 in Verbindung mit einem HM-LC-Sw1-BA-PCB verwenden.
Beide Devices sind mit meinem CUL gepaired. Anschließend habe ich sie gepeert:
set HM_Sen_MDIR_O_2_2EF36A peerChan 0 SW1_1 single

Zum Abschluss wollte ich das Template motionOnSw verwenden. Ein get hm templateList sagt, dass es vorhanden ist.
Folgendes Kommando führt zur Fehlermeldung: "template undefined motionOnSw"
set hm templateSet SW1_1 motionOnSw  HM_Sen_MDIR_O_2_2EF36A:short 20 30

Könnte mir bitte jemand einen Hinweis geben, was ich da falsch mache?

Beide Devices funktionieren getrennt betrachtet. Sie kommunizieren mit dem CUL und ich kann über FHEM den Schalter betätigen. Wenn der Bewegungsmelder auslöst, schaltet der Schalter ein, löst er das zweite Mal nach Ablauf der im Bewegungsmelder eingestellten Zeit aus, so schaltet der Schalter aus. Mir ist zwar klar, da steht etwas im Schalter noch falsch, er toggelt und macht kein on for .., aber warum kann ich das Template nicht verwenden? (wie ich meine es verstanden zu haben)

Gruß Hermann
NUC12i3, Proxmox VE, Ubuntu 24.04, FHEM (aktuell): 2 HMUART, ca. 50 HM Devices, ca. 10 Devices über MQTT, 4 DECT200 über FBAHAHTTP, Heizungssteuerung über RS232, HMCCU, Telegram
CCU3, RaspberryMatic (aktuell): ca. 10 HmIP Devices

martinp876

das sollte funktionieren. jedenfalls nicht mit dem Fehler abbrechen.
was sagt ein
get hm templateList
da sollte  es auftauchen

Hermann20

Herzlichen Dank für die Antwort.
Das Template tauchte, wie oben beschrieben, auch Anfang der Woche in der Liste auf.
Heute habe ich ein Update durchgeführt und kann motionOnSw nun ohne Fehlermeldung aufrufen. (Keine Ahnung warum, möglicherweise doch verschrieben, oder ...)

Die Kombination Bewegungsmelder - Schalter macht allerdings nicht ansatzweise was ich erwarte. Wahrscheinlich habe ich durch meine Fehlversuche nun einen Zustand, wo nichts mehr geht.

Ist folgender Gedankengang für den nächsten Versuch eigentlich korrekt, oder habe ich da auch schon etwas falsch verstanden?

  • Beide Devices in den Auslieferzustand versetzen
  • Devices mit CUL pairen
  • Devices miteinander peeren
  • Template motionOnSw aufrufen
  • Ergebnis: Ist die Schwelle unterschritten und es bewegt sich etwas, so wird der Schalter für die vorgegebene Zeit eingeschaltet
Gruß Hermann
NUC12i3, Proxmox VE, Ubuntu 24.04, FHEM (aktuell): 2 HMUART, ca. 50 HM Devices, ca. 10 Devices über MQTT, 4 DECT200 über FBAHAHTTP, Heizungssteuerung über RS232, HMCCU, Telegram
CCU3, RaspberryMatic (aktuell): ca. 10 HmIP Devices

martinp876

das pairing sollte noch stehen (du kannst dich mit beiden unterhalten?)

dann kannst du einfach peeren. beim Peeren werden die peering-register auf einen default zurückgesetzt.
dann das template ausführen.
dann sollte es kappen.
wenn nicht, schicke einmal die Register - am übersichtlichsten, wenn du sie mit HMInfo darstellst

Hermann20

Danke für die Antwort und Deine Geduld.

Die Kommunikation der beiden Devices mit FHEM funktioniert, der Bewegungsmelder sendet, den Schalter kann ich betätigen. Wenn ich es richtig interpretiere, sind sie auch gepeert.

Das Template habe ich so aufgerufen:
set hm templateSet SW1_1 motionOnSw HM_Sen_MDIR_O_2_2EF36A:short 20 30

Hier die Register:HM_Sen_MDIR_O_2_2EF36A type:motionDetector -
list:peer register         :value
   0:      pairCentral      :0x0815AC
   1:      brightFilter     :7
   1:      captInInterval   :off
   1:      evtFltrNum       :1
   1:      evtFltrPeriod    :1 s
   1:      ledOnTime        :0 s
   1:      minInterval      :240
   4:SW1_1_chn:01 peerNeedsBurst   :off


SW1_1 type:switch -
list:peer register         :value
   0:      intKeyVisib      :invisib
   0:      ledMode          :off
   0:      lowBatLimitBA    :10.5 V
   0:      pairCentral      :0x0815AC
   1:      sign             :off
                       HM_Sen_MDIR_O_2_2EF36A_chn:01
                       lg              sh
ActionType             jmpToTarget     jmpToTarget
CtDlyOff               geLo            ltLo
CtDlyOn                geLo            ltLo
CtOff                  geLo            ltLo
CtOn                   geLo            ltLo
CtValHi                100             100
CtValLo                50              30
MultiExec              on
OffDly            [s]  0               0
OffTime                unused          unused
OffTimeMode            absolut         absolut
OnDly             [s]  0               0
OnTime            [s]  unused          20
OnTimeMode             absolut         absolut
SwJtDlyOff             off             dlyOn
SwJtDlyOn              on              on
SwJtOff                dlyOn           dlyOn
SwJtOn                 dlyOff          on
SW4_1 type:switch -
list:peer register         :value
   0:      intKeyVisib      :visib
   0:      ledMode          :off
   0:      localResDis      :off
   0:      pairCentral      :0x0815AC


Der Schalter rührt sich bei Bewegung leider nicht.

Gruß Hermann
NUC12i3, Proxmox VE, Ubuntu 24.04, FHEM (aktuell): 2 HMUART, ca. 50 HM Devices, ca. 10 Devices über MQTT, 4 DECT200 über FBAHAHTTP, Heizungssteuerung über RS232, HMCCU, Telegram
CCU3, RaspberryMatic (aktuell): ca. 10 HmIP Devices

martinp876

was eingestellt ist:
kommt ein short trigger von HM_Sen_MDIR_O_2_2EF36A_chn:01 mit level kleiner 30 wird aggiert.

vom mdir kommen nur short trigger. long gibt es nicht.
wenn nun also ein entsprechender Trigger kommt wird gemäß plan wird auf on geschaltet. die Zeit ist auf 2sec begrenzt.

wenn der BM auslösst solltest du einen entsprechenden trigger - mit einem Level kleiner 30 bekommen. Trigger größer 30 werden ignoriert.
Welcher trigger kommt also?

Hermann20

Danke für die Erläuterung. Ich bin derzeit im Urlaub und komme daher nicht dran. Aus der Erinnerung vermute ich, dass ich mich oberhalb von 30 bewege. Werde mich in einigen Tagen melden.
Gruß Hermann
NUC12i3, Proxmox VE, Ubuntu 24.04, FHEM (aktuell): 2 HMUART, ca. 50 HM Devices, ca. 10 Devices über MQTT, 4 DECT200 über FBAHAHTTP, Heizungssteuerung über RS232, HMCCU, Telegram
CCU3, RaspberryMatic (aktuell): ca. 10 HmIP Devices

Hermann20

Hallo,

ich habe den Level nun höher (auf 120) gestellt. Er war zu niedrig, der BM liegt noch auf dem Schreibtisch, daher ist es relativ hell. Aber ich bekomme das Ganze nicht hin, der Schalter rührt sich nicht.

FHEM ist aktuell und es gibt keine Fehlermeldungen beim configCheck.

Aufruf des Templates mit:
set hm templateSet SW1_1 motionOnSw HM_Sen_MDIR_O_2_2EF36A:short 300 120

Der BW sendet bei Bewegung:
2015-01-29_17:21:37 HM_Sen_MDIR_O_2_2EF36A trigger_cnt: 144
2015-01-29_17:21:37 HM_Sen_MDIR_O_2_2EF36A motion
2015-01-29_17:21:37 HM_Sen_MDIR_O_2_2EF36A motion: on (to SW1_1)
2015-01-29_17:21:37 HM_Sen_MDIR_O_2_2EF36A motionCount: 144_next:116s
2015-01-29_17:21:37 HM_Sen_MDIR_O_2_2EF36A brightness: 112


Der Schalter sieht für mich gut aus: shOnTime 300 s, shCtValLo 120

Zur Vollständigkeit ein List vom Schalter:
Internals:
   CFGFN      /opt/fhem/FHEM/Schalter.cfg
   CUL_0_MSGCNT 27
   CUL_0_RAWMSG A0D1CA4102E14810815AC06010000::-65.5:CUL_0
   CUL_0_RSSI -65.5
   CUL_0_TIME 2015-01-29 17:27:17
   DEF        2E1481
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     27
   NAME       SW1_1
   NR         118
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:1C - t:10 s:2E1481 d:0815AC 06010000
   peerList   HM_Sen_MDIR_O_2_2EF36A,
   protCmdDel 2
   protLastRcv 2015-01-29 17:27:17
   protResnd  1 last_at:2015-01-29 17:26:22
   protResndFail 1 last_at:2015-01-29 17:26:26
   protSnd    37 last_at:2015-01-29 17:27:17
   protState  CMDs_done
   rssi_CUL_0 avg:-60.5 min:-61 max:-60 lst:-61 cnt:2
   rssi_at_CUL_0 avg:-63.64 min:-76.5 max:-60.5 lst:-65.5 cnt:27
   Readings:
     2015-01-29 17:07:40   CommandAccepted yes
     2015-01-18 17:04:24   D-firmware      1.6
     2015-01-18 17:04:24   D-serialNr      LEQ0771371
     2015-01-29 17:26:16   PairedTo        0x0815AC
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgActionType jmpToTarget
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgCtDlyOff geLo
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgCtDlyOn geLo
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgCtOff geLo
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgCtOn geLo
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgCtValHi 100
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgCtValLo 50
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgMultiExec on
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgOffDly 0 s
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgOffTime unused
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgOffTimeMode absolut
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgOnDly 0 s
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgOnTime unused
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgOnTimeMode absolut
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgSwJtDlyOff off
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgSwJtDlyOn on
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgSwJtOff dlyOn
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-lgSwJtOn dlyOff
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shActionType jmpToTarget
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shCtDlyOff ltLo
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shCtDlyOn ltLo
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shCtOff ltLo
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shCtOn ltLo
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shCtValHi 100
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shCtValLo 120
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shOffDly 0 s
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shOffTime unused
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shOffTimeMode absolut
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shOnDly 0 s
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shOnTime 300 s
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shOnTimeMode absolut
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shSwJtDlyOff dlyOn
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shSwJtDlyOn on
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shSwJtOff dlyOn
     2015-01-29 17:26:11   R-HM_Sen_MDIR_O_2_2EF36A_chn-01-shSwJtOn on
     2015-01-18 16:57:29   R-intKeyVisib   invisib
     2015-01-04 16:10:33   R-ledMode       off
     2015-01-18 16:57:29   R-lowBatLimitBA 10.5 V
     2015-01-18 16:57:29   R-pairCentral   0x0815AC
     2015-01-04 16:10:33   R-sign          off
     2015-01-29 17:26:16   RegL_00:          02:01 05:00 0A:08 0B:15 0C:AC 12:69  00:00
     2015-01-29 17:27:17   battery         ok
     2015-01-29 17:27:17   deviceMsg       off (to CUL_0)
     2015-01-29 17:27:17   level           0
     2015-01-29 17:27:17   pct             0
     2015-01-29 17:26:10   peerList        HM_Sen_MDIR_O_2_2EF36A,
     2015-01-29 17:25:56   powerOn         2015-01-29 17:25:55
     2015-01-29 17:27:17   recentStateType info
     2015-01-29 17:27:17   state           off
     2015-01-29 17:27:17   timedOn         off
     Regl_01::
       VAL
   Helper:
     cSnd       010815AC2E148101040000000001
     dlvlCmd    ++A0110815AC2E14810201000000
     getCfgList all
     getCfgListNo ,3
     mId        006C
     peerIDsRaw ,2EF36A01,00000000
     rxType     2
     Io:
       newChn     +2E1481,00,01,00
       nextSend   1422548837.55209
       prefIO
       rxt        0
       vccu
       p:
         2E1481
         00
         01
         00
     Mrssi:
       mNo        1C
       Io:
         CUL_0      -63.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       prs        1
     Rpt:
       IO         CUL_0
       flg        A
       ts         1422548837.46209
       ack:
         HASH(0x159eae8)
         1C80020815AC2E148100
     Rssi:
       Cul_0:
         avg        -60.5
         cnt        2
         lst        -61
         max        -60
         min        -61
       At_cul_0:
         avg        -63.6481481481481
         cnt        27
         lst        -65.5
         max        -60.5
         min        -76.5
     Shadowreg:
Attributes:
   IODev      CUL_0
   actStatus  dead
   alias      SW1
   autoReadReg 5_readMissing
   expert     2_full
   firmware   1.6
   model      HM-LC-SW1-BA-PCB
   msgRepeat  1
   peerIDs    00000000,2EF36A01,
   room       Schalter
   serialNr   LEQ0771371
   subType    switch
   webCmd     statusRequest:on:off


Irgend etwas muss das falsch sein, es funktioniert nicht und finde den Fehler einfach nicht.

Vielen Dank im voraus,
Hermann
NUC12i3, Proxmox VE, Ubuntu 24.04, FHEM (aktuell): 2 HMUART, ca. 50 HM Devices, ca. 10 Devices über MQTT, 4 DECT200 über FBAHAHTTP, Heizungssteuerung über RS232, HMCCU, Telegram
CCU3, RaspberryMatic (aktuell): ca. 10 HmIP Devices

martinp876

sieht eigentlich gut aus.
der SW ist mit dem MDIR gepeert. ist das auch umgekehrt der Fall?

Hermann20

Hallo,

ich habe mich noch einmal mit meinem Problem beschäftigt.

Zitat von: martinp876 am 31 Januar 2015, 14:36:04
sieht eigentlich gut aus.
der SW ist mit dem MDIR gepeert. ist das auch umgekehrt der Fall?
Ja, ist der Fall.

Nach einigen weiteren erfolglosen Versuchen mit dem Einkanalschalter habe ich das Ganze mit einem HM-LC-Sw4-Ba probiert. (Peer mit SW1 gelöst, Peer mit SW4 durchgeführt, Template aufgerufen.)

Ergebnis: Funktioniert auf Anhieb! Ich habe keine Ahnung warum. Aber egal, wenn der BM erst über der Haustür hängt, soll er mit einem UP-Schalter reden. Mal abwarten, wie das funktioniert. Ich werde berichten.

Gruß Hermann

NUC12i3, Proxmox VE, Ubuntu 24.04, FHEM (aktuell): 2 HMUART, ca. 50 HM Devices, ca. 10 Devices über MQTT, 4 DECT200 über FBAHAHTTP, Heizungssteuerung über RS232, HMCCU, Telegram
CCU3, RaspberryMatic (aktuell): ca. 10 HmIP Devices