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
Moin,
in den Attributen vom Device sollte IODev zur Verfügung zu sein. Stell den auf den MAXCUL um.
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 :)
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
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.
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"
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.
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?
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.
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
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.
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
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.
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
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
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!
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.