Autocreate legt unerwünschtes HM-Device an

[connormcl]

Hallo,

betreibe an einem FHEM-Server eine CCU2 und einen nanoCUL im Homematic Modus.

Dabei habe ich eigentlich zwei getrennte Gruppen von HM-Geräten; die einen sollen nur an der CCU2 angelernt sein; die anderen nur am nanoCUL.

Seit zwei Tagen, als ich ein anderes HM Device an den nanoCUL angelernt habe, spielt  eines der bisherigen Devices, das an die CCU2 angelernt ist verrückt und erscheint über den nanoCUL in FHEM. Löschen und unpairen in FHEM hilft nicht, es erscheint wieder, obwohl der nanoCUL dabei nicht im pairing Modus ist:

2017.08.21 22:39:00 3: Device 563FB2 removed from ActionDetector
2017.08.21 22:52:02 2: CUL_HM Unknown device HM_563FB2 is now defined
2017.08.21 22:52:02 2: autocreate: define HM_563FB2 CUL_HM 563FB2
2017.08.21 22:52:02 2: autocreate: define FileLog_HM_563FB2 FileLog /var/log/fhem/HM_563FB2-%Y.log HM_563FB2
2017.08.21 22:52:02 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.21 22:52:07 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.21 22:57:32 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.21 22:57:32 3: CUL_HM set HM_563FB2 getConfig
2017.08.21 23:03:45 3: CCURPC: CB2001 Received 500 events from CCU since last check
2017.08.21 23:13:28 3: CUL_HM set HM_563FB2 unpair
2017.08.21 23:13:54 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.21 23:13:54 3: CUL_HM set HM_563FB2 getConfig
2017.08.21 23:23:31 2: CUL_HM Unknown device HM_563FB2 is now defined
2017.08.21 23:23:31 2: autocreate: define HM_563FB2 CUL_HM 563FB2
2017.08.21 23:23:31 2: autocreate: define FileLog_HM_563FB2 FileLog /var/log/fhem/HM_563FB2-%Y.log HM_563FB2
2017.08.21 23:23:32 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.21 23:23:36 3: Device HM_563FB2 added to ActionDetector with 002:50 time

Im FHEM-Log erscheint alle paar Minuten bei diesem - und das stört mich -:
2017.08.21 23:23:32 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.21 23:23:36 3: Device HM_563FB2 added to ActionDetector with 002:50 time[


Wieso passiert das und wie bekomme ich das Ding wieder ausschliesslich an die CCU2 angelernt?

[Pfriemler]

Wie Du das Ding dazu bringst, mit der CCU2 zu reden, musst Du allda aushandeln.

Ein Gerät, was von FHEM erkannt wird, aber nicht ausgewertet oder benutzt werden soll, kann man auf ignore setzen:

Code Auswählen Erweitern

attr HM_563FB2 ignore 1

Es bleibt dann definiert, wird aber versteckt und nicht mehr ausgewertet, eben ignoriert.

[CoolTux]

Für HM Geräte empfiehlt sich auch immer eine VCCU. Da kann man dann ganz einfach falsch erkannte Geräte in einem Rutsch auf ignore setzen.

[gamauf]

Du willst also zwei unabhängige HM-Netze aufziehen.
Dann haben die beiden IO-Devices doch sicher unterschiedliche HM-IDs! Oder?

[connormcl]

Nochmal ein Versuch der Problembeschreibung:

Ich habe bisher schon zwei getrennte Homematic Netze am Laufen.

Einmal 22 HM-Devices an einer CCU2
Einmal 7 HM-Devices an einem nanoCUL

Nun hat sich plötzlich ein HM-Device, dass an der CCU2 angelernt ist, per autocreate in FHEM am nanoCUL gemeldet und das möchte ich nicht.

Seltsamerweise kann ich den Statuswechsel des Devices sowohl in der CCU2, als auch in FHEM sehen...ich dachte man kann ein HM-Device nur an eine Basisstation anlernen?

Die Fragen dazu:

1) wieso hat das nur dieses eine getan...und die 21 anderen der CCU2 Devices tun das nicht? bzw. wodurch könnte das ausgelöst worden sein? (Im fraglichen Zeitraum des ersten Autocreates habe ich evtl. ein anderes HM-Device an den nanoCUL angelernt...)

2) wie lösche ich das Device dauerhaft aus FHEM, so dass es wieder nur an der CCU2 angemeldet ist...?

[CoolTux]

Wer sagt denn das es an FHEM angelernt (gepairt ist)? Es werden HM Devices per broadcast gefunden und in FHEM angelegt. Man kann sogar deren Status erkennen auch wenn sie von ihrer eigentlichen Basis geschalten werden. Aber selber schalten kann man dann wiederum nicht, dazu müssen die gepairt sein.

[connormcl]

Wer sagt denn das es an FHEM angelernt (gepairt ist)? Es werden HM Devices per broadcast gefunden und in FHEM angelegt. Man kann sogar deren Status erkennen auch wenn sie von ihrer eigentlichen Basis geschalten werden. Aber selber schalten kann man dann wiederum nicht, dazu müssen die gepairt sein.

Ok, dann möchte ich verstehen, wieso das nicht mit allen HM-Devices passiert. Ich habe hier 7 HM-Devices, die garantiert in Funkreichweite des nanoCULs sind und nicht damit gepairt sind. Von den 7 zeigt genau einer das Verhalten des Broadcasts und wird in FHEM angelegt...

[CoolTux]

list vom cul
list vom device welches unerwünscht angelegt wurde

[gloob]

Ok, dann möchte ich verstehen, wieso das nicht mit allen HM-Devices passiert. Ich habe hier 7 HM-Devices, die garantiert in Funkreichweite des nanoCULs sind und nicht damit gepairt sind. Von den 7 zeigt genau einer das Verhalten des Broadcasts und wird in FHEM angelegt...

Hast du das Gerät neu gestartet? Batterien gewechselt? Pairing erneut durchgeführt?

Ich hatte mal einen Bewegungsmelder von meinem Nachbarn bei mir drin, nach einem Batteriewechsel.

[Pfriemler]

Für HM Geräte empfiehlt sich auch immer eine VCCU. Da kann man dann ganz einfach falsch erkannte Geräte in einem Rutsch auf ignore setzen.

Hm ... meinst Du damit solche Einträge bei der VCCU?

Code Auswählen Erweitern

    2017-08-21 23:27:12   unknown_11411A  received
     2017-07-04 16:16:43   unknown_161C0B  received
     2016-10-28 13:21:19   unknown_1FC9FE  received

Da finden sich nämlich auch einige Geräte, die ich inzwischen im produktiven Einsatz habe ...

Ernstlich: Hin und wieder autocreatete Geräte waren auch mir mal ein Dorn im Auge, worauf ich den Hinweis mit dem "ignore" bekam. Neue Geräte landen bei mir default in einem Room "Neugeräte", der nur in meiner Admininstanz sichtbar ist (bei raffinierten readingsGroups etc. funktionert das allerdings nicht so) und von mir regelmäßig "geleert" wird, d.h. bei Geräten von Nachbarn kommt eben - ganz egal welche Funkfamilie - besagtes ignore zum Einsatz. Die Dinger findet man anschließend nur noch mit "list xyz" (wobei xyz exakt die Gerätebezeichnung sein muss, keine Wildcards möglich) - oder in fhem.cfg mit der Suche nach "ignore 1".

Und den Effekt mit dem autocreate nach einem Batteriewechsel kenne ich nur zur Genüge: Viele HM-Geräte sind bei mir früher zuerst so aufgetaucht, bevor sie gepairt wurden.

Den Parallelbetrieb (Bedienen über CCU2, mitlesen über FHEM) habe ich selbst eine Zeitlang absichtlich probiert, dann aber wegen anderer Probleme wieder fallengelassen.

[connormcl]

@gloob: hatte an dem Gerät keine Batterien gewechselt...nur etwa zur gleichen Zeit, wo es los ging ein anderes an den nanoCUL angelernt...

Es geht mir um jede Menge Nachrichten wie folgende von diesem Device, die mehrmals pro Minute im Log kommen...was bedeuten die und weshalb kommen sie ständig? Deshalb will ich das Problem lösen/wissen, bevor weitere HM Devices das bei mir auch anfangen:

Code Auswählen Erweitern

2017.08.22 12:49:01 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.22 12:53:18 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.22 12:53:48 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.22 12:54:26 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.22 12:55:08 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.22 12:55:48 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.08.22 12:55:59 3: Device HM_563FB2 added to ActionDetector with 002:50 time


@cooltux:

HM Device:

Code Auswählen Erweitern

Internals
CFGFN

DEF 563FB2
HMnanoCUL_MSGCNT 163
HMnanoCUL_RAWMSG A193CA603563FB255C9DCDC9EE4DCC173AB5D16B2DBEEA6393315::-70:HMnanoCUL
HMnanoCUL_RSSI -70
HMnanoCUL_TIME 2017-08-22 20:20:02
IODev HMnanoCUL
LASTInputDev HMnanoCUL
MSGCNT 163
NAME HM_563FB2
NOTIFYDEV global
NR 2589
STATE closed
TYPE CUL_HM
lastMsg No:3C - t:03 s:563FB2 d:55C9DC DC9EE4DCC173AB5D16B2DBEEA6393315
protCmdDel 6
protLastRcv 2017-08-22 20:20:02
protResnd 6 last_at:2017-08-22 18:58:57
protResndFail 2 last_at:2017-08-22 19:00:21
protSnd 8 last_at:2017-08-22 19:00:17
protState CMDs_done_Errors:1
rssi_at_HMnanoCUL cnt:163 avg:-68.05 max:-59 lst:-70 min:-72

Readings
Activity alive 2017-08-22 19:14:14
D-firmware 1.0 2017-08-22 19:14:14
D-serialNr OEQ0200182 2017-08-22 19:14:14
RegL_00.
alive yes 2017-08-22 20:20:02
battery low 2017-08-22 20:20:02
contact closed (to 55C9DC) 2017-08-22 20:20:02
powerOn 2017-08-22 13:48:59 2017-08-22 13:48:59
recentStateType info 2017-08-22 20:20:02
sabotageError off 2017-08-22 20:20:02
state closed 2017-08-22 20:20:02
trigDst_55C9DC noConfig 2017-08-22 16:18:49
trigger_cnt 226 2017-08-22 16:18:49


nanoCUL:

Code Auswählen Erweitern

Internals
CMDS ABCEeFfGhiKklMmRTtUVWXxYZz
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.3.22:10005 0000
DeviceName 192.168.3.22:10005
FD 16
FHTID 0000
HMnanoCUL_MSGCNT 22701
HMnanoCUL_TIME 2017-08-22 21:05:32
NAME HMnanoCUL
NR 41
NR_CMD_LAST_H 4
PARTIAL RAWMSG A0F8586103C517D0000000AA8CE0F644009
RSSI -69.5
STATE Initialized
TYPE CUL
VERSION V 1.67 nanoCUL868
initString X21 Ar

[CoolTux]

Sorry aber das ist kein korrektes list


list DEVICENAME

list ist ein FHEM Befehl.

[connormcl]

neuer Versuch:


HM Device

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        563FB2
   HMnanoCUL_MSGCNT 167
   HMnanoCUL_RAWMSG A193FA603563FB255C9DCAB886B9D14A1ADC1E4361B621000DF71::-71:HMnanoCUL
   HMnanoCUL_RSSI -71
   HMnanoCUL_TIME 2017-08-22 22:08:48
   IODev      HMnanoCUL
   LASTInputDev HMnanoCUL
   MSGCNT     167
   NAME       HM_563FB2
   NOTIFYDEV  global
   NR         2589
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:3F - t:03 s:563FB2 d:55C9DC AB886B9D14A1ADC1E4361B621000DF71
   protCmdDel 6
   protLastRcv 2017-08-22 22:08:48
   protResnd  6 last_at:2017-08-22 18:58:57
   protResndFail 2 last_at:2017-08-22 19:00:21
   protSnd    8 last_at:2017-08-22 19:00:17
   protState  CMDs_done_Errors:1
   rssi_at_HMnanoCUL cnt:167 avg:-68.2 max:-59 lst:-71 min:-77.5
   Readings:
     2017-08-22 19:14:14   Activity        alive
     2017-08-22 19:14:14   D-firmware      1.0
     2017-08-22 19:14:14   D-serialNr      OEQ0200182
     2017-08-22 20:56:32   RegL_00.
     2017-08-22 22:08:48   alive           yes
     2017-08-22 22:08:48   battery         low
     2017-08-22 22:08:48   contact         closed (to 55C9DC)
     2017-08-22 13:48:59   powerOn         2017-08-22 13:48:59
     2017-08-22 22:08:48   recentStateType info
     2017-08-22 22:08:48   sabotageError   off
     2017-08-22 22:08:48   state           closed
     2017-08-22 16:18:49   trigDst_55C9DC  noConfig
     2017-08-22 16:18:49   trigger_cnt     226
   Helper:
     HM_CMDNR   63
     PONtest    0
     cSnd       01227735563FB200040000000000,01227735563FB200040000000000
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     rxType     28
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +563FB2,00,00,00
       nextSend   1503432529.06919
       prefIO
       rxt        2
       vccu
       p:
         563FB2
         00
         00
         00
     Mrssi:
       mNo        3F
       Io:
         HMnanoCUL  -69
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmnanocul:
         avg        -68.2065868263474
         cnt        167
         lst        -71
         max        -59
         min        -77.5
Attributes:
   IODev      HMnanoCUL
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCo
   room       CUL_HM
   serialNr   OEQ0200182
   subType    threeStateSensor


nanoCUL

Code Auswählen Erweitern

Internals:
   CMDS       ABCEeFfGhiKklMmRTtUVWXxYZz
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.3.22:10005 0000
   DeviceName 192.168.3.22:10005
   FD         16
   FHTID      0000
   HMnanoCUL_MSGCNT 22863
   HMnanoCUL_TIME 2017-08-22 22:30:59
   NAME       HMnanoCUL
   NR         41
   NR_CMD_LAST_H 4
   PARTIAL
   RAWMSG     A0F0386103C43D10000000AA8CF0F644019
   RSSI       -61.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 nanoCUL868
   initString X21
Ar
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-08-12 17:08:32   cmds             A B C E e F f G h i K k l M m R T t U V W X x Y Z z
     2017-08-22 22:30:59   state           Initialized
   XMIT_TIME:
     1503419492.83645
     1503419493.07544
     1503421132.00124
     1503421216.95702
   Helper:
     53b9e0:
       QUEUE:
     540555:
       QUEUE:
     559688:
       QUEUE:
     563fb2:
       QUEUE:
     58b68a:
       QUEUE:
Attributes:
   hmId       227735
   rfmode     HomeMatic
   room       Admin
   verbose    2

[Damu]

Empfiehlt sich auch immer eine VCCU. Da kann man dann ganz einfach falsch erkannte Geräte in einem Rutsch auf ignore setzen.

Ist mir klar, verstehe aber nich wieso neue HM Geräte zu jeder Zeit automatisch angelegt werden müssen.
Würde es nicht reichen wenn das nur geschieht wenn die VCCU auf pairen 60 sek (oder ähnlich) gestellt wird,
Und der Rest automatisch ignoriert wird?
Habe eben 10 Neue Fenstersensoren an einer Pi3 mit HM-Uart mit einer Anderen HM-ID als die ich auf meinem Fhem mit Nuc habe angelernt.
Der Nuc hat glaub für jeden Sensor auch ein Device mit Log erstellt.

Wäre es nicht besser wenn neue Geräte nur erstellt werden wenn die VCCU auf pairen steht?

[Pfriemler]

verstehe aber nich wieso neue HM Geräte zu jeder Zeit automatisch angelegt werden müssen.
...
Wäre es nicht besser wenn neue Geräte nur erstellt werden wenn die VCCU auf pairen steht?

In diesem speziellen letzteren Fall könnte man das Autocreate im Rahmen eines Pairing quasi als erlaubt unterscheiden, stimmt. Ansonsten aber werden nicht nur HM-, sondern auch diverse andere Geräte automatisch angelegt, wenn Daten empfangen werden. Dafür kann man autocreate ja gezielt bezogen auf bestimmte Hardwarefamilien deaktiveren (habe ich bspw. bei den zahllosen IT-Geräten in meiner Umgebung gemacht). Das kann wohl getrennt davon auch für das automatische Anlegen von FileLogs definiert werden, eine Einstellung die sich ohnehin empfiehlt, wenn man nicht mehr Anfänger ist... Gerade Neugeräte laufen aber zumindest ein paar Tage gern bei mir mit FileLog, schon mal um ihnen genau auf die Finger sehen zu können.
Ist eben alles Ansichtssache. Ebenso wie das Verfahren, einmal erkannte fremde Geräte in der Umgebung einmal manuell auf ignore zu setzen.