CUL_MAX vergisst nach Neustart die Adresse > Fensterkontakte 3 Mal > RF-error

[max333]

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?

[Wzut]

save vergessen bzw. kann nicht durchgeführt werden ? Was sagt das Log nach save ?

[max333]

nein am save liegt es nicht. Log sagt: Global global SAVE

Alle anderen Änderungen werden auch gespeichert und auch übernommen.

[Wzut]

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

[max333]

ich habe list 3 Mal ausgeführt, vor dem Neustart, danach und nach modify:

Code Auswählen Erweitern


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.

[Wzut]

hm das ist schon ne Nummer ... streich ich dein List zusammen bleibt im Kern dreimal das  Gleiche übrig :

Code Auswählen Erweitern

   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.

[Wzut]

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.

[max333]

Ich habe den MaxCube ausgetauscht und somit ist der CUN0 scheinbar hinter das cm-Device gekommen.

Jedenfalls war das der Fehler! 1000 Dank!