FHEM Forum

Hallo,

monatelang funktionierte meine FHEM Installation störungslos. Hardware und Konfiguration scheinen also in Ordnung. Nach einem Rechnerneustart (Ubuntu x86_64) ging plötzlich nichts mehr.

FHEM hat einen CUL868 (Revision 1.61, Homematic) und einen CUL433 (Revision 1.65, WS2000). Nach dem Ausfall habe ich FHEM geupdated (2015.10.04). Einmal lief FHEM danach an. Nach einem weiteren Rechnerneustart gab es lediglich Meldungen, dass die CULs ignoriert werden. Der Fehler ist absolut reproduzierbar.

Es sieht für mich so aus, als würde der CUL433 in der Initialisierungsphase mit empfangenen und sinnvollen Paketen der Sensoren antworten, die FHEM aber nicht erwartet. Beispiel (attr global verbose 5):


⋮
2015.10.06 08:03:00.000 5: SW: X21
2015.10.06 08:03:00.010 5: SW: Ar
2015.10.06 08:03:00.020 2: Switched CUL868 rfmode to HomeMatic
2015.10.06 08:03:00.020 5: Cmd: >define CUL433 CUL /dev/serial/by-id/usb-busware.de_CUL433-if00  1234<
2015.10.06 08:03:00.021 3: Opening CUL433 device /dev/serial/by-id/usb-busware.de_CUL433-if00
2015.10.06 08:03:00.021 3: CUL433 device opened
2015.10.06 08:03:00.021 5: CUL/RAW (ReadAnswer): K21520172FF


2015.10.06 08:03:00.022 5: CUL/RAW (ReadAnswer): K616601733A
K7400026289F72D
K7400026289F72B
K5149917602

2015.10.06 08:03:00.022 1: /dev/serial/by-id/usb-busware.de_CUL433-if00 disconnected, waiting to reappear (CUL433)
2015.10.06 08:03:00.171 5: Triggering CUL433 (1 changes)
2015.10.06 08:03:00.171 5: Notify loop for CUL433 DISCONNECTED
2015.10.06 08:03:00.171 5: SW: V
2015.10.06 08:03:00.181 1: Cannot init /dev/serial/by-id/usb-busware.de_CUL433-if00, ignoring it (CUL433)
⋮


Was kann ich tun?

Gruß
Hermann

Folgendes wuerde ich der Reihe nach probieren (und aufhoeren, falls es funktioniert):
- mit "set CUL433 raw B00" ein reboot erzwingen. Falls ueber FHEM nicht geht, dann ueber screen.
- CUL ausstecken/einstecken
- Factory reset ("set CUL433 raw e", siehe http://culfw.de/commandref.html)
- Firmware neu flashen
- mit screen/minicom/etc verifizieren, dass auf V<return> keine Antwort kommt.

Danke für die schnelle Antwort.

Zitat von: rudolfkoenig am 06 Oktober 2015, 09:42:30
- mit "set CUL433 raw B00" ein reboot erzwingen. Falls ueber FHEM nicht geht, dann ueber screen.

Über FHEM gibt es im FHEM-log:


2015.10.06 12:33:34.192 5: Cmd: >set CUL433 raw B00<
2015.10.06 12:33:34.193 3: set CUL433 raw B00
2015.10.06 12:33:34.203 5: Triggering CUL433 (1 changes)
2015.10.06 12:33:34.203 5: Notify loop for CUL433 raw B00


Das /var/log/syslog zeigt nichts.

Mit screen (als root) gibt B00:


[screen is terminating]


und die Schnittstelle wird beim Neustart wieder mit den richtigen Rechten angelegt (syslog / ls):


Oct  6 12:53:19 e4 kernel: [74028.848381] usb 1-1.3: USB disconnect, device number 12
Oct  6 12:53:20 e4 kernel: [74029.150835] usb 1-1.3: new full-speed USB device number 13 using ehci-pci
Oct  6 12:53:20 e4 kernel: [74029.245227] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=204b
Oct  6 12:53:20 e4 kernel: [74029.245233] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct  6 12:53:20 e4 kernel: [74029.245235] usb 1-1.3: Product: CUL433
Oct  6 12:53:20 e4 kernel: [74029.245238] usb 1-1.3: Manufacturer: busware.de
Oct  6 12:53:20 e4 kernel: [74029.245678] cdc_acm 1-1.3:1.0: ttyACM1: USB ACM device



ls -l /dev/ttyACM1
crw-rw---- 1 fhem dialout 166, 1 Oct  6 12:53 /dev/ttyACM1
ls -l /dev/serial/by-id/*CUL433*
lrwxrwxrwx 1 root root 13 Oct  6 12:53 /dev/serial/by-id/usb-busware.de_CUL433-if00 -> ../../ttyACM1


Von all dem bekommt FHEM nichts mit.

Zitat von: rudolfkoenig am 06 Oktober 2015, 09:42:30
- CUL ausstecken/einstecken

Das sieht ähnlich aus wie der Reset. FHEM ignoriert das Gerät vollständig.

Im syslog wird der CUL re-initialisiert:


Oct  6 13:03:35 e4 kernel: [74644.944540] usb 1-1.3: USB disconnect, device number 13
Oct  6 13:03:39 e4 kernel: [74648.472350] usb 1-1.3: new full-speed USB device number 14 using ehci-pci
Oct  6 13:03:39 e4 kernel: [74648.566873] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=204b
Oct  6 13:03:39 e4 kernel: [74648.566878] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct  6 13:03:39 e4 kernel: [74648.566881] usb 1-1.3: Product: CUL433
Oct  6 13:03:39 e4 kernel: [74648.566883] usb 1-1.3: Manufacturer: busware.de
Oct  6 13:03:39 e4 kernel: [74648.567285] cdc_acm 1-1.3:1.0: ttyACM1: USB ACM device


Zitat von: rudolfkoenig am 06 Oktober 2015, 09:42:30
- Factory reset ("set CUL433 raw e", siehe http://culfw.de/commandref.html)

Im FHEM-log:


2015.10.06 13:05:26.602 5: Cmd: >set CUL433 raw e<
2015.10.06 13:05:26.603 3: set CUL433 raw e
2015.10.06 13:05:26.613 5: Triggering CUL433 (1 changes)
2015.10.06 13:05:26.613 5: Notify loop for CUL433 raw e


und mit screen wieder einmal


[screen is terminating]


Und die Schnittstelle wird korrekt initialisiert.

Zitat von: rudolfkoenig am 06 Oktober 2015, 09:42:30
- Firmware neu flashen

Klappt einwandfrei mit dfu-programmer:


     target: atmega32u4
    chip_id: 0x2ff4
  vendor_id: 0x03eb
    command: flash
      quiet: false
      debug: 2
device_type: AVR
------ command specific below ------
   validate: true
   hex file: CUL_V3.hex

Validating...
28376 bytes used (98.97%)


Zitat von: rudolfkoenig am 06 Oktober 2015, 09:42:30
- mit screen/minicom/etc verifizieren, dass auf V<return> keine Antwort kommt.

FHEM liefert wieder das Übliche (log):


2015.10.06 13:12:13.470 5: Cmd: >set CUL433 raw V<
2015.10.06 13:12:13.471 3: set CUL433 raw V
2015.10.06 13:12:13.481 5: Triggering CUL433 (1 changes)
2015.10.06 13:12:13.481 5: Notify loop for CUL433 raw V


screen funktioniert:


V 1.65 CUL433


Kannst du bitte pruefen, ob das CUL433 ein dummy attribut hat, und wenn ja, loeschen, und nochmal testen?

Zitat von: rudolfkoenig am 06 Oktober 2015, 13:39:30
Kannst du bitte pruefen, ob das CUL433 ein dummy attribut hat, und wenn ja, loeschen, und nochmal testen?

Ich gehe davon aus, dass das dummy Attribut in der fhem.cfg stehen müsste. Das tut es nicht:


fgrep dummy /opt/fhem/fhem.cfg


gibt nichts.

Und list CUL433 liefert:


Internals:
   CMDS       
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:
   DEF        /dev/serial/by-id/usb-busware.de_CUL433-if00  1234
   DevIoJustClosed 1
   DeviceName /dev/serial/by-id/usb-busware.de_CUL433-if00
   FHTID      1234
   NAME       CUL433
   NR         11
   PARTIAL   
   STATE      disconnected
   TYPE       CUL
   initString X21
   Matchlist:
     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....(1|5|9).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]+
   Readings:
     2015-10-05 20:57:34   cmds            B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
     2015-10-06 08:03:00   state           disconnected
Attributes:
   rfmode     SlowRF
   verbose    4


Beste Grüsse Hermann

Sorry, ich habe erstmal keine weiteren Ideen.

Hallo

Ich hatte das gleiche Problem, CUL und RFXTRX gingen nach einem Ubuntu Update plötzlich nicht mehr.

Der Fehler lag bei mir bei einem Bugs des 3.13.0-65 Kernel.

Wechsle zurück auf einen älteren Kernel.

Auf die Fährte half mir folgender Thread:
http://forum.fhem.de/index.php/topic,41634.0.html (http://forum.fhem.de/index.php/topic,41634.0.html)

Hoffe, es ist dasselbe :-)

Gruss

Daniel