aktuelles HowTo gesucht für Umstieg von MAXCube auf CUL/MAX_CUL + Kaufempfehlung

[sTaN]

Liebe Community,

es ist nach knapp 8 Wochen wieder passiert, dass mein Cube nun alle Einstellungen verloren hat, nach dem ich für ca. 1 Woche nicht zu Hause war.

Ja ich habe mich lange davor gedrückt, in der Hoffnung, dass es vor ca. 8 Wochen eine einmalige Sache war, aber nun werde ich fast wahnsinnig...

Das Forum ist ja bereits voll von den Empfehlungen auf CUL/MAX_CUL umzusteigen.

Gibt es ein aktuelles HowTo, was relativ aktuell und kompakt beschreibt, welchen CUL man kaufen sollte und wie man rasch seine Konfiguration daraufhin umbaut, ohne ggf. alle Wand- und Heizthermostate in FHEM neu anzulegen?

Über einen Direktlink zu einem aktuell empfohlenen CUL würde ich mich ebenfalls freuen. Ich verwende bereits einen CUL von Busware zur Steuerung zahlreicher FS20 Komponenten etc.

Momentan verliere ich im Forum total den Überblick, was aktuell ist und wie man am besten vorgeht.

Ich bedanke mich und wünsche bereits jetzt einen guten Rutsch!
sTaN

[willyk]

Meine Empfehlung: den Cube umflashen. Das geht ganz prima, der Cube hat dann die Funktion eines CUL, und du kannst dir die Anschaffung eines CUL sparen.
Gruss
Willyk

[Wzut]

der wichtigste Schritt : Backup von jedem Device machen -> set <name> saveConfig
diese .max Dateien gut aufheben ( stehen unterhalb von log/ )
 
Die sechstellige MAXID des Cube aufschreiben -> Internals addr

Diese beiden Sachen sollte jeder MAXLAN Nutzer min 1x gemacht haben, egal ob sein Cube Alzheimer hat oder nicht !

Ich schreiben es nun zum X-ten mal : Bitte kein MAX Device in FHEM löschen !!!

Der zweite Schritt ist die Beschaffung eines CUL :
a. einfach , billig und von jedem zu stemmen der eine Büroklammer aufbiegen und zu einem U wieder zubiegen kann : CUBE neu flashen -> http://forum.fhem.de/index.php/topic,38404.0.html

b. billig : einen nanoCUL bauen oder im Marktplatz oder sonstige Quellen einen fertigen kaufen
 - altenrativ : MapleCUL
c. teuer : einen original Busware CUL kaufen

der dritte Schritt ist die Inbetriebnahme, hier muss man unterscheiden ob man hart vom Cube zum CUL wechseln möchte
( bei a. wird das so sein )
oder ob man den CUL ersteinmal passiv zusätzlich zum Cube ins System nimmt.

CUL als FHEM Device anlegen  Wer a. gewählt hat kann den CUBE nun auch als USB Gerät verwenden
Tut Euch gleich einen Gefallen und verwendet bei USB nicht /dev/ttyACM0 , /dev/ttyUSB0 , etc
nehmt gleich die by-id oder by-path Variante und denkt daran das bei MAX die FHTID 0000 ist
Bsp :

Code: [Auswählen]

define CUL CUL /dev/serial/by-id/usb-busware.de_CUL868-if00 0000
CUL_MAX Device anlegen

Die sechstellige MAXID habt ihr ja bereits oben aufgeschrieben, wenn nicht jetzt ist die letzte Gelgenheit !
Nun das CUL_MAX Device (cm) anlegen

Code: [Auswählen]

define cm CUL_MAX <sechstellige MAXID>Kommt es hier zu einer Fehlermeldung (hängt von der Version der MAX Module ab) save & shutdown restart
das cm bekommt als Attribut IOdev  den Namen des CUL

wer "wechselt" :
Das MAXLAN Device kann nun gelöscht werden, aber nur das !
Nun jedesMAX Device anwählen und als IOdev statt des alten MAXLAN Device das neue cm eintragen.
FHEM neu starten

wer den CUL ersteinmal nur zusätzlich passiv nutzen möchte  :

Nachrichten vom Device gehen nun direkt via CUL->CUL_MAX->MAX zum FHEM Device , d.h. es aktualisiert sofort seine Werte und nicht erst beim nächsten Cube Poll.
 
 

[sTaN]

Danke Wzut! Genau wonach ich gesucht habe! Ich hoffe dies hilft ggf. auch anderen.

Ich habe mich für die Variante c. entschieden und warte nun auf meinen CUL von Busware.
Bis dahin muss ich eben noch auf die manuelle Steuerung der Heizungsthermostate zurückgreifen, aber den Cube wollte ich mir noch original aufheben!

Gruß
sTaN

[Wzut]

Halte trotzdem die Augen auf nach einem gebrauchten Cube ! Stichwort anderer Thread  Multi IO
Kannst aber auch deinen heutigen CUL mal von SlowRF auf MAX umstellen und einen Probedurchlauf starten.

[sTaN]

Kannst aber auch deinen heutigen CUL mal von SlowRF auf MAX umstellen und einen Probedurchlauf starten.

Ach ich kann den bestehenden CUL ohne umflashen mit MAX temporär nutzen bzw. von SlowRF auf MAX umstelen?

Das würde ich natürlich gern mal probieren. Ich wollte sowieso den neuen CUL mit aktuellster Firmware 1.67 flashen und als primären CUL für alles andere verwenden und den bestehen alten für MAX, da ich das letzte mal die Firmware glaube 2013 mit Version 1.53 geflasht habe.

Wie gehe ich hier am Besten vor bzw. wie kann ich den bestehenden temporär auf Max umstellen und wieder zurück.
Kann ich dann auch den neuen CUL einfach mit dem aktuellen CUL tauchen oder muss ich diesen auch erneut mappen bzw. alle Devices daraufhin umstellen?

Aktuell ist mein CUL wie folgt eingebunden:
define CUL1 /dev/ttyACM0@9600 1234

Du empfiehlst aber diesen by.id einzurichten. Kann ich einfach im DEF den Link abändern oder den CUL1 in CUL2 umbenennen und wenn der neue kommt diesen als CUL1 neu anlegen?

EDIT: Ein

Code: [Auswählen]

ls -l /dev/serial/by-id/
gibt mir folgendes aus:

Code: [Auswählen]

lrwxrwxrwx 1 root root 13 Oct  1 20:27 usb-busware.de_CUL868-if00 -> ../../ttyACM0

Gruß
sTaN

[Wzut]

solange du nur 1 USB Gerät hast kannst bei deiner  dev/ttyACM0 beleiben , aber sobald der zweite dazukommt ist das Chaos vorprogrammiert.
Daher ändere es jetzt schon, egal ob er für FS20 genutzt wird oder MAX.

Lege doch jetzt schon das cm Device an wie beschrieben, solange der CUL auf rfmode != max steht passier eh nichts.
Das cm bekommt kein MAX telegramm vom CUL.
Dann änderst du einfach mal den rfmode und save , shutdown restart
Teste
Schalte den CUL wieder zurück und  save , shutdown restart

[sTaN]

solange du nur 1 USB Gerät hast kannst bei deiner  dev/ttyACM0 beleiben , aber sobald der zweite dazukommt ist das Chaos vorprogrammiert.
Daher ändere es jetzt schon, egal ob er für FS20 genutzt wird oder MAX.

Das wollte ich soeben machen. Habe auch gelesen, dass bei zwei CUL Devices von Busware die id immer die gleiche ist und man diese gar nicht unterscheiden kann?

Ich wollte soeben das DEF des CUL1 devices ändern:

Code: [Auswählen]

#/dev/ttyACM0@9600 1234
/dev/serial/by-id/usb-busware.de_CUL868-if00@9600 0000
Allerdings habe ich folgende Fehlermeldung erhalten:

FHTID must be H1H2, with H1 and H2 hex and both smaller than 64

Habe dann statt 0000 die 1234 gewählt. Ich dachte ggf. die 1234 waren noch Altlasten, da ich damals mit FHT Heizthermostaten angefangen habe und wollte deshalb auf 0000 umstellen. Aber in beiden Fällen erhalte ich den Fehler.

Das cm device lege ich dann gleich mal an und setze, wenn ich den CUL1 auf id umgestellt habe mal das attribut rfmode = MAX. Bisher hatte ich das Atribut gar nicht gesetzt, aber er schein SlowRF dann immer als Standard zu nehmen.
Verdammt lange her, dass ich mich mit dem CUL beschäftigt habe. Das macht man in der Regel ja nur am Anfang. Sorry deshalb für die Fragerei!. Aber vielleicht passt das noch sehr gut in den Thread Titel HowTo! ;-)

EDIT: Ich musste die Zeile #/dev/ttyACM0@9600 1234 aus dem DEF entfernen. Aufgrund dessen kam die Fehlermeldung. Scheinbar mag er keine Kommentare.

Gruß sTaN

[sTaN]

Lege doch jetzt schon das cm Device an wie beschrieben, solange der CUL auf rfmode != max steht passier eh nichts.
Das cm bekommt kein MAX telegramm vom CUL.
Dann änderst du einfach mal den rfmode und save , shutdown restart
Teste
Schalte den CUL wieder zurück und  save , shutdown restart

Habe mir jetzt das device cm angelegt mittels:

Code: [Auswählen]

define cm CUL_MAX CubeAdresse
in meinem CUL1 device habe ich das Attribut rfmode = MAX gesetzt und mal im Badezimmer das WT, HT und Fensterkontakt das Attribut IODev von CubeMax auf cm. Dann den Cube stromlos gemacht bzw. das Netzwerkkabel gezogen. Anschließend gespeichert und fhem neugestartet.

Allerdings bleibt das device cm auf state ? ? ? und ich kann auch weiterhin noch meine FS20 Steckdosen etc. steuern. Scheinbar greift der rfmode noch nicht? Neu anlernen muss ich die devices doch nicht oder?

EDIT: Und im Log steht folgender Fehler:

Code: [Auswählen]

2020.12.29 21:19:25 1: cm, Send Queue error CUL  did not answer request for current credits. Waiting 5 seconds
Gruß
sTaN

[Wzut]

Wenn die "echten" CULs immer die gleiche ID haben kannst du noch auf by-path ausweichen, dann stimmt es solange du den USB Port nicht wechselst.
Machst du aber nichts bekommst du ACM0, ACM1 usw. Das geht dann eine Weile gut bis irgendwann nach einem Neustart der bisherige ACM0 plötzlich ACM1 ist und vice versa. Daher habe ich mir schon lange angewöhnt nie die einfache Variante zu nehmen selbst wenn gerade nur ein USB Gerät gesteckt ist.

Dein cm Device kann nicht mit dem CUL reden, bzw. er gibt auf die credit10ms Anfrage keine Antwort. Eigentlich sollte dann etwas im Log zu finden sein direkt nach Neustart wenn cm erstmalig Kontakt mit dem CUL aufnimmt um dessen Init String zu setzen.
Schau dir mal deinem CUL an bzw poste ein list von ihm und dem cm Device.

Und nein da wird nichts neu gepaired !  Die MAX Geräte haben keine Ahnung das ihre Zentrale (mit der gleichen Adresse) nun eine neue Hardware ist.
Daher ist das ja so elegant wenn man die alte MAXID nimmt, da man mit wenigen Klicks und einem FHEM Neustart sofort wieder den alten Zustand hat.
 

[sTaN]

Wenn die "echten" CULs immer die gleiche ID haben kannst du noch auf by-path ausweichen, dann stimmt es solange du den USB Port nicht wechselst.
Machst du aber nichts bekommst du ACM0, ACM1 usw. Das geht dann eine Weile gut bis irgendwann nach einem Neustart der bisherige ACM0 plötzlich ACM1 ist und vice versa. Daher habe ich mir schon lange angewöhnt nie die einfache Variante zu nehmen selbst wenn gerade nur ein USB Gerät gesteckt ist.

Habe den bestehenden mal by-id eingebunden und schau mal, wie es mit dem Neuen aussieht. Vermute mal der wird die gleiche haben und ich binde ihn by-path ein.

Hier mal die lists des CUL1 und des cm devices:

CUL1 device:

Code: [Auswählen]

Internals:
   CMDS       BCFiAZEGMRTVWXefmltux
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 0000
   DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00@9600
   FD         11
   FHTID      0000
   FUUID      5c464392-f33f-dd7c-eedb-60b0ff5c3d16ecea
   NAME       CUL1
   NR         114
   NR_CMD_LAST_H 1
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.53 CUL868
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-12-29 21:59:40   cmds             B C F i A Z E G M R T V W X e f m l t u x
     2020-12-06 18:14:25   raw             is0FFF0F0FFF10
     2020-12-29 21:59:40   state           Initialized
     2020-12-29 21:23:56   version         V 1.53 CUL868
   XMIT_TIME:
     1609590405.17716
Attributes:
   group      Systeme
   icon       cul_cul
   room       Wohnzimmer
Wobei ich das attr rfmode = MAX aktuell wieder entfernt habe. Bei initString stand meines erachtens neben dem X21 noch etwas...

cm device:

Code: [Auswählen]

Internals:
   DEF        1XXXXX (=Cube Adresse)
   FUUID      5XXXXX
   LASTInputDev
   NAME       cm
   NR         789
   STATE      Defined
   SVN        22175
   TYPE       CUL_MAX
   addr       1XXXXX (=Cube Adresse)
   cnt        0
   pairmode   0
   retryCount 0
   sq         0
   READINGS:
     2020-12-29 21:33:01   state           ???
   sendQueue:
Attributes:
   fakeSCaddr 222222
   fakeWTaddr 111111
   room       MAX
Ansonsten warte ich aber auf den neuen CUL, der hoffentlich nächste Woche kommt. Mein Idee ist es, die aktuellste Firmware auf den neuen zu CUL flashen, alten CUL1 in CUL2 umzubennen und diesen den neuen als CUL1 zu definieren. Dann den alten CUL mit neuster Firmware flashen und für MAX einzurichten.
Mal schauen wie es dann aussieht.

EDIT:
Hier noch mal das list der devices, nachdem ich beim CUL1 das attr rfmode = MAX gesetzt habe, bei einem Wandthermostat das IODev von MAXCube auf cm, Netzwerkkabel des Cube entfernt und fhem neugestartet habe:

list CUL1:

Code: [Auswählen]

Internals:
   CMDS       BCFiAZEGMRTVWXefmltux
   CUL1_MSGCNT 32
   CUL1_TIME  2021-01-02 14:11:32
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 0000
   DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00@9600
   FD         10
   FHTID      0000
   FUUID      5c464392-f33f-dd7c-eedb-60b0ff5c3d16ecea
   NAME       CUL1
   NR         114
   PARTIAL   
   RAWMSG     Z0E5302021A6EC2192F920001190028FC
   RSSI       -76
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.53 CUL868
   initString X21
Zr
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2021-01-02 14:05:47   cmds             B C F i A Z E G M R T V W X e f m l t u x
     2020-12-06 18:14:25   raw             is0FFF0F0FFF10
     2021-01-02 14:11:32   state           Initialized
     2020-12-29 21:23:56   version         V 1.53 CUL868
Attributes:
   group      Systeme
   icon       cul_cul
   rfmode     MAX
   room       Wohnzimmer
list cm device:

Code: [Auswählen]

Internals:
   CUL1_MSGCNT 35
   CUL1_RAWMSG Z0C780442191DB51A6E80001CAA
   CUL1_RSSI  -61
   CUL1_TIME  2021-01-02 14:13:13
   DEF        1XXXXX (=Cube Adresse)
   FUUID      5feb850f-f33f-1bd5-d62a-a5dbec70bb338dbb
   IODev     
   LASTInputDev CUL1
   MSGCNT     35
   NAME       cm
   NR         789
   STATE      ???
   SVN        22175
   TYPE       CUL_MAX
   addr       1XXXXX (=Cube Adresse)
   cnt        0
   pairmode   0
   retryCount 0
   sq         0
   READINGS:
     2021-01-02 14:13:13   state           ???
   sendQueue:
Attributes:
   fakeSCaddr 222222
   fakeWTaddr 111111
   room       MAX
EDIT2: Spannend finde ich aber auch, dass nachdem Setzen des rfmode = MAX meine FS20 Aktoren dennoch geschaltet werden. Wozu braucht man dann einen zweiten CUL? Aber es scheint ja noch nicht sauber zu funktionieren, also irgendwo ist da noch was faul.

EDIT3: Habe doch noch was im fhem.log gefunden:

Code: [Auswählen]

cm, did not find suitable IODev (CUL etc. in rfmode MAX)! You may want to execute 'attr cm IODev SomeCUL'
Gruß
sTaN

[sTaN]

Okay die Lösung versteckte sich in meinem letzten EDIT3. Ich musste beim device cm noch das Attribut attr IODev = CUL1 setzen und anschließend lässt sich auch das zu testende Wandthermostat schalten!
Das hatte ich in keinem Post oder Wiki gefunden, aber die Fehlermeldung ließ darauf schließen.

Aber warum dennoch meine FS20 Aktoren funktionieren ist mir noch nicht klar.

Gruß, ach und allen ein gesundes neues Jahr!!! 
sTaN

[Wzut]

Das hatte ich in keinem Post oder Wiki gefunden, aber die Fehlermeldung ließ darauf schließen.

Aber warum dennoch meine FS20 Aktoren funktionieren ist mir noch nicht klar.

a. Augen auf , das hatte ich aber oben geschrieben :

das cm bekommt als Attribut IOdev  den Namen des CUL

und ich hatte geschrieben das nach setzen des rfmode max , man save und shutdown restart machen soll weil sonst der Init String des CUL nicht richtig gesetzt wird.

b. Warum soll FS20 nicht gehen ? Wenn ich es richtig verstehe ist FS20 genauso dumm wie Intertechno, d.h. Einweg Kommunikation.
Zwei verschieden Protokolle empfangen das geht nicht, aber senden kann der "fast" alles sogar Intertechno wenn auch bescheiden kurz da der CC1101 als 868 Mhz Ausführung die falsche Abstimmung für 433Mhz hat. IMHO leidet da nur das EEPROM wenn ständig der Mode gewechselt wird.

Dann den alten CUL mit neuster Firmware flashen und für MAX einzurichten

Warum ? Am MAX Teil der CUL FW wurde schon ewig nichts mehr geändert, vermutlich ist die uralt FW genau so gut wie die aktuellste.

[sTaN]

Warum ? Am MAX Teil der CUL FW wurde schon ewig nichts mehr geändert, vermutlich ist die uralt FW genau so gut wie die aktuellste.

Hallo Wzut,

ich wollte noch auf deine Frage antworten.
Nach der Einrichtung des neuen CUL und Umstellung des alten habe ich folgende Meldung im Logfile erhalten:

Code: [Auswählen]

2021.01.12 21:24:37 2: cm, You are using an old version of the CUL firmware, which has known bugs with respect to MAX! support. Please update.
Bisher scheint aber alles ganz gut zu funktionieren, aber folgende Dinge sind mir aufgefallen:

1. Das Symbol für die Verbindung zum Cube (Antenne) blinkt an den Wand- und Heizthermostaten des öfteren. Aber das Schalten über FHEM oder die Geräte klappt ohne Probleme. Ist das normal?

2. Nun habe ich in den MAX devices natürlich noch alte MAXLAN Readings, die nicht mehr aktualisiert werden.
Kann man die ohne Probleme mit  deletereading <devspec> <readingname> entfernen bzw. ist dies überhaupt empfehlenswert?

3. Gibt es ggf. neue Readings durch CUL_MAX die jetzt durch die Verwendung der "alten" devices gar nicht angelegt werden?

4. Sollte man nach der Umstellung ggf. noch weitere Settings optimieren oder einfach alles belassen, wie es ist?

Hier mal exemplarisch das Wohnzimmer WT:

Code: [Auswählen]

Internals:
   DEF        WallMountedThermostat XXXXXX
   FUUID      5XXXXX
   IODev      cm
   LASTInputDev cm
   MSGCNT     1239
   NAME       WT_Wohnzimmer
   NR         744
   NTFY_ORDER 50-WT_Wohnzimmer
   STATE      22.0
   SVN        23290
   TYPE       MAX
   TimeSlot   1
   addr       XXXXXX
   cm_MSGCNT  1239
   cm_TIME    2021-01-14 18:15:26
   devtype    3
   type       WallMountedThermostat
   webCmd     desiredTemperature
   READINGS:
     2020-12-29 01:33:33   MAXLAN_error    0
     2020-12-29 01:33:33   MAXLAN_errorInCommand
     2020-12-29 01:33:33   MAXLAN_initialized 1
     2020-12-29 01:33:33   MAXLAN_isAnswer 0
     2020-12-29 01:33:33   MAXLAN_valid    1
     2021-01-14 18:15:26   RSSI            -40
     2020-12-29 01:33:28   SerialNr        XXXXX
     2021-01-14 17:15:29   battery         low
     2021-01-14 17:15:29   batteryState    low
     2020-12-29 01:33:28   boostDuration   5
     2020-12-29 01:33:28   boostValveposition 80
     2021-01-09 22:14:36   comfortTemperature 22.0
     2021-01-14 18:15:26   desiredTemperature 22.0
     2021-01-14 18:15:26   deviation       0.2
     2021-01-14 17:15:29   displayActualTemperature 1
     2020-12-29 01:33:28   ecoTemperature  16.5
     2021-01-09 22:13:54   error           invalid or missing value  for READING windowOpenDuration
     2020-12-29 01:33:28   firmware        1.0
     2021-01-14 17:15:29   gateway         1
     2020-11-27 19:58:47   groupid         1
     2020-12-29 20:44:24   lastConfigSave  ./log/WZ_Wandthermostat.max
     2021-01-14 14:54:57   lastTimeSync    2021-01-14 14:54:57
     2021-01-13 22:00:04   lastcmd         desiredTemperature 16.5
     2020-12-29 01:33:28   maximumTemperature on
     2020-12-29 01:33:28   measurementOffset 0.0
     2020-12-29 01:33:28   minimumTemperature off
     2021-01-14 18:11:03   mode            manual
     2021-01-14 14:54:57   msgcnt          24
     2021-01-14 17:15:29   panel           unlocked
     2021-01-14 18:15:26   peerIDs         000000,XXXXXX,XXXXXX,XXXXXX,XXXXXX
     2021-01-14 18:15:26   peerList        Broadcast,FK_Esszimmer,FK_Wohnzimmer,HT_Esszimmer,HT_Wohnzimmer
     2021-01-14 17:15:29   rferror         0
     2021-01-14 18:15:26   state           22.0
     2021-01-14 18:15:26   temperature     22.2
     2020-12-29 01:33:28   testresult      255
     2020-12-29 01:33:28   weekprofile-0-Sat-temp 18.0 °C
     2020-12-29 01:33:28   weekprofile-0-Sat-time 00:00-24:00
     2020-12-29 01:33:28   weekprofile-1-Sun-temp 18.0 °C
     2020-12-29 01:33:28   weekprofile-1-Sun-time 00:00-24:00
     2020-12-29 01:33:28   weekprofile-2-Mon-temp 18.0 °C
     2020-12-29 01:33:28   weekprofile-2-Mon-time 00:00-24:00
     2020-12-29 01:33:28   weekprofile-3-Tue-temp 18.0 °C
     2020-12-29 01:33:28   weekprofile-3-Tue-time 00:00-24:00
     2020-12-29 01:33:28   weekprofile-4-Wed-temp 18.0 °C
     2020-12-29 01:33:28   weekprofile-4-Wed-time 00:00-24:00
     2020-12-29 01:33:28   weekprofile-5-Thu-temp 18.0 °C
     2020-12-29 01:33:28   weekprofile-5-Thu-time 00:00-24:00
     2020-12-29 01:33:28   weekprofile-6-Fri-temp 18.0 °C
     2020-12-29 01:33:28   weekprofile-6-Fri-time 00:00-24:00
     2021-01-09 22:13:54   windowOpenDuration 15
     2020-12-29 01:33:28   windowOpenTemperature 12.0
   helper:
     io:
       CUL_MAX:
         raw        XXXXXXXXXXXXXXXXXXXXXXXXXX
         rssi       -40
         time       1610644526.26635
Attributes:
   IODev      cm
   alexaName  Heizung Wohnzimmer
   event-on-change-reading .*
   genericDeviceType thermostat
   group      Heizung
   icon       max_wandthermostat
   model      WallMountedThermostat
   room       Homekit,MAX,Wohnzimmer
EDIT: Ich sehe auch ab und an mal folgende Meldungen im Event Monitor, aber ohne das ich jetzt Probleme feststelle:

Code: [Auswählen]

2021-01-14 18:42:52 MAX WT_Bad 18.0 (rf error)
2021-01-14 18:42:52 MAX WT_Bad RSSI: -58
2021-01-14 18:42:52 MAX WT_Bad rferror: 1
2021-01-14 18:42:52 CUL_MAX cm CUL_MAX:ok
Danke vorab schon mal und Grüße
sTaN

[Wzut]

Die known Bugs Zeile stammt aus grauer Vorzeit, ich habe nie hier im Forum gefunden welche das sind.
I.d.R. flasht heute ja niemand mehr eine so alte FW.

1. Wenn der Funkmast blinkt hat das Gerät eine Antwort nicht bekommen die es aber gerne hätte, da hilft nur das übliche verbose 5 am cm und Log lesen.

2. ja , alles was mit MAXLAN beginnt

3. nein

4. nein sieht doch ganz gut aus. Du kannst noch das Attribut debug auf 1 setzen, das erzeugt noch ein paar Readings.
Allerdings sind die im Normalbetrieb nicht so intressant, eher für den Fall das mal etwas nicht so will wie es soll um mehr Infos zur Fehlersuche zu bekommen.

Was ich aber nicht verstehe ist warum du dir die Mühe mit den XX gemacht hast, alles keine sensiblen geheimen Daten.