Ignorieren von Wettersensoren o.ä. THR128_??

[idansch]

Habe das Problem das sich nicht regelmäßig, aber immer wieder neue Wettermodule der Baureihe THR128_?? in mein fhem.cfg eintragen.
Mir ist klar das ich auch "fremde" Module empfange. Zur Zeit habe ich ca. 30!! Es kann doch nicht sein das meine Nachbarn sich ständig neue zulegen um mich zu ärgern. :-)
Die Daten der "Eindringlinge" sind auch nicht realistisch und manchmal nicht auslesbar ().
Zur Zeit setzte ich alle einzeln auf Ignorieren und lösche die log define. Die Liste wir aber immer länger und unübersichtlicher.

Meine Frage ist:
Wie kann ich Module der Baureihe THR128_?? (die ?? ändern sich zwischen 1 und 300) allgemein Inorieren. Am besten mit einer Definition in der fhem.cfg?

Das ist ein Beispiel von einen Eintrag. (log habe ich schon gelöscht)
define THR128_34 TRX_WEATHER THR128_34
attr THR128_34 IODev TRX_0

Danke.

[Belei]

Du kannst autocreate in der fhem.cfg ausschalten! Dann leg sein fhem keine neuen Geräte mehr automatisch an! Einfach ein #vor den autocreate Eintrag!


Gesendet von iPhone mit Tapatalk

[idansch]

Danke für die Info. Wollte aber diese Fuktion aktiv halten. Hatte mir gedacht im Befehl "ingnore 1" auf die Senoren  anzulegen.
z.B. attr THR128_* ignore 1
Wie kommt es das es so viele (in meinen Fall) THR128_?? gefunden werden. Wechseln die Sensoren ihre Bezeichnung automatisch durch?  Es kann doch nicht sein das es über 30 Einheiten in meiner Umgegebung gibt?
Oder es hat einer eine Tick! :-)

[Adimarantis]

Ich greife mal diesen alten Thread wieder auf.
Habe mir folgenden Sensor zugelegt:
https://www.amazon.de/gp/product/B07M9W6K5L/ref=ppx_yo_dt_b_asin_title_o01_s02?ie=UTF8&psc=1
Dieser wird als "THR128" erkannt.

Da Problem ist, dass es in der Nachbarschaft noch weitere dieser Sensoren gibt. Obwohl man per Schalter eine ID 1-3 einstellen kann, hat dies keinen Effekt.
Eine Analyse der Message ergibt folgendes:

Code: [Auswählen]

2021.08.09 12:20:45 5: TRX/RAW: P▒▒Y
2021.08.09 12:20:45 5: TRX: TRX_Read '085001e98d0000f859'
2021.08.09 12:20:45 5: TRX_Read rmsg '085001e98d0000f859'
2021.08.09 12:20:45 5: TRX_Read TRX_data '085001e98d0000f859'
2021.08.09 12:20:45 5: TRX_Parse() '085001e98d0000f859'
2021.08.09 12:20:45 5: rfxtrx433: dispatch 085001e98d0000f859
2021.08.09 12:20:45 5: TRX_WEATHER: decoding delay=3 hex=085001e98d0000f859
2021.08.09 12:20:45 5: TRX_WEATHER: parsing sensor_id=50 message='085001e98d0000f859'
2021.08.09 12:20:45 5: TRX_Read END
Interessant ist folgendes Feld:
085001e9 #8d00# 00f859'

#8d00# ist die ID des Sensors. Diese hat aber anscheinend nichts mit der Einstellung (1-3) am Sensor selbst zu tun sondern wird bei jedem Batteriewechsel neu vergeben.

Das würde die Masse an Sensoren erklären die der TE gefunden hat.

Aktuell wird aber nur ein THR128 erstellt - ohne "_" - eventuell hat sich da seit damals was am Modul geändert?

Interessant wäre jetzt, wenn man
a) Diese ID in einem Reading anzeigen könnte (damit man sie überhaupt weiss)
b) Man z.B. über ein Attribut festlegen kann, dass er nur Messungen dieser ID verwenden soll

So kommt man Überschneidungen mit dem Nachbarn aus und könnte theoretisch 65536 Sensoren ansteuern (naja, nicht wirklich, da die IDs ja zufällig vergeben werden, aber schon eine ganze Menge - und bei Konflikt muss man eben nochmal die Batterie rausnehmen).
Da der Sensor eine "TX" Taste hat, lässt sich die ID recht eindeutig rausfinden (eben jene die kurz nach Knopfdruck erscheint). Quasi eine Art Anlernprozess.

Jörg

[Adimarantis]

Und mal wieder gibt intensiveres Studium von Code/Doku die Antwort:
Einfach das longids Attribut setzen und schon wird der Code an den devicenamen angehängt (welcher mit dem im "DEF" verglichen wird, man also beim Wechsel des Codes nicht alle seine DOIFs ändern muss).
Noch der Tipp den Loglevel auf "3" erhöhen damit man den Code auch mitbekommt.