CoC und rfmode MAX

Begonnen von C. Zimmermann, 31 Januar 2013, 17:48:12

Vorheriges Thema - Nächstes Thema

C. Zimmermann

Hallo,

habe ein Problem mit dem CoC im Zusammenspiel mit rfmode MAX.

Wenn der CoC auf rfmode MAX ist und ich die fhem.cfg speichere, wird der CoC nicht mehr als solcher erkannt:
2013.01.31 17:26:27 1: Including fhem.cfg
2013.01.31 17:26:27 3: telnetPort: port 7072 opened
2013.01.31 17:26:27 3: WEB: port 8083 opened
2013.01.31 17:26:27 3: WEBphone: port 8084 opened
2013.01.31 17:26:27 3: WEBtablet: port 8085 opened
2013.01.31 17:26:27 3: Opening COC device /dev/ttyAMA0
2013.01.31 17:26:27 3: Setting COC baudrate to 38400
2013.01.31 17:26:27 3: COC device opened
2013.01.31 17:26:28 1: Not an CUL device, got for V:  SM868
00000000
2013.01.31 17:26:28 1: Cannot init /dev/ttyAMA0, ignoring it
2013.01.31 17:26:28 2: Switched COC rfmode to MAX
2013.01.31 17:26:28 1: Including ./log/fhem.save


Ein shutdown restart seitens FHEM bringt nichts, nur wenn ich per putty das ganze System reboote:

2013.01.31 17:27:30 0: Server shutdown
2013.01.31 17:28:20 1: Including fhem.cfg
2013.01.31 17:28:22 3: telnetPort: port 7072 opened
2013.01.31 17:28:24 3: WEB: port 8083 opened
2013.01.31 17:28:24 3: WEBphone: port 8084 opened
2013.01.31 17:28:24 3: WEBtablet: port 8085 opened
2013.01.31 17:28:25 3: Opening COC device /dev/ttyAMA0
2013.01.31 17:28:26 3: Setting COC baudrate to 38400
2013.01.31 17:28:26 3: COC device opened
2013.01.31 17:28:26 3: COC: Possible commands: mCFiAZOGMRTVWXefltux
2013.01.31 17:28:26 2: Switched COC rfmode to MAX
2013.01.31 17:28:27 1: Including ./log/fhem.save
2013.01.31 17:28:27 1: usb create starting
2013.01.31 17:28:28 1: usb create end
2013.01.31 17:28:28 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2013.01.31 17:28:28 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2601 2013-01-30 10:39:30Z rudolfkoenig $, pid 1867)


Bisher lief der Pi+CoC auf rfmode SlowRF und hier traten in einer Zeitspanne von ca. 10 Tagen keine Probleme auf.

Meine Vermutung ist, dass sich der CoC beim Aufruf verhaspelt, da der String für get Raw V unterschiedliche Ergebnisse zeigt :

2013.01.31 15:57:51 1: Not an CUL device, got for V:  1.52 CSM868
F7
2013.01.31 15:57:54 1: Not an CUL device, got for V:  1.52 CSM868
24
2013.01.31 15:58:10 1: Not an CUL device, got for V:  1.52 CSM868
84
2013.01.31 15:59:44 1: Not an CUL device, got for V:  1.52 CSM868
00
2013.01.31 16:49:24 1: Not an CUL device, got for V:  1.52 CSM868
13
2013.01.31 16:49:27 1: Not an CUL device, got for V:  1.52 CSM868
00
2013.01.31 16:51:12 1: Not an CUL device, got for V:  1.52 CSM868
00
2013.01.31 16:53:05 1: Not an CUL device, got for V:  1.52 CSM868
71
2013.01.31 16:53:43 1: Not an CUL device, got for V:  1.52 CSM868
m
2013.01.31 16:57:11 1: Not an CUL device, got for V:  1.52 CSM868
5
2013.01.31 16:57:46 1: Not an CUL device, got for V:  1.52 CSM868
40
2013.01.31 17:02:36 1: Not an CUL device, got for V:  68
 u x
Z0045
2013.01.31 17:08:27 1: Not an CUL device, got for V:  5383C8M868
006A5C700000
2013.01.31 17:09:32 1: Not an CUL device, got for V:  030303SM868
D49890102020
2013.01.31 17:26:28 1: Not an CUL device, got for V:  SM868
00000000


Zum Einsatz kommt die Debian Distribution vom 16.12, gepatcht mit den Busware patches und mit der aktuellen SVN FHEM version. Hexdump liefert mir
00000000  43 4f 43 20 56 31 2e 31  20 46 55 4c 4c 20 32 30  |COC V1.1 FULL 20|
00000010  31 33 2d 30 31 2d 31 37  0a ff ff ff ff ff ff ff  |13-01-17........|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000100


Da ich mir nicht sicher bin, obs an der Hardware liegt oder an der Software, hab ich es hier ins Unterforum eingestellt.

Vielleicht hat jemand eine Idee, was hier schief läuft und kann mir weiterhelfen.

C. Zimmermann