Wie werde ich die "CUL_WS UNDEFINED temp/hum sensor detected" im Log los?

[Pfriemler]

Moin,
ich nutze ein paar alte WS2000-Sensoren, und mein CUL868 (!) empfängt die im Umkreis von 5 Metern und per autocreate wurden entsprechende Devices angelegt. Ich nutze aber ein anderes Interface für den Empfang und benötige die Devices nicht. Also gelöscht und "CUL_WS.*" bei Autocreate (edit: bei ignoreTypes) hinzugefügt und Ruhe?

Ne. Jetzt füllen "CUL_WS UNDEFINED temp/hum sensor detected, code ..."-Meldungen das Log im 3-Minuten-Takt.

Lösung 1: Ich lasse die CUL_WS wieder definieren, kille die FileLogs und verschiebe sie in einen hidden room.
Lösung 2: Ich verhindere nachhaltig, dass mich CUL & Co auf neue Sensoren hinweisen. Ich brauche auch sonst keine Meldungen über irgendwelche Telegramme, die der CUL nicht auswerten konnte. Autocreate abzuschalten scheint dazu nicht zu genügen. Ich habe schon mal "do_not_notify" beim CUL gesetzt (edit: vermutlich verschont mich genau das vor irgendwelchen Dekodierfehlermeldungen seitens des CUL), aber die o.g. Meldungen kommen weiterhin. Ich habe also derzeit keine Ahnung, was das Verhalten auslöst (ist es das Modul CUL_WS? Wieso wird es aktiv?).

Die Sufu führt mich zu diversen Problemen, wo definierte Geräte erneut angelegt werden sollen/wollen im Zusammenhang mit fhem2fhem und wasweißichnichtalles. Bei mir ist nichts außergewöhnlich. Ich möchte einfach nur, dass alle CUL_WS-Geräte einfach ignoriert werden. Aber nirgends ein Hinweis, wie man dieses etwas, pardon, vorlaute Verhalten, beeinflussen kann.

Vielleicht bin ich mit diesem Wunsch tatsächlich allein...

[rudolfkoenig]

Geraet anlegen (lassen), Attribut ignore setzen.

Bei mir ist nichts außergewöhnlich.

Das sagen sie alle.

[Pfriemler]

Funktioniert. Ist im Prinzip meine Lösung 1 mit Erweiterung ... überzeugt mich aber nicht wirklich. Ich MUSS also bspw. um Ruhe vor den Geräten des Nachbarn zu haben diese bei mir anlegen um sie anschließend ignorieren zu können?  Seltsame Logik. Sinnvoll, wenn man das eigene FHEM lernbereit halten möchte,    sinnvoll, wenn FHEM weiß, auf welche Geräte es nicht zu achten braucht. Aber Handlungsbedarf in meinem System entstehen zu lassen, weil sich im Umfeld etwas ändert, ist für mich maximal Plan B.

Jm2c.

geht nich Gips nich ...

[Axel.K]

Hallo

Ich habe Autocreate ausgeschaltet.
Wenn du keine neuen Devices hast, brauchst du es doch nicht

Gruß Axel

[Pfriemler]

Ich habe Autocreate ausgeschaltet.
Wenn du keine neuen Devices hast, brauchst du es doch nicht

Das hat mit der Problemstellung wenig zu tun. Bei mir kommen schon regelmäßig neue Geräte herein und da ist Autocreate recht hilfreich (wenngleich man es auch nur zum Anlernen einschalten braucht, richtig). Umgekehrt gehe ich davon aus, dass ein ignore-Eintrag im Autocreate (siehe Eingangspost) auch dazu führt, dass das betroffene Modul still bleibt. Die erwähnten Fundstellen zur Fehlermeldung zeigen aber, dass das Problem auch bei ganz deaktiviertem Autocreate auftritt.

[Puschel74]

Ich MUSS also bspw. um Ruhe vor den Geräten des Nachbarn zu haben diese bei mir anlegen um sie anschließend ignorieren zu können?

So ist es.
FHEM kann ja nicht wissen das die Geräte nicht bei dir stehen sondern bei deinem Nachbarn.
Damit FHEM das weiß muss der User logischerweise eingreifen (können).

Auch wenn das für den Anfang ein kleines bischen Mehraufwand bedeutet.
Wobei das Device anklicken, Attribut auswählen und auf 1 setzen und mit klick auf attr übernehmen nicht wirklich so der riesige Mehraufwand ist.
Zumal das ja nur einmal pro Nachbargerät zu machen ist.
Wenn der Nachbar natürlich mehrere Geräte hat und/oder immer mal wieder eins dazu kauft ist das natürlich am Anfang aufwändiger und/oder immer mal wieder zu machen.
Beschwerden dazu bitte an den Nachbarn richten 

[Pfriemler]

Ja, ich habe nun verstanden warum es so ist wie es ist. Aber ich möchte es besser.

Klar, solange ich noch selbst ein lernendes und in Konstruktion befindliches System besitze, sind Argumente wie

FHEM kann ja nicht wissen das die Geräte nicht bei dir stehen sondern bei deinem Nachbarn.
Damit FHEM das weiß muss der User logischerweise eingreifen (können).

ja völlig richtig. Auch dass es keinen wirklichen Mehraufwand bedeutet, unerwünschte Geräte einmal "abzunicken" und in den Zoo zu sperren.

Auch wenn das für den Anfang ein kleines bischen Mehraufwand bedeutet.

Das ist ja das Problem. Es ist eben nicht nur für den Anfang. Ich will's mal nochmal klar sagen: Solche Effekte wie oben beschrieben beeinträchtigen ein fertiges und laufendes System, das an sich keiner Wartung mehr bedürfte. Selbst wenn ich autocreate abschalte, schreit eine Komponente weiter "ich sehe was was du noch nicht gesehen hast" und schafft es ganz ohne meiin Zutun, das tägliche Volumen an Logmeldungen zu verhundertfachen. Nein, ich möchte bitte einen Schalter, mit dem ich meinem System sagen kann: Ignoriere bitte alle neu auftauchenden Komponenten der Familie XY, weil ich für mich beschlossen habe, keine davon einzusetzen. Und dass das namentlich für CUL_WS geht, hat mir noch keiner hier gezeigt.

[noice]

Die Firmware vom CUL modifizieren und CUL_WS auskommentieren?!

[Pfriemler]

Ja, das ginge. Wenn man denn die Firmware von einem CUL mal eben modden und neu kompilieren kann. Geht leider auch nicht im Vorbeigehen.

Das Problem ist nach wie vor ungelöst und wird erfolgreich weiter ignoriert, so wie ich das sehe.

Mittlerweile habe ich alle Geräte in der Nähe auf der Ignore-Liste. Bis das nächste beim Nachbarn auftaucht und das Log wieder zumüllt.

[Pfriemler]

Hihi, auf der Suche nach einem aktuellen Problem finde ich meines wieder ...

Zwischenstand: Ich verwende die CUL_WS gar nicht mehr, will sie weiterhin komplett ignorieren. Wegen Empfangsproblemen kommt es regelmäßig zu Fehlererkennungen, und durch eine geänderte xx_CUL_WS.pm bei mir waren zuletzt ca 40 eigentlich nicht exisiterende Geräte angelegt. Die würde ich ungern komplett auf die ignore-Liste setzen.

Geht das immer noch nicht einfacher?

[rudolfkoenig]

Das ist aber echt eine alte Geschichte
Vorschlag: autocreate ignoreTypes auf CUL_WS.* setzen.
Alternative: patch fuer culfw bauen, damit alle 8 Bits des Checksums ausgewertet werden, nicht nur 4 (wenn ich mich recht erinnere).

[Pfriemler]

Wie ich schon eingangs sagte: Den "Patch" erwarte ich entweder in der Firmware (Funk-Familien per Befehl mute schalten), lieber aber in einer entsprechenden Event-Behandlung durch FHEM. In autocreate CUL_WS_.* zu setzen verhindert ja nur das automatische Anlegen neuer Geräte - das Log wird ja trotzdem mit "Fehlermeldungen" geflutet:

Code Auswählen Erweitern

2019.01.02 11:50:05 1: CUL_WS UNDEFINED temp/hum sensor detected, code K61301071
2019.01.02 11:51:08 1: CUL_WS UNDEFINED temp/hum sensor detected, code K31600146
2019.01.02 11:54:04 1: CUL_WS UNDEFINED temp/hum sensor detected, code K31600146
2019.01.02 11:57:37 1: CUL_WS UNDEFINED temp/hum sensor detected, code K41280238
2019.01.02 12:03:27 1: CUL_WS UNDEFINED temp/hum sensor detected, code K41280238
2019.01.02 12:06:22 1: CUL_WS UNDEFINED temp/hum sensor detected, code K41280238
...
Wie vor drei Jahren scheint die einzige wirkliche Lösung darin zu bestehen, die Geräte anzulegen und anschließend zu "ignorieren" (attr ignore 1). Auch danach wird CUL_WS bei jedem neuen Gerät der Bauart entsprechend meckern. Besser wäre es doch, wenn die entsprechenden Events gar nicht erst entstünden. Wo man da ansetzt, weißt Du sicher viel besser als ich.

Ich habe die gepatchte Version von 14_CUL_WS.pm inzwischen wieder durch das Original ersetzt - so entstehen maximal 8 Geräte, die ich dann ignorieren muss. Ein passabler, aber dennoch ein Workaround, der das Problem nicht wirklich löst...

Anfrage bei culfw/aculfw stellen?

[rudolfkoenig]

In autocreate CUL_WS_.* zu setzen verhindert ja nur das automatische Anlegen neuer Geräte - das Log wird ja trotzdem mit "Fehlermeldungen" geflutet:

Ab sofort nicht mehr: das CUL_WS Modul sucht den ersten autocreate, nimmt dessen ignoreTypes Attribut, und meldet nichts, falls CUL_WS_$cde matcht.

[Pfriemler]

(Daumen hoch) ... heruntergeladen, reloaded, autocreate gesetzt, einen häufig empfangenen Sensor gelöscht ... und nun beobachten ...

Nach drei Monaten dieser Nachtrag: TOP! Wünschte ich mir für CUL_TX auch ...