CUL diconnected

Andreas_ · 04 Juli 2016, 17:24:31

Hallo liebe Profis,

nach lesen verschiedener Beiträge komme ich dennoch nicht weiter:
Hardware BananaPi mit CUL Stick, alles funktionierte. FHEM frisch upgedated (Nachdem die Ausfälle auftraten), System komplett neu gestartet, also auch den BananaPi geresetet.

Auffälligkeit: Der CUL wird warm, also man spürt, das er leicht warm ist, wenn man die Platine anfasst.

DAS System hat lange einwandfrei funktioniert. Allerdings hatte ich diesen Fehler schon öfter und schob es aber auf mechanischen Wackelkontakt durch die Schwingungen der am Bananapi fest angebrachten HDD. Mittlerweile ist die HDD separat gelagert, dann hat es wieder funktioniert.

Nun fängt es wieder an, vielleicht hat jemand ne Idee:

^{2016.07.04 17:12:24 3: CUL_HM set Kueche on
2016.07.04 17:12:24 3: CUL_HM set Arbeit1 on
2016.07.04 17:12:24 3: CUL_HM set Arbeit2 on
2016.07.04 17:12:24 3: CUL_HM set Arbeit3 on
2016.07.04 17:12:24 3: CUL_HM set Wohn1 on
2016.07.04 17:12:24 3: CUL_HM set Wohn2 on
2016.07.04 17:12:24 3: CUL_HM set Wohn3 on
2016.07.04 17:12:24 3: CUL_HM set Wohn4 on
2016.07.04 17:12:24 3: CUL_HM set Wohn5 on
2016.07.04 17:12:26 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.07.04 17:12:27 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.07.04 17:12:27 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:27 1: /dev/ttyACM0 reappeared (CUL_0)
2016.07.04 17:12:29 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.07.04 17:12:30 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.07.04 17:12:30 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:30 1: /dev/ttyACM0 reappeared (CUL_0)
2016.07.04 17:12:32 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.07.04 17:12:33 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.07.04 17:12:33 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:33 1: /dev/ttyACM0 reappeared (CUL_0)
2016.07.04 17:12:35 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.07.04 17:12:36 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.07.04 17:12:37 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:37 1: /dev/ttyACM0 reappeared (CUL_0)
2016.07.04 17:12:39 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.07.04 17:12:40 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.07.04 17:12:40 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:40 1: /dev/ttyACM0 reappeared (CUL_0)
2016.07.04 17:12:41 1: General 100-0
2016.07.04 17:12:41 1: General 100-0
2016.07.04 17:12:43 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.07.04 17:12:44 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.07.04 17:12:44 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:44 1: /dev/ttyACM0 reappeared (CUL_0)
2016.07.04 17:12:45 1: General 100-0
2016.07.04 17:12:45 1: General 100-0
2016.07.04 17:12:45 1: General 100-0
2016.07.04 17:12:45 1: General 100-0
2016.07.04 17:12:45 1: General 100-0
2016.07.04 17:12:45 1: General 100-0
2016.07.04 17:12:47 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.07.04 17:12:48 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.07.04 17:12:48 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:49 1: /dev/ttyACM0 reappeared (CUL_0)
2016.07.04 17:12:49 1: General 100-0
2016.07.04 17:12:49 1: General 100-0
2016.07.04 17:12:49 1: General 100-0
2016.07.04 17:12:49 1: General 100-0
2016.07.04 17:12:51 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.07.04 17:12:52 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.07.04 17:12:53 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:53 1: /dev/ttyACM0 reappeared (CUL_0)}

Wernieman · 05 Juli 2016, 09:51:25

"Der CUL wird warm" ... ich würde auf einen Defekt tippen ...

Ist der eigentlich Direkt am Pi oder über einen USB-Hub?

Aber etwas anderes:
Für die Zukunft ist es besser, einen Stick über "/dev/serial/by-id" oder alternativ "/dev/serial/by-path" anzulegen. Wenn man mehr als eine Serielle Schnittstelle hat, kann bei Verwendung von "/dev/tty*" es bei en zahlen zu Veränderungen kommen, d.h. aus 0 wird 1 oder umgekehrt .. nach jedem reboot.

Ich galueb aber nicht, das dieses Dein Fehlr ist, da er den Stick zuerst ansprechen kann:

Code Auswählen

2016.07.04 17:12:30 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.02016.07.04 17:12:30 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.07.04 17:12:30 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:30 1: /dev/ttyACM0 reappeared (CUL_0)7.04 17:12:30 3: CUL_0: Possible commands: BbCFiAZEKGMKUYRTVWXefmltux
2016.07.04 17:12:30 1: /dev/ttyACM0 reappeared (CUL_0)

P.S. Wie sieht die Stromversorgung aus?

Andreas_ · 05 Juli 2016, 10:48:55

Der Bananapi hängt an eine 3A Netzteil. Ich hab jetzt mal nen neuen CUL bestellt.Heute abend werde ich mal den CUL an nen Rasperry mit einer alten fhem Installation testen....dann werde ich sehen, ob der Stick zuverlässig funktioniert.
Bisher ist es so, das manche Befehle abgesetzt werden, viele aber nicht...

Wie ändere ich den Pfad für den Stick? In der fhem.cfg?

Mal sehen, danke für die Info, ich melde mich

Andreas_ · 05 Juli 2016, 14:09:38

Es geht mit folgender Konstellation auch nicht: Raspberrypi, FHEM 5.6, Cul Firmware V1.61.

Ich gehe davon aus, das der Stick ne Macke hat. Habe einen anderen gekauft und melde mich wenn der dann eingesetzt wird...

Wernieman · 06 Juli 2016, 08:08:23

ZitatWie ändere ich den Pfad für den Stick? In der fhem.cfg?

Ja, oder in FHEM selber bei der Definition des Sticks. Kannst Du bearbeiten ...

Andreas_ · 06 Juli 2016, 18:37:51

Auch auf die Gefahr, als völlig ahnungslos zu wirken...

_{Für die Zukunft ist es besser, einen Stick über "/dev/serial/by-id" oder alternativ "/dev/serial/by-path" anzulegen.}

Wie finde ich die ID? Ich habe folgendes gemacht:

^{root@bananapi ~ # lsusb
Bus 002 Device 002: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 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 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@bananapi ~ #}

und dann
in FHEM.CFG
_{define CUL_0 CUL /dev/serial/03eb@9600 1034}

oder auch mal

^{define CUL_0 CUL /dev/serial/Device002@9600 1034}

oder

^{define CUL_0 CUL /dev/serial@9600 1034}

eingegeben.... funktioniert nicht...

Es ist wohl ne sehr primitive Frage: Wie kriege ich den Pfad oder Devicename raus? Ich habe es nun mit dmesg, udevadm, ls -1 /dev probiert. Bei letzterem sieht man, das bei neu einstecken /serial hinzukommt..... aber wie oben eingegeben, es tut nicht...

Ich bitte um Hilfe, ich habe jetzt 2 Stunden rumgewürgt!

mw77 · 06 Juli 2016, 19:03:14

Zitatroot@bananapi ~ # lsusb

Gib mal den Befehll

Code Auswählen

ls /dev/serial/by-id/ ein

Dann sollte ungfähr so etwas dabei rauskommen

Zitat/dev/serial/by-id/usb-busware.de_CUL868-if00@9600

Dann kannst du mit

Code Auswählen

define CUL_0 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1034 den Cul einbinden.

Andreas_ · 06 Juli 2016, 19:10:09

Hallo nochmal,

Also es kam dann das raus:

_{root@bananapi ~ # ls /dev/serial/by-id/
usb-busware.de_CUL868-if00@
root@bananapi ~ #}

Also die 9600 usw, das hat es mir nicht angezeigt. Dann habe ich Deine Zeile eingebunden - es funktioniert

DANKE MW77!

... und noch viel besser:

also beim Versuch, den Tipp mit dem Pfad umzusetzen, fiel mir auf, das ich CUL_0 und CUL_1 definiert hatte, keine Ahnung warum..... Nun habe ich mal in der fhem.cfg gesucht und ganz am Ende der fhem.cfg folgendes z. Teil doppelt gefunden und gelöscht:

^{define CUL_1 CUL /dev/ttyACM1@9600 1134
define allowed_WEB allowed
attr allowed_WEB basicAuth XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
attr allowed_WEB validFor WEB
define allowed_WEBphone allowed
attr allowed_WEBphone basicAuth XXXXXXXXXXXXXXXXXXXXXXXXXXX
attr allowed_WEBphone validFor WEBphone}

Nun funktioniert es. Alle 9 Rolladen gehen gleichzeitig runter oder hoch, kein Fehler im log file...

FRAGE:
^{Für die Zukunft ist es besser, einen Stick über "/dev/serial/by-id" oder alternativ "/dev/serial/by-path" anzulegen. Wenn man mehr als eine Serielle Schnittstelle hat, kann bei Verwendung von "/dev/tty*" es bei en zahlen zu Veränderungen kommen, d.h. aus 0 wird 1 oder umgekehrt .. nach jedem reboot.}

Kann es daran liegen?

Ich weiß zwar oft nicht, was ich tue, aber das ich das nun gelöschte selber reinkopiert habe, daran kann ich mich echt nicht erinnern... DANKE für jeden TIPP!!!

Wernieman · 07 Juli 2016, 10:01:52

Es kann daran liegen.

Noch einen Tipp:
Schalte das "Autodiscover" beim Start von FHEM ab!

Code Auswählen

attr initialUsbCheck disable 1

Andreas_ · 09 Juli 2016, 08:02:03

Hallo noch mal,

also mein System läuft ja wieder auch mit dem alten CUL. Ich hatte ja einen neuen gekauft, eingesteckt, funktioniert auch einwandfrei. Nun habe ich noch mal die gelöschten Zeilen (siehe oben) in die fhem.cfg kopiert, den CUL_O wieder mit der Orginalpfadangabe versehen, also praktisch die fhem.cfg in den Zustand versetzt als es nicht funktionierte.

Allerdings hatte ich diese WebAuthent-Daten ja mit XXX versehen, was dann dazu führte, das ich mich mehr einloggen konnte

Dann habe ich das wieder entfernt (mit WINSCP und Systemneustart, weil ich ja nicht an die FHEM-Oberfläche kam), nur die zweite CUL- Definition reingeschrieben und das System läuft nun trotzdem einwandfrei. Ich wollte den Fehler nachvollziehen, was mir leider nicht gelungen ist.

Aus einer alten Sicherung, die funktionierte, fiel mir auf, das da zwar der CUL_1 am Ende der fhem.cfg definiert war, aber nicht diese WebAuthent-Zeilen.

Schade. Das nächste Mal mach ich ein Backup, bevor ich was ändere.

Nun habe ich die hier gegebenen Tipps (Pfad des CUL, Suche bei Start verhindern) wieder eingebunden und bin froh, das mein System funktioniert.

Ich bedanke mich bei allen, die mir die Tipps in einer für mich verständlichen Form gegeben haben.

D A N K E ! ! ! ! !