Hallo,
ich habe zwar FHEM schon einige Jahre im Einsatz, bei meinem aktuellen Problem fühle ich mich allerdings wie ein Anfänger :)
Und zwar habe ich in einer neuen Installation von FHEM einen EigenbauCUL (nanoCUL), über dem unter anderem 3 FHTTK kommunizieren. Diese sind per autocreate angelegt worden, funktionierten solange problemlos.
BIS: ich die zwecks Lesbarkeit umbenannt und in einen anderen Raum verschoben habe, also zum Beispiel durch:
rename CUL_FHTTK_2920eb Fenster_Gaestezimmer
attr Fenster_Gaestezimmer room Gaestezimmer
Dann passiert folgendes : bei der nächsten Fensteröffnung (oder battery-state Meldung des Fensterkontaktes) wird WIEDER ein neuer FHTTK mit Namen CUL_FHTTK_2920eb angelegt, der kriegt auch alle Änderungen mit, mein umbenanntes Device im Gaestezimmer ist ab diesem Zeitpunkt nutzlos..
Kann mich jemand bitte in die richtige Richtung schubsen, ich checks grade nicht..
mein CUL:
defmod CUL_868 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI035P0Z-if00-port0@38400 4711
attr CUL_868 addvaltrigger 1
attr CUL_868 model nanoCUL
attr CUL_868 rfmode SlowRF
attr CUL_868 room IO_DEVICES
Danke,
Chris
Hast Du bitte auch noch mal je ein List von dem umbenannten und dem automatisch angelegten - gerne, wenn gerade beide "aktiv" sind.
Nutz aber bitte die Code-Tags für die Lists. Danke!
Grüße
Hallo,
danke für deine Antwort - ja, hab ich - die unterscheiden sich ausschliesslich in der FUUID:
Internals:
CODE 2920eb
CUL_868_MSGCNT 12
CUL_868_RAWMSG T2920EB02
CUL_868_RSSI -75.5
CUL_868_TIME 2020-10-08 16:58:08
DEF 2920eb
FUUID 5f7dc778-f33f-fba0-7204-e790058fe0707dd2
IODev CUL_868
LASTInputDev CUL_868
MSGCNT 12
NAME Fenster_Gaestezimmer
NR 69
OPEN 0
PREVSTATE Closed
PREVTIMESTAMP 1602168838
STATE Closed
TYPE CUL_FHTTK
PREV:
STATE 02
TIMESTAMP 1602169088
READINGS:
2020-10-08 07:26:14 Previous Open
2020-10-08 16:58:08 Reliability ok
2020-10-08 16:58:08 Window Closed
2020-10-08 16:58:08 batteryState ok
2020-10-08 16:58:08 state Closed
Attributes:
IODev CUL_868
room Gaestezimmer
Internals:
CODE 2920eb
CUL_868_MSGCNT 136
CUL_868_RAWMSG T2920EB02
CUL_868_RSSI -73.5
CUL_868_TIME 2020-10-08 16:36:03
DEF 2920eb
FUUID 5f7d5de1-f33f-fba0-cfdb-37c662fe476345e4
IODev CUL_868
LASTInputDev CUL_868
MSGCNT 136
NAME Fenster_Gaestezimmer
NR 65
OPEN 0
PREVSTATE Closed
PREVTIMESTAMP 1602168862
STATE Closed
TYPE CUL_FHTTK
PREV:
STATE 02
TIMESTAMP 1602169110
READINGS:
2020-10-08 16:37:08 Previous Open
2020-10-08 16:37:30 Reliability ok
2020-10-08 16:37:30 Window Closed
2020-10-08 16:37:30 batteryState ok
2020-10-08 16:37:30 state Closed
Attributes:
IODev CUL_868
room Gaestezimmer
lg,
Chris
Zitat von: grizu am 08 Oktober 2020, 17:07:32
Internals:
CODE 2920eb
[...]
FUUID 5f7dc778-f33f-fba0-7204-e790058fe0707dd2
[...]
NAME Fenster_Gaestezimmer
[...]
Internals:
CODE 2920eb
[...]
FUUID 5f7d5de1-f33f-fba0-cfdb-37c662fe476345e4
[...]
NAME Fenster_Gaestezimmer
[...]
Jetzt frage ich mich, wie Du die beiden Lists erzeugt hast. Denn ein
list CUL_FHTTK_2920eb
und
list Fenster_Gaestezimmer
kann meines Wissens nach keines nicht zu obigem Ergebnis führen, da "CUL_FHTTK_2920eb" in keiner der beiden Definitionen enthalten ist.
Grüße
Hallo,
entschuldige die späten Antworten, im Moment is es grad ein wenig stressig..
richtig, das war unglücklich - ich habe ein list ist von einem device, das nicht funktioniert hat gemacht, dann habe ich dummerweise schon gelöscht und das funktionierende umbenannt und davon das andere list gezogen.. sorry dafür.
Ich habe allerdings im Zuge dessen dann eine "Lösung" gefunden, in Anführungszeichen deswegen, weils eigentlich keine richtige Lösung ist:
Ausganssituation : Device plus Log ist mit originalem Namen per autocreate angelegt (CUL_FHTTK...)
- umbenennen des Devices mit rename > Logfile wird automatisch mitumbenannt
- config speichern
- warten, bis das Device mit originalem Namen wieder angelegt wird
- OHNE speichern "shutdown restart" ausführen
-> das neu angelegte Device ist nicht mehr da, das umbenannte wird ab jetzt sauber mit Daten befüllt, es wird auch kein neues mehr angelegt.
Kann es sein, dass im Buffer des CULs noch Daten sind, die im fhem dazu führen, dass per autocreate das Device neu angelegt wird ? Ich kenne die Interna da zu wenig, aber sonst fällt mir keine Erklärung ein..
Jedenfalls Danke für deine Zeit, System funktioniert bei mir jetzt mal; falls jemand Interesse hat dem nachzugehen kann ich gerne testen, leider wie gesagt immer mit ein wenig Verzug :)
lg,
Chris
Also (auch keine "Lösung" ;) ) aber: ich habe autocreate "immer" aus.
AUßER: ich brauche es, weil ich dann doch mal ein neues Gerät anlege (wie oft macht man das noch, wenn das System mal eine gewisse "Reife" hat ;) )... Und dann schalte ich es halt wieder kurz ein...
Manche haben sich zum "Anlernen" auch einen cmdalias gebastelt, der dann autocreate aktiviert und das Anlernen startet etc.
(also ich schaffe es noch beide Schritte manuell zu tun ;) Und: wie oft macht man das ;) )
Ansonsten kenne ich das Modul zu wenig.
Aber andere Module, z.B. CUL_HM schaffen es auch Telegramme zuzuordnen, selbst wenn das Device anders heißt. D.h. die Zuordnung geschieht dann (wohl) nicht über den Namen, sondern über interne IDs etc.
EDIT: es gibt aber auch Module (z.B. HUE-Bridge) die haben ein "ähnliches Problem", da heißen die Devices alle HUEDevice1, HUEDevice2 usw. dort wird dann mit alias gearbeitet. Ist allerdings nur zur "Ansicht", der Schaltbefehl muss dann weiterhin über HUEDeviceX gemacht werden...
Es könnte auch helfen, den Thread von "Anfängerfragen" in den passenden Bereich zu verschieben, dann findet sich (bestimmt/vielleicht) jemand, der Ahnung von den internen Abläufen hat...
Im Anfängerbereich ist/wäre das eher "Zufall"...
Verschieben kann der Thread-Ersteller selbst!!
Gruß, Joachim