Ich habe seit ca. einem halben Jahr das Problem, dass nach jedem Neustart das cm Device CUL_MAX seine Adresse vergisst. Bemerkbar ist das am einfachsten an den Fensterkontakten, diese blinken 3 Mal beim betätigen. Außerdem steht bei den Fensterkontakten der Status RF-error.
define cm CUL_MAX 654321
habe ich definiert, also nicht die Standartadresse. Nach jedem Neustart von fhem muss ich erst "DEF" von DEVICE cm und dann "modify cm" klicken ohne etwas zu verändern und dann läuft wieder alles einwandfrei.
Hat jemand eine Idee woran das liegt?
save vergessen bzw. kann nicht durchgeführt werden ? Was sagt das Log nach save ?
nein am save liegt es nicht. Log sagt: Global global SAVE
Alle anderen Änderungen werden auch gespeichert und auch übernommen.
was steht denn nach dem Neustart im Def ?
Bzw. gib doch bitte mal ein "list TYPE=CUL_MAX" direkt nach Neustart ein und poste die Ausgabe
udn dann nochmal nach deiner Änderung und save
Mir fallen da jetzt spontan nur zwei Möglichkeiten ein :
a. du hast mehr ein ein cm Device in deiner config
b. du arbeitest mit include configs
ich habe list 3 Mal ausgeführt, vor dem Neustart, danach und nach modify:
Internals:
CUN0_MSGCNT 112
CUN0_RAWMSG Z0E02020208251A0311EF0001190020
CUN0_RSSI -59
CUN0_TIME 2019-09-19 11:45:09
DEF 654321
FUUID 5c952a2f-f33f-44cd-1a73-8bf065056a83ccc5
IODev CUN0
LASTInputDev CUN0
MSGCNT 112
NAME cm
NR 25
STATE Defined
TYPE CUL_MAX
addr 654321
cnt 0
pairmode 0
retryCount 0
READINGS:
2019-09-10 16:08:20 packetsLost 15605
2016-12-23 15:27:41 state 0
sendQueue:
Attributes:
DbLogExclude .*
IODev CUN0
room Gateway
showtime 1
Internals:
CUN0_MSGCNT 3
CUN0_RAWMSG Z0EB6020201756A4561230001180522
CUN0_RSSI -70.5
CUN0_TIME 2019-09-19 11:49:05
DEF 654321
FUUID 5c952a2f-f33f-44cd-1a73-8bf065056a83ccc5
IODev CUN0
LASTInputDev CUN0
MSGCNT 3
NAME cm
NR 25
STATE Defined
TYPE CUL_MAX
addr 654321
cnt 0
pairmode 0
retryCount 0
READINGS:
2019-09-10 16:08:20 packetsLost 15605
2016-12-23 15:27:41 state 0
sendQueue:
Attributes:
DbLogExclude .*
IODev CUN0
room Gateway
showtime 1
Internals:
CUN0_MSGCNT 3
CUN0_RAWMSG Z0EB6020201756A4561230001180522
CUN0_RSSI -70.5
CUN0_TIME 2019-09-19 11:49:05
DEF 654321
FUUID 5c952a2f-f33f-44cd-1a73-8bf065056a83ccc5
IODev CUN0
LASTInputDev CUN0
MSGCNT 3
NAME cm
NR 25
STATE Defined
TYPE CUL_MAX
addr 654321
cnt 0
pairmode 0
retryCount 0
READINGS:
2019-09-10 16:08:20 packetsLost 15605
2016-12-23 15:27:41 state 0
sendQueue:
Attributes:
DbLogExclude .*
IODev CUN0
room Gateway
showtime 1
Ich habe nur ein cm CUL_MaX und include configs finde ich in der fhem.cfg auch nicht.
hm das ist schon ne Nummer ... streich ich dein List zusammen bleibt im Kern dreimal das Gleiche übrig :
DEF 654321
addr 654321
DEF 654321
addr 654321
DEF 654321
addr 654321
Es wird nichts geändert, aber du erzwingst das das CUL_MAX Modul nochmal durch seine Define Sub läuft.
Die Define Sub ist ist recht simpel und überschaubar, einzig interessant ist dort der Aufruf von SetupCUL und ich denke nun kommen wir der Sache näher.
Dein Problemkind ist IMHO nicht das cm Device sondern offensichtlich müsste man dein CUN0 Device nach Neustart und Änderung näher beobachten.
Also zurück zum Anfang und nochmal ein list des CUN0 direkt nach Neustart und rf_error und nachdem du mittels DEF edit ihn wieder in die Spur gebracht hast.
was mir gerade noch einfällt :
Hast du mal umgebaut , d.h. das CUN0 Device war früher mal etwas anderes ?
Wenn ja , wirf mal einen Blick in deine fhem.cfg. Steht das cm Device vor oder nach dem CUN0 ?
Wenn es vor dem CUN0 steht dann hast du das typische Reihenfolge Problem und das würde sowohl die Symptome als auch deine erfolgreiche Bekämpfung erklären.
Ich habe den MaxCube ausgetauscht und somit ist der CUN0 scheinbar hinter das cm-Device gekommen.
Jedenfalls war das der Fehler! 1000 Dank! :) :) :) :) :) :)