Raspi3B mit nanoCUL (CUL868) und FS20 läuft nicht

Begonnen von zuluhulu, 27 Januar 2021, 00:15:03

Vorheriges Thema - Nächstes Thema

zuluhulu

Moin,

ich habe letzten Sommer FHEM aufgesetzt auf einem Raspi 3B+ und den nanoCUL zur Steuerung der 12 bis 20 Schalter installiert. Die FS20 Steuerung ist seit 2010 etwas gewachsen und ich wollte statt der Fernbedienungen auch mal cool über das Display wischen können.

Nach und nach hatte ich alles am laufen. Dann hatte ich noch HOMEBRIDGE installiert und angebunden.
Mit dem iPhone konnte ich die FS20 dann über Apple HOME steuern.

Alles toll, bis ich den Raspi dann mal im Spätsommer 2020 upgedatet hatte, dann ging nichts mehr.
/dev/ttyUSB0 fehlte.
FHEM gesichert und gut. Raspi von Grund auf nochmal neu aufgesetzt. FHEM installiert, Backup retour,.....nix - bis heute.
Hatte keine Zeit und komme erst jetzt dazu mich darum zu kümmern

dmesg liefert folgendes:
[    4.105651] usb 1-1.1.2: new full-speed USB device number 5 using dwc_otg
[    4.264391] usb 1-1.1.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[    4.264407] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    4.264422] usb 1-1.1.2: Product: FT232R USB UART
[    4.264436] usb 1-1.1.2: Manufacturer: FTDI
[    4.264450] usb 1-1.1.2: SerialNumber: A50285BI


Der Eintrag ist wieder da
pi@lawrasp1:/dev $ ls -la ttyU*
crw-rw---- 1 root dialout 188, 0 Jan 26 23:30 ttyUSB0[/td]


FHEM sagt:
2021.01.12 18:33:50 1: Including fhem.cfg
2021.01.12 18:33:56 3: WEB: port 8083 opened
2021.01.12 18:33:56 2: eventTypes: loaded 70 events from ./log/eventTypes.txt
2021.01.12 18:33:56 3: Opening CUL868 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
2021.01.12 18:33:56 3: Setting CUL868 serial parameters to 38400,8,N,1
2021.01.12 18:55:28 3: CUL868: Possible commands: ABCEeFfGhiKklMmRTtUVWXxYZz
2021.01.12 18:55:28 3: CUL868 device opened
2021.01.12 18:55:28 1: Including ./log/fhem.save
2021.01.12 18:55:28 1: usb create starting
2021.01.12 18:55:29 3: Probing ZWDongle device /dev/serial0
2021.01.12 18:55:29 3: Probing ZWDongle device /dev/serial1
2021.01.12 18:55:29 3: Probing CUL device /dev/ttyAMA0
2021.01.12 18:55:30 3: Probing TCM_ESP3 device /dev/ttyAMA0
2021.01.12 18:55:30 3: Probing ZWDongle device /dev/ttyAMA0
2021.01.12 18:55:30 3: Probing SIGNALDuino device /dev/ttyAMA0
2021.01.12 18:55:30 3: Probing MYSENSORS device /dev/ttyAMA0
2021.01.12 18:55:30 3: Probing ArduCounter device /dev/ttyAMA0
2021.01.12 18:55:30 3: Probing ElsnerWS device /dev/ttyAMA0
2021.01.12 18:55:31 3: Probing FRM device /dev/ttyAMA0
2021.01.12 18:55:37 3: Probing CUL device /dev/ttyS0
2021.01.12 18:55:37 1: usb create end
2021.01.12 18:55:37 0: Featurelevel: 6
2021.01.12 18:55:37 0: Server started with 24 defined entities (fhem.pl:21056/2020-01-26 perl:5.028001 os:linux user:fhem pid:730)
2021.01.26 23:30:15 1: [b]/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 disconnected, waiting to reappear (CUL868)
2021.01.26 23:30:20 3: Setting CUL868 serial parameters to 38400,8,N,1
2021.01.26 23:30:29 1: Cannot init /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0, ignoring it (CUL868)[/b]
2021.01.26 23:47:44 2: AttrTemplates: got 127 entries
2021.01.26 23:48:07 3: FS20 set WZ.Licht.Erker on
2021.01.26 23:48:11 3: FS20 set WZ.Licht.Erker off


Unter "Everything" wird folgendes angezeigt: >> Bild

Ich kann mir jetzt nix mehr erklären. Habt Ihr Tips für mich? Was kann ich testen oder machen?
(nanoCUL abziehen und so hatte ich schon.)

Danke für Infos

cu Lothar


KölnSolar

Hi Lothar,
nimm mal das usb create raus. Und dann nach restart mal ein list CUL868 hier einstellen.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Otto123

Hi

attr initialUsbCheck disable 1
danach save
danach shutdown restart

;)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Das mit initialUsbCheck verhilft zwar zu einem schnelleren Start, dürfte aber kaum dazu beitragen, das eigentliche Problem zu beseitigen.

Sieht so aus, als könnte der USB-Seriell-Wandler den ATMega nicht zuverlässig erreichen. Sowas kann alle möglichen Ursachen haben, angefangen von falschem Netzteil über USB-Inkombabilitäten bis hin zu beschädigter firmware.

Hier würde ich darauf tippen, dass es ein Kompabilitätsproblem ist. Ursache dürfte sein, dass es kein originaler FTDI ist: http://www.starlino.com/ftdi-chip-real-of-fake-how-to-spot-a-fake-rt232r-rt232rl-and-others.html (gefunden mit der Seriennummer).

Würde empfehlen, den CUL gegen einen Maple-basierten zu tauschen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Da bin ich nicht ganz bei Dir:
2021.01.12 18:33:56 3: Opening CUL868 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
2021.01.12 18:33:56 3: Setting CUL868 serial parameters to 38400,8,N,1
2021.01.12 18:55:28 3: CUL868: Possible commands: ABCEeFfGhiKklMmRTtUVWXxYZz
2021.01.12 18:55:28 3: CUL868 device opened
...
2021.01.12 18:55:37 1: usb create end
2021.01.12 18:55:37 0: Featurelevel: 6
2021.01.12 18:55:37 0: Server started with 24 defined entities (fhem.pl:21056/2020-01-26 perl:5.028001 os:linux user:fhem pid:730)
2021.01.26 23:30:15 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 disconnected, waiting to reappear (CUL868)
2021.01.26 23:30:20 3: Setting CUL868 serial parameters to 38400,8,N,1
2021.01.26 23:30:29 1: Cannot init /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0, ignoring it (CUL868)
Ja bei usbcreate steht nix von der Schnittstelle. Ich weiß aber auch bei anderen Sticks, das die zuverlässig durch usb create "abgeschossen" werden. Teilweise so, dass man die vom Strom nehmen muss und ein restart nicht reicht.
Also der Verlauf im Log sieht schon etwas danach aus, kann aber auch sein nicht. Die Abschaltung von initialUsbCheck bringt mMn mehr Nutzen als Schaden :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Wir sind uns durchaus einig, dass man initialUsbCheck - so oder so - abschalten sollte ;D .

Es kann auch durchaus sein, dass das Ding wegen initialUsbCheck in die Knie geht, aber die eigentliche Ursache ist das mAn. nicht. In der verlinkten Quelle ist u.A. auch die Rede davon, dass man fakes durch zu hohe Baudraten abschießen kann, und initialUsbCheck setzt u.A. die Baudrate (mehrfach) auf 112k... Paßt also alles halbwegs zusammen ;) .

Als short term solution könnte es reichen, den Check zu deaktivieren, mittelfristig is mAn. Ersatz zu empfehlen.

Just my2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

Jetzt lasst doch den TE erst einmal die ersten Schritte machen....Dann wissen wir mehr.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt