Cul868 auf Ninjablock (Beaglebone) disonnected

[KnockKnocK]

Hallo zusammen,

ich möchte gerne auf einem Ninjablock Fhem installieren,
scheitere aber daran, dass der CUL immer schon beim Start
von FHEM als disconnected gemeldet wird.
Ich habe es direkt am USB Anschluss sowie an 2 verschiedenen
aktiven USB Hubs versucht und komme einfach nicht weiter.
Ich habe fhem in die Gruppe dialout eingetragen und ich denke,
dass es kein Rechteproblem ist.


So stellt sich das im Log dar:
2013.11.24 06:34:02 3: Opening CUL_0 device /dev/ttyACM0
2013.11.24 06:34:03 3: Setting CUL_0 baudrate to 38400
2013.11.24 06:34:03 3: CUL_0 device opened
2013.11.24 06:34:03 2: CUL_0: unknown message ? (? is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x

2013.11.24 06:34:06 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.11.24 06:34:06 3: CUL_0: Possible commands: Noanswer
2013.11.24 06:34:06 1: Cannot init /dev/ttyACM0, ignoring it

Wenn ich dann dreist versuche in den homematic modus zu schalten kommt:

2013.11.24 06:34:16 2: CUL_0: Mode HomeMatic not supported

Auf meinem Raspberry funktioniert alles einwandfrei, daher würde ich
davon ausgehen, dass die Firmware funktionsfähig geflashed wurde.

Habt ihr zufällig einen Ansatzpunkt?

Vielen Dank im Voraus!

[betateilchen]

Berechtigungsproblem beim Zugriff auf /dev/ttyACM0

[KnockKnocK]

Hallo Betateilchen,

ich habe jetzt mal ergänzend chmod o+rw /dev/ttyACM0 ausgeführt und fhem
erneut gestartet. Leider brachte das keine Besserung. Der Benutzer fhem war aber
auch schon in der dialout Gruppe.


2013.11.25 09:09:54 3: Opening CUL_0 device /dev/ttyACM0
2013.11.25 09:09:54 3: Setting CUL_0 baudrate to 9600
2013.11.25 09:09:54 3: CUL_0 device opened
2013.11.25 09:09:55 2: CUL_0: unknown message ? (? is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x

2013.11.25 09:09:58 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.11.25 09:09:58 3: CUL_0: Possible commands: Noanswer
2013.11.25 09:09:58 1: Cannot init /dev/ttyACM0, ignoring it
2013.11.25 09:09:58 1: Including ./log/fhem.save
2013.11.25 09:09:58 1: usb create starting
2013.11.25 09:09:59 3: Opening CUL device /dev/ttyACM0
2013.11.25 09:09:59 3: Setting CUL baudrate to 9600
2013.11.25 09:09:59 3: CUL device opened
2013.11.25 09:09:59 1: define CUL_0 CUL /dev/ttyACM0@9600 1034
2013.11.25 09:09:59 1: usb create end

Ich komme einfach nicht dahinter 

[fiedel]

Hi,

hier mal einiger Lesestoff zu Rechteproblemen:

http://forum.fhem.de/index.php/topic,12037.msg71272.html#msg71272

http://forum.fhem.de/index.php/topic,11650.msg69264.html#msg69264

http://forum.fhem.de/index.php/topic,12611.msg75929.html#msg75929

http://forum.fhem.de/index.php/topic,9734.msg54202.html#msg54202

http://forum.fhem.de/index.php/topic,11441.msg66891.html#msg66891

http://forum.fhem.de/index.php/topic,11160.msg64567.html#msg64567


...wobei mir zur eindeutigen Identifikation eines Rechteproblems das "Permission denied" im Log fehlt.

Du solltest auch mal in Richtung Schnittstelle forschen und gucken, was Linux beim Anstecken des CUL sagt:

Auf der Konsole:

Code Auswählen Erweitern


tail -f /var/log/messages
oder
tail -f /var/log/syslog


Und unbedingt auch das "usbcreate" abschalten. Das kommt als Ursache auch in Frage.

Gruß

Frank

[betateilchen]

...wobei mir zur eindeutigen Identifikation eines Rechteproblems das "Permission denied" im Log fehlt.

Das "permission denied" gabs bei mir neulich auch nicht, als ich bei exakt dem gleichen Fehler vier Stunden lang nach der Ursache gesucht hatte...

[KnockKnocK]

MoinMoin,

erstmal vielen Dank für EureUnterstützung 

Ja das "permission denied" gab es am Anfang, das war aber vor dem Hinzufügen von fhem zur dialout Gruppe.
Ich hatte jetzt auch fhem zur Gruppe tty hinzugefügt, ebenfalls ohne Besserung.

Die Rechte auf /opt/fhem passen. (sudo chmod -R a+w fhem war bereits ausgeführt)

tail -f /var/log/syslog:
Nov 25 20:40:37 ninjablock kernel: [  704.453063] usb 1-1.1: new full-speed USB device number 5 using musb-hdrc
Nov 25 20:40:38 ninjablock kernel: [  704.554931] usb 1-1.1: New USB device found, idVendor=03eb, idProduct=204b
Nov 25 20:40:38 ninjablock kernel: [  704.554962] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Nov 25 20:40:38 ninjablock kernel: [  704.554992] usb 1-1.1: Product: CUL868
Nov 25 20:40:38 ninjablock kernel: [  704.554992] usb 1-1.1: Manufacturer: busware.de
Nov 25 20:40:38 ninjablock kernel: [  704.559417] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device

Weitere Hinweise in den Links habe ich jetzt leider nicht gefunden.

Für mich sieht alles ok aus FHEM sieht das leider anders.

Ist es möglich, dass eine andere Anwendung vom Ninjablock sich das Device unter den Nagel reißt?
Kann man sowas erkennen?

Ich bin kurz davor den Stick nochmal zu flashen.. nur wieso läuft er dann am PI?

lg
Patrick

[fiedel]

Hi Patrick,

was du noch testen kannst: In der Konsole "minicom" oder "screen" starten und mit der Schnittstelle verbinden. Dann die Version des CUL abfragen. Dann weißt du, ob der Zugriff auf die COM generell funktioniert. Der Stick scheint sich ja korrekt anzumelden.
Du könntest auch fhem zur Gruppe root hinzufügen, dann  sollte es ja gehen. Dann wieder auf user setzen und schrittweise Rechte anpassen.

[KnockKnocK]

Hi,

leider brachte auch das Hinzufügen zur Root Gruppe keinen Erfolg. Die Fehlermeldung blieb exakt wie zuvor bestehen. Ich habe dann mit minicom getestet und der CUL hat ganz brav geantwortet. Ich habe die Version mehrmals hintereinander abgefragt und das Kerlchen reagierte immer prompt. So langsam nehme ich das persönlich. Ich habe dann mal weitergeforscht und bin auf ältere Hinweise bez. irgendwelcher echo settings des USB Ports gestoßen. Auch testweise vorgenommene Manipulationen an diesen Settings blieben bisher erfolglos.
Passend hab ich jetzt heute meine Ninjablock Micro SD physisch geschrottet  Morgen kommt Ersatz und ich gebe nicht auf.
Falls Ihr noch Tipps habt - ich teste alles 

LG
Patrick

[fiedel]

Hi Patrick,

hm - sieht alles soweit richtig aus. Jetzt wird es langsam eng mit der Ferndiagnose. 
Hattest du denn mal dieses leidige "usbcreate" auskommentiert? Das hatten wir schon mal als Ursache dafür:

Code Auswählen Erweitern


2013.11.25 09:09:58 1: usb create starting
2013.11.25 09:09:59 3: Opening CUL device /dev/ttyACM0
2013.11.25 09:09:59 3: Setting CUL baudrate to 9600
2013.11.25 09:09:59 3: CUL device opened
2013.11.25 09:09:59 1: define CUL_0 CUL /dev/ttyACM0@9600 1034
2013.11.25 09:09:59 1: usb create end


Wenn du es nicht abschaltest und wie gewohnt den CUL per Hand in die CFG einträgst, gibt es eine Überschneidung.

Hast du vor Wut den armen Rechner in Richtung Wand handbeschleunigt? 

Gruß

Frank

Edit: Dein CUL funktioniert ja im Prinzip, aber hier musste ihn jemand wirklich neu flashen bei dem gleichen Fehlerbild:

http://forum.fhem.de/index.php/topic,14847.msg95432.html#msg95432

[KnockKnocK]

Pah ich wurde heute von der Post im Stich gelassen
Aaber: Neu beschrieben hatte ich das Kerlchen bereits - hab ich vergessen zu erwähnen!

Um hier nicht den falschen Eindruck zu erwecken:
In übernächtigter Dösbaddeligkeit habe ich scheinbar spontan verdummt vergessen, dass ein micro SD slot durchaus eine Auswurffunktion haben kann und wollte die Karte auf unsagbar idiotische Weise ziehen.
Näher will ich darauf nicht eingehen, ich bin allerdings nicht
gewalttätig sondern einfach nur doof 

Vielleicht bringt der komplette Neustart auf frischer SD ja was

LG Patrick

[KnockKnocK]

Hallo,

leider brachte auch ein Neubeginn keinen Erfolg und ich fürchte, dass es irgendwie am USB Port liegt.
Da ich keine neuen Ideen mehr habe, gebe ich hiermit
auf
Falls irgendwer noch eine Idee hat, so teste ich gerne nochmal - alles was bisher erwähnt wurde hat die disonnected Meldung nicht beeinflusst.
Dennoch vielen Dank für die Unterstützung!!

Lg Patrick