Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

Nach Update/Upgrade Raspbian - ist ACM0 weg

Begonnen von 1wire, 14 Januar 2015, 11:46:39

Vorheriges Thema - Nächstes Thema

1wire

Hallo zusammen,
da ich meinen CUL von V1.55 auf aktuell V1.62 flashen wollte, hab ich erstmal mein Raspbian mit apt-get update und upgrade aktualisiert. Mein Raspbian war ein Stand von ca. Sept. 2014. Nach dem reboot war allerdings der CUL disconnectet und mit ls /dev/ stellte ich fest das kein ACM0 (auch kein ACMx) da ist.
Fhemlog:

2015.01.12 23:56:46 3: Opening CUL_0 device /dev/ttyACM0
2015.01.12 23:56:47 3: Setting CUL_0 baudrate to 9600
2015.01.12 23:56:47 3: CUL_0 device opened
2015.01.12 23:56:47 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2015.01.12 23:56:47 2: Switched CUL_0 rfmode to HomeMatic
2015.01.12 23:57:39 1: Including ./log/fhem.save
2015.01.12 23:57:43 1: usb create starting
2015.01.12 23:57:45 3: Probing CUL device /dev/ttyAMA0
2015.01.12 23:57:45 3: Probing TCM_ESP3 device /dev/ttyAMA0
2015.01.12 23:57:45 3: Probing FRM device /dev/ttyAMA0
2015.01.12 23:57:50 1: usb create end


Da ich vorher ein Image gezogen hatte bin ich noch mal zum vorherigen Zustand und hab da Update/Upgrade noch mal versucht und siehe da selbe Ergebnis ACMx ist weg.
Danach hab ich das neueste Raspbian
RASPBIAN
Debian Wheezy
Version:December 2014
Release date:2014-12-24

von Raspberry.org gezogen, auch da ist kein ACMx zu finden.

Mittlerweile bin ich jetzt wieder auf meinem Sept2014 stand und hab ohne Update/Upgrade den CUL mit FHEM auf V1.62 geflasht. Das ging wunderbar einfach. An Dieser Stelle mal ein DANKE an die unermüdlichen Entwickler und Tester für dieses Projekt.

Ist das jetzt nur bei mir?
Darf ich jetzt nie mehr Update machen ::)
Wie hänge ich den CUL bei dem neuen Raspbian ein?

VG
1wire

Tion

FHEM@CT||RFXTRX,CUL868@MAX,HM-Usb,JeeLink
Jee:TX29DTH-IT||Max:Thermostat,ShutterContact,
HM:SEC-MDIR,LC-SW1-PL2,LC-Dim1TPBU-FM,PB-2-WM55
RFX:FA20RF/2, HE501EU,ITL-230,OWL Intuition-lc,YCT-100,div Brennstuhl,IT 1500
FS20:IRU,KSE||FbDect 200,EG-PM2-LAN

1wire

Danke, das hab ich zwar schon gefunden aber nicht wirklich den Nutzen für mich erkannt.

Habe das aus probiert:
Beim alten System (Sept.2014)
ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 Jan  1  1970 usb-busware.de_CUL868-if00 -> ../../ttyACM0


nach dem Update und Reboot
ls -l /dev/serial/by-id
ls: Zugriff auf /dev/serial/by-id nicht möglich: Datei oder Verzeichnis nicht gefunden

sudo ls -l /dev/serial/by-id
ls: Zugriff auf /dev/serial/by-id nicht möglich: Datei oder Verzeichnis nicht gefunden


Die Idee war gut... hat aber nicht funktioniert.

ABER: die gute Nachricht. Der CUL wird im System schon irgendwie gefunden:

dmesg
[    3.627163] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=204b
[    3.635671] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.644536] usb 1-1.3: Product: CUL868
[    3.649773] usb 1-1.3: Manufacturer: busware.de


pi@PiFHEM ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0951:1607 Kingston Technology DataTraveler 100
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project


Ist es jetzt einer von diesen?
pi@PiFHEM ~ $ ls /dev
autofs           loop7               ram4    tty13  tty33  tty53      vcs1
block            loop-control        ram5    tty14  tty34  tty54      vcs2
bsg              MAKEDEV             ram6    tty15  tty35  tty55      vcs3
bus              mem                 ram7    tty16  tty36  tty56      vcs4
cachefiles       mmcblk0             ram8    tty17  tty37  tty57      vcs5
char             net                 ram9    tty18  tty38  tty58      vcs6
console          network_latency     random  tty19  tty39  tty59      vcs7
cpu_dma_latency  network_throughput  raw     tty2   tty4   tty6       vcsa
disk             null                root    tty20  tty40  tty60      vcsa1
fb0              ppp                 sda     tty21  tty41  tty61      vcsa2
fd               ptmx                sda1    tty22  tty42  tty62      vcsa3
full             pts                 sda2    tty23  tty43  tty63      vcsa4
input            ram0                shm     tty24  tty44  tty7       vcsa5
kmsg             ram1                stderr  tty25  tty45  tty8       vcsa6
log              ram10               stdin   tty26  tty46  tty9       vcsa7
loop0            ram11               stdout  tty27  tty47  ttyAMA0    xconsole
loop1            ram12               tty     tty28  tty48  ttyprintk  zero
loop2            ram13               tty0    tty29  tty49  urandom
loop3            ram14               tty1    tty3   tty5   vc-cma
loop4            ram15               tty10   tty30  tty50  vchiq
loop5            ram2                tty11   tty31  tty51  vc-mem
loop6            ram3                tty12   tty32  tty52  vcs


Falls ja, wie kann ich die genauer untersuchen bzw. Details ausgeben?

VG
1wire

betateilchen

was liefert denn ein

ll /sys/class/tty/ttyUSB*

als Ausgabe?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

1wire

leider auch nur ein
ls: Zugriff auf /sys/class/tty/ttyUSB* nicht möglich: Datei oder Verzeichnis nicht gefunden

1wire

#5
Also ich habe meine alte Umgebung vom Backup wieder hergestellt und das läuft jetzt erstmal so, ohne ein Upgrade

Dann hab ich auf meinem TestRaspi in aller Ruhe mal das neueste Raspbian auf SD-Karte gezogen und dann den CUL mal da angehängt und geprüft.

Und es geht.

Mein aktuelles Produktiv-System hat wohl arge Probleme. Na ja, ich werde jetzt in aller Ruhe das neue System sauber aufsetzen und dann das alte ablösen.

Danke für eure schnelle Hilfe.

VG
1wire

skiffin

Hallo,

dieses Verhalten kann ich bestätigen für Cubietruck mit neusten Igor-Image (Kernerl 3.4.103-sun7i+).

Genauer gesagt wird ein Device /dev/ttyACMirgendwas gar nicht erst erstellt.

dmesg sagt bei Ab- und Anstecken eines HM-CFG-USB:
[ 5041.863424] usb 4-1.1: USB disconnect, device number 3
[ 5050.497869] usb 4-1.1: new full-speed USB device number 8 using sw-ehci
[ 5050.616126] generic-usb 0003:1B1F:C00F.0007: hiddev0,hidraw0: USB HID v1.10 Device [eQ-3 HM-CFG-USB] on usb-sw-ehci-1.1/input0


dmesg zu CUL:
[ 5472.710922] usb 4-1.4: USB disconnect, device number 6
[ 5475.459756] usb 4-1.4: new full-speed USB device number 9 using sw-ehci


Für mich sieht es so aus als würde für den CUL keine Treiber geladen werden (können).

Cul und HM händen an einen aktiven USB-Hub und mit Igor-Image < 2.8 funktioniert das auch einwandfrei.

Grüße

Reimund
fhem auf SheevaPlug, RFXtrx, Z-Wave Aeon Labs