[gelöst] nanocul läuft nicht mehr auf Raspberry Pi 4

Begonnen von SirBen, 27 Dezember 2019, 16:16:01

Vorheriges Thema - Nächstes Thema

SirBen

Moin,
ich habe meinen Banana Pi gegen einen Raspberry Pi 4 ausgetauscht und habe FHEM komplett umgezogen.
Es läuft soweit alles, bis auf den nanoCul.
Ich habe ihn selbst gebaut mit einem nano clon.
Auf dem Raspberry Pi kann ich alle HM Geräte empfangen, allerdings nichts senden.
Stecke ich den nanoCul wieder an den Banana Pi, läuft auf Anhieb alles.
Im Log des Raspberry Pi steht nanoCUL: "Unknown code ERR:CCA, help me!"
Es kann allerdings kein Störsender sein, weil auf dem Banana Pi alles läuft.
Habe auch mit einem DVB-T Stick die Frequenz überwacht, keine Störungen zu sehen.

Nun vermute ich ein Problem mit den Treibern.
dmesg gibt auf dem Banana Pi folgendes aus:
[   11.045589] hub 5-0:1.0: 1 port detected
[   11.499646] usb 3-1: new full-speed USB device number 2 using ohci-platform
[   11.593725] zram0: detected capacity change from 0 to 52428800
[   11.724807] usb 3-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63
[   11.724824] usb 3-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[   11.724830] usb 3-1: Product: USB2.0-Serial
[   13.300161] usbcore: registered new interface driver usbserial_generic
[   13.300224] usbserial: USB Serial support registered for generic
[   13.308486] usbcore: registered new interface driver ch341
[   13.308558] usbserial: USB Serial support registered for ch341-uart
[   13.308652] ch341 3-1:1.0: ch341-uart converter detected
[   13.321047] usb 3-1: ch341-uart converter now attached to ttyUSB0


vom Raspberry Pi:
[30623.008125] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
[30623.144480] usb 1-1.3: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63
[30623.144487] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[30623.144493] usb 1-1.3: Product: USB2.0-Serial
[30623.147104] ch341 1-1.3:1.0: ch341-uart converter detected
[30623.153854] usb 1-1.3: ch341-uart converter now attached to ttyUSB0


Was mir auffällt:
[   13.300161] usbcore: registered new interface driver usbserial_generic
gibt es beim Raspberry Pi nicht.

Die def vom nanoCul sieht so aus:
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 1234

Auf dem Raspberry Pi kann ich die Version etc. vom nanoCul auslesen.

Hat jemand einen Rat für mich?

Vielen Dank schon mal und frohe Feiertage!

LG Ben

Otto123

Hi Ben,

ZitatAuf dem Raspberry Pi kann ich alle HM Geräte empfangen, allerdings nichts senden.
Wie äußert sich "nicht senden" ?
Hast Du mal ein list vom cul und von einem HM Device wenn es nicht steuerbar ist?

ich vermute ja ein Problem mit der hmId.

BTW: ich würde perspektivisch auf dem Pi lieber ein richtiges HM (19€) Modul von elv stecken https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi

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

SirBen

Hi,
hier mal das list von einem Rollladenaktor:
Internals:
   DEF        120101
   FUUID      5d3a0600-f33f-2b06-7d63-367d83b6f700f538
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     5
   NAME       HM_120101
   NOTIFYDEV  global
   NR         89
   NTFY_ORDER 50-HM_120101
   STATE      MISSING ACK
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:1B - t:10 s:120101 d:310388 0601000032
   nanoCUL_MSGCNT 5
   nanoCUL_RAWMSG A0E1BA2101201013103880601000032::-47.5:nanoCUL
   nanoCUL_RSSI -47.5
   nanoCUL_TIME 2019-12-27 15:35:12
   peerList   self01,self02,
   protCmdDel 8
   protLastRcv 2019-12-27 15:35:10
   protRcv    2 last_at:2019-12-27 15:35:10
   protResnd  18 last_at:2019-12-27 20:16:51
   protResndFail 6 last_at:2019-12-27 20:16:57
   protSnd    11 last_at:2019-12-27 20:16:36
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL cnt:5 min:-53 max:-47.5 avg:-50.2 lst:-47.5
   rssi_nanoCUL cnt:2 min:-53 max:-50 avg:-51.5 lst:-50
   READINGS:
     2019-12-26 15:58:01   CommandAccepted yes
     2019-07-25 21:41:52   D-firmware      2.4
     2019-07-25 21:41:52   D-serialNr      RolloKuec1
     2019-12-22 09:28:51   PairedTo        0x310388
     2019-08-01 09:17:38   R-driveDown     18.5 s
     2019-07-25 21:42:08   R-driveTurn     0.5 s
     2019-08-01 09:17:38   R-driveUp       20 s
     2019-07-25 21:42:07   R-pairCentral   0x310388
     2019-07-25 21:42:09   R-self01-lgActionType jmpToTarget
     2019-07-25 21:42:09   R-self01-lgOnLevel 100 %
     2019-07-25 21:42:09   R-self01-shActionType jmpToTarget
     2019-07-25 21:42:09   R-self01-shOnLevel 100 %
     2019-07-25 21:42:10   R-self02-lgActionType jmpToTarget
     2019-07-25 21:42:10   R-self02-lgOnLevel 100 %
     2019-07-25 21:42:10   R-self02-shActionType jmpToTarget
     2019-07-25 21:42:10   R-self02-shOnLevel 100 %
     2019-07-25 21:42:08   R-sign          off
     2019-12-27 15:35:10   deviceMsg       off (to nanoCUL)
     2019-07-25 22:51:48   fwUpdate        done
     2019-12-27 15:35:10   level           0
     2019-12-27 15:35:10   motor           stop:off
     2019-12-27 15:35:10   pct             0
     2019-12-27 11:32:44   peerList        self01,self02,
     2019-12-22 09:28:49   powerOn         2019-12-22 09:28:49
     2019-12-27 15:35:10   recentStateType info
     2019-12-27 20:16:57   state           MISSING ACK
     2019-12-27 15:35:10   timedOn         off
   helper:
     HM_CMDNR   30
     cSnd       0131038812010100040000000000,01310388120101010E
     getCfgList all
     getCfgListNo ,3
     mId        0005
     peerFriend peerSens,peerVirt
     peerOpt    3:blindActuator
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     dir:
       cur        stop
       rct        down
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       newChn     +120101,00,00,00
       nextSend   1577457312.75059
       prefIO     
       rxt        0
       vccu       
       p:
         120101
         00
         00
         00
     mRssi:
       mNo        1B
       io:
         nanoCUL:
           -39.5
           -39.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         nanoCUL
       flg        A
       ts         1577457312.6518
       ack:
         HASH(0x4212920)
         1B800231038812010100
     rssi:
       at_nanoCUL:
         avg        -50.2
         cnt        5
         lst        -47.5
         max        -47.5
         min        -53
       nanoCUL:
         avg        -51.5
         cnt        2
         lst        -50
         max        -50
         min        -53
     tmpl:
Attributes:
   IODev      nanoCUL
   autoReadReg 4_reqStatus
   event-on-change-reading pct,motor,state
   expert     0_defReg
   firmware   2.4
   genericDeviceType blind
   model      HM-LC-BL1-FM
   peerIDs    00000000,12010101,12010102,
   room       Küche,CUL_HM,Homebridge
   serialNr   RolloKuec1
   siriName   Rollladen
   subType    blindActuator
   webCmd     statusRequest:toggleDir:on:off:up:down:stop


und hier das vom cul:
Internals:
   CMDS       ABCEeFfGiKlMNRTtUVWXxZ
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 1234
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
   FD         4
   FHTID      1234
   FUUID      5c850f39-f33f-2b06-1c60-ac40d8efb5887847
   NAME       nanoCUL
   NR         31
   NR_CMD_LAST_H 4
   PARTIAL   
   RAWMSG     ERR:CCA
   RSSI       -40.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) nanoCUL868 (F-Band: 868MHz)
   initString X21
Ar
   nanoCUL_MSGCNT 43
   nanoCUL_TIME 2019-12-27 20:16:53
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-12-27 08:34:48   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2019-12-27 20:13:39   cmds             A B C E e F f G i K l M N R T t U V W X x Z
     2019-12-27 08:35:24   raw             No answer
     2019-12-27 20:16:53   state           Initialized
     2019-12-27 10:51:50   uptime          0 02:16:39
     2019-12-27 08:47:36   version         V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) nanoCUL868 (F-Band: 868MHz)
   XMIT_TIME:
     1577474196.87547
     1577474201.96306
     1577474207.35627
     1577474211.96831
   helper:
     120101:
       QUEUE:
     120102:
       QUEUE:
     120201:
       QUEUE:
     120202:
       QUEUE:
     120203:
       QUEUE:
     120301:
       QUEUE:
     220101:
       QUEUE:
     220201:
       QUEUE:
     220301:
       QUEUE:
     220401:
       QUEUE:
Attributes:
   hmId       310388
   rfmode     HomeMatic



Hier mal aus dem WIKI die Befehle zum Kontrollieren der seriellen Schnittstelle:
root@SERVER:~# ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Dez 27 07:30 /dev/ttyAMA0
root@SERVER:~# ls -l /dev/serial*
lrwxrwxrwx 1 root root  7 Dez 27 07:29 /dev/serial1 -> ttyAMA0

/dev/serial:
insgesamt 0
drwxr-xr-x 2 root root 60 Dez 27 20:13 by-id
drwxr-xr-x 2 root root 60 Dez 27 20:13 by-path


und hier lsusb:
root@SERVER:~# lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8564:1000 Transcend Information, Inc. JetFlash
Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 012: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub



Im Log vom Raspberry Pi äußert sich das vergebliche Senden mit dem Eintrag:
2019.12.27 20:16:36 3: CUL_HM set HM_120101 statusRequest
2019.12.27 20:16:38 3: nanoCUL: Unknown code ERR:CCA, help me!


Auf dem Banana Pi habe ich Armbian installiert und auf dem Raspberry Pi habe ich Raspbian buster drauf.
Installiert habe ich FHEM nach der WIKI Anleitung und dann den FHEM Ordner gelöscht und den FHEM Ordner vom Banana Pi drauf kopiert.
Läuft halt alles wie vorher, nur der nanoCul nicht mehr...

Vielen Dank!

Gruß Ben

Otto123

Hallo Ben,

den hier finde ich lustig - wie macht man sowas?
     2019-07-25 21:41:52   D-serialNr      RolloKuec1
Dein Zitat aus dem Wiki ist glaube ich für Dich nicht zutreffend, da geht es doch um die interne UART Schnittstelle. :o

Wieso gehst Du davon aus, dass der CUL (etwas sinnvolles) empfängt?

kannst Du mal bitte so testen und die Ausgabe posten:
ls -lhaR /dev/serial

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

SirBen

Hi Otto,
root@SERVER:~# ls -lhaR /dev/serial
/dev/serial:
insgesamt 0
drwxr-xr-x  4 root root   80 Dez 27 20:13 .
drwxr-xr-x 18 root root 3,9K Dez 27 20:13 ..
drwxr-xr-x  2 root root   60 Dez 27 20:13 by-id
drwxr-xr-x  2 root root   60 Dez 27 20:13 by-path

/dev/serial/by-id:
insgesamt 0
drwxr-xr-x 2 root root 60 Dez 27 20:13 .
drwxr-xr-x 4 root root 80 Dez 27 20:13 ..
lrwxrwxrwx 1 root root 13 Dez 27 20:13 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0

/dev/serial/by-path:
insgesamt 0
drwxr-xr-x 2 root root 60 Dez 27 20:13 .
drwxr-xr-x 4 root root 80 Dez 27 20:13 ..
lrwxrwxrwx 1 root root 13 Dez 27 20:13 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0 -> ../../ttyUSB0


Die Rollladenaktoren habe ich selbst gebaut. Bei 10 Stück hat sich der Aufwand gelohnt  ;)
Daher hatte ich freie Auswahl bei der SerialNr.

UART ist auch irgendwie eine Serielle Schnittstelle, ich greife nach jedem Strohhalm ;)

Der CUL empfängt etwas, wenn ich den Rollladen manuell fahre. Der Aktor sendet seine Position einfach an den CUL.

Gruß Ben

Otto123

also ich habe auch bloß Strohalme gezupft :)
Ich habe leider keine Vorstellung warum es nicht geht, eigentlich sieht alles ok aus  ;)
Klingt eigenartig wenn eine Kommunikation so einseitig geht...
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

amenomade

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

amenomade

ERR:CCA (clear channel assessment) deutet in der Regel auf eine Funkstörung: entweder babbling idiot, oder irgendein Komponent, der in der Nähe steht.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

SirBen

Buster ist aktualisiert, FHEM auch.
Einen Störsender konnte ich ausschließen, weil es beim Umstecken des CULs in den Banana Pi sofort wieder alles funktioniert hat und ich mit dem Frequenzscan keine Störungen ermitteln konnte.

root@SERVER:~# ls -la /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Dez 27 20:45 /dev/ttyUSB0

yersinia

#10
Mal so ne dusslige Frage: wenn der nanoCUL angesteckt wird, warum wird nicht der FTDI Treiber gezogen? Oder ist dies einer der nanoCULs ohne FTDI Chip? ;)
Ggf mal den prüfen ob der Treiber überhaupt benutzt wird:
usb-devices | awk '/1a86/' RS="\n\n"
Quelle und diese

Ansonsten wäre es interessant, welche Kernelversion im Armbian/Bananapi läuft. Armbian klingt fast nach Bleeding Edge und könnte eine wesentliche neuere Kernelversion gegenüber Raspbian haben. MWn ist Raspbian Buster derzeit bei 4.19.88-v7l+.

Obwohl zumindest bei mir das entsprechende Kernelmodul ch341.ko geladen ist. Prüfbar mit
ls /lib/modules/$(uname -r)/kernel/drivers/usb/serial
viele Grüße, yersinia
----
FHEM 6.4 (SVN) on RPi 4B with RasPi OS Bookworm (perl 5.36.0) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

Otto123

Zitat von: SirBen am 28 Dezember 2019, 04:05:46
Einen Störsender konnte ich ausschließen, weil es beim Umstecken des CULs in den Banana Pi sofort wieder alles funktioniert hat und ich mit dem Frequenzscan keine Störungen ermitteln konnte.
Es könnte allerdings auch sein das der Pi bzw dessen Stromversorgung "einstört". Das muss man von außen (also mit Störsenderscan) nicht unbedingt sehen.
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

SirBen

Moin,
ls /lib/modules/$(uname -r)/kernel/drivers/usb/serial
Zeigt ch341.ko
Ja, der Nano hat einen CH340G Chip und keinen FTDI.

Raspbian hat bei mir aktuell 4.19.75-v7l
Armbian für den Banana Pi hat 4.19.62

Das mit der Stromversorgung teste ich nachher.

Gruß Ben

Otto123

#13
beim HM-MOD-RPI-PCB liegt ein Ferritkern bei um den das Stromversorgungskabel des Pi gewickelt werden muss.

Allerdings ob das wirklich eine Wunderwaffe ist? Bei mir funktioniert das Modul mit und ohne :)

fhem ist in der Gruppe dialout?
groups fhem

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

SirBen

Ja, der User fhem ist in der Gruppe dialout.

Ich habe noch einen Ferritkern gehabt und ihn mal um das USB Kabel der Stromversorgung gemacht. Auch um das USB Kabel vom nanoCUL selbst.
Hat keinen Erfolg gebracht.
Da der RPi4 USB C als Netzteil benötigt, habe ich das nicht tauschen können. Ich besitze nur dieses.
Soweit ich das verstanden habe, wirkt ein Kabel eventuell wie eine Antenne, das Funk-Störungen verursachen kann. Mit einem Ferritkern wird diese Störung beseitigt.
Bei dem Test mit dem CUL am Banana Pi lag dieser ca. 1m neben dem eingeschalteten RPi4.
Also würde ich mal vermuten, dass eine Störung vom Netzteil des RPi4 sich immer auf die 868 MHz Frequenz in der Nähe auswirkt.
Hätte ja klappen können.  :(