FHEM Forum

FHEM - Hausautomations-Systeme => MAX => Thema gestartet von: Parador am 28 September 2019, 19:44:46

Titel: Probleme bei Umstieg auf geflashten Cube
Beitrag von: Parador am 28 September 2019, 19:44:46
Hallo Zusammen,

ich muss irgendwas falsch gemacht haben. Nachdem ich das Cube flashen wie hier https://forum.fhem.de/index.php/topic,38404.0.html (https://forum.fhem.de/index.php/topic,38404.0.html) beschrieben hinbekommen habe, wollte ich mit einem Heizkörper-Thermostat HKT anfangen.
Schritt1: Reset des HKT - erfolgreich , Schritt2: Pairing mit dem neuen Cube - erfolgreich, Schritt3 testen, ob Einstellungen gesendet werden - Mißerfolg
Wenn ich das richtig sehe, versucht FHEM nun über den noch exisiterenden MAXLAN-Cube Befehle an den mit dem MAX-CUL gepairten HKT zu senden, was nicht klappt... auf jeden Fall kommt nichts an...

Wer kann mir Tipps geben, bzw. was kann ich liefern, damit Ihr helfen könnt.
Vielen Dank im Voraus
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Jackson am 30 September 2019, 07:42:36
Moin,

in den Attributen vom Device sollte IODev zur Verfügung zu sein. Stell den auf den MAXCUL um.
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Wzut am 30 September 2019, 10:28:04
fast richtig :)
jedes MAX! Device muß mit seinem Attribut IODev auf das CUL_MAX Device zeigen (im Wiki cm genannt)
Das CUL_MAX Device hat selbst wieder ein Attribut IODEV das muß auf den umgebumsten Cube zeigen ( TYPE = CUL )
D.h. im Gegensatz zu HM haben hier leider eine Dreierkette. Wichtig ist noch beim CUL den richtigen RF Mode zu setzen und beim CUL_MAX Device die eigene ID als Parameter beim DEF
Wenn du dir noch einen Gefallen tun willst nimmst du eine andere sechstellige Zahl als 99% der MAX User mit ihrer aus dem Wiki abgeschriebenen 123456 :)   
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Parador am 30 September 2019, 20:00:23
Hey Danke erstmal für die Unterstützung!
ich werde zwar schon besser beim Umgang mit FHEM, aber "internals" hab ich bisher noch nicht geändert.
Vielleicht könnt Ihr mir da nochmal weiter helfen. Habe im Forum was zum Befehl defmod gelsen, möchte aber nichts falsch machen...

Den richtigen RF Mode hab ich m.M. nach gesetzt, konnte ja auch ein Pairing machen. Das mit der ID hab ich vermutlich nicht hinbekommen, wenn ich das richtig interpretiere steht da "0000" bei mir

Meine "alten" HKTs lauf über ein IODev "ml"
Die beiden neuen Devices des geflashten Cubes habe ich "CULMAX_Lan_0" (Type CUL_MAX)  und "MAX_Lan_CUN" (Type CUL) genannt.
Der HKT den ich umstellen wollte ist automatisch angelegt worden und nennt sich aktuell noch "MAX_0a23c1"


List MAX_Lan_CUN:
Internals:
   CMDS       
   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        192.168.1.49:2323 0000
   DeviceName 192.168.1.49:2323
   FHTID      0000
   FUUID      5d8f4bb4-f33f-71bb-6482-d32ed7376d2045c3
   NAME       MAX_Lan_CUN
   NEXT_OPEN  1569866143
   NR         376
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   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:
     2019-09-28 19:20:27   cmds            B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2019-09-28 19:32:47   credit10ms      3311
     2019-09-30 19:54:43   state           Initialized
Attributes:
   rfmode     MAX
   room       CUL_MAX


List CULMAX_Lan_0:
Internals:
   DEF        123456
   FUUID      5d8f50ee-f33f-71bb-8362-e8d4326e68ba946a
   IODev      MAX_Lan_CUN
   IODevName  MAXCUN
   NAME       CULMAX_Lan_0
   NR         377
   STATE      Defined
   TYPE       CUL_MAX
   addr       123456
   cnt        0
   pairmode   0
   retryCount 0
   READINGS:
     2019-09-28 19:27:00   packetsLost     3
   sendQueue:
Attributes:
   IODev      MAX_Lan_CUN
   room       CUL_MAX


Wenn Ihr mir jetzt mit den richtigen Befehlen weiterhelfen könnt wäre das spitze
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Wzut am 02 Oktober 2019, 09:38:44
Zitat von: Parador am 30 September 2019, 20:00:23
Das mit der ID hab ich vermutlich nicht hinbekommen, wenn ich das richtig interpretiere steht da "0000" bei mir
Nein , schau dir dein CULMAX_Lan_0 an :
DEF        123456
addr       123456

Da du nun doch schon mit der 123456 angefangen hast, mach halt damit weiter. Nur wundere dich nicht wenn eines Tages dein Nachbar auf die gleiche gute Idee kommt ...
Zitat von: Parador am 30 September 2019, 20:00:23
aber "internals" hab ich bisher noch nicht geändert
--snipp --
Habe im Forum was zum Befehl defmod gelsen
Nix defmod , im Webfrontend Internals des CULMAX_Lan_0 einfach links auf DEF klicken und in dem großen Textfenster die 123456 ändern und den modify Knopf drücken. Allerdings hast ja jetzt schon deinem ersten MAX! Device "123456" ins Hirn geschrieben, das müsste dann zuerst wieder via Werksreset dumm gemacht werden.
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Parador am 02 Oktober 2019, 11:59:49
Hi, ok, dass hab ich jetzt gesehen und verändert. Dem HKT werde ich heute Abend die neue Zahlenkombi beibringen, kein Thema...
Was mir aber jetzt noch fehlt ist, wie ich das hier
Zitatjedes MAX! Device muß mit seinem Attribut IODev auf das CUL_MAX Device zeigen (im Wiki cm genannt)
Das CUL_MAX Device hat selbst wieder ein Attribut IODEV das muß auf den umgebumsten Cube zeigen ( TYPE = CUL )
D.h. im Gegensatz zu HM haben hier leider eine Dreierkette. Wichtig ist noch beim CUL den richtigen RF Mode zu setzen
hinbekomme... der Wert bei IODev ist bei mir in den "Internals" deshalb die Idee mit "defmod"
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Wzut am 02 Oktober 2019, 13:33:36
ich schrieb doch
Zitat von: Wzut am 30 September 2019, 10:28:04
jedes MAX! Device muß mit seinem Attribut IODev auf das CUL_MAX Device zeigen (im Wiki cm genannt)
Das CUL_MAX Device hat selbst wieder ein Attribut IODEV das muß auf den umgebumsten Cube zeigen ( TYPE = CUL )
also halte dich nicht mit INTERNALS auf sondern schau nach den Attributen, die müssten ja inzwischen mal gestimmt haben sonst hätte autocreate dir nicht das eine Device angelegt.
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Parador am 03 Oktober 2019, 10:11:04
Hallo Wzut,

ok, ich denke ich habe es a) verstanden und b) weitestgehend hinbekommen.
Habe alle neuen "geflashten Cube Devices" gelöscht und nochmal neu angelegt und den einen "Test"-HKT neu gepairt.

Soweit so gut. Ich konnte auch eine "desired Temp" erfolgreich übermitteln... das geht aktuell auch nicht mehr... alles "discarded"
Aber danach gings auch schon los:


2019.10.03 08:51:08 2: MAX: Invalid value  for READING groupid on MAX_0a23c1. Forcing to 0
2019.10.03 08:52:08 2: MAXLAN_Parse: Command was discarded
2019.10.03 08:52:08 2: MAXLAN_Parse: Command was discarded
2019.10.03 08:55:18 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/10_MAX.pm line 846.
2019.10.03 08:55:18 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_MAX.pm line 848.
2019.10.03 08:55:18 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_MAX.pm line 850.
2019.10.03 08:55:18 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_MAX.pm line 852.
2019.10.03 08:55:18 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_MAX.pm line 854.
2019.10.03 08:55:18 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_MAX.pm line 857.
2019.10.03 08:55:18 2: MAX_Parse: Don't know how to interpret Ack payload for
2019.10.03 09:43:05 2: MAX_Parse: Don't know how to interpret Ack payload for


Die "groupid" kann ich noch setzen
das MAXLAN_Parse  ordne ichdem "alten System" mit dem nicht geflashten Cube "ml" zu (bin aber nicht sicher)
passiert bei neuen System mit dem geflashten Cube, die Weekprofiles werden nicht übertragen
Und alles danach bereitet mir auch Kopfschmerzen... Ideen und Anregungen?
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Wzut am 06 Oktober 2019, 17:06:01
Zitat von: Parador am 03 Oktober 2019, 10:11:04

2019.10.03 08:51:08 2: MAX: Invalid value  for READING groupid on MAX_0a23c1. Forcing to 0
2019.10.03 08:52:08 2: MAXLAN_Parse: Command was discarded

Das mit der Group ID ist normal , das Reading wird ja danach auf 0 gesetzt.
Woher deine MAXLAN Meldungen kommen ist mir völlig schleierhaft, du hast doch komplett auf den Zweig CUL -> cm -> MAX Device umgestellt,
d.h. in deiner fhem.cfg dürfte kein Eintrag mehr für MAXLAN vorhanden sein.
Und Wochenprofile ist ein Thema für sich, dafür hatte ich ja mal MAX Backup geschrieben wenn der User nicht das Weekprofile Modul nutzt.
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Parador am 06 Oktober 2019, 19:38:34
Hallo Wzut,

danke nochmal für Deine Unterstützung.
Ich fasse aber nochmal kurz zusammen...
aktuell habe ich zwei Cubes, einen im Orginalzustand (A) und einen geflashten (B)
ich habe einige HKTs, die meisten noch am Orginalzustand Cube (A), aber drei sind aktuell bereits mit dem geflashten (B) gepaired.

Es gelingt mir nicht über den geflashten Cube Befehle an die mit ihm gepairten HKTs zu senden. Ich erhalte dann entweder keinen Logeintrag, oder "discarded" Einträge.

Zur Sicherheit poste ich jetzt nochmal einige Einträge bei mir...
1. Ein mit dem geflashten Cube (B) gepairter HKT, dass attr IODev zeigt auf "cm" was der geflashte Cube (B) ist.
Internals:
   DEF        HeatingThermostat 0a23c1
   FUUID      5d959a21-f33f-71bb-fa2b-2722fa699a8de5b5
   IODev      ml
   LASTInputDev ml
   MSGCNT     740
   NAME       Thermostat_EG_ArbZi
   NR         381
   RSSI       -49.5
   STATE      21.0 °C
   TYPE       MAX
   addr       0a23c1
   backend    ml
   cm_MSGCNT  24
   cm_TIME    2019-10-06 19:22:16
   dstsetting 1
   ml_MSGCNT  716
   ml_TIME    2019-10-06 19:27:21
   mode       0
   rferror    0
   serial     KMD3041480
   type       HeatingThermostat
   READINGS:
     2019-10-06 19:27:21   MAXLAN_error    0
     2019-10-06 19:27:21   MAXLAN_errorInCommand
     2019-10-06 19:27:21   MAXLAN_initialized 1
     2019-10-06 19:27:21   MAXLAN_isAnswer 0
     2019-10-06 19:27:21   MAXLAN_valid    1
     2019-10-06 19:27:21   RSSI            -49.5
     2019-10-06 19:27:21   battery         ok
     2019-10-06 19:27:21   batteryState    ok
     2019-10-06 07:40:23   boostDuration   5
     2019-10-06 07:40:23   boostValveposition 80
     2019-10-06 07:40:23   comfortTemperature 20.5
     2019-10-06 07:40:23   decalcification Fri 12:00
     2019-10-06 19:27:21   desiredTemperature 21.0
     2019-10-06 07:40:23   ecoTemperature  18.5
     2019-10-06 07:40:23   firmware        1.8
     2019-10-06 07:40:23   groupid         2
     2019-10-06 07:40:23   maxValveSetting 100
     2019-10-06 07:40:23   maximumTemperature on
     2019-10-06 07:40:23   measurementOffset 0.0
     2019-10-06 07:40:23   minimumTemperature off
     2019-10-06 19:27:21   mode            auto
     2019-10-03 08:51:08   msgcnt          3
     2019-10-06 19:27:21   state           21.0 °C
     2019-10-06 19:27:21   temperature     22.3
     2019-10-06 07:40:23   testresult      255
     2019-10-06 07:40:23   valveOffset     0
     2019-10-06 19:27:21   valveposition   10
     2019-10-06 07:40:23   weekprofile-0-Sat-temp 19.0 °C  /  20.5 °C  /  20.5 °C  /  19.0 °C  /  19.0 °C
     2019-10-06 07:40:23   weekprofile-0-Sat-time 00:00-05:45  /  05:45-07:00  /  07:00-21:15  /  21:15-23:55  /  23:55-00:00
     2019-10-06 07:40:23   weekprofile-1-Sun-temp 19.0 °C  /  20.5 °C  /  20.5 °C  /  19.0 °C  /  19.0 °C
     2019-10-06 07:40:23   weekprofile-1-Sun-time 00:00-05:45  /  05:45-07:00  /  07:00-21:15  /  21:15-23:55  /  23:55-00:00
     2019-10-06 07:40:23   weekprofile-2-Mon-temp 18.5 °C  /  20.5 °C  /  18.5 °C  /  20.5 °C  /  18.5 °C  /  18.5 °C
     2019-10-06 07:40:23   weekprofile-2-Mon-time 00:00-05:45  /  05:45-06:30  /  06:30-16:15  /  16:15-21:15  /  21:15-23:55  /  23:55-00:00
     2019-10-06 07:40:23   weekprofile-3-Tue-temp 18.5 °C  /  20.5 °C  /  18.5 °C  /  20.5 °C  /  18.5 °C  /  18.5 °C
     2019-10-06 07:40:23   weekprofile-3-Tue-time 00:00-05:45  /  05:45-06:30  /  06:30-16:15  /  16:15-21:15  /  21:15-23:55  /  23:55-00:00
     2019-10-06 07:40:23   weekprofile-4-Wed-temp 18.5 °C  /  20.5 °C  /  18.5 °C  /  20.5 °C  /  18.5 °C  /  18.5 °C
     2019-10-06 07:40:23   weekprofile-4-Wed-time 00:00-05:45  /  05:45-06:30  /  06:30-16:15  /  16:15-21:15  /  21:15-23:55  /  23:55-00:00
     2019-10-06 07:40:23   weekprofile-5-Thu-temp 18.5 °C  /  20.5 °C  /  18.5 °C  /  20.5 °C  /  18.5 °C  /  18.5 °C
     2019-10-06 07:40:23   weekprofile-5-Thu-time 00:00-05:45  /  05:45-06:30  /  06:30-16:15  /  16:15-21:15  /  21:15-23:55  /  23:55-00:00
     2019-10-06 07:40:23   weekprofile-6-Fri-temp 18.5 °C  /  20.5 °C  /  18.5 °C  /  20.5 °C  /  18.5 °C  /  18.5 °C
     2019-10-06 07:40:23   weekprofile-6-Fri-time 00:00-05:45  /  05:45-06:30  /  06:30-16:15  /  16:15-21:15  /  21:15-23:55  /  23:55-00:00
     2019-10-06 07:40:23   windowOpenDuration 15
     2019-10-06 07:40:23   windowOpenTemperature 12.0
   internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      cm
   comment    Bereits umgestellt auf geflashten Cube 03.10.2019
   room       EG_ArbZi,MAX


2. hier das List von "cm"
Internals:
   DEF        446644
   FUUID      5d9598f6-f33f-71bb-9d12-fbd0e5ae82f8ad07
   IODev      MAX_CUL_0
   LASTInputDev MAX_CUL_0
   MAX_CUL_0_MSGCNT 394
   MAX_CUL_0_RAWMSG Z0F0004600AE8CD0000000018092A00DE
   MAX_CUL_0_RSSI -59.5
   MAX_CUL_0_TIME 2019-10-06 19:24:26
   MSGCNT     394
   NAME       cm
   NR         380
   STATE      Defined
   TYPE       CUL_MAX
   addr       446644
   cnt        0
   pairmode   0
   retryCount 0
   READINGS:
     2019-10-03 15:49:01   packetsLost     1
   sendQueue:
Attributes:
   IODev      MAX_CUL_0
   room       MAX


3. das List von MAX_CUL_0
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.1.49:2323 0000
   DeviceName 192.168.1.49:2323
   FD         81
   FHTID      0000
   FUUID      5d9598ef-f33f-71bb-fac2-8d7435ef99ed9db9
   MAX_CUL_0_MSGCNT 394
   MAX_CUL_0_TIME 2019-10-06 19:24:26
   NAME       MAX_CUL_0
   NR         379
   NR_CMD_LAST_H 2
   PARTIAL   
   RAWMSG     Z0F0004600AE8CD0000000018092A00DE1D
   RSSI       -59.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za446644
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-10-06 07:40:11   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2019-10-03 15:51:44   credit10ms      3214
     2019-10-06 19:24:26   state           Initialized
   XMIT_TIME:
     1570340411.48391
     1570340411.78442
Attributes:
   rfmode     MAX
   room       MAX


Was mich irritiert, ist, dass die mit (B) gepairten HKTs anscheinend immer wieder Readings bekommen, auch die Weekprofiles werden angezeigt wie ich sie gesetzt habe... die HKTs verwenden dieses Weekprofile aber nicht, sind alle noch in der Werkseinstellung, ich kann auch keine sonstigen Befehle übertragen, also auch kein "desiredtemp".

Wenn ich jetzt einen Befehl absetzt kommt folgendes im Log:
Befehl: set Thermostat_EG_ArbZi desiredTemperature 10
Log: - kein Eintrag -
HKT: keine Reaktion, bleibt bei 21.0

Befehl: set Thermostat_EG_ArbZi weekProfile Fri 18.5,05:45,20.5,07:00,18.5,16:15,20.5,21:15,18.5,23:55,18.5
Log: 2019.10.06 19:36:41 2: MAXLAN_Parse: Command was discarded
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Wzut am 07 Oktober 2019, 09:20:04
OK, mir war nicht klar das du Mischbetrieb fährst (habe ich damals nicht gemacht und daher auch keine Erfahrung)
Nun musst du leider den Spaten auspacken und etwas tiefer graben .....
Ein großes wenig beachtetes Problem von FHEM ist die Abhängigkeit von Modulen in Bezug ihrer Reihenfolge innerhalb der fhem.cfg.
Auf Entwicklerseite hat man das Problem vor einiger Zeit zwar erkannt und Module bzw. FHEM versucht dagegen "robust" zu machen,
allerdings werden die MAX! Module schon einige Zeit nicht mehr überarbeitet. Was bedeutet das nun für dich ?
Schaue dir zuerst deine fhem.cfg an wo welches Device wirklich steht. D.h. alles was IO ist muß unbedingt vor dem Device stehen das es benutzen will.
Im Falle von MALAN recht einfach, MAXLAN zuerst, dann  alle MAX Geräte dahinter. Beim dreistufigen CUL : CUL , CUL_Max - > MAX
Bei deinem Mischbetrieb kann es nun sein das diese strenge Reihenfolge an irgend einer Stelle nicht zu 100% stimmt und ein MAX Gerät mit einem IO für CM geladen wird bevor CUL  & CM geladen sind und das Ding dann am MAXLAN hängt.
Tipp :
ganz oben in der cfg sollten die echten IOs stehen -> MAXLAN & CUL, gleich dahinter dann das CM ( es brauch ja das CUL Device)
Erst danach die definierten MAX Geräte, hier dürfte die Reihenfolge egal sein wenn sicher gestellt ist das ihre Abhängikeiten erfüllt sind und die benötigten IOs  wirklich geladen wurden.

So und nun die Preisfrage : Wie die Reihenfolge in der fhem.cfg sicherstellen ?
Ein Hardliner würde nun antworten : Finger weg von der fhem.cfg, lege alles ordenlich nacheinander an und fasse gerade die IO am Besten nie mehr an. (IMHO unrealistisch in einem gewachsenen System)
Mach dir zuerst ein Backup deiner fhem.cfg, dann gehe mit einem Linux tauglichen Editor (es kann auch der in FHEMWEB sein) durch deine cfg und hole Blöcke von defines die zu weit unten stehen weiter nach oben und überprüfe dabei immer den Eintrag des Attributes IODev. Speichere und starte FHEM neu. 

   
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Parador am 07 Oktober 2019, 21:57:35
Hallo Wzut,

nochmal Danke für Deine Geduld mit meinem Problem und mir ;-) und Deine ausführlichen Erläuterungen.
Ich bin jetzt mal tief in die Eingeweide der fhem.cfg getaucht... Bisher noch ohne Veränderungen.
Was ich bisher sehen konnte ist, das die Reihenfolge zu stimmen scheint... weiter oben das MAXLAN, dann ziemlich weit unten weil erst frisch integriert erst er CUL für cm, dann cm und dann die HKTs die als IODev cm haben...

jetzt kommt das "Aber" und vielleicht liegt da auch schon das Problem. Du schreibst es geht um die reihenfolge und wann was geladen wird.
In der ursprünglichen Konfiguration (alles über MAXLAN) hatte ich mit einer structure die HKTs je Stockwerke zusammengefasst.

und um jetzt mal in Abschnitten meiner fhem.cfg zu sprechen
oben: MAXLAN und dannach die HKTs die über MAXLAN laufen
mittig: Structure mit den HKT's die aktuell gemischt sind, also welche über ml und welche über cm
unten: Cul_MAX, cm und dann die HKTs die nur über cm laufen

kann der mittige Teil das Problem sein? dort werden bei structure nun auch HKT's genannt die eigentlich erst später definiert werden...
reicht es evtl aus, wenn ich diesen structure-Teil an das Ende verfrachte, oder ist das eher nicht das Problem...
Hoffe ich habe das jetzt gut beschrieben ;-))
Viele Grüße
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Wzut am 08 Oktober 2019, 13:02:35
ich denke structure ist das erst einmal wurscht.
Leider kann ich den Mischbetrieb nicht nachstellen mangels Cube mit eq3 Firmware.
Allerdings habe ich so einen Verdacht das in 00_MAXLAN.pm ein kleiner Highlander schlummert ("es kann nur Einen  geben")  ...
Teste doch mal folgendes :
Kommentiere den ganzen MAXLAN define Block in der fhem.cfg aus, speichere fhem.cfg und restarte FHEM
(nicht löschen ! sonst hast du später beim neu anlegen MAXLAN hinter deinen Geräten )
Nun gehen zwar deine "alten" Geräte nicht mehr, aber du kannst jetzt problemlos mal die Neuen durchtesten.

Irgendwo hier im Forum gibt es die Info welche ID der Cube mit der eq3 FW benutzt ( Aufdruck auf dem Cube ? )
Würdest du diese ID bei deinem CM Device statt der 123456 benutzen wäre der ganze Umzug vollkommen stressfrei da du nur das IODev der Geräte ändern müsstest ohne sie zu löschen / neu anlegen und vor allem ganz ohne Werksreset.
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Parador am 08 Oktober 2019, 21:10:23
Aaalso....
nach dem Auskommentieren und neustarten konnte ich erfolgreich eine "desiredTemp" an einen der neu gepairten HKTs senden, beim Versuch das Weekprofile zu senden, was wohl zumindest etwas Wirkung zeigte, stieg mir aber der geflashte Cube aus und ging in eine Endlos-Neustart-Schleife... das sah dann in etwa so aus...:


2019.10.08 20:43:17 1: 192.168.1.49:2323 reappeared (MAX_CUL_0)
2019.10.08 20:43:49 1: 192.168.1.49:2323 disconnected, waiting to reappear (MAX_CUL_0)
2019.10.08 20:43:49 1: Error in CUL_MAX_SendQueueHandler: CUL MAX_CUL_0 did not answer request for current credits. Waiting 5 seconds.
2019.10.08 20:43:49 1: 192.168.1.49:2323 reappeared (MAX_CUL_0)
2019.10.08 20:44:13 1: 192.168.1.49:2323 disconnected, waiting to reappear (MAX_CUL_0)
2019.10.08 20:44:13 1: Error in CUL_MAX_SendQueueHandler: CUL MAX_CUL_0 did not answer request for current credits. Waiting 5 seconds.
2019.10.08 20:44:13 1: 192.168.1.49:2323 reappeared (MAX_CUL_0)


Nun aber ich vermute ich muss wirklich MAXLAN komplett entfernen und mit dem Umstieg auf den geflashten Cube starten...
Die Frage ist nur, ob die Einstellungen wie Weekprofile sich dann auch setzen lassen, oder mir jedesmal den Cube neustarten.. oder könnte das nun auch von den alten HKTs kommen die jetzt evtl. versucht haben statt über ml über cl zu kommunizieren ;-) (MIST!)

Die Idee mit der eq3-Pairing-ID find ich auch klasse, bin noch am suchen ob ich was hierzu finde... mal sehen
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Wzut am 09 Oktober 2019, 07:20:04
Ich fang mal hinten an :
die gesuchte ID scheint sich im MAXLAN Device unter addr zu verstecken -> https://forum.fhem.de/index.php/topic,86695.msg810186.html#msg810186
D.h. so kann man relativ stressfrei jederzeit zum Test wechseln ohne die MAX! Geräte selbst anfassen zu müssen.

Das ein IO Device mit der a-culfw sich bei einem bestimten Telegrammtyp so weghängt habe ich hier im Forum noch nie gelesen.
Was da schief läuft wird dir hier in diesem Unterforum vermutlich niemand sagen können, da müssten Leute ran die Ahnung von der Software des Microcontrollers haben.
Bzw. wie man den Cube an der Stelle debuggen kann Stichwort USB TTL Wandler an einer freien CUBE Schnittstelle ->  https://forum.fhem.de/index.php/topic,38404.0.html 
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Parador am 10 Oktober 2019, 17:32:45
Also hier nochmal mein Fazit...
Der Schrittweise umstieg von eq3 Cube auf einen geflashten Cube ist schwierig - Für alle die es jetzt probieren wollen... Lieber gleich einmal rumgehen, reset'en, pairen und dann happy sein... ;-)
Das habe ich heute angefangen und nach dem Herausnehmen des "alten eq3-Cubes" aus der config geht im Moment alles wunderbar...
Bringe gerade den HKTs die Weekprofile nach und nach bei... aber auch das klappt!

Vielen Dank nochmal an Dich Wzut für Geduld & Mühe!
Titel: Antw:Probleme bei Umstieg auf geflashten Cube
Beitrag von: Wzut am 11 Oktober 2019, 12:05:59
Ja ist schade das du nun mehr Arbeit hattest als eigentlich nötig gewesen wäre
Stichwort MAX Wiki , da fehlt die Info wie man leicht mit der ID Übernahme von MAXLAN nach CM wechseln kann ohne Werksreset
und der Zusatz auf eine mögliches Problem beim Mischbetrieb.