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"
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
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
CUL_HM Act_Dach RAWMSG: A0D348410250A5C00000006010000::-55:CUL
CUL_HM Act_Dach RSSI: -55
CUL_HM L_Stiege off
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
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
funktioniert leider schon wieder nicht. Die udev-rule war es auch nicht.
selbes Verhalten wie im 1. Post beschrieben
Zeig mal bitte die Ausgaben vonls -l /dev/serial/by-idund
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?
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)
# 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
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...
so sieht der CUL aus:
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
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 ;) .
ZitatZitatDEF /dev/ttyACM0@19200 2306
wo hast du die 19200 her?
ich kenne bei den orginal culs nur 38400 bzw 9600
nimm mal die 38400
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
Ü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?
hmProtocolEvents 1_dump
das ist ein Zeitfresser und eigentlich benützt man den nichtmehr. lösch den mal weg
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
https://forum.fhem.de/index.php/topic,27861.msg207836.html#msg207836 (https://forum.fhem.de/index.php/topic,27861.msg207836.html#msg207836)
set CUL raw e