Homematic vom Nachbarn mitspionieren - aber haufenweise attack:: im Log

[Pfriemler]

In meiner Nachbarschaft wurde letztes Jahr ein größeres Projekt aufgezogen: Der Status von ca. 30 Fensterkontakten landet unter anderem auf vier HM-OU-LED16-Anzeigen. Die Geräte wurden alle bei der Einrichtung auch automatisch bei mir autocreated. Die verwendete Zentralen-hmId ist bekannt und völlig verschieden von meinen.
Ich möchte ein wenig "spionieren". Alle Fensterkontakte sind "ignored", auch die LED-Kanäle der Anzeigen, nur die Anzeigegeräte selbst liefern ihren LED-Status als hex-Wert. Sie sind alle readonly=1.

Jetzt führt offenbar jede Änderung des Status der LEDs zu einer attack::-Warnung in meinem Log, bspw.

Code: [Auswählen]

2021.11.02 14:32:03 2: CUL_HM Nachbar_Dis16LED1 attack::1zzzzzzdddddd800C01(mit zzzzzz als Zentralen-ID und dddddd als ID eines Displays).

Wenn ich ein HM-IODev (was nicht in meiner VCCU läuft) hernehme und ihm die Fremd-Zentralen-ID zuweise, könnte ich verstehen, dass sich FHEM über Pakete beschwert, die von ihm kommen sollten, es aber nicht tun. Wenn aber Geräte einfach nur ganz offensichtlich rein zum "Mitlesen" definiert sind, sehe ich keine Grundlage für attack:: Meldungen.

Welchen Trick übersehe ich? Wird man die Meldungen auch anderweitig los?

edit: Moooment. Offenbar in einem Anfall geistiger Umnachtung erstellt, finde ich gerade hier einen "virtual" mit der hmID der Zentrale. Nicht dass dieses Ding FHEM dazu veranlasst zu denken, dass da draußen jemand fremdes mit der ID einer eigenen Definition herumsendet? ist gelöscht, beobachte...

[frank]

untersucht werden messages an die ledanzeige.
gute messages kommen entweder von "pairedTo" oder von den peers. alles andere ist attack.

du könntest deine led anzeige auf die nachbar hmid umpairen.
vielleicht funktioniert auch ein peering mit dem io.
theoretisch am besten müsste eine 2. vccu mit nachbar hmid sein der du das io zuweist und dann die ledanzeige damit pairst. wie gesagt theoretisch. 

[Pfriemler]

Die Idee mit der zweiten VCCU hatte ich auch schon. Abgesehen vom Management sollte aber die Zuteilung eines IO allein ähnliches bewirken: Selbst wenn aus FHEM-Sicht alles so aussieht, als seien die Fremd-Displays mit meinem dafür abgestellten IO gepairt, müssen die normalen Meldungen von deren Zentrale ja wie attack wirken.

Ich weiß nicht: nach der aktuellen Logik gibt es ja nur keine Attacks mehr, wenn FHEM alle infrage kommenden Sender kennt. Das sollte normalerweise ja der Fall sein, macht aber ein stilles Mitlesen fremder Geräte auf diese Weise völlig unmöglich, es sei denn, ich schneide die Konfigurationsnachrichten der Fremdzentrale ebenfalls vollständig mit und mein FHEM wäre dann im Bilde. Mir fällt gerade auch kein Mechanismus ein, mit dem man das umgehen könnte.

Letztes Jahr war das noch kein Thema, da lief hier alles irgendwie mit ohne dass das Log zumüllte.
Ich würde mir einen Mechanismus wünschen, mit dem man die attacks zumindest für einzelne Geräte deaktivieren kann.

readOnly scheint auch irgendwie nicht wirklich ernstgenommen zu werden: Mit einem gerade mal testweise "scharfen" IO mit der Fremdzentralen-ID habe ich mit einem simplen getConfig massenhaft Aussendungen an das Gerät produziert (der AskSinAnalyzer hat's gezeigt) und somit wohl für ein Rudel Sabotagemeldungen in deren CCU gesorgt. Dabei hätte ich mit diesem Display sowieso gar nicht reden können - es steht auf aesKeyNbr=02 und den Schlüssel habe ich natürlich hier nicht.
Bei der Gelegenheit hat das IO auch gleich noch ein Rudel "help me!" abgesondert, nur weil ein paar der ignored Devices gerade Nachrichten geschickt haben.

Jetzt ist erst mal alles auf dummy=1, vielleicht ist jetzt Ruhe.
Stalken ist ja auch nicht unbedingt schön, aber wenn man offenbar auch nicht mal mit Wissen und Dulderung der Nachbarn deren Geräte unfallfrei mitverfolgen kann, fände ich das etwas schade.