Hallo,
ich hatte das Problem schon einmal. Nach einem Stromausfall. nun musste ich auf einen neuen Bananapi migrieren und das Problem ist wieder da.
Der CULL Meldet sich mit
2015.09.02 22:11:22 3: CUL_HM set HZ_SW4_SW_2 off
2015.09.02 22:11:24 1: /dev/ttyACM0 disconnected, waiting to reappear (COC)
2015.09.02 22:11:26 3: Setting COC serial parameters to 38400,8,N,1
2015.09.02 22:11:26 1: /dev/ttyACM0 reappeared (COC)
2015.09.02 22:11:26 3: COC: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.09.02 22:11:28 1: /dev/ttyACM0 disconnected, waiting to reappear (COC)
2015.09.02 22:11:29 3: Setting COC serial parameters to 38400,8,N,1
2015.09.02 22:11:29 1: /dev/ttyACM0 reappeared (COC)
2015.09.02 22:11:30 3: COC: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.09.02 22:11:33 1: /dev/ttyACM0 disconnected, waiting to reappear (COC)
2015.09.02 22:11:34 3: Setting COC serial parameters to 38400,8,N,1
2015.09.02 22:11:34 1: /dev/ttyACM0 reappeared (COC)
2015.09.02 22:11:34 3: COC: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.09.02 22:11:38 1: /dev/ttyACM0 disconnected, waiting to reappear (COC)
2015.09.02 22:11:39 3: Setting COC serial parameters to 38400,8,N,1
Dazu kommt in /var/log/messages
Sep 2 22:11:39 bananapi kernel: [ 349.461343] cdc_acm 4-1:1.0: ttyACM0: USB ACM device
Sep 2 22:11:42 bananapi kernel: [ 352.681185] usb 4-1: USB disconnect, device number 17
Sep 2 22:11:43 bananapi kernel: [ 353.442397] usb 4-1: new full-speed USB device number 18 using sw-ohci
Sep 2 22:11:43 bananapi kernel: [ 353.633557] usb 4-1: New USB device found, idVendor=03eb, idProduct=204b
Sep 2 22:11:43 bananapi kernel: [ 353.650889] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 2 22:11:43 bananapi kernel: [ 353.665221] usb 4-1: Product: CUL868
Sep 2 22:11:43 bananapi kernel: [ 353.676665] usb 4-1: Manufacturer: busware.de
Sep 2 22:11:43 bananapi kernel: [ 353.691409] cdc_acm 4-1:1.0: ttyACM0: USB ACM device
Sep 2 22:13:06 bananapi kernel: [ 437.022418] usb 4-1: USB disconnect, device number 18
Sep 2 22:13:07 bananapi kernel: [ 437.783952] usb 4-1: new full-speed USB device number 19 using sw-ohci
Sep 2 22:13:07 bananapi kernel: [ 437.974555] usb 4-1: New USB device found, idVendor=03eb, idProduct=204b
Sep 2 22:13:07 bananapi kernel: [ 437.991891] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 2 22:13:07 bananapi kernel: [ 438.006169] usb 4-1: Product: CUL868
Sep 2 22:13:07 bananapi kernel: [ 438.017601] usb 4-1: Manufacturer: busware.de
Sep 2 22:13:07 bananapi kernel: [ 438.033095] cdc_acm 4-1:1.0: ttyACM0: USB ACM device
Sep 2 22:13:46 bananapi kernel: [ 477.435767] usb 4-1: USB disconnect, device number 19
Sep 2 22:13:47 bananapi kernel: [ 478.194701] usb 4-1: new full-speed USB device number 20 using sw-ohci
Sep 2 22:13:47 bananapi kernel: [ 478.390549] usb 4-1: New USB device found, idVendor=03eb, idProduct=204b
Sep 2 22:13:47 bananapi kernel: [ 478.408356] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 2 22:13:47 bananapi kernel: [ 478.422699] usb 4-1: Product: CUL868
Sep 2 22:13:47 bananapi kernel: [ 478.434112] usb 4-1: Manufacturer: busware.de
Sep 2 22:13:48 bananapi kernel: [ 478.448123] cdc_acm 4-1:1.0: ttyACM0: USB ACM device
lsusb gibt folgendes aus
root@bananapi:/var/log# lsusb
Bus 004 Device 029: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Die fhem.cfg sieht so aus
define COC CUL /dev/ttyACM0@38400 4711
attr COC rfmode HomeMatic
Im Logfile finde ich auch noch
2015-09-02_19:54:19 COC UNKNOWNCODE A0C5586702F211A00000000C44A::-78:COC
2015-09-02_21:30:47 COC UNKNOWNCODE A0C7B86702F211A00000000C54A::-66.5:COC
Beim ersten Mal habe ich es mit einem Reflash hinbekommen leider ist das diesmal nicht der Fall.
Ja ich habe im Forum gesucht und die Lösungsvarianten hier ( modem treiben löschen, hatte ich aber gar keinen, Udev Rules erstellen etc) aber nix hat funktioniert.
Nun spielt mein FHEM installation komplett verrückt.
Hat jemand einen Lösungsansatz ?
Bin echt für jeden Tip dankbar
Cheers
skelton
Hi nochmal,
hier noch die root@bananapi:~# cat /etc/udev/rules.d/10-cul.rules
KERNEL=="ttyACM*", ATTRS{product}=="CUL868", SYMLINK+="cul868", wqOWNER="fhem", GROUP="fhem", MODE="660"
root@bananapi:~#
und ein ps -aux ( fhem ist gestoppt ) um auszuschliessen das es ein anderer konkurrierender Prozess ist
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 2360 716 ? Ss Sep02 0:05 init [2]
root 2 0.0 0.0 0 0 ? S Sep02 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S Sep02 0:04 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S Sep02 0:00 [kworker/u:0]
root 6 0.0 0.0 0 0 ? S Sep02 0:00 [migration/0]
root 7 0.0 0.0 0 0 ? S Sep02 0:00 [migration/1]
root 8 0.0 0.0 0 0 ? S Sep02 0:00 [kworker/1:0]
root 9 0.0 0.0 0 0 ? S Sep02 0:01 [ksoftirqd/1]
root 10 0.0 0.0 0 0 ? S< Sep02 0:00 [cpuset]
root 11 0.0 0.0 0 0 ? S< Sep02 0:00 [khelper]
root 12 0.0 0.0 0 0 ? S Sep02 0:00 [kdevtmpfs]
root 13 0.0 0.0 0 0 ? S< Sep02 0:00 [netns]
root 14 0.0 0.0 0 0 ? S Sep02 0:00 [sync_supers]
root 15 0.0 0.0 0 0 ? S Sep02 0:00 [bdi-default]
root 16 0.0 0.0 0 0 ? S< Sep02 0:00 [kintegrityd]
root 17 0.0 0.0 0 0 ? S< Sep02 0:00 [crypto]
root 18 0.0 0.0 0 0 ? S< Sep02 0:00 [kblockd]
root 19 0.0 0.0 0 0 ? S Sep02 0:03 [khubd]
root 20 0.0 0.0 0 0 ? S< Sep02 0:00 [cpufreq_uevent]
root 21 0.0 0.0 0 0 ? S< Sep02 0:00 [md]
root 22 0.0 0.0 0 0 ? S< Sep02 0:00 [kfantasy]
root 23 0.0 0.0 0 0 ? S< Sep02 0:00 [rpciod]
root 24 0.0 0.0 0 0 ? S Sep02 0:01 [kworker/1:1]
root 25 0.0 0.0 0 0 ? S Sep02 0:00 [khungtaskd]
root 26 0.0 0.0 0 0 ? S Sep02 0:00 [kswapd0]
root 27 0.0 0.0 0 0 ? SN Sep02 0:00 [ksmd]
root 28 0.0 0.0 0 0 ? S Sep02 0:00 [fsnotify_mark]
root 29 0.0 0.0 0 0 ? S< Sep02 0:00 [nfsiod]
root 30 0.0 0.0 0 0 ? S< Sep02 0:00 [cifsiod]
root 44 0.0 0.0 0 0 ? S< Sep02 0:00 [kthrotld]
root 45 0.0 0.0 0 0 ? S Sep02 0:00 [scsi_eh_0]
root 47 0.0 0.0 0 0 ? S Sep02 0:00 [kworker/u:2]
root 49 0.0 0.0 0 0 ? S Sep02 0:00 [cfinteractive]
root 50 0.0 0.0 0 0 ? S< Sep02 0:00 [binder]
root 51 0.0 0.0 0 0 ? S< Sep02 0:00 [codec_resume]
root 52 0.0 0.0 0 0 ? S Sep02 0:10 [hdmi proc]
root 53 0.0 0.0 0 0 ? S Sep02 0:00 [mmcqd/0]
root 54 0.0 0.0 0 0 ? S< Sep02 0:00 [deferwq]
root 55 0.0 0.0 0 0 ? S Sep02 0:00 [jbd2/sda1-8]
root 56 0.0 0.0 0 0 ? S< Sep02 0:00 [ext4-dio-unwrit]
root 157 0.0 0.1 10372 1124 ? Ss Sep02 0:00 udevd --daemon
root 1094 0.0 0.1 31420 1484 ? Ssl Sep02 0:00 /usr/sbin/rsyslogd
root 1153 0.0 0.3 7168 3408 ? Ss Sep02 0:10 /usr/sbin/haveged -w 1024
root 1168 0.0 0.0 6108 796 ? Ss Sep02 0:00 /usr/sbin/cron
ntp 1245 0.0 0.1 4716 1692 ? Ss Sep02 0:02 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:109
root 1288 0.0 0.1 6516 1028 ? Ss Sep02 0:00 /usr/sbin/sshd
root 1314 0.0 0.0 4012 712 tty1 Ss+ Sep02 0:00 /sbin/getty 38400 tty1
root 1315 0.0 0.0 4012 712 tty2 Ss+ Sep02 0:00 /sbin/getty 38400 tty2
root 1316 0.0 0.0 4012 712 tty3 Ss+ Sep02 0:00 /sbin/getty 38400 tty3
root 1317 0.0 0.0 4012 712 tty4 Ss+ Sep02 0:00 /sbin/getty 38400 tty4
root 1318 0.0 0.0 4012 712 tty5 Ss+ Sep02 0:00 /sbin/getty 38400 tty5
root 1319 0.0 0.0 4012 712 tty6 Ss+ Sep02 0:00 /sbin/getty 38400 tty6
root 1320 0.0 0.0 1784 648 ttyS0 Ss+ Sep02 0:00 /sbin/getty -L ttyS0 115200 vt100
root 1331 0.0 0.0 0 0 ? S Sep02 0:00 [kauditd]
root 1561 0.0 0.0 0 0 ? S Sep02 0:00 [kworker/0:0]
root 1808 0.1 0.0 0 0 ? S 05:22 0:00 [kworker/0:2]
root 1809 0.3 0.2 9972 2656 ? Ss 05:29 0:00 sshd: root@pts/0
root 1811 0.0 0.1 6236 1668 pts/0 Ss 05:29 0:00 -bash
root 1815 0.0 0.0 0 0 ? S 05:29 0:00 [flush-8:0]
root 1817 0.0 0.0 0 0 ? S 05:31 0:00 [kworker/0:1]
root 1819 0.0 0.0 5884 908 pts/0 R+ 05:32 0:00 ps aux
Linux Variante ist Debian GNU/Linux 8 auf dem aktuellen Stand
CUL Firmware ist CUL_VER_161 mit 1.55 war es aber auch nicht besser
dfu-programmer ist dfu-programmer-0.7.2
HILFE, mein Kaffee ist morgens kalt :-)
Niemand eine Idee ????
Hi
hat wirklich niemand eine Idee.... ?
Ich habe glaube ich fast alles was im Internet an Tips & Tricks Stand ausprobiert aber entweder ich übersehe die Lösung oder es tut sich hier ein neues Problem auf....
Was habe ich bisher alles gemacht
- Udev-Regeln.
- CUL neu geflasht
- Firmware neu compliliert und nochmals geflachst
- Debian Distribution nochmals komplett neu installiert
- umask des tty umgestellt auf 666
- Bananapi Pro Netzteil getauscht
- Keine weiteren USB Teilnehmer am Bus
- FHEM aktualisiert
- nach konkurrierendem Prozessen gesucht
usw...
Ich währe wirklich dankbar wenn man mich mal in die richtige Richtung schupsen könnte ....
Meine fhem steht komplett ....
cheers
skeleton
Für gewöhnlich arbeitet der Busware CUL mit einer Baudrate von 9600.
define CUL1 CUL /dev/ttyACM0@9600 1234
Hi,
danke für den TIP aber die 38k stehen da schon seit ca 1 Jahr und es gab nie Probleme.
Aber ich habe deinen Rat befolgt und es auf 9600 umgestellt was aber keine Änderung brachte....
Also das Problem besteht immer noch :-(
Cheers
skeleton
Hi,
Habe das Problem seit ein paar Tagen auch obwohl ich nichts am System geändert habe ausser Updates
Gab es eine Lösung ?
Gruss
https://forum.fhem.de/index.php/topic,28496.msg231954/topicseen.html#msg231954 (https://forum.fhem.de/index.php/topic,28496.msg231954/topicseen.html#msg231954)
Noe ne echte Lösung habe ich nicht gefunden.
Da ich auch immer mehr Fehler in meiner FHEM installation feststelle ( Befehle werden nicht mehr gesendet, Gewisse Türöffner Meldungen werden sehr stark verzögert behandelt ( sinnvoll bei einer Alarmanlage haha ) andere werden sofort signalisiert. CUL streikt nach wie vor und quellt die Platte zu, und das auch noch immer öfter ( auch ein neuer CUL, mit 8 DB Antenne, ich wollte einen HW Fehler ausschliessen)
Routinen die definitiv 1 Jahr gelaufen sind verweigern den Dienst ( auslesen der aktuellen desired Temp wenn Fenster auf und Rückstellen darauf wenn Fenster zu. Gas Zaehlerstand auslesen und Verbrauchs Berechnung)
Ich könnte so stundenlang weiter erzählen. Zuerst dachte ich es liegt an mir, aber nach einer langen Unterhaltung mit einem Bekannten, scheine nicht nur ich solche frustrierenden Erlebnisse zu haben. Auf jedenfall bin ich neuen Systemen die meine HW Unterstützen und einfacher zu Verwalten sind aufgeschlossen. Ich habe einfach keine Zeit alle 3 Tage Fehler zu suchen
Ich weiss Entwickeln ist schwer ( ich bin im Software Vertrieb ....Ok) aber irgendwie glaube ich ist meine Combo nicht sehr gelungen...mag sein das das alles bei anderen fehlerfrei funktioniert aber bei mir eben net.
Keine Kritik am Entwickler, Keine Kritik am Produkt, lediglich ein Erfahrungsbericht.
Bei mir ist ein zeitliches Intervall (~ 1.5h) zu finden, und es "verschwinden" immer zuerst Beide, dann werden diese wieder automatisch hinzugefuegt :
2016.03.13 00:06:53 1: /dev/ttyUSB2 disconnected, waiting to reappear (myJeeLink)
2016.03.13 00:06:53 1: /dev/ttyACM1 disconnected, waiting to reappear (CUL1)
2016.03.13 00:06:55 3: Setting CUL1 serial parameters to 9600,8,N,1
2016.03.13 00:06:55 1: /dev/ttyACM1 reappeared (CUL1)
2016.03.13 00:06:55 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2016.03.13 00:06:55 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.03.13 00:06:55 1: /dev/ttyUSB2 reappeared (myJeeLink)
2016.03.13 01:23:47 1: /dev/ttyUSB2 disconnected, waiting to reappear (myJeeLink)
2016.03.13 01:23:47 1: /dev/ttyACM1 disconnected, waiting to reappear (CUL1)
2016.03.13 01:23:48 3: Setting CUL1 serial parameters to 9600,8,N,1
2016.03.13 01:23:48 1: /dev/ttyACM1 reappeared (CUL1)
2016.03.13 01:23:48 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2016.03.13 01:23:48 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.03.13 01:23:49 1: /dev/ttyUSB2 reappeared (myJeeLink)
2016.03.13 02:48:16 1: /dev/ttyUSB2 disconnected, waiting to reappear (myJeeLink)
2016.03.13 02:48:16 1: /dev/ttyACM1 disconnected, waiting to reappear (CUL1)
2016.03.13 02:48:18 3: Setting CUL1 serial parameters to 9600,8,N,1
2016.03.13 02:48:18 1: /dev/ttyACM1 reappeared (CUL1)
2016.03.13 02:48:18 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2016.03.13 02:48:18 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.03.13 02:48:18 1: /dev/ttyUSB2 reappeared (myJeeLink)
2016.03.13 04:25:31 1: /dev/ttyUSB2 disconnected, waiting to reappear (myJeeLink)
2016.03.13 04:25:31 1: /dev/ttyACM1 disconnected, waiting to reappear (CUL1)
2016.03.13 04:25:32 3: Setting CUL1 serial parameters to 9600,8,N,1
2016.03.13 04:25:32 1: /dev/ttyACM1 reappeared (CUL1)
2016.03.13 04:25:32 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2016.03.13 04:25:33 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.03.13 04:25:33 1: /dev/ttyUSB2 reappeared (myJeeLink)
2016.03.13 05:53:03 1: /dev/ttyUSB2 disconnected, waiting to reappear (myJeeLink)
2016.03.13 05:53:04 1: /dev/ttyACM1 disconnected, waiting to reappear (CUL1)
2016.03.13 05:53:05 3: Setting CUL1 serial parameters to 9600,8,N,1
2016.03.13 05:53:05 1: /dev/ttyACM1 reappeared (CUL1)
2016.03.13 05:53:05 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2016.03.13 05:53:05 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.03.13 05:53:05 1: /dev/ttyUSB2 reappeared (myJeeLink)
2016.03.13 07:21:38 1: /dev/ttyUSB2 disconnected, waiting to reappear (myJeeLink)
2016.03.13 07:21:38 1: /dev/ttyACM1 disconnected, waiting to reappear (CUL1)
2016.03.13 07:21:39 3: Setting CUL1 serial parameters to 9600,8,N,1
2016.03.13 07:21:39 1: /dev/ttyACM1 reappeared (CUL1)
2016.03.13 07:21:39 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2016.03.13 07:21:40 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.03.13 07:21:40 1: /dev/ttyUSB2 reappeared (myJeeLink)
Jemand 'ne Idee wie ich dem auf die Spur komme ?
Wie gesagt ich habe nicht wirklich was am System geändert ausser Updates ...
Gruss
Joe
Hallo,
Was ich noch festgestellt habe ist folgendes :
Ich habe 2 x CUL (MAX, SlowRF) als ttyACM0/1.
Nur einer davon taucht aber auch als USB-Device (CUL868) auf und nur einer steigt auch immer aus.
Kann man die Zuordnungen der Devices (ttyUSBxx bzw ttyACMx) loschen und die Devices neu erkennen lassen ?
Gruss
Anstatt über ttyACMX, welche sich nach einem Neustart ändern kann, solltest Du über die Serien-Devices gehen.
/dev/serial/by-id/
z.B. bei mir, da ist es aber ein JeeLink:
/dev/serial/by-id/pci-FTDI_FT232R_USB_UART_A702GD6P-if00-port0
Hatte dort auch mal 2 CULs, welche nur momentan wegen Nichtgebrauch nicht gesteckt sind.
2 Kleine Frage
a) Wie hast Du den Stick angeschlossen, USB-Hub?
b) wie hast Du Ihn geflasht (Direkt, USB-Hub, Win/Lin-Rechner ...)
Bitte Entschuldige, wenn Du es schon geschrieben hast .. habe es so nicht gefunden.
Kleine Ergänzung:
Habe den Thread nur durch Zufall gesehen. Hätte Ihn eher unter "Einplatienenrechner" oder "Linux-Server" gesehen ..
Hi,
das mit by-id habe ich bereits gelesen, behebt aber nicht mein Problem.
Denn der CUL verschwindet tatsächlich am Raspy und wird dann wieder erkannt ...
Hängen alle seit 3 Jahren am selben USB-HUB. Wie ich die geflasht habe ? Bin mir nicht mehr sicher, glaube direkt am Raspy ...
Kann man die Zuordnungen aufm Raspy irgendwie komplett "cleanen "
Gruss
Joe
Wie meinst Du das??
Ich muß jetzt auch gestehen, das ich nicht von der RasPi, sondern der Linux-Server-Seite komme. Kann Dir also bezüglich Linux, aber wenig bezüglich RasPi helfen.
Was mich wundert, warum der "Cul" bei Dir immer wieder verschwindet. Mal so als Test, wenn fhem nicht läuft, passiert dieses dann auch?
Edit:
Bist Du Dir sicher, das der Cul sauber funktioniert? Du hattest geschrieben, das Du beim letzten mal neu Flashen mustest ...
P.S. Aus welcher Ecke Deutschlands kommst Du?
Wenn aus Sachsen .. habe (momentan) 2 Cul über ... zum testen
Hab nun den USB-Hub getauscht und nun geht wieder alles.
Der muss wohl mit der Zeit was abbekommen haben ...
Oder das erkennen der neuen USB-Hub-Hardware hat was geändert ...