Hallo,
Ich habe in meiner FHEM Installation sehr viele unbekannte CUL_FHTTK_ Devices.
So viele dass FHEM den Raum CUL_FHTTK schon gar nicht mehr laden kann.
Nach sehr langer Ladezeit bricht der Browser die Verbindung ab.
FHEM läuft aber stabil weiter. Alle anderen Räume lassen sich laden.
Geräte lassen sich steuern etc.
Jetzt habe ich direkt in der fhem.cfg gekuckt, und finde dort 480 Zeilen die mit
define CUL_FHTTK_... beginnen.
Kopiere ich die fhem.cfg ins Word, besteht sie bereits aus 250 Seiten. Irgendwann wird das bestimmt zu viel oder?!
Hat jemand einen Tipp für mich was das für Dinger sind? Wo sie herkommen?
Oder wenigstens, wie ich sie wieder aus meiner Installation kriege? Ohne sie manuell einzeln zu löschen?
Viele Grüße
Stefan
Falls es relevant ist. Mein FHEM läuft auf einem Raspberry PI 1 (RASPBMC). Die Signale werden über einen CUNO empfangen.
P.S. Ich wohne auf dem Land. Ich habe zwar Nachbarn. Aber keine Hochhäuse die eine so hohe Zahl auch nur ansatzweise erklären könnten.
Mit dem Attribut ignore kannst du die falschen Devices ausblenden:
attr CUL_FHTTK_xxxxx ignore 1
Diese werden von Fhem anschliessend nicht mehr beachtet und angezeigt.
Zitat von: SwordMaster am 22 Dezember 2015, 23:56:53
Kopiere ich die fhem.cfg ins Word, besteht sie bereits aus 250 Seiten. Irgendwann wird das bestimmt zu viel oder?!
Aber: Bitte auf keinen Fall die fhem.cfg mit Word bearbeiten. Das am besten über FHEMWEB machen.
Bei sovielen "falschen" Devices wäre es aber auch gut der Ursache näher zu kommen.
Es könnte ein einmaliges Problem sein --> Dann könnte man sie löschen und hoffen, dass es nie wieder passiert.
Es könnte aber auch sein, dass weiterhin und nochmehr entstehen und dann muss man immer nacharbeiten.
Gibt der Log etwas über die Herkunft her?
Was ist denn der IODev?
@Stromer: Danke, das Attribut kenne ich bereits. Ich will das aber nun wirklich nicht für 480 Geräte machen :)
@viegener: Bei IODev steht immer "cuno".
Habe jetzt mal ins Log gesehen. Es scheint ein wiederkehrendes Problem zu sein:
Ich habe an mehreren Tagen im Dezember Einträge wie solche (Ich habe ein paar Zeilen davor und danach auch noch mitkopiert... Sollte aber nicht dazugehören...)
2015.12.15 06:51:39 1: 192.168.53.17:2323 reappeared (cuno)
2015.12.15 06:51:40 3: cuno: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq
2015.12.15 07:32:04 1: FHTTK Unknown device d2001b, please define it
2015.12.15 07:32:04 2: autocreate: define CUL_FHTTK_d2001b CUL_FHTTK d2001b
2015.12.15 07:32:05 2: autocreate: define FileLog_CUL_FHTTK_d2001b FileLog ./log/CUL_FHTTK_d2001b-%Y.log CUL_FHTTK_d2001b
2015.12.15 07:32:05 2: autocreate: define SVG_CUL_FHTTK_d2001b SVG FileLog_CUL_FHTTK_d2001b:fht80tf:CURRENT
2015.12.15 10:31:22 1: 192.168.53.17:2323 disconnected, waiting to reappear (cuno)
2015.12.15 10:31:22 1: 192.168.53.17:2323 reappeared (cuno)
2015.12.15 10:31:22 3: cuno: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq
2015.12.15 12:42:47 1: 192.168.53.17:2323 disconnected, waiting to reappear (cuno)
Im Nachhinein wird es wohl schwierig den Grund herauszufinden. Musse ich wohl länger beobachten.
Aber habt ihr einen Tipp wie ich diese Ganzen Devices raus bekomme? Ich habe Angst dass es mir mein FHEM lamlegt wenn das so weitergeht.
So nach dem Motto: "Lösche alle Devices die mit "CUL_FHTTK_*" beginnen? :-) Hab leider kein Perl wissen :(
Weil sonst wird es echt eine mühselige Aufgabe...
Weil ja zu jedem FHTTK Device auch noch automatisch ein FileLog und ein SVG_CUL_FHTTK angelegt wurde.
Ich müsste also 480 * 3 Devices löschen.... Da ist der Weihnachtsurlaub durch bis ich da fertig bin.
Viele Grüße
Stefan
Hallo,
delete CUL_FHTTK_.*
delete FileLog_CUL_FHTTK_.*
und evtl.:
attr autocreate disable 1
(ungetestet)
und du hast hoffentlich Ruhe
Gruß
Hans
Man kann in autocreate auch das Attribut ignoreTypes auf CUL_FHTTK_.* setzen.
warum disconnected der cuno ständig? gibt es da ein zusammenhang?
Vermutlich nicht - mein CUNO hat keine disconntects aber bei mir schlagen auch laufend "neue" CUL_WS auf.
Edith: Die disconnects dürften vermutlich von einer instabilen Netzwerkanbindung kommen - Netzwerkkabel odgl.
Aber wie geschrieben - vermutlich.
Aber darum geht es hier ja nicht.