Autocreate legt unerwünschtes HM-Device an

Begonnen von connormcl, 21 August 2017, 23:44:11

Vorheriges Thema - Nächstes Thema

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:

Zitat2017.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:
attr HM_563FB2 ignore 1

Es bleibt dann definiert, wird aber versteckt und nicht mehr ausgewertet, eben ignoriert.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

connormcl

Zitat von: CoolTux am 22 August 2017, 10:09:31
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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

gloob

Zitat von: connormcl am 22 August 2017, 11:48:58
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.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Pfriemler

Zitat von: CoolTux am 22 August 2017, 03:27:17
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?
    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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

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:

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:

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:

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

connormcl

neuer Versuch:


HM Device

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

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

ZitatEmpfiehlt 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

Zitat von: Damu am 26 August 2017, 10:07:39
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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Damu

Wäre es nicht besser wenn jedes device das autocreate selber für sich umsetzt.
Oder das autocreate nicht nur on:off hat.
Ein Status damit kein neues device geschrieben wird, nur ein vorhandenes device umgeschrieben oder geändert werden kann?

Benni

Zitat von: Damu am 27 August 2017, 10:27:22
Wäre es nicht besser wenn jedes device das autocreate selber für sich umsetzt.
Oder das autocreate nicht nur on:off hat.
Ein Status damit kein neues device geschrieben wird, nur ein vorhandenes device umgeschrieben oder geändert werden kann?

autocreate hat ein Attribut IgnoreTypes über das Gerätetypen ausgeschlossen werden können. Damit lässt sich das doch schon mal etwas genauer differenzieren, als nur on oder off. Zum Verhindern, dass neu erzeugte Geräte auch direkt automatisch in die Konfig geschrieben werden gibt es das Attribut autosave am global-Device.
Und schließlich kann ich ja das autocreate-Device off setzen und dann selbst nur bei Bedarf aktivieren. Das könnte man bei HM (natürlich auch für andere) ja sogar in ein cmdalias packen (Pseudocode)

autocreate aktivieren
paring starten (60 sek.)
60 sekunden warten (sleep)
autocreate deativieren


Alles da! Man  muss es nur zu nutzen wissen ;)

connormcl

Ja, zur Not werde ich einfach ein ignore auf das betreffende Device setzen.

Ich behandle nur ungern die Symptome, ohne die Ursache  zu verstehen....und das eine an die CCU2 angelernte HM-Device wird hier in FHEM am nanoCUL autocreated und das direkt daneben nicht...solcherlei Inkonsistenz deutet meistens auf einen Unterschied in der Konfiguration oder Bugs in den Devices oder FHEM hin...

Klar hätte ich das alles hinnehmen und totschweigen können...so lernt man aber nix und kehrt das Problem nur unter den Tisch...

martinp876

Wenn fhem-HM config sieht und das device nicht kennt wird es angelegt. fertig.
Wenn du eine vccu hast findest Du es dort.
Wenn du es ignorieren willst, schalte es in der vccu aus. alle auf einmal.

Alles doch Recht einfach meine ich. Es braucht nicht mehr. Du schaltest aus,was du nicht willst. Das andere ok lässt du.

Was soll man diskutieren? 10 weitere möglichkeiten ein device im funkbereich zu ignorieren? Abschalten kann ich es nicht.
Wenn eines nicht angelegt wird ist keine config gekommen.

connormcl

Zitat von: martinp876 am 28 August 2017, 21:54:07
Wenn eines nicht angelegt wird ist keine config gekommen.

Was sorgt dafür das eine "config durchkommt"? Bzw. wie löst man das aus?

Bspw. sind zwei der Devices ind Empfangsreichweite des nanoCUL, aber dort nicht angelernt, sondern ausschliesslich an der CCU2.

Weshalb gibt dann nur eines der Devices seine Config durch und verursacht ein Autocreate über den nanoCUL? Müssten das dann nicht beide tun?
Könnte die leergehende Batterie in einem der Devices Schuld sein?

Habe halt einige HM-Devices in Reichweite des nanoCUL und bisher wurde ausschliesslich nur bei aktivem pairing am nanoCUL dasjenige HM-Device autocreated, auf dem ich dann den Anlernknopf aktiviert habe. Alle anderen wurden ignoriert; innerhalb und ausserhalb des Anlernvorgangs...

Damu

#20
Zitat
Sorry, aber wieso etwas abschalten das ich nicht will?

Ich finde besser nur einschalten was ich will.

Ja natürlich es war ja immer so, aber vielleicht ist es besser anders.

So wie es jetzt ist machen die meisten gar nichts.
Vccu einrichten und fertig.
Mehr steht in der Wiki unter vccu auch nicht.
Zitat
Was soll man diskutieren? 10 weitere möglichkeiten ein device im funkbereich zu ignorieren?

Wo finde ich diese?

Pfriemler

Zitat von: connormcl am 28 August 2017, 22:36:48
Könnte die leergehende Batterie in einem der Devices Schuld sein?

Nicht die leergehende, aber die Meldungen, die ein HM-Gerät bei einem Power-up, also nach einem Batteriewechsel, sendet, haben in der Vergangenheit bei so manchem meiner Geräte schon für ein autocreate gesorgt.

Ich verstehe jetzt aber dennoch nicht ganz, was genau das Problem ist. Autocreate ist ein Segen gerade für Anfänger, und wie man es abschaltet oder konfiguriert, ist sogar hier hinlänglich erklärt. Wenn ich ein neues Gerät kaufe, ist es im "Idiotenmodus" (Kamera, Fritzbox, Auto, ...) Ich kann den Idiotenmodus abschalten (-> P-Mode, -> Expertenmodus usw), wenn ich den Idiotenmodus nicht will. Da ist FHEM keine Ausnahme. Wozu die Aufregung?
Ich bin raus ...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Benni

Zitat von: Damu am 28 August 2017, 22:48:35
Wo finde ich diese?

Nirgends!
Es war die, etwas sarkastische Frage, ob man denn wirklich über Einführung von 10 weiteren Möglichkeiten diskutieren Soll, das automatische Erstellen eines Gerätes ggf. abschalten zu können.  ::)

Btw.: Du solltest vielleicht mal noch das zitieren üben  ;)

Benni

Zitat von: connormcl am 28 August 2017, 22:36:48
Was sorgt dafür das eine "config durchkommt"? Bzw. wie löst man das aus?

Bspw. mit getConfig
Das wird übrigens auch beim Pairing-Vorgang ausgeführt. So dass nicht ursächlich das Pairing dafür sorgt, sondern das anschließende getConfig (das aber in dem Fall obligatorisch ist).

Unter welchen Umständen ggf. deine CCU2 oder ein HM-Device (je nachTyp / Firmware)  sonst noch (ggf. von sich aus) eine Konfig sendet ist aber eher eine Frage, die ins Homematic-Forum gehört oder die du EQ3 stellen solltest.

gb#

Damu

#24
ZitatNirgends!
Weiss ich.

Ich binn dafür das mann FHEM sicherer und einfacher macht.
Es gibt immer mehr Module und so weiter.
Das macht die Sache für Anfänger immer wie schwieriger.
Natürlich Anfänger doku lesen etc.
Für das haben doch die meisten gar keine Zeit mehr und machen es wenn Sie am Installieren sind.
Und viele Sachen die findet mann leider nur im Forum hier.
Das macht es nicht einfacher.





Benni

Zitat von: Damu am 29 August 2017, 18:58:24
Ich binn dafür das mann FHEM sicherer und einfacher macht.
Es gibt immer mehr Module und so weiter.
Das macht die Sache für Anfänger immer wie schwieriger.
Natürlich Anfänger doku lesen etc.
Für das haben doch die meisten gar keine Zeit mehr und machen es wenn Sie am Installieren sind.
Und viele Sachen die findet mann leider nur im Forum hier.
Das macht es nicht einfacher.


Und die genannten 10 Varianten würden es jetzt einfacher machen oder was? Verstehe ich nicht!

Wer zum Einlesen keine Zeit hat, sollte sich vielleicht ein anderes Hobby suchen  ::)

Und die, die immer über fehlende Doku meckern könnten sich stattdessen gerne beteiligen und bspw. im Wiki beim Dokumentieren mithelfen! Ach so ... stimmt ja: keine Zeit.
Aber die haben ja die Entwickler noch übrig, ganz neben Hauptberuf, Entwicklung und Betreuung hier im Forum.

Und zack! Sind wir mal wieder popcorn-mäßig OT.  ::)
Keine Angst, das waren auch schon meine letzten 2Ct. für diese Diskussion!
Ich bin dann mal raus!

PS: Für die, die's nicht merken: Das ganze sollte einen leicht sarkastischen Unterton haben.


zap

Zitat von: Benni am 29 August 2017, 20:59:35
Wer zum Einlesen keine Zeit hat, sollte sich vielleicht ein anderes Hobby suchen  ::)

Vorsicht, noch mehr off topic ;-)

Oder eine andere Smarthome Plattform nehmen, die leichter zu Bedienen ist. Denn seien wir mal ehrlich: FHEM ist sehr flexibel, integriert viele Geräte. Es ist aber sicher kein Paradebeispiel für eine anwenderfreundliche Software.

Da gibt es mittlerweile Alternativen, bei denen ein Einsteiger deutlich schneller zum Ziel kommt und die teilweise sogar mehr unterschiedliche Geräte integrieren können (iobroker, openhab)


2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

connormcl

Mein Problem mit dem einen Homematic-Device entwickelt leider ein Eigenleben und ich weiss nicht, ob es an FHEM oder dem Türsensor selbst liegt...

Mit der CCU2 funktioniert das Device weiterhin wie es soll...

Aber seitdem es per Autocreate in FHEM angelegt wurde erscheinen ständig solche Zeilen im Log:

Zitat2017.09.22 14:04:18 3: Device HM_563FB2 added to ActionDetector with 002:50 time
2017.09.22 14:04:18 3: CUL_HM set HM_563FB2 getConfig

Das wäre nicht weiter schlimm...aber der Türkontakt hält mit neuer Batterie nun gerade mal 3-7 Tage durch!

Werde wohl nicht drumherum kommen, das ignore mal zu probieren, falls sonst niemand eine Idee hat...

martinp876


Damu

ZitatDas wäre nicht weiter schlimm...aber der Türkontakt hält mit neuer Batterie nun gerade mal 3-7 Tage durch!

Ist das wirklich so?

Schöne Aussichten wenn da ein Nachbar mit einem FHEM dir die Batterien leer macht.

Benni

Zitat von: Damu am 24 September 2017, 09:00:39
Schöne Aussichten wenn da ein Nachbar mit einem FHEM dir die Batterien leer macht.

Das kann doch gar nicht gehen. Ein Türkontakt, als batteriebetriebener Sensor, sendet doch nur von sich aus nicht nicht durch Abfrage oder sonstigen Anstoß von FHEM. Schon gar nicht über ein FHEM (bzw. IO) mit dem er gar nicht gepairt ist.  ???

Damu

#31
Und wenn Du den Türkontakt mal mit der CCU2 zuerst auf Werkseinstellungen stellst und danach neu an der CCU2 Anlernst?

Du hast an der CCU2 und an FHEM schon eine andere HM ID vergeben?

martinp876

Die Empfehlung gilt seit Anfang an:
Richte eine vccu ein. Die sammelt devices ein, welche im Funkraum unterwegs sind und nicht von der vccu bedient werden sollen. Gelegentlich alle devices auf ignorieren setzen (ein Kommando in der vccu) und fertig. Fhem wird Ruhe bewahren.

Damu

ZitatDie Empfehlung gilt seit Anfang an:
Richte eine vccu ein. Die sammelt devices ein, welche im Funkraum unterwegs sind und nicht von der vccu bedient werden sollen. Gelegentlich alle devices auf ignorieren setzen (ein Kommando in der vccu) und fertig. Fhem wird Ruhe bewahren.
Natürlich, dem stimme ich auch zu.
Aber wenn bei einem Melder die Batterien nach 3-7 Tagen Leer sind, stimmt da doch etwas mit diesem Melder nich?

Die anderen 21 scheinen das Problem nicht zu haben.

Vielleicht ist dieser Melder auch defekt?

Pfriemler

#34
ZitatGelegentlich alle devices auf ignorieren setzen (ein Kommando in der vccu) und fertig.
Da kann ich persönlich nur davon abraten, denn wie ich im Post #9 hier schon sagte, bleiben in den unknowns (in den Readings der VCCU) ganz offenbar auch Geräte stehen, die inzwischen definiert sind und im produktiven Einsatz. Hier fehlt der VCCU offenbar ein Mechanismus, die unknowns aufzuräumen.

Also denke ich - ungetestet - : setzt man nach längerer Zeit in der VCCU "defIgnUnknown", kickt man evtl auch gewollte Geräte ins Off - oder wird das abgefangen, Martin?

edit: wie Martin im Folgepost erläutert, sind meine Bedenken unbegründet. Danke!


"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

martinp876

Habe es gerade getestet: defIgnUnknown setzt alle Devices auf ignore welche nicht definiert sind. Alle anderen bleiben unberührt - auch wenn sie zwischendurch definiert wurden.

Um faktisch zu sehen, wer die Batterie leert solltest du den sniffer einschalten und alles von diesem Device loggen.
Dann können wir es sehen.

connormcl

#36
Da sich das Problem glücklicherweise weiterhin nur auf diesen einen Türkontakt bezieht, gehe ich vorerst mal von einem Gerätebezogenen Problem aus.
Hatte ja die Befürchtung, dass ich einen Fehler im System habe und jetzt alles Homematic Equipment hier potentiell das Spinnen anfangen kann...

Ich habe also das Device in FHEM auf Ignore gesetzt und werde zusätzlich noch den Kontakt auf Werkseinstellungen zurücksetzen und neu an die CCU2 anlernen.

Danach dauert es leider wieder ca. Woche, bis ich weiss, ob die Batterie hält oder nicht...

Falls sie dann wieder leer sein sollte würde ich den Türkontakt als defekt einstufen und durch einen anderen ersetzen... (bei ELV liest man im Forum, dass das ab und zu vorkommt, dass Türkontakte in dieser Art und Weise defekt sind und die Batterie leerziehen...hatte nur Aufgrund des gleichzeitig auftretenden FHEM-Verhaltens bei diesem Kontakt ein Softwareproblem vermutet...)

Pfriemler

@Martin: Danke fürs Testen, ich bin beruhigt und habe meine Bedenken ensprechend kommentiert.

@connormci: Wir dürfen gespannt sein, aber ich vermute nicht FHEM als Übeltäter. Zwar kann FHEM den Kontakt zusätzlich stressen, etwa wenn bei jeder Meldung des Kontakts erst diverse Übertragungen zusätzlich angestoßen werden, aber dass das so ein Teil im regulären Betrieb in einer Woche leerzieht, halte ich doch für sehr unwahrscheinlich. Aber schauen wir mal.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."