Seit FHEM-Update funktioniert CUL nicht mehr richtig

didi-fritz · 09 Juli 2018, 00:05:23

Hallo,

seit meinem heutigen Fhem-Update funktioniert der Cul nicht immer..
- einige Sensoren liefern keine Daten
- es kann kein Aktor geschaltet werden (state set_* / missing ack) und der CUL "bootet"

Code Auswählen

CUL_HM Act_Dach CMDs_pending
CUL_HM L_Stiege set_off
CUL CUL DISCONNECTED
CUL_HM Act_Dach CMDs_pending
CUL CUL cmds:  B b C F i A Z E G M K U Y R T V W X e f m l t u x
CUL CUL Initialized
CUL CUL CONNECTED
CUL CUL DISCONNECTED
CUL CUL cmds:  B b C F i A Z E G M K U Y R T V W X e f m l t u x
CUL CUL Initialized
CUL CUL CONNECTED
CUL CUL DISCONNECTED
CUL CUL cmds:  B b C F i A Z E G M K U Y R T V W X e f m l t u x
CUL CUL Initialized
CUL CUL CONNECTED
CUL CUL DISCONNECTED
CUL CUL cmds:  B b C F i A Z E G M K U Y R T V W X e f m l t u x
CUL CUL Initialized
CUL CUL CONNECTED

in /var/log/syslog finde ich

Code Auswählen

Jul  8 23:36:12 raspi-fhem kernel: [ 3751.536173] usb 1-1.5: USB disconnect, device number 113
Jul  8 23:36:12 raspi-fhem kernel: [ 3751.536333] cdc_acm 1-1.5:1.0: failed to set dtr/rts
Jul  8 23:36:13 raspi-fhem kernel: [ 3751.833680] usb 1-1.5: new full-speed USB device number 114 using dwc_otg
Jul  8 23:36:13 raspi-fhem kernel: [ 3751.977042] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=204b
Jul  8 23:36:13 raspi-fhem kernel: [ 3751.977062] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul  8 23:36:13 raspi-fhem kernel: [ 3751.977075] usb 1-1.5: Product: CUL868
Jul  8 23:36:13 raspi-fhem kernel: [ 3751.977088] usb 1-1.5: Manufacturer: busware.de
Jul  8 23:36:13 raspi-fhem kernel: [ 3751.978421] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device

schaltet man direkt am Aktor, dann wird der Zustand (als broadcast) übermittelt

Code Auswählen

CUL_HM Act_Dach RAWMSG: A0D348410250A5C00000006010000::-55:CUL
CUL_HM Act_Dach RSSI: -55
CUL_HM L_Stiege off

Code Auswählen

list  L_Stiege
Internals:
   DEF        250A5C01
   NAME       L_Stiege
   NOTIFYDEV  global
   NR         763
   NTFY_ORDER 50-L_Stiege
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     Act_Dach
   READINGS:
     2018-07-08 00:55:04   CommandAccepted yes
     2015-11-18 23:12:31   R-self01-lgActionType jmpToTarget
     2015-11-18 23:12:31   R-self01-shActionType jmpToTarget
     2015-11-18 23:12:29   R-sign          off
     2018-07-08 23:39:29   deviceMsg       off (to broadcast)
     2018-07-08 23:39:29   level           0
     2018-07-08 23:39:29   pct             0
     2018-07-08 23:39:29   recentStateType info
     2018-07-08 23:39:29   state           off
     2018-07-08 23:39:29   timedOn         off
   helper:
     dlvlCmd    ++A011F12306250A5C0201000000
     regLst     ,1,3p
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   event-min-interval .*:3600
   event-on-change-reading state|level
   expert     0_off
   group      Licht,_Beleuchtung
   icon       light_light
   model      HM-LC-SW2-FM
   peerIDs    00000000,
   room       Licht
   webCmd     on:off


list Act_Dach
Internals:
   CUL_MSGCNT 4
   CUL_RAWMSG A0D348410250A5C00000006010000::-55:CUL
   CUL_RSSI   -55
   CUL_TIME   2018-07-08 23:39:29
   DEF        250A5C
   IODev      CUL
   LASTInputDev CUL
   MSGCNT     4
   NAME       Act_Dach
   NOTIFYDEV  global
   NR         761
   NTFY_ORDER 50-Act_Dach
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 L_Stiege
   channel_02 L_Dach
   lastMsg    No:34 - t:10 s:250A5C d:000000 06010000
   protCmdDel 2
   protIOdly  1 last_at:2018-07-08 23:35:56
   protLastRcv 2018-07-08 23:39:29
   protResnd  6 last_at:2018-07-08 23:36:10
   protResndFail 2 last_at:2018-07-08 23:36:15
   protSnd    3 last_at:2018-07-08 23:35:56
   protState  CMDs_done_Errors:1
   rssi_at_CUL lst:-55 cnt:4 max:-54.5 min:-56.5 avg:-55.25 
   READINGS:
     2018-01-12 20:25:56   CommandAccepted yes
     2017-05-16 21:56:44   D-firmware      1.12
     2017-05-16 21:56:44   D-serialNr      KEQ1072987
     2015-11-18 23:12:29   PairedTo        0xF12306
     2015-11-18 23:12:29   R-pairCentral   0xF12306
     2018-05-08 20:37:27   level           0
     2018-05-08 20:37:27   pct             0
     2018-05-08 20:37:27   powerOn         2018-05-08 20:37:27
     2018-05-08 20:37:27   recentStateType info
     2018-07-08 23:36:15   state           MISSING ACK
     2018-05-08 20:37:27   timedOn         off
   helper:
     HM_CMDNR   52
     cSnd       11F12306250A5C0201000000,11F12306250A5C0201000000
     mId        0009
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       newChn     +250A5C,00,00,00
       nextSend   1531085969.62219
       prefIO     
       rxt        0
       vccu       
       p:
         250A5C
         00
         00
         00
     mRssi:
       mNo        34
       io:
         CUL:
           -49
           -49
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_CUL:
         avg        -55.25
         cnt        4
         lst        -55
         max        -54.5
         min        -56.5
     tmpl:
Attributes:
   IODev      CUL
   autoReadReg 4_reqStatus
   event-min-interval .*:28800
   event-on-change-reading .*
   expert     0_off
   firmware   1.12
   icon       rc_SHUFFLE
   model      HM-LC-SW2-FM
   room       CUL_HM
   serialNr   KEQ1072987
   subType    switch
   webCmd     getConfig

hab ich alle pairings verloren oder ist der CUL "readonly"?

Danke für eure Hilfe
lg Didi

didi-fritz · 09 Juli 2018, 08:00:33

ich hab den Fehler gefunden

es war eine fehlerhafte udev-rule für meine GPIOs (/etc/udev/rules.d/80-gpio-noroot.rules), das nach dem fhem-restart getriggert wurde.
Der Fehler hatte nichts mit dem Update zu tun

didi-fritz · 09 Juli 2018, 15:55:01

funktioniert leider schon wieder nicht. Die udev-rule war es auch nicht.

selbes Verhalten wie im 1. Post beschrieben

Beta-User · 09 Juli 2018, 16:01:17

Zeig mal bitte die Ausgaben von

Code Auswählen

ls -l /dev/serial/by-idund

Code Auswählen

ls -l /dev/serial/by-path
Wenn mehrere USB-Schnittstellen genutzt werden: Poste bitte je ein "list".

Dann: Was ist das für ein Netzteil?

didi-fritz · 09 Juli 2018, 16:48:22

hallo,

Netzteil hab ich das original RPi 2,5 A 5,1 V, habe aber eine Powerbank mit 2,3A dazwischen (bereits mehr als 1 Jahr ohne Probleme im Einsatz)

Code Auswählen

# ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jul  9 16:38 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jul  9 15:49 usb-HSPA_Data_Card_HSPA_Data_Card_1234567890ABCDEF-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jul  9 15:49 usb-HSPA_Data_Card_HSPA_Data_Card_1234567890ABCDEF-if01-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jul  9 15:49 usb-HSPA_Data_Card_HSPA_Data_Card_1234567890ABCDEF-if02-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Jul  9 15:49 usb-HSPA_Data_Card_HSPA_Data_Card_1234567890ABCDEF-if03-port0 -> ../../ttyUSB3


# ls -l /dev/serial/by-path
total 0
lrwxrwxrwx 1 root root 13 Jul  9 15:49 platform-3f980000.usb-usb-0:1.3:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jul  9 15:49 platform-3f980000.usb-usb-0:1.3:1.1-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jul  9 15:49 platform-3f980000.usb-usb-0:1.3:1.2-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Jul  9 15:49 platform-3f980000.usb-usb-0:1.3:1.3-port0 -> ../../ttyUSB3
lrwxrwxrwx 1 root root 13 Jul  9 16:38 platform-3f980000.usb-usb-0:1.5:1.0 -> ../../ttyACM0


# ls -l /dev/ttyA*
crw-rw---- 1 root dialout 166,  0 Jul  9 16:40 /dev/ttyACM0
crw-rw---- 1 root dialout 204, 64 Jul  9 15:49 /dev/ttyAMA0

# ls -l /dev/ttyUS*
crw-rw---- 1 root dialout 188, 0 Jul  9 16:47 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Jul  9 15:49 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 2 Jul  9 15:49 /dev/ttyUSB2
crw-rw---- 1 root dialout 188, 3 Jul  9 15:49 /dev/ttyUSB3


# lsusb
Bus 001 Device 076: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 004: ID 04d9:a052 Holtek Semiconductor, Inc.
Bus 001 Device 007: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


# lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 3: Dev 7, If 4, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 3: Dev 7, If 2, Class=Vendor Specific Class, Driver=option, 480M
        |__ Port 3: Dev 7, If 0, Class=Vendor Specific Class, Driver=option, 480M
        |__ Port 3: Dev 7, If 3, Class=Vendor Specific Class, Driver=option, 480M
        |__ Port 3: Dev 7, If 1, Class=Vendor Specific Class, Driver=option, 480M
        |__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 5: Dev 76, If 0, Class=Communications, Driver=cdc_acm, 12M
        |__ Port 5: Dev 76, If 1, Class=CDC Data, Driver=cdc_acm, 12M

ich hab nun alle anderen USB-Devices abgesteckt und den Cul an den andern Port getestet - leider ohne Erfolg

danke
didi

Beta-User · 09 Juli 2018, 17:25:45

Hmmm, wie ist der CUL in FHEM definiert? "by-id"? (Sollte eigentlich keinen Unterschied machen).

Wenn etwas über ein Jahr funktioniert hat, ist das noch kein Beweis, dass nicht doch die Stromversorgung Probleme verursacht, vor allem, wenn da doch noch einiges über die Ports Strom zieht (hier: 4 Modems??? - War das auch schon immer so? Lief darüber schon immer so viel Verkehr wie jetzt usw.?). Würde es als erstes mal mit einem aktiven Hub versuchen, dann wäre das ggf. als Fehlerquelle auszuschließen. Dann kann man weitersehen...

didi-fritz · 09 Juli 2018, 18:22:20

so sieht der CUL aus:

Code Auswählen

Internals:
   CMDS       ABbCeFGhiKkLlMmNRTtUuVWXxYZ
   CUL_MSGCNT 15
   CUL_TIME   2018-07-09 18:13:32
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@19200 2306
   DeviceName /dev/ttyACM0@19200
   FD         33
   FHTID      2306
   NAME       CUL
   NR         336
   NR_CMD_LAST_H 11
   PARTIAL    
   RAWMSG     A169886534BE1590000000041015E42017443FFEA44001612
   RSSI       -65
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 CUL868
   initString X21
Ar
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-01-28 19:38:41   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2018-07-09 18:10:19   cmds             A B b C e F G h i K k L l M m N R T t U u V W X x Y Z
     2015-11-10 20:11:42   credit10ms      900
     2015-11-10 20:12:00   fhtbuf          AE
     2018-07-09 17:54:49   raw             V 1.67 CUL868
     2018-07-09 18:13:32   state           Initialized
     2018-01-28 19:39:53   uptime          17 14:04:56
     2018-07-09 17:45:12   version         No answer
   XMIT_TIME:
     1531152637.55539
     1531152638.9894
     1531152642.40583
     1531152642.5348
     1531152646.89773
     1531152647.43622
     1531152652.76941
     1531152715.43819
     1531152718.08466
     1531152723.54674
     1531152728.47897
   helper:
     1D88A8:
       QUEUE:
     4DBD17:
       QUEUE:
Attributes:
   addvaltrigger 1
   hmId       F12306
   hmProtocolEvents 1_dump
   icon       cul_868
   rfmode     HomeMatic
   room       System->Config
   verbose    5
   webCmd     hmPairForSec 600

das mit den 4 modems war schon immer (es aber nur eines

)

der Verkehr und Last im System ist gleich wie immer

leider kein Erfog mit folgenden Vorgehen:
- alle anderen usb-devices abgesteckt
- aktiven usb-hub eingebaut
- CUL neu geflasht (CULflash CUL CUL_V3)
- verbose am CUL auf 5 gestellt ( jetzt sehe ich "CUL: Unknown code ERR:CCA, help me!" im log

Beta-User · 09 Juli 2018, 18:28:48

Sorry, aber da kann ich vermutlich nicht weiterhelfen. Sieht irgendwie so aus, als wäre mit dem CUL was. Ggf. mal an einem anderen PC testen, ob da über Screen oder die Serielle Konsole einer Arduino-IDE was vernünftiges rauskommt (culfw.de für die Kommandos).

Gruß und Viel Erfolg,

Beta-User

PS: für den Fall, dass der CUl wirklich einen Hau hat: für HM besser ein anderes IO besorgen

.

LuckyDay · 09 Juli 2018, 21:02:17

Zitat
ZitatDEF /dev/ttyACM0@19200 2306

wo hast du die 19200 her?

ich kenne bei den orginal culs nur 38400 bzw 9600
nimm mal die 38400

didi-fritz · 09 Juli 2018, 21:45:31

ich hab nun mit 38400 und 9600 getestet - leider ohne Erfolg.

Die Kommunikation mit dem Cul scheind ja zu funktionieren, da von manchen Sensoren die Daten gelesen werden

Beta-User · 09 Juli 2018, 22:15:45

Über das Thema mit der Baud-Rate bin ich auch mal gestolpert; da das Teil aber als Modem agiert, darf der Rechner die Baudrate vorgeben, es ist also scheinbar (fast) alles erlaubt...

Da der CUL sich ständig resettet, ist irgendwas anderes faul - dass überhaupt immer mal wieder etwas empfangen wird, ist zwar erfreulich, aber kein verlässliches Anzeichen, dass er wirklich funktioniert, jedenfalls beim Senden. Welche Sendeleistung ist eingestellt? Kannst du das testweise mal reduzieren?

Und bist du sicher, dass kein anderer OS-Prozess versucht, auf den CUL zuzugreifen?

LuckyDay · 09 Juli 2018, 22:18:04

Code Auswählen

hmProtocolEvents 1_dump

das ist ein Zeitfresser und eigentlich benützt man den nichtmehr. lösch den mal weg

Code Auswählen

2018-07-09 17:45:12 version No answer
das ist nicht gut

es gibt einen raw Befehl um einen Werksreset vom cul zu machen! mir fällt es nur nimmer ein

LuckyDay · 09 Juli 2018, 22:27:24

https://forum.fhem.de/index.php/topic,27861.msg207836.html#msg207836

set CUL raw e