Autocreate legt unerwünschtes HM-Device an

[Benni]

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]

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]

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.

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]

Gelegentlich 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!

[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]

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.