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
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
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
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
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
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...
Was sagt
ls -la /dev/ttyUSB0?
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.
ist buster up to date?
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
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 (https://www.linuxquestions.org/questions/linux-hardware-18/ch341-device-recognized-as-dev-usb0-but-won%27t-communicate-4175623209/) und diese (https://unix.stackexchange.com/questions/189896/testing-qinheng-electronics-hl-340-usb-serial-adapter)
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
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.
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
beim HM-MOD-RPI-PCB liegt ein Ferritkern bei um den das Stromversorgungskabel des Pi gewickelt (https://technikkram.net/wp-content/uploads/2016/12/Homematic-Funkmodul-Aufbau7-e1492633634108.jpg)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
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. :(
Moin,
ich habe heute den CUL wieder an den Banana Pi angeschlossen, das "alte" FHEM beendet und ser2net installiert und konfiguriert.
Die Verbindung zum FHEM des Raspberry Pi hat funktioniert (initialized) und ich konnte die Version auslesen.
Nur hat auch hier kein Gerät kommuniziert. Es gab allerdings keine Fehlermeldung mehr im Log.
Dann habe ich den ser2net Dienst beendet und auf dem Banana Pi FHEM gestartet. Sofort hatte ich Verbindung zu allen Geräten und ich konnte sie steuern.
Somit muss es mit FHEM zu tun haben.
Ein neues Pairing habe ich versucht. Der Aktor geht in den Anlernmodus, aber hmPair bleibt auf 1 und es findet keine Kommunikation statt.
Was mache ich denn jetzt am Besten? :o
Gab es in den letzten Wochen ein Update bei FHEM bezüglich HM/CUL?
Dann würde ich darauf tippen es hat hiermit zu tun:
ZitatInstalliert habe ich FHEM nach der WIKI Anleitung und dann den FHEM Ordner gelöscht und den FHEM Ordner vom Banana Pi drauf kopiert.
Ich mache es etwas anders, ich lösche nicht ;)
- stop FHEM
- Backup FHEM
- Kopie der aktuellen Backupdatei -> Server | USB Stick | per scp lokal
- neues System, neue SD Card mit aktuellem Image
- Setup FHEM auf neuem System, testen
- Backupdatei verfügbar machen -> Server | USB Stick mounten | per scp - lokal -> nach /home/pi
- stop fhem
- restore des Backups
- start fhem
Hast Du den CUL mal einfach so getestet? Also am Pi mit frisch installiertem FHEM? Eine Definition kopieren und testen?
Braucht dein CUL irgendeine Zusatzsoftware die Du vergessen hast?
Gruß Otto
ZitatBraucht dein CUL irgendeine Zusatzsoftware die Du vergessen hast?
vielleicht die rjindal lib?
apt-get install libcrypt-rijndael-perl
Habe ich erfolgreich installiert. Leider keine Besserung.
Werde das System bald noch mal mittels Backup Funktion neu aufsetzen.
Normalerweise benötige ich keine zusätzliche Software für den nanoCUL.
Das Wiki mit dem Selbstbau CUL habe ich befolgt. Da stand nichts von weiteren libs oder so.
Ich hatte allerdings bei der Erstinstallation von FHEM auf dem Raspberry Pi 4 den CUL eingesteckt.
Laut Wiki kann das zu Problemen führen.... Hm...
Naja, ich kann mir da nur ein Problem vorstellen: Die initialUsbCheck Routine rennt los und verklemmt sich am CUL oder sie macht was mit dem CUL. Also die würde ich in jedem Fall deaktivieren, aber sie ist ja gerade für den CUL gebaut ;)
Also ich meine: Der CUL muss an einem nackten FHEM funktionieren! Also nackt im Sinne nur der CUL definiert und mal ein Gerät....
Es gibt spezielle Software für den CUL und ich meine dazu gehört auch ein spezielles Modul. Aber ich bin ohne CUL groß geworden, ich kann kaum mitreden. Ich habe mal einen geflashed und habe noch einen Arduino nano und ein Sendemodul rumliegen und wollte mal spielen.
Moin,
ich habe heute mal
apt-get purge fhem
gemacht und auch den /opt/fhem Ordner gelöscht.
Anschließend nach Wiki FHEM neu installiert und dann lediglich den CUL eingerichtet:
Internals:
CFGFN
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 8
FHTID 1234
FUUID 5e098c99-f33f-9381-6e00-c59de9ee1d1a131c
HM_CMDNR 2
NAME nanoCUL
NR 20
PARTIAL
RAWMSG ERR:CCA
RSSI -59.5
STATE Initialized
TYPE CUL
VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) nanoCUL868 (F-Band: 868MHz)
hmPair 1
hmPairSerial RolloKuec1
initString X21
Ar
nanoCUL_MSGCNT 14
nanoCUL_TIME 2019-12-30 06:42:58
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-30 06:40:58 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2019-12-30 06:35:24 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-30 06:42:58 state Initialized
2019-12-30 06:35:49 version V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) nanoCUL868 (F-Band: 868MHz)
Attributes:
hmId 310388
rfmode HomeMatic
Ich habe es dann mit "hmPairSerial RolloKuec1" probiert.
Es kommt wieder der gleiche Fehler:
2019.12.30 06:41:37 3: nanoCUL: Unknown code ERR:CCA, help me!
Habe dann mal einen anderen Rollladenaktor senden lassen:
2019.12.30 06:42:07 3: nanoCUL: Unknown code A0E41A2102201013103880601000047::-59:nanoCUL, help me!
2019.12.30 06:42:07 3: nanoCUL: Unknown code A0E41A2102201013103880601000047::-59.5:nanoCUL, help me!
2019.12.30 06:42:08 3: nanoCUL: Unknown code A0E41A2102201013103880601000047::-59.5:nanoCUL, help me!
2019.12.30 06:42:08 3: nanoCUL: Unknown code A0E41A2102201013103880601000047::-59.5:nanoCUL, help me!
2019.12.30 06:42:09 3: nanoCUL: Unknown code A0E41A2102201013103880601000047::-60:nanoCUL, help me!
2019.12.30 06:42:09 3: nanoCUL: Unknown code A0E41A2102201013103880601000047::-60:nanoCUL, help me!
2019.12.30 06:42:10 3: nanoCUL: Unknown code A0E42A2102201013103880601000047::-59:nanoCUL, help me!
2019.12.30 06:42:11 3: nanoCUL: Unknown code A0E42A2102201013103880601000047::-59:nanoCUL, help me!
2019.12.30 06:42:11 3: nanoCUL: Unknown code A0E42A2102201013103880601000047::-59.5:nanoCUL, help me!
2019.12.30 06:42:12 3: nanoCUL: Unknown code A0E42A2102201013103880601000047::-59.5:nanoCUL, help me!
2019.12.30 06:42:13 3: nanoCUL: Unknown code A0E42A2102201013103880601000047::-59:nanoCUL, help me!
2019.12.30 06:42:13 3: nanoCUL: Unknown code A0E42A2102201013103880601000047::-59.5:nanoCUL, help me!
Also der Empfang funktioniert, nur das Senden nicht...
Im Wiki (https://wiki.fhem.de/wiki/Selbstbau_CUL#Software (https://wiki.fhem.de/wiki/Selbstbau_CUL#Software)) habe ich bezüglich eventuell benötigter Software für nanoCuls nichts gefunden. Dort ist lediglich vom Flashen die Rede. Aber das flashen hat ja funktioniert...
Ich habe trotzdem die libs
avr-libc avrdude binutils-avr gcc-avr libftdi1 libhidapi-libusb0 installiert. Keine Änderung. Weiterhin ERR:CCA
:(
EDIT:
Hier mal ein Auszug von lsmod:
root@SERVER:~# lsmod
Module Size Used by
nfnetlink 16384 0
bnep 20480 2
hci_uart 40960 1
btbcm 16384 1 hci_uart
serdev 20480 1 hci_uart
bluetooth 389120 24 hci_uart,bnep,btbcm
ecdh_generic 28672 1 bluetooth
8021q 32768 0
garp 16384 1 8021q
stp 16384 1 garp
llc 16384 2 garp,stp
fuse 110592 3
ch341 16384 1
usbserial 40960 3 ch341
sg 28672 0
brcmfmac 311296 0
v3d 61440 0
brcmutil 16384 1 brcmfmac
vc4 176128 0
gpu_sched 28672 1 v3d
drm_kms_helper 184320 1 vc4
sha256_generic 20480 0
cfg80211 614400 1 brcmfmac
drm 442368 5 v3d,vc4,gpu_sched,drm_kms_helper
rfkill 28672 6 bluetooth,cfg80211
raspberrypi_hwmon 16384 0
hwmon 16384 1 raspberrypi_hwmon
drm_panel_orientation_quirks 16384 1 drm
bcm2835_codec 36864 0
snd_soc_core 192512 1 vc4
v4l2_mem2mem 24576 1 bcm2835_codec
bcm2835_v4l2 45056 0
snd_compress 20480 1 snd_soc_core
bcm2835_mmal_vchiq 32768 2 bcm2835_codec,bcm2835_v4l2
snd_pcm_dmaengine 16384 1 snd_soc_core
syscopyarea 16384 1 drm_kms_helper
snd_bcm2835 24576 1
sysfillrect 16384 1 drm_kms_helper
sysimgblt 16384 1 drm_kms_helper
fb_sys_fops 16384 1 drm_kms_helper
snd_pcm 102400 4 vc4,snd_pcm_dmaengine,snd_bcm2835,snd_soc_core
vc_sm_cma 36864 1 bcm2835_mmal_vchiq
v4l2_common 16384 1 bcm2835_v4l2
videobuf2_vmalloc 16384 1 bcm2835_v4l2
videobuf2_dma_contig 20480 1 bcm2835_codec
snd_timer 32768 1 snd_pcm
videobuf2_memops 16384 2 videobuf2_dma_contig,videobuf2_vmalloc
videobuf2_v4l2 24576 3 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem
snd 73728 7 snd_compress,snd_timer,snd_bcm2835,snd_soc_core, snd_pcm
videobuf2_common 45056 4 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem,videobuf 2_v4l2
videodev 200704 6 bcm2835_codec,v4l2_common,videobuf2_common,bcm28 35_v4l2,v4l2_mem2mem,videobuf2_v4l2
media 36864 3 bcm2835_codec,videodev,v4l2_mem2mem
rpivid_mem 16384 0
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
fixed 16384 0
ip_tables 24576 0
x_tables 32768 1 ip_tables
ipv6 450560 50
ch341 und usbserial werden geladen...
Ich habe einen ähnlichen Beitrag gefunden:
https://forum.fhem.de/index.php?topic=103446.0 (https://forum.fhem.de/index.php?topic=103446.0)
Aufgrund dessen habe ich noch mal mit der Position des CULs gespielt.
Es gibt einen kleinen Bereich, in dem er plötzlich sendet!
Bewegt man den CUL nur wenige cm nach oben, sendet er sofort. In der Horizontalen kann man ihn noch so weit bewegen, kein Senden möglich. Am Kabel liegt es sicher nicht, ist bereits das dritte Kabel.
Habe jetzt eine USB Verlängerung genommen und den CUL auf einen kleinen Karton gelegt. Nun kann ich wieder alle Geräte steuern.
Was mich trotzdem wundert, dass mit ser2net die Verbindung nicht geklappt hat, obwohl der Banana Pi damit klar kam...
Naja, wie dem auch sei, ich bin froh, dass es wieder funktioniert und ein paar Jahre älter.
Vielen Dank an alle die sich Gedanken gemacht haben und mir Tipps gegeben haben.
Guten Rutsch.
LG Ben
Moin Ben,
also stört doch der Pi4 in irgendeiner Weise den Empfang vom CUL?
Gruß Otto
Moin Otto,
das ist eine gute Frage. Ich habe die Festplatte abgesteckt, was keine Änderung brachte.
Am Netzteil ist noch immer der Ferritkern.
Ich vermute eventuell eine Störung durch Bluetooth oder WLAN im Pi.
Sendet aber eigentlich beides im GHz Bereich und ich nutze es nicht - noch nicht. ;)
Gruß Ben