[gelöst] - MAX Cube als mehrfach CUNO

[Manley]

Hi.

Ich habe seit einiger Zeit meinen MAX! Cube geflasht.

Aus Lust an der Freude habe ich jetzt einen CC1101 mit 433MHz eingebaut.
Habe die CUBEx4 geflasht. Alles ohne Probleme.
Der Cube funktioniert auch wie vorher ohne Probleme mit den MAX! Komponenten.

Jetzt kommt das aber:
Sobald ich den 2. CUL per:

Code: [Auswählen]

define CUL1 STACKABLE_CC CUL0defeniere, startet der Cube immer wieder neu.
Ich dachte erst, daß es mit dem doch recht schwachen Netzteil zu tun hat.
Das konnnte ich aber mit nem stärkeren Netzteil wiederlegen.

Vielleicht hat ja jmd eine Idee.

MfG Manley

Auszug aus dem Logfile:

Code: [Auswählen]

2019.03.13 22:23:02 1: 192.168.1.29:2323 disconnected, waiting to reappear (CUL0)
2019.03.13 22:23:02 3: CUL0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2019.03.13 22:23:02 1: 192.168.1.29:2323 reappeared (CUL0)
2019.03.13 22:23:02 3: CUL1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2019.03.13 22:23:30 1: 192.168.1.29:2323 disconnected, waiting to reappear (CUL0)
2019.03.13 22:23:30 3: CUL0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2019.03.13 22:23:30 1: 192.168.1.29:2323 reappeared (CUL0)
2019.03.13 22:23:30 3: CUL1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2019.03.13 22:23:58 1: 192.168.1.29:2323 disconnected, waiting to reappear (CUL0)
2019.03.13 22:23:58 3: CUL0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2019.03.13 22:23:58 1: 192.168.1.29:2323 reappeared (CUL0)
2019.03.13 22:23:58 3: CUL1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2019.03.13 22:24:26 1: 192.168.1.29:2323 disconnected, waiting to reappear (CUL0)
2019.03.13 22:24:26 3: CUL0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2019.03.13 22:24:26 1: 192.168.1.29:2323 reappeared (CUL0)
2019.03.13 22:24:26 3: CUL1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2019.03.13 22:24:54 1: 192.168.1.29:2323 disconnected, waiting to reappear (CUL0)
2019.03.13 22:24:54 3: CUL0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2019.03.13 22:24:54 1: 192.168.1.29:2323 reappeared (CUL0)
2019.03.13 22:24:55 3: CUL1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
List CUL0:

Code: [Auswählen]

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz*
   CUL0_MSGCNT 15658
   CUL0_TIME  2019-03-14 11:22:21
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.1.29:2323 1234
   DeviceName 192.168.1.29:2323
   FD         24
   FHTID      1234
   FUUID      5c44b228-f33f-9a7c-f087-2ee0161588f64815
   NAME       CUL0
   NR         81
   NR_CMD_LAST_H 2
   PARTIAL   
   RAWMSG     Z0ED102021BCC5B19C363000118002836
   RSSI       -47
   STACKED    CUL1
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBEx4_83 (F-Band: 868MHz)
   initString X21
Zr
Za123456
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:
     2018-12-11 14:22:52   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2019-03-14 11:11:53   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-03-14 11:17:10   credit10ms      2029
     2019-03-13 17:58:34   fhtbuf          AE
     2019-03-14 11:22:21   state           Initialized
     2019-03-13 17:58:18   uptime          10 02:44:57
     2019-03-14 11:10:16   version         V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBEx4_83 (F-Band: 868MHz)
   XMIT_TIME:
     1552558629.31241
     1552558630.81693
Attributes:
   group      Netzwerk
   rfmode     MAX
List CUL1:

Code: [Auswählen]

Internals:
   CFGFN     
   CMDS       bCFiAZNEGMKLUYRTVWXfz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        CUL0
   FUUID      5c8a2b74-f33f-9a7c-8019-af7f4780e677ae69
   IODev      CUL0
   NAME       CUL1
   NOTIFYDEV  CUL0
   NR         12544
   NTFY_ORDER 50-CUL1
   PARTIAL   
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBEx4_83 (F-Band: 868MHz)
   initString X21
Zr
Za123456
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-03-14 11:23:26   cmds             b C F i A Z N E G M K L U Y R T V W X f z
     2019-03-14 11:23:26   state           Initialized
Attributes:

[Manley]

Habe jetzt mehrmals den Cube neu geflasht. Brachte euch keinen Erfolg.
Hat denn keiner eine Idee woran es liegen könnte?

[adn77]

Das hatte ich auch schon mal...
Setze beim CUL1 das Atrribut rfmode auf SlowRF

Momentan wird der zweite Tranceiver nicht richtig initialisiert.

[Manley]

Das brachte leider keine Besserung. Liegt es vielleicht an den falschen Einstellungen?
Er zeigt ja auch an, das er angeblich auf 868MHz läuft. Laut Version.

[adn77]

Versuche mal ein Telnet auf den Cube.

Ein "V" sollte die den Status des ersten Transceivers geben.
Ein "*V" den des zweiten.

Schau erstmal ob hier alles stimmt. Mit "*X21" solltest du auf dem Cube dann auch eingehende 433Mhz Nachrichten sehen.

Wenn alles nichts hilft, per "e" kann man glaube ich einen Reset herbeiführen, der das eeprom neu initialisiert.
http://culfw.de/commandref.html#cmd_e

Alex

[Manley]

Bei V und *V kommt:

Code: [Auswählen]

V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBEx4_83 (F-Band: 868MHz)
Bei X21 machte der Cube einen Neustart.

Wenn ich es benutze, muss ich dann meine gesamten MAX! Komponenten neu pairen?

[adn77]

Hast du bereits ein "e" gemacht?

Ja, alle MAX Geräte müssen neu gepairt werden, wenn du sie per FHEM steuern möchtest. Nur mitlesen sollte auch so gehen.

[Manley]

Ne, "e" hab ich noch nicht gemacht, weil ich befürchte dann alle MAX Geräte neu pairen zu müssen.
Das würde dank der Kredits einen halben Tag dauern. Die Zeit habe ich im Moment noch nicht.

[adn77]

Sorry, hatte überlesen, dass du bereits MAX auf CUL benutzt.

Ein Cube Reset wirkt sich nach meinem Verständnis nicht auf die FHEM bekannten Geräte aus - das Pairing findet schließlich nicht mehr im Cube statt, sondern in FHEM.

Ansonsten kann ich dir den culfw@ARM Thread empfehlen.
https://forum.fhem.de/index.php/topic,38404.0.html

[Manley]

Meines Wissens nach findet das Pairing in den Komponenten statt. Die ID vom Cube wird in die Komponenten geschrieben um von ihm Befehle anzunehmen. Kann mich da aber auch irren.
Und wenn der Cube ne neue ID bei "e" bekommt wars das. Ich werde es testen sobald ich genug Zeit habe.
Wie gesagt, ist ja nur ne Spielerei mit dem 2. Transceiver. Das eilt nicht.

Sobald ich es getestet habe gebe ich wieder Laut.

Sollte einer noch ne andere Idee haben, immer raus damit

[adn77]

Dein Problem ähnelt jedenfalls diesem hier (Lösung zwei Posts weiter):
https://forum.fhem.de/index.php/topic,38404.msg754423.html#msg754423

Alex

[Wzut]

Meines Wissens nach findet das Pairing in den Komponenten statt.

richtig !

Die ID vom Cube wird in die Komponenten geschrieben um von ihm Befehle anzunehmen. Kann mich da aber auch irren.
Und wenn der Cube ne neue ID bei "e" bekommt wars das.

ja du irrst dich ! Deine sechstellige MAXId "hängt" am cm Device (bei HM ist die HMId ein Attr des CUL direkt) , aber bei beiden Systemen hat die CUL FW davon keine Ahnung.

[Manley]

So,

Problem gelöst.
Mit "e" hat es tatsächlich funktioniert.
Danke an euch alle.

[Tompsg]

Ich hatte tatsächlich das Problem aufgrund zu geringer Stromversorgung am Fritzbox USB-Anschluß. Mit Netzteil klappt es einwandfrei. Danke für den Hinweis im Thread.