Kein R-Sign beim: HM-OU-CFM-PL (MP3 - Funkgong)

[Leeloo_Dallas]

Hallo zusammen,

in Verbindung mit meiner Alarmanlage wollte ich nun auch beim Homematic-MP3-Funkgong (HM-OU-CFM-PL) AES aktivieren und dazu "R-sign" beider Kanäle (MP3 und LED) auf "on" setzen.

Leider erscheint nach dem Abschicken des Befehls

Code Auswählen Erweitern

set FunkGongHM_MP3__DG_Eingang sign on
per GUI oder Commandozeile folgende Meldung:

Code Auswählen Erweitern

cannot calculate value. Please issue set FunkGongHM_MP3__DG_Eingang getConfig first - invalid

Alle andere Funktionen laufen bisher ohne Probleme. Bisher macht nur die Aktivierung von AES Zicken.

Weiß jemand Rat?

Gruß
Leeloo

Nachtrag 1: Ein ConfigCheck liefert übrigens keine Einträge/Fehler.
Nachtrag 2: getConfig habe ich schon x-mal ausgeführt, aber ohne Erfolg
Nachtrag 3: Hier gab es schon einmal ein ähnliches Problem https://forum.fhem.de/index.php/topic,21756.msg152184.html#msg152184. Die Lösung war damals eine Software-Anpassung.

[Leeloo_Dallas]

Nachtrag:
Scheinbar fehlt hier das Register "R-Sign"
Ggf. ähnlich wie Thread:  https://forum.fhem.de/index.php?topic=55104.msg468240#msg468240

Zur vollständigen Übersicht habe ich folgendes beim FunkGongHM__DG_Eingang gesetzt.

Code Auswählen Erweitern

attr FunkGongHM__DG_Eingang expert 251_anything
set FunkGongHM__DG_Eingang regSet intKeyVisib visib

Anbei die Lists der Channels (LED und MP3) von FunkGongHM_LED__DG_Eingang:
--------
=>FunkGongHM_LED__DG_Eingang

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/mycfg/99_alarm.cfg
   DEF        3BA00301
   NAME       FunkGongHM_LED__DG_Eingang
   NR         1068
   NTFY_ORDER 50-FunkGongHM_LED__DG_Eingang
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     FunkGongHM__DG_Eingang
   peerList   self01,
   Readings:
     2016-07-05 14:31:48   CommandAccepted yes
     2016-07-05 18:56:38   R-self01-lgActNum 7
     2016-07-05 18:56:38   R-self01-lgActTypeLed orangeL
     2016-07-05 18:56:38   R-self01-lgActionType jmpToTarget
     2016-07-05 18:56:38   R-self01-lgCtDlyOff geLo
     2016-07-05 18:56:38   R-self01-lgCtDlyOn geLo
     2016-07-05 18:56:38   R-self01-lgCtOff geLo
     2016-07-05 18:56:38   R-self01-lgCtOn geLo
     2016-07-05 18:56:38   R-self01-lgCtValHi 100
     2016-07-05 18:56:38   R-self01-lgCtValLo 50
     2016-07-05 18:56:38   R-self01-lgMultiExec on
     2016-07-05 18:56:38   R-self01-lgOffDly 0 s
     2016-07-05 18:56:38   R-self01-lgOffTime unused
     2016-07-05 18:56:38   R-self01-lgOffTimeMode absolut
     2016-07-05 18:56:38   R-self01-lgOnDly 0 s
     2016-07-05 18:56:38   R-self01-lgOnTime 6 s
     2016-07-05 18:56:38   R-self01-lgOnTimeMode absolut
     2016-07-05 18:56:38   R-self01-lgSwJtDlyOff no
     2016-07-05 18:56:38   R-self01-lgSwJtDlyOn no
     2016-07-05 18:56:38   R-self01-lgSwJtOff dlyOn
     2016-07-05 18:56:38   R-self01-lgSwJtOn no
     2016-07-05 18:56:38   R-self01-shActNum 7
     2016-07-05 18:56:38   R-self01-shActTypeLed orangeL
     2016-07-05 18:56:38   R-self01-shActionType jmpToTarget
     2016-07-05 18:56:38   R-self01-shCtDlyOff geLo
     2016-07-05 18:56:38   R-self01-shCtDlyOn geLo
     2016-07-05 18:56:38   R-self01-shCtOff geLo
     2016-07-05 18:56:38   R-self01-shCtOn geLo
     2016-07-05 18:56:38   R-self01-shCtValHi 100
     2016-07-05 18:56:38   R-self01-shCtValLo 50
     2016-07-05 18:56:38   R-self01-shMultiExec off
     2016-07-05 18:56:38   R-self01-shOffDly 0 s
     2016-07-05 18:56:38   R-self01-shOffTime unused
     2016-07-05 18:56:38   R-self01-shOffTimeMode absolut
     2016-07-05 18:56:38   R-self01-shOnDly 0 s
     2016-07-05 18:56:38   R-self01-shOnTime 6 s
     2016-07-05 18:56:38   R-self01-shOnTimeMode absolut
     2016-07-05 18:56:38   R-self01-shSwJtDlyOff off
     2016-07-05 18:56:38   R-self01-shSwJtDlyOn on
     2016-07-05 18:56:38   R-self01-shSwJtOff dlyOn
     2016-07-05 18:56:38   R-self01-shSwJtOn dlyOff
     2016-07-05 18:58:23   RegL_03.self01   02:00 03:00 04:32 05:64 06:00 07:26 08:00 09:FF 0A:01 0B:14 0C:63 24:32 25:07 26:00 27:00 28:00 29:00 2A:00 2B:FF 82:00 83:00 84:32 85:64 86:00 87:26 88:00 89:FF 8A:21 8B:10 8C:00 8D:32 8E:07 A4:32 A5:07 A6:00 A7:00 A8:00 A9:00 AA:00 AB:FF 00:00
     2016-07-05 18:58:22   peerList        self01,
     2016-07-05 14:31:48   recentStateType ack
     2016-07-05 14:31:48   state           off
   Helper:
     dlvl       00
     dlvlCmd    ++A011F112343BA0030201000000
     peerIDsRaw ,3BA00301,00000000
     Expert:
       def        1
       det        1
       raw        1
       tpl        1
     Role:
       chn        1
     Shadowreg:
     Tmpl:
Attributes:
   fp_001_DG  235,850,1,FunkGongHM_LED__DG_Eingang,
   group      System_realDevices
   icon       light_led
   model      HM-OU-CFM-PL
   peerIDs    00000000,3BA00301,
   room       SYSTEM
   webCmd     press short:press long

--------
=>FunkGongHM_MP3__DG_Eingang

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/mycfg/99_alarm.cfg
   DEF        3BA00302
   NAME       FunkGongHM_MP3__DG_Eingang
   NR         1069
   NTFY_ORDER 50-FunkGongHM_MP3__DG_Eingang
   STATE      off
   TYPE       CUL_HM
   chanNo     02
   device     FunkGongHM__DG_Eingang
   peerList   self02,
   Readings:
     2016-07-05 14:31:48   CommandAccepted yes
     2016-07-05 18:56:39   R-self02-lgActNum 1
     2016-07-05 18:56:39   R-self02-lgActTypeMp3 0
     2016-07-05 18:56:39   R-self02-lgActionType jmpToTarget
     2016-07-05 18:56:39   R-self02-lgCtDlyOff geLo
     2016-07-05 18:56:39   R-self02-lgCtDlyOn geLo
     2016-07-05 18:56:39   R-self02-lgCtOff geLo
     2016-07-05 18:56:39   R-self02-lgCtOn geLo
     2016-07-05 18:56:39   R-self02-lgCtValHi 100
     2016-07-05 18:56:39   R-self02-lgCtValLo 50
     2016-07-05 18:56:39   R-self02-lgIntense vol_100
     2016-07-05 18:56:39   R-self02-lgMultiExec on
     2016-07-05 18:56:39   R-self02-lgOffDly 0 s
     2016-07-05 18:56:39   R-self02-lgOffTime unused
     2016-07-05 18:56:39   R-self02-lgOffTimeMode absolut
     2016-07-05 18:56:39   R-self02-lgOnDly 0 s
     2016-07-05 18:56:39   R-self02-lgOnTime unused
     2016-07-05 18:56:39   R-self02-lgOnTimeMode absolut
     2016-07-05 18:56:39   R-self02-lgSwJtDlyOff no
     2016-07-05 18:56:39   R-self02-lgSwJtDlyOn no
     2016-07-05 18:56:39   R-self02-lgSwJtOff dlyOn
     2016-07-05 18:56:39   R-self02-lgSwJtOn no
     2016-07-05 18:56:39   R-self02-shActNum 1
     2016-07-05 18:56:39   R-self02-shActTypeMp3 0
     2016-07-05 18:56:39   R-self02-shActionType jmpToTarget
     2016-07-05 18:56:39   R-self02-shCtDlyOff geLo
     2016-07-05 18:56:39   R-self02-shCtDlyOn geLo
     2016-07-05 18:56:39   R-self02-shCtOff geLo
     2016-07-05 18:56:39   R-self02-shCtOn geLo
     2016-07-05 18:56:39   R-self02-shCtValHi 100
     2016-07-05 18:56:39   R-self02-shCtValLo 50
     2016-07-05 18:56:39   R-self02-shIntense vol_100
     2016-07-05 18:56:39   R-self02-shMultiExec off
     2016-07-05 18:56:39   R-self02-shOffDly 0 s
     2016-07-05 18:56:39   R-self02-shOffTime unused
     2016-07-05 18:56:39   R-self02-shOffTimeMode absolut
     2016-07-05 18:56:39   R-self02-shOnDly 0 s
     2016-07-05 18:56:39   R-self02-shOnTime unused
     2016-07-05 18:56:39   R-self02-shOnTimeMode absolut
     2016-07-05 18:56:39   R-self02-shSwJtDlyOff off
     2016-07-05 18:56:39   R-self02-shSwJtDlyOn on
     2016-07-05 18:56:39   R-self02-shSwJtOff dlyOn
     2016-07-05 18:56:39   R-self02-shSwJtOn dlyOff
     2016-07-05 18:58:25   RegL_03.self02   02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 24:00 25:01 26:00 27:00 28:00 29:00 2A:00 2B:FF 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:10 8C:00 8D:00 8E:01 A4:00 A5:01 A6:00 A7:00 A8:00 A9:00 AA:00 AB:FF 00:00
     2016-05-01 18:56:28   level           set_0
     2016-07-05 18:58:22   peerList        self02,
     2016-07-05 14:32:02   recentStateType info
     2016-07-05 14:32:02   state           off
   Helper:
     peerIDsRaw ,3BA00302,00000000
     Expert:
       def        1
       det        1
       raw        1
       tpl        1
     Role:
       chn        1
     Shadowreg:
     Tmpl:
Attributes:
   fp_001_DG  280,849,1,FunkGongHM_MP3__DG_Eingang,
   group      System_realDevices
   icon       audio_loudness
   model      HM-OU-CFM-PL
   peerIDs    00000000,3BA00302,
   room       SYSTEM
   webCmd     press short:press long:playTone replay

[Leeloo_Dallas]

Gibt es jemand, der helfen kann oder gar beim HM-OU-CFM-PL (MP3 - Funkgong)
R-sign=on einstellen konnte?

[Prof. Dr. Peter Henning]

Warum sollte man das tun ? Wer hat denn Interesse daran, einen Funkgong unberechtigt zu aktivieren ?

Bei aller Freude an der Digitalisierung - aber dieser modernen Version des "Schellenkloppens" (oder wie auch immer es im jeweiligen Lokaldialekt genannt wird) gebe ich wenig Aussicht auf Erfolg.

LG

pah

[Leeloo_Dallas]

Erst mal Danke für das Feedback.
Es geht mir jedoch hierbei weniger um die unberechtigte Aktivierung. Dazu kann ich Ihr Argument noch teilen.

Die unberechtigte Deaktivierung eines Alarms (Led , MP3) steht hier eher im Vordergrund.
Klar, kann jemand das Gerät einfach aus der Steckdose ziehen. Das geht aber nur, wenn bereits ein Zugriff auf das Objekt möglich ist.
Auch könnte der Strom für ganze Haus abgeschaltet werden, aber dann hat man andere Probleme,....

Konkretes Beispiel, bei dem eine unberechtigte Deaktivierung eine wichtige Rolle spielt:
Bei uns wird dieses Gerät als "inhouse- Alarm" eingesetzt, um u.a. Fehlerzustände von Geräten zu melden
z.B.
- Wasserleitung undicht => LED= blinkt gelb
und
- als Alarmsignal (Alarmanlage an=LED grün ; Einbruch => LED=blinkt rot und MP3=laute Sirene).
Dieser "inhouse-Arlarm" dient dazu das Haus abzusichern, wenn wir uns darin befinden.
Falls sich jemand unberechtigten Zutritt verschafft hat, dann möchten wir geweckt werden.

Also aus meiner Sicht wäre es sinnvoll AES beim HM-OU-CFM-PL (MP3 - Funkgong) einzusetzten, um eine unberechtigte Deaktivierung zu verhindern.

Gruß
Leeloo

[Prof. Dr. Peter Henning]

Ich bleibe dabei, dass ich das nicht für sinnvoll halte. 

Ein Einbrecher, der durch das Mitsniffen des Verkehrs (z.B. zwischen einem Handsender und einem Türöffner, so wie das inzwischen immer häufiger im Automobilbereich geschieht) einfach mal die Tür öffnen kann, ist durchaus denkbar. Dass dieser aber durch längere Vorbereitungszeit herausfinden kann, welches interne Gerät er deaktivieren muss, scheint mir für einen Privathaushalt überzogen. Lässt sich übrigens auf einfachste Weise selbst zur Alarmierung nutzen: Wenn jemand um 3 Uhr in der Frühe meine Alarmierung ausschaltet, liegt klar eine Sabotage vor.

Viel wahrscheinlicher ist, dass der Einbrecher sich einen richtig kräftigen Sender besorgt und einfach alle HomeMatic-Empfänger lahmlegt, Wegen der verwendeten Frequenzmodulation ist das ohne großen technischen Aufwand machbar.

LG

pah

[Leeloo_Dallas]

Interessante Aspekte, die ich ggf. auch teilen kann/werde.

Wahrscheinlich gibt/gab es diese Debatte bereits, wenn nicht können wir den Thread gerne eröffnen und eine Debatte führen, wann und wie AES sinnvoll in die Hausautomation integriert werden kann. 
In etwa so: "AES in der Hausautomatisierung: Grenzen, Risiken und Möglichkeiten zur Minderung der Risiken"
Teile dazu stehen bereits, recht ausführlich und somit transparent für Interessierte, im Wiki. Danke dafür

Aber jetzt zu den zwei interessanten Aspekten Ihrer Erläuterungen.
A)

....Lässt sich übrigens auf einfachste Weise selbst zur Alarmierung nutzen: Wenn jemand um 3 Uhr in der Frühe meine Alarmierung ausschaltet, liegt klar eine Sabotage vor.

Dieser Hinweis ist korrekt und richtig. Eine Alarmanlage die diese Programmlogik beinhaltet ist sicherer als eine ohne diese Ergänzung.
Danke für diesen Hinweis, meine Alarmanlage wird sicher in den nächsten Tagen dbzgl. erweitert.

Übrigens, diese Logik lässt sich 1:1 auf den Türöffner anwenden.

Wenn jemand um 3 Uhr in der Frühe meine Tür öffnet, liegt klar eine Sabotage vor.

Da dieser Aspekt/dieses Argument sich nun sicherlich auf viele Komponenten in der Hausautomatisierung ausweiten läßt,
sich dabei bei jeder Komponente wahrscheinlich unzählige Diskussionen anschließen werden, ob es nun sinnvoll ist im jeweiligen Fall, AES zu nutzen oder nicht,
wäre es meiner Ansicht nach konsequenter die Komponenten, die eine AES-Funktionalität von Haus aus mitbringen, in vollen Umfang von FHEM zu unterstützen.

Entdeckt jemand, dass die AES-Funktion bei einer Homematic-Komponente fehlt, fehlerhaft und inkonsequent ist. Dann wird nicht darüber diskutiert, ob es nun generell sinnvoll ist oder nicht. Da mit Homematic, dies Option grundsätzlich realisierbar wäre, versuchen wir diese auch in FHEM hinzubekommen.
Aus meiner Sicht ist diese Vorgehensweise zielführender und bedarf in Summe weniger Aufwand.


B)

Viel wahrscheinlicher ist, dass der Einbrecher sich einen richtig kräftigen Sender besorgt und einfach alle HomeMatic-Empfänger lahmlegt, Wegen der verwendeten Frequenzmodulation ist das ohne großen technischen Aufwand machbar.

Dieser Aspekt war mir gar nicht bewußt und die techn. Umsetzung ist mir noch völlig fremd.
Da es aus Ihrere Sicht jedoch wohl mit einfachsten Mitteln realisiert werden kann, gehört dieser Hinweis wohl eindeutig in den Bereich "Grenzen".
Ein Störsender stellt somit die "Sicherheit" aller Funk-Komponeten in Frage, unabhängig von AES.
AES-Komponeten bieten hier keine zusätzliche Sicherheit. Wenn das so stimmt, dann ist dieser Hinweis im Wiki sicherlich sehr hilfreich und wichtig.

Sorry für meine ggf. naive Nachfrage zu diesem Bereich. Wie gesagt, für mich ist dieser Zusammenhang neu.

Kann das Risiko eines "Störsender" ähnlichen dem "Workaround" aus Abschnitt A minimiert werden?

Etwa:
Wenn meine Zentrale um 3 Uhr in der Frühe x von y Komponenten nicht erreichen kann, liegt wahrscheinlich eine Sabotage vor.


Gruß
Leeloo

[Prof. Dr. Peter Henning]

Diese Nachfragen sind nicht überflüssig, sondern sogar sehr wichtig.

Nochmal zum AES: Der Signaturmodus verdoppelt, grob gesagt, die Funklast: Kommando, Challenge, Response. Kommando und Response sind Aussendungen der Hauszentrale (oder des auslösenden Senders). Da für diese auch die 1%-Regel gilt, kann dadurch eine deutliche Verzögerung entstehen.

Das reine Öffnen der Tür um 1 Uhr in der Frühe ist nicht unbedingt eine Sabotage - vielleicht komme ich von einer Dienstreise (unwahrscheinlich...) oder einem Ball (schon eher ...).

Eine professionelle Intrusion Detection arbeitet mit Mustern von Events. In FHEM lässt sich das sehr schön mit dem Device sequence realisieren - beispielsweise wird meine Alarmanlage ausgeschaltet, indem zwei Köpfe in einer bestimmten Sequenz bedient werden (es gibt natürlich, um den WAF zu erhöhen, auch noch eine einfachere Möglichkeit...).

Beispielsweise könnte eine Alarmanlage für 15 Minuten unscharf geschaltet werden, indem erst das Garagtentor und dann innerhalb von 10 Minuten die Haustür betätigt werden. Oder ein Alarm wird ausgelöst, wenn nachts die Tür geöffnet, das Licht aber nicht angeschaltet wird.

Ich hatte auch schon überlegt, das in das Modul 95_Alarm.pm einzubauen, habe aber bisher noch nicht sgefunden, was sich nicht mit sequence erledigen ließe.

LG

pah

[Leeloo_Dallas]

Um Ihren Gedanken weiter zu führen,...

demnach sollten alle Geräte die an einer solchen sequence mitwirken auch R-Sign=on erhalten.

Diese Schlußfolgerung kommt meinem Argument natürlich entgegen.

Entdeckt jemand, dass die AES-Funktion bei einer Homematic-Komponente fehlt, fehlerhaft und inkonsequent ist. Dann wird nicht darüber diskutiert, ob es nun generell sinnvoll ist oder nicht. Da mit Homematic, dies Option grundsätzlich realisierbar wäre, versuchen wir diese auch in FHEM hinzubekommen.

Unabhängig davon kann aus meiner Sicht, das von Ihnen aufgeführte Risiko "Störsender", nicht mit einer sequence gemindert werden.

Zur Erweiterung der Integration von HM-OU-CFM-PL in FHEM :
Ich habe mir die "HMConfig.pm" gestern mal näher angesehen und verschiedenes ausprobiert. Leider konnte ich den HM-OU-CFM-PL (MP3 - Funkgong) nicht sauber integrieren. Mir war es nicht möglich den Code so zu ändern, dass ich das Register R-Sign setzen konnte.
Leider ist noch nicht ganz klar, in welchem Abschnitt die "calculation" gemacht wird.

Code Auswählen Erweitern

cannot calculate value. Please issue set FunkGongHM_MP3__DG_Eingang getConfig first - invalid

Gruß
Leeloo

[Prof. Dr. Peter Henning]

demnach sollten alle Geräte die an einer solchen sequence mitwirken auch R-Sign=on erhalten.

Nur, wenn es sich um die Alarmauslösung handelt, oder um das direkte Schalten eines sicherheitskritischen Gerätes.

LG

pah

[Leeloo_Dallas]

demnach sollten alle Geräte die an einer solchen sequence mitwirken auch R-Sign=on erhalten.

Klar bzw. Logisch, war ja auch so gemeint. Aber sicher ist sicher

Schön, jetzt haben wir zusätzliche Kenntnisse bzgl. der Nutzung von AES in der Hausautomatisierung zusammen getragen.   

Im konkreten Fall "HM-OU-CFM-PL (MP3 - Funkgong)" können wir also festhalten:
Da es sich beim HM-OU-CFM-PL (MP3 - Funkgong), um ein sicherheitskritisches Gerätes handeln kann, wäre es sinnvoll hierbei auch R-Sign=on nutzen zu können.
Zusätzlich handelt es sich dabei um eine Komponente, die diese Funktionalität von Haus aus unterstützt. Weshalb wir versuchen werden diese Funktionalität auch in FHEM zu implementieren.

Zur Implementierung:
Wie lässt sich dies nun in FHEM realisieren?
Reicht eine Anpassung in "HMConfig.pm"?
=> Wenn "Ja", welche?
=> Wenn "Nein", was muss noch angepaßt werden?

Vorarbeit zum Coding:
Zeilen in der HMConfig.pm die mMn mit der gewünschten Implementierung in Zusammenhang stehen:

Zeile 190 => Erweiterung unklar

Code Auswählen Erweitern

,"0075" => {name=>"HM-OU-CFM-PL"            ,st=>'outputUnit'        ,cyc=>''      ,rxt=>''       ,lst=>'3'            ,chn=>"Led:1:1,Mp3:2:2",}


Zeile 1082  und 1083 => Erweiterung um jeweils ein ",sign            =>1"

Code Auswählen Erweitern

,"HM-OU-CFM-PL01"    =>{ ActTypeLed      =>1,sign            =>1}
,"HM-OU-CFM-PL02"    =>{ ActTypeMp3      =>1,Intense         =>1,sign            =>1}


Gruß
Leeloo

[Prof. Dr. Peter Henning]

Da es sich beim HM-OU-CFM-PL (MP3 - Funkgong), um ein sicherheitskritisches Gerätes handeln kann, wäre es sinnvoll hierbei auch R-Sign=on nutzen zu können.

Pardon, aber das sehe ich immer noch nicht. Von so etwas darf die Alarmierung nicht abhängen - man denke nur an den Fall, dass der Hausbewohner  gerade die Haare föhnt.

LG

pah

[Leeloo_Dallas]

- man denke nur an den Fall, dass der Hausbewohner  gerade die Haare föhnt.

?

Mit Verlaub, was will mir der Autor mit diesen Worten in Wirklichkeit mitteilen?
Ich kann darin keinen Beitrag zur konstruktiven Diskussion erkennen.

Gruß
Leeloo

[Prof. Dr. Peter Henning]

Nun, dann ganz langsam zum Mitschreiben: Die Audio-Leistung des MP3-Funkgongs ist nicht so groß, dass man ihn im Nebenraum hören würde, wenn man sich gerade die Haare föhnt.

LG

pah

[Leeloo_Dallas]

Ah,... jetzt ja.
Dieser Anwendungsfall ist so realitätsfern, dass ich nicht gleich darauf gekommen bin.

Aber seien Sie versichert, mit einer entsprechenden Audio-Datei sowie einer guten Platzierung des Alarmgebers im Haus,
hört man den Alarm sogar, wenn im gleichen Haus Schlagzeug spielt wird.
Sogar am Drum-Set selbst kann man dann das Signal noch hören.
Letzteres ist ein Beispiel aus der Praxis, da ich so beim Schlagzeugspielen informiert werde, wenn jemand an der Haustür klingelt.

Um auf Nummer sicher zu gehen, dass dies nicht als nächstes Gegenargument genutzt wird.
Die wahrscheinlich eines Einbruchs sinkt natürlich signifikant, wenn im Haus ein Schlagzeug zu hören ist.

Gruß
Leeloo