autocreate unvollständig

Begonnen von Rollo_Wikinger, 21 Januar 2023, 19:11:55

Vorheriges Thema - Nächstes Thema

Rollo_Wikinger

Moin,
habe einen HM-Sen-MDIR-O-3 angelernt, Ergebnis:

define HM_XXXXXX CUL_HM XXXXXX
setuuid HM_XXXXXX 63c317a9-f33f-64c4-30a1-f8c6aaf5a6bac819
attr HM_XXXXXX room CUL_HM
define FileLog_HM_XXXXXX FileLog ./log/HM_XXXXXX-%Y.log HM_XXXXXX
setuuid FileLog_HM_XXXXXX 63c317a9-f33f-64c4-e0cb-a2c016fb503fa249
attr FileLog_HM_XXXXXX logtype text
attr FileLog_HM_XXXXXX room CUL_HM

Meine Recherchen in Doku, Wiki und Forum haben ergeben, dass doch mindestens mal IODev fehlt, oder?
Komisch ist, der Sender scheint trotzdem zu funktionieren, jedenfalls liefert er move, battery, brightness usw. im Logfile.
Irgendjemand eine Idee?
RPi 1 Model B|HM-MOD-RPI-PCB|1x HM-LC-Bl1-FM|3x HM-LC-Bl1PBU-FM|2x HM-LC-Sw1-PI-DN-R1|1x HM-PB-2-WM55-2|1x HM-LC-Sw1-FM

frank

gepairt hast du jedenfalls nicht.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Rollo_Wikinger

Habe trotzdem mal einen rename gemacht, und siehe da:
define FDO_MotDet CUL_HM XXXXXX
setuuid FDO_MotDet 63c317a9-f33f-64c4-30a1-f8c6aaf5a6bac819
attr FDO_MotDet .mId 010A
attr FDO_MotDet IODev HmUART1
attr FDO_MotDet autoReadReg 4_reqStatus
attr FDO_MotDet expert rawReg
attr FDO_MotDet firmware 1.7
attr FDO_MotDet model HM-SEN-MDIR-O-3
attr FDO_MotDet room CUL_HM
attr FDO_MotDet serialNr QEQXXXXXXX
attr FDO_MotDet subType motionDetector
define FileLog_FDO_MotDet FileLog ./log/FDO_MotDet-%Y.log FDO_MotDet
setuuid FileLog_FDO_MotDet 63c317a9-f33f-64c4-e0cb-a2c016fb503fa249
attr FileLog_FDO_MotDet logtype text
attr FileLog_FDO_MotDet room CUL_HM
RPi 1 Model B|HM-MOD-RPI-PCB|1x HM-LC-Bl1-FM|3x HM-LC-Bl1PBU-FM|2x HM-LC-Sw1-PI-DN-R1|1x HM-PB-2-WM55-2|1x HM-LC-Sw1-FM

frank

Zitatund siehe da
8) deine beiträge sind für mich ein wenig rätselhaft.
pairing funktioniert jedenfalls nicht über rename.

aussagekräftigere infos liefert in der regel ein "list" der devices.
du musst grundsätzlich unterscheiden zwischen "anlegen eines devices" und "pairen eines devices".
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Rollo_Wikinger

#4
Tut mir leid, ich werde versuche, etwas ausführlicher zu schreiben, also:
Bisher habe ich immer die Zentrale mittels hmPairForSec in den Anlernmodus gebracht, dann den Knopf am Gerät gedrückt und autocreate hat den Rest gemacht, d. h. alle Einträge vollständig in die fhem.cfg eingetragen.
Danach konnte ich das Gerät immer einwandfrei benutzen, also ging ich davon aus, dass autocreate auch das Pairing gleich miterledigt hat, ist dem nicht so?

Zuletzt hat das jedoch zwei-/dreimal nicht geklappt, es kommen nur die Einträge im ersten Post zustande. Anschließend rename  und fhem.cfg sieht aus wie in meinem zweiten Post. Ein HM-LC-Bl1-FM funktioniert seitdem auch einwandfrei, mit dem HM-Sen-MDIR-O-3 bin ich noch nicht ganz so weit, um das abschließend zu beurteilen (aber wie gesagt, er liefert zumindest Messwerte).

Die einzige Erklärung, die ich hätte, wäre, dass ich vor einiger Zeit von einem HM-CFG-LAN auf HM-MOD-RPI-PCB gewechselt bin - arbeiten die beiden unterschiedlich bei autocreate?

Hier der list, meine Kenntnisse reichen aber nicht, um daraus zu beurteilen, ob erfolgreich gepairt oder nicht:
Internals:
   DEF        XXXXXX
   FUUID      63c317a9-f33f-64c4-30a1-f8c6aaf5a6bac819
   HmUART1_MSGCNT 57
   HmUART1_RAWMSG 05000034818441XXXXXX00000001800080
   HmUART1_RSSI -52
   HmUART1_TIME 2023-01-28 18:15:07
   IODev      HmUART1
   LASTInputDev HmUART1
   MSGCNT     57
   NAME       FDO_MotDet
   NR         146
   NTFY_ORDER 48-FDO_MotDet
   STATE      motion
   TYPE       CUL_HM
   chanNo     01
   disableNotifyFn 1
   lastMsg    No:81 - t:41 s:XXXXXX d:000000 01800080
   protLastRcv 2023-01-28 18:15:07
   protRcv    57 last_at:2023-01-28 18:15:07
   rssi_at_HmUART1 cnt:57 min:-65 max:-45 avg:-48.77 lst:-52
   READINGS:
     2023-01-14 21:59:22   D-firmware      1.7
     2023-01-14 21:59:22   D-serialNr      QEQnnnnnnn
     2023-01-25 20:58:23   IODev           HmUART1
     2023-01-28 18:15:07   battery         ok
     2023-01-28 18:15:07   brightness      0
     2023-01-14 21:59:22   cfgState        updating
     2023-01-14 21:59:22   commState       CMDs_pending
     2023-01-28 18:15:07   motion          on (to broadcast)
     2023-01-28 18:15:07   motionCount     128_next:240s
     2023-01-28 17:02:31   motionDuration  242
     2023-01-28 18:15:07   state           motion
     2023-01-28 18:15:07   trigger_cnt     128
   helper:
     HM_CMDNR   129
     lastMsgTm  1674926107.70916
     mId        005D
     moStart    1674926107.70916
     peerFriend peerAct,peerVirt
     peerOpt    4:motionDetector
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     cmds:
       TmplKey    :no:1674676703.80225
       TmplTs     1674676703.80225
       cmdKey     1:1:0::FDO_MotDet:005D:01:
       cmdLst:
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   -btnNumber- -actChn- [({single})] [({set}|unset)] [actor|remote|both]
         peerSmart  -peerOpt-
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sign       [(on|{off})]
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         trgEventL  -peer- -condition-
         trgEventS  -peer- -condition-
         trgPressL  [(-peer-|{all})]
         trgPressS  [(-peer-|{all})]
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt    ATT_Circ,BR0_Lamp_Mirror
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       flgs       2
       newChn     +XXXXXX,02,00,00
       nextSend   1674926107.80108
       rxt        2
       vccu       
       p:
         XXXXXX
         00
         00
         00
       prefIO:
     mRssi:
       mNo        81
       io:
         HmUART1:
           -46
           -46
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_HmUART1:
         avg        -48.7719298245614
         cnt        57
         lst        -52
         max        -45
         min        -65
     tmpl:
Attributes:
   IODev      HmUART1
   autoReadReg 4_reqStatus
   expert     rawReg
   firmware   1.7
   model      HM-SEN-MDIR-O-3
   room       CUL_HM
   serialNr   QEQnnnnnnn
   subType    motionDetector
RPi 1 Model B|HM-MOD-RPI-PCB|1x HM-LC-Bl1-FM|3x HM-LC-Bl1PBU-FM|2x HM-LC-Sw1-PI-DN-R1|1x HM-PB-2-WM55-2|1x HM-LC-Sw1-FM

frank

vorweg:
das unkenntlichmachen der hmid ist völlig überflüssig.
ein list lässt sich viell, viel besser lesen, wenn es mit code-tags formatiert ist.
ist dein fhem up-to-date?

der bm ist noch nicht gepairt.
also erneut drüberpairen, aber nichts löschen oder resetten.

vor dem pairen noch "set clear msgEvents".
eventuell den sensor beim pairen abdecken, damit ggf trigger nicht dazwischen funken können.

anschliessend kannst du mit "get hminfo configCheck" kontrollieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Rollo_Wikinger

FHEM damals:
Featurelevel: 6.1
Woran erkennst Du, dass er nicht gepairt ist?

Da er trotzdem einwandfrei läuft, habe ich erstmal nichts gemacht, aber danke für die Tips, bestimmt nützlich, wenn man mal Schwierigkeiten hat.
RPi 1 Model B|HM-MOD-RPI-PCB|1x HM-LC-Bl1-FM|3x HM-LC-Bl1PBU-FM|2x HM-LC-Sw1-PI-DN-R1|1x HM-PB-2-WM55-2|1x HM-LC-Sw1-FM

1.fhemtester

In den Readings sollte

PairedTo 0x123456 o.ä. stehen.

Weil im "ungepairden" Zustand eine Broadcast verschickt wird, geht's auch ohne.