EDIT:// nun mittlerweile habe ich ihn auf opened. ;) Warum das auf einmal geht weiß ich aber nicht...! :-\
Wenn ich den sduino einmal abziehe bleibt er beim nächsten einstecken wieder auf disconnected
Muss also noch etwas nacharbeiten weil ich dann wieder die Fehlermeldung mit Permission denied bekomme.
Wie kann ich das dauerhaft lösen..?
Bei mir bleibt er immer auf disconnected
Ich bin hier nach dem Wiki (https://wiki.fhem.de/wiki/SIGNALduino) vorgegangen.
Ein
ls -l /dev/serial/by-id
bringt mir folgendes
lrwxrwxrwx 1 root root 13 Aug 9 13:52 usb-SIGNALduino_433_MHz-if00-port0 -> ../../ttyUSB0
mein Device habe ich angelegt mit
define sduino SIGNALduino /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
ein list vom Gerät:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
DEF /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
DMSG nothing
DevState disconnected
DeviceName /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
LASTDMSG nothing
NAME sduino
NR 5372
PARTIAL
STATE disconnected
TIME 1533815576.71338
TYPE SIGNALduino
versionmodul v3.3.3-dev_20.04.
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^u30#.*
18:FLAMINGO ^P13#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
READINGS:
2018-08-09 13:52:56 state disconnected
2018-08-09 13:14:43 version 0
mcIdList:
10
11
12
18
43
47
52
57
58
msIdList:
0
1
2
3
3.1
4
6
7
13
13.2
14
15
17
22
23
25
32
33
35
38
41
51
55
65
68
72.1
muIdList:
5
8
9
13.1
16
20
21
24
26
27
28
29
30
31
36
37
39
40
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
75
79
Attributes:
flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
room System
Meine Frage was muss ich jetzt noch machen damit es Opened anzeigt, muss ich da etwas flashen..?
Ein reset des sduino zeigt mir im Log folgendes:
2018.08.09 14:03:08 1: sduino: Can't open /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0: Permission denied
2018.08.09 14:03:08 3: Opening sduino device /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0
2018.08.09 14:03:08 3: sduino reset
hier ist wohl etwas faul mit Permission denied
Einmal den Befehl chown -R fhem:dialout /opt/fhem
abgesetzt, aber das gilt ja nicht dann für den /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0 Pfad
Bei mir sieht's etwas anders aus, aber ich habe auch einen Signalduino mit FTDI-chip:
lrwxrwxrwx 1 root root 13 Mai 15 19:19 usb-FTDI_FT232R_USB_UART_A98BBXT5-if00-port0 -> ../../ttyUSB0
Vielleicht liegt's an dem Arduino (keine eindeutige id)?
wie kann ich die zuordnen oder erst einmal rausbekommen?
Hier mal ein aktuelles list:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
DEF /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
DMSG YsA0454547E83E33
DevState initialized
DeviceName /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
FD 70
LASTDMSG YsA0454547E83E33
MSGCNT 14
NAME sduino
NR 5372
PARTIAL
RAWMSG MC;LL=-1184;LH=1304;SL=-577;SH=676;D=5022A2A3F41F198;C=623;L=57;R=227;
RSSI -88.5
STATE opened
TIME 1533823388.23516
TYPE SIGNALduino
sendworking 0
version V 3.3.1-RC4 SIGNALduino cc1101 - compiled at Mar 10 2018 23:20:23
versionmodul v3.3.3-dev_20.04.
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^u30#.*
18:FLAMINGO ^P13#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2018-08-09 15:03:36 ccconf freq:433.420MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:3173.83Baud)
2018-08-09 14:40:59 ccreg C3E = 00 84 00 00 00 00 00 00
2018-08-09 15:04:30 cmds V R t X F S P C r W x e
2018-08-09 16:06:38 ping OK
2018-08-09 15:40:38 state opened
2018-08-09 15:40:38 version V 3.3.1-RC4 SIGNALduino cc1101 - compiled at Mar 10 2018 23:20:23
getcmd:
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
msIdList:
0
1
2
3
3.1
4
6
7
13
13.2
14
15
17
22
23
25
32
33
35
38
41
51
55
65
68
72.1
muIdList:
5
8
9
13.1
16
20
21
24
26
27
28
29
30
31
36
37
39
40
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
75
79
Attributes:
flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware nanoCC1101
icon cul@blue
room HWR,System
verbose 4
Ich mache hier mal weiter weil ich immer noch die Probleme mit meinem sduino habe.
Folgendes Problem mit dem sduino habe ich was er mit einem wilden flackern anzeigt.
Nach nur einer Eingabe, egal ob ich nun einen Rollladen von fhem aus programmiere oder einen der beiden Rollläden in irgend eine Richtung fahre da hängt sich der sduino total auf. Und dann kann ich nichts mehr bedienen...!
Muss ihn jedesmal vom Strom trennen, dann geht er auf "closed" wenn ich dann "resete" auf "disconnected" und dann muss ich ihm die Rechte mit meinem FTP Programm bestätigen, dann geht er auf "openend" da ist doch irgend etwas nicht richtig.
Ich hoffe mir kann hier jemand weiter helfen..?
das steht dazu im Log:
2018.08.14 14:53:55 1: sduino: Can't open /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0: Permission denied
2018.08.14 14:53:55 3: Opening sduino device /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0
2018.08.14 14:53:55 3: sduino reset
Noch eine Ergänzung von mir, wenn der sduino wild blinkt, kann ich selbst mit meinen Somfy Fernbedienungen die Rollläden nicht mehr bedienen und ich habe noch etwas bemerkt ich habe zwei Lampen mit einer weiteren Fernbedienung die ich noch nie in fhem hatte, aber weil die wohl mit 433MHz arbeiten kann ich die auch nicht bedienen.
Es sieht so aus als wenn der sduino all diese Geräte blockiert.
hier noch ein aktuelles List:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
DEF /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
DMSG nothing
DevState INACTIVE
DeviceName /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
LASTDMSG nothing
NAME sduino
NR 5454
STATE closed
TIME 1534246581.44243
TYPE SIGNALduino
initResetFlag 1
initretry 3
sendworking 0
version
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^u30#.*
18:FLAMINGO ^P13#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2018-08-10 18:06:52 ccconf freq:433.420MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
2018-08-10 18:18:39 ccreg C3E = 00 C0 00 00 00 00 00 00
2018-08-09 16:20:56 cmds V R t X F S P C r W x e
2018-08-14 14:14:46 ping OK
2018-08-14 14:47:52 state closed
2018-08-14 14:31:20 version V 3.3.1-RC4 SIGNALduino cc1101 - compiled at Mar 10 2018 23:20:23
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
msIdList:
0
1
13
14
15
17
2
22
23
25
3
3.1
32
33
35
38
4
41
51
55
6
68
7
72.1
muIdList:
13.1
16
20
21
24
26
27
28
29
30
31
36
37
39
40
44
44.1
45
46
48
49
5
50
56
59
60
61
62
64
65
66
67
69
70
71
72
75
8
9
Attributes:
flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
group Hardware
hardware nanoCC1101
icon cul@blue
room HWR,System
sortby 01
verbose 4
Also, mein list sieht genau so aus, mehr oder weniger. Ich befürchte, dass das ein hardware-Problem ist. Entweder sind da Lötstellen nicht korrekt oder der CC1101 hat ein Problem. Mach mal zuerst ein Firmware-update. Aber wenn das nicht hilft, ist das Gerät defekt.
eine Frage zum Pfad des USB im DEV, ist das bei dir auch so..?
Welche Firmware hast du drauf und welche soll ich flashen..?
Ich habe im anderen Thread folgende Varianten gefunden...!
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_332rc1.hex
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_332rc2.hex
Unter Linux kann man unter /etc/udev/rules.d das Verhalten der devices steuern.
z.Z. Bin ich nicht an meinem pi sonst könnte ich dir so eine Datei anhängen. Das sollte auch bei usb-devices mit keiner eindeutigen id gehen sofern sie immer auf dem gleichen usb-Port bleiben.
Pejonp
was meinst du genau mit "Verhalten der devices steuern" ich bin da nicht so der Linux Fuchs, so dass ich damit leider erst einmal nichts anfangen kann.
der USB Port bleibt der gleiche, soll heißen ich stecke den nicht um.
Aber ich hatte die Tage schon einen Test gemacht und selbst wenn ich ihn in den anderen USB Port stecke und auslese, sieht der Pfad genauso aus. Sind zwei USB 3 Ports am meinem Intel NUC
lsusb -t unter linux . mit lsusb -? bekommts du Hilfe.
root@localhost:/dev# lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 9, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
|__ Port 3: Dev 8, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
|__ Port 4: Dev 11, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 5: Dev 7, If 0, Class=Human Interface Device, Driver=, 12M
Datei in /etc/udev/rules.d/99-local.rules ergänzen oder neu anlegen. Der Name ist eigentlich egal.
Die letzten beiden sind die Einträge für USB-Geräte ohne S/N mit gleicher Vendor und Product-ID, da wird an Hand des Steckplatzes unterschieden.
# UNO V3
SUBSYSTEMS=="usb",ATTRS{idProduct}=="0043", ATTRS{idVendor}=="2341", ENV{ID_SERIAL_SHORT}=="64032373833351F0D191", SYMLINK+="uno1", MODE="0666"
# Mega 2560
#SUBSYSTEMS=="usb",ATTRS{idProduct}=="0042", ATTRS{idVendor}=="2341", ATTRS{iSerial}=="85332343332351101172", SYMLINK+="rflink", MODE="0666"
SUBSYSTEMS=="usb",ATTRS{idProduct}=="0042", ATTRS{idVendor}=="2341", SYMLINK+="rflink", MODE="0666"
#fs20pcs
SUBSYSTEMS=="usb" ATTRS{idVendor}=="18ef" ATTRS{idProduct}=="e015" MODE:="0666"
# USB-HUB Port 1
KERNELS=="1-1.3.1.3", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE="0666", SYMLINK+="CH340_1"
# USB-HUB Port 2
KERNELS=="1-1.3.1.4", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE="0666", SYMLINK+="CH340_2"
dann Service udev neu starten (service udev restart) oder das ganze System. (https://wiki.ubuntuusers.de/udev/)
pejonp
Zitat
Noch eine Ergänzung von mir, wenn der sduino wild blinkt, kann ich selbst mit meinen Somfy Fernbedienungen die Rollläden nicht mehr bedienen und ich habe noch etwas bemerkt ich habe zwei Lampen mit einer weiteren Fernbedienung die ich noch nie in fhem hatte, aber weil die wohl mit 433MHz arbeiten kann ich die auch nicht bedienen.
Es sieht so aus als wenn der sduino all diese Geräte blockiert.
Klar. Er blinkt nicht nur wild, er funkt wild, was jegliche 433-Kommunikation(Protokollerkennung) unmöglich macht.
Ich tippe auf andies Diagnose :'(
Hier meine Internals
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
DMSG W44#E12DA4071ED25BF8FE
DevState initialized
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0@57600
FD 10
LASTDMSG W44#E12DA4071ED25BF8FE
MSGCNT 18899
NAME sduino
NR 21
NR_CMD_LAST_H 2
PARTIAL
RAWMSG MU;P0=-32001;P1=422;P2=-5024;P3=-3896;P4=3868;P5=1965;P6=-1954;D=01213435353535656565653565653565353565353565356565356565656565656535353565656535353535653535653565653565653565353565353535353535356565653535353535353;CP=5;R=25;
RSSI -61.5
STATE opened
TIME 1534272864
TYPE SIGNALduino
sendworking 0
unknownmessages
version V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
versionmodul v3.3.3-dev_20.04.
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^u30#.*
18:FLAMINGO ^P13#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
Gesendet von iPhone mit Tapatalk Pro
Flashe mal mit den firmwares, die du hast. Viel scheint nicht mehr kaputt gehen zu können...
Gesendet von iPhone mit Tapatalk Pro
ich kläre das mit dem Verkäufer über ebay bevor ich etwas damit mache, er hat geschrieben das er mir einen neuen schickt.
Da wollte ich jetzt nicht dazwischen funken, so bekommt er den wieder wie er mir ihn geliefert hat...
...und das Problem
2018.08.14 14:53:55 1: sduino: Can't open /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0: Permission denied
kann auch damit zusammen hängen..?
@andies
bei dir sieht das hier etwas anders aus
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
@pejonp
so sieht die Ausgabe bei mir aus
root@FHEM-Server:~# lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/11p, 480M
|__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 4: Dev 29, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 7: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
bei mir heißt die Datei unter /etc/udev/70-persistent-net.rules
und das steht drin:
# PCI device 0x8086:0x15a3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:ae:ed:77:ba:d2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x095a (iwlwifi)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="34:13:e8:40:92:a0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
Ich melde mich dann wieder....!
Vielen Dank für eure Unterstützung
Wenn der usb-stick erkannt wird, muss er auch bei lsusb -t aufgelistet werden.
Ich denke mal der ftdi_sio ist es. Legt mal eine neue Datei an und trage das ein. Wiki udev gibt dir Hinweise.
# USB-HUB Port 1
KERNELS=="2-4.29", ATTRS{idVendor}=="???", ATTRS{idProduct}=="???", MODE="0666", SYMLINK+="signal"
Die Datei ist fürs Netzwerk und ist ok. Du kannst für andere devices eine extra datei (siehe weiter oben) anlegen.
Pejonp
habe die Datei jetzt angelegt:
Die Abfrage mit der angelegten Datei "99-local.rules" und einem Neustart sieht jetzt so aus:
root@FHEM-Server:~# lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/11p, 480M
|__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 7: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
hier hat sich eigentlich nur das geändert, war vorher so:
Port 4: Dev 29, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
ich werde den Stick mal an einen anderen USB Port stecken, hatte ich aber glaube ich schon probiert :-\
diese Abfrage sieht so aus und hier hat sich nichts geändert...!
root@FHEM-Server:~# ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 Aug 15 12:41 usb-SIGNALduino_433_MHz-if00-port0 -> ../../ttyUSB0
ich bekomme einen weiteren Stick, mal schauen wie es weiter geht.
jetzt habe ich den Stick nochmals umgesteckt:
root@FHEM-Server:~# lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/11p, 480M
|__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 3: Dev 5, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 7: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
es scheint also der ftdi_sio zu sein, denn diese Angabe hat sich geändert
Der da drüber ist mein Homematic USB Stick.
Leider überdeckt der Homematic USB-Stick einen weiteren USB Anschluss, sonst würde ich da mal dran testen, denn ich weiß nicht ob es einen Unterschied macht ob USB 3 (blau) oder eben USB 2 (gelb) Anschluss am Intel-NUC.
Meine beiden bisher getesteten sind die USB 3 Anschlüsse.
die Datei "99-local.rules" ist dafür da um dem USB-device einen eindeutigen namen zu geben. siehe wiki udev.
"99-local.rules" hat nichts mit "lsusb" zu tun.
Wenn die Daten in der Datei "99-local.rules" stimmen wird unter /dev ein Device "signal" angezeigt, mit den richtigen Zugriffsrechten.
Das ist doch dein Problem.
Can't open /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0: Permission denied
wie richtest du den diese Verlinkung ein. jedesmal von Hand.
lrwxrwxrwx 1 root root 13 Aug 15 12:41 usb-SIGNALduino_433_MHz-if00-port0 -> ../../ttyUSB0
Mach doch mal ein "ls -lisa /dev |grep USB". Was hat den ttyUSB0 für Zugriffsrechte und wer ist der Eigner ?
pejonp
Zitat von: pejonp am 15 August 2018, 18:47:07
Wenn die Daten in der Datei "99-local.rules" stimmen wird unter /dev ein Device "signal" angezeigt, mit den richtigen Zugriffsrechten.
Das ist doch dein Problem.
Can't open /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0: Permission denied
du meinst sicher das device "serial"
(siehe screenshot)
Ich bin laut Wiki vorgegangen und sobald ich den Stick eingesteckt hatte erscheint dieses device, wenn ich da drauf gehe und mir die Dateiattribute von dem symlink anschaue sind die "777"
Wenn ich auf den Ordner "serial" gehe sind die "755"
Zitat von: pejonp am 15 August 2018, 18:47:07
wie richtest du den diese Verlinkung ein. jedesmal von Hand.
lrwxrwxrwx 1 root root 13 Aug 15 12:41 usb-SIGNALduino_433_MHz-if00-port0 -> ../../ttyUSB0
nein, wie oben beschrieben wird die erstellt
Zitat von: pejonp am 15 August 2018, 18:47:07
Mach doch mal ein "ls -lisa /dev |grep USB". Was hat den ttyUSB0 für Zugriffsrechte und wer ist der Eigner ?
die Ausgabe von "ls -lisa /dev |grep USB" sieht so aus
root@FHEM-Server:~# ls -lisa /dev |grep USB
27120 0 crwxrwxrwx 1 root dialout 188, 0 Aug 16 12:09 ttyUSB0
ob das nun richtig ist weiß ich nicht, ich habe das ja nicht verändert.
Der Ordner serial wie gesagt hat "755"
Nein nicht serial sondern ,,signal" wenn die Daten in der Datei "99-local.rules" richtig sind. Es wird in /dev ein neues device ,,signal" mit den richtigen Zugriffesrechten angelegt. Symbolische Links können die Zugriffsrechte der devices nicht übersteuern. Schau in die Wiki.
Pejonp
Also ich lese hier mit und glaube, dass ihr aneinander vorbei redet und beide nicht den Kern trefft ;-)
1) die Rechte an dem Device unter Linux: Es ist ein FTDI der richtig erkannt wird! Ich schätze auch die Rechte, obwohl uns das
ls -la /dev/serial/by*sudo addgroup fhem dialout
2) Sind Deine Signalduino Abstürze kein Rechteproblem, sondern Hardware oder nich eher ein nicht richtig geflashte Firmware.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
bitte beachten ich habe kein Raspi ich arbeite mit dem Intel NUC
hier mal die Augabe:
root@FHEM-Server:~# ls -la /dev/serial/by*
/dev/serial/by-id:
insgesamt 0
drwxr-xr-x 2 root root 60 Aug 15 15:13 .
drwxr-xr-x 4 root root 80 Aug 15 15:07 ..
lrwxrwxrwx 1 root root 13 Aug 15 15:07 usb-SIGNALduino_433_MHz-if00-port0 -> ../../ttyUSB0
/dev/serial/by-path:
insgesamt 0
drwxr-xr-x 2 root root 60 Aug 15 15:13 .
drwxr-xr-x 4 root root 80 Aug 15 15:07 ..
lrwxrwxrwx 1 root root 13 Aug 15 15:07 pci-0000:00:14.0-usb-0:3:1.0-port0 -> ../../ttyUSB0
ich denke das ist soweit OK
wenn ich jetzt penjob seine Aussage richtig verstehe fehlt mir dieses device "signal" demnach sollte das in der 99-local.rules Datei wohl nicht richtig sein. Dafür kenne ich aber Linux zu schlecht.
Zu der "dailout" Gruppe, kann ich nur sagen fhem ist in dieser Gruppe.
Ich kann mich an diese "Permission denied" Sachen gut erinnern, denn oft liest man hier im Forum davon das Leute damit Probleme haben, nur nützt mir dieses absetzen des Befehls
chown -R fhem:dialout /opt/fhem
hier rein gar nichts, da ich ja im ganz anderen Zweig bin nämlich /dev/serial und hier gibt es irgendwelche Unstimmigkeiten
Ich warte ja noch auf den neuen Stick dann kann ich mehr dazu sagen, ob das Problem ein Hardware Problem ist, wobei ich es ganz stark vermute :)
Okay ich sehe ,,root:root"
Also user root und Gruppe root bekommt die Rechte, dann kann user fhem nicht dran ;-)
Welche Distribution nutzt Du? Wie sehen Deine Udev Regeln aktuell aus?
Evtl. hier nachsehen!?
sudo nano /etc/udev/rules.d/50-usb-serial.rules
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{product}=="FT232R USB UART", SYMLINK+="usb_dsmr", GROUP="dialout", MODE="0666"
evtl ohne oder mit anderem ATTRS{product}==,,SIGNAL*"
könnte helfen!? Ich weiss nicht wie oben in der Anleitung der Kernel identifiziert wurde ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 16 August 2018, 20:56:10
Welche Distribution nutzt Du? Wie sehen Deine Udev Regeln aktuell aus?
Evtl. hier nachsehen!?
sudo nano /etc/udev/rules.d/50-usb-serial.rules
ich nutze Ubuntu 15.10 (GNU/Linux 3.13.0-111-generic x86_64)
Udev habe ich aktuell diese 2 Dateien:
70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x15a3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:ae:ed:77:ba:d2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x095a (iwlwifi)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="34:13:e8:40:92:a0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
# USB-HUB Port 1
KERNELS=="1-1.3.1.3", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE="0666", SYMLINK+="CH340_1"
# USB-HUB Port 2
KERNELS=="1-1.3.1.4", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE="0666", SYMLINK+="CH340_2"99-local.rules
# USB-HUB Port 1
KERNELS=="2-4.29", ATTRS{idVendor}=="???", ATTRS{idProduct}=="???", MODE="0666", SYMLINK+="signal"
Zitat von: RaspiLED am 16 August 2018, 20:56:10
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{product}=="FT232R USB UART", SYMLINK+="usb_dsmr", GROUP="dialout", MODE="0666"
soll ich das in die Datei eintragen..?
Zitat von: RaspiLED am 16 August 2018, 20:56:10
evtl ohne oder mit anderem ATTRS{product}==,,SIGNAL*"
könnte helfen!? Ich weiss nicht wie oben in der Anleitung der Kernel identifiziert wurde ;-)
ich kenne mich da leider nicht gut aus
Morgen
Die Einträge von mir waren nur Beispiele ,,usb-hub Port" kannst du löschen oder du schreibst die richtigen Werte rein. Die Einträge mit dem ,,???" musst du durch richtige Werte ersetzen.
Mit lsusb -s 00?:00? -v ?=richtige usb ids kann man die Werte der usb-Geräte auslesen. Wenn die Parameter nicht stimmen lsusb -? Hilft dir.
Dieser Eintrag bringt nichts.
ATTRS{product}==,,SIGNAL*"
Pejonp
Hey Pejonp,
Mea culpa und Du hast total recht! Auch meins war nur als Beispiel gedacht. Aber das hilft alles nichts, wenn der thread owner nicht in der Doku von udev nachlesen will und auch die Beispiele nicht ausprobiert ;-)
Dennoch glaube ich an mein group=,,dialout".
Warten wir mal ab.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hi raspiled,
Ich glaube bei mir sind die devices auch in der Gruppe dialout und fhem ist da auch drin.
Pejonp
Zitat von: pejonp am 17 August 2018, 10:56:27
Hi raspiled,
Ich glaube bei mir sind die devices auch in der Gruppe dialout und fhem ist da auch drin.
Pejonp
ja genau das hatte ich aber schon geschrieben, dass es bei mir so ist nur eben dieser Stick ist ja ganz woanders drin in /dev/serial
Zitat von: RaspiLED am 17 August 2018, 10:30:53
Aber das hilft alles nichts, wenn der thread owner nicht in der Doku von udev nachlesen will und auch die Beispiele nicht ausprobiert ;-)
Dennoch glaube ich an mein group=,,dialout".
nicht so ungeduldig... ;)
Ich habe doch bisher die Beispiele ausprobiert nur mit meinem marginalen Wissen über Linux bin ich da auch ein wenig auf vorgefertigtes angewiesen :-\
"udev" habe ich ausgiebig gelesen bei ubuntu schon beim ersten Hinweis weiter oben, aber verstehen ist die zweite Sache.
Wenn ich genau wüßte was ich da eintragen muss, hätte ich es sicher getan... nun habe ich leider das falsche eingetragen :-\
Ich gebe mir große Mühe alles was ihr mir schreibt zu verstehen und umzusetzen.
So heute nun ist der neue Stick gekommen, bisher habe ich ihn noch nicht ausgepackt, wollte erst einmal hier antworten.
Damit ihr Bescheid wisst.
Was ich jetzt schon gemacht habe den anderen Stick abgezogen. Nun gibt es auch diesen Ordner "Serial" nicht mehr.
Werde jetzt von vorn anfangen... Fhem updaten, neu starten, dann den Stick rein. Dann schaue ich nochmal diese rules Dateien an.
Vorab ein "ls -lisa /dev |grep USB" gemacht da kommt nichts mehr...?
Der Stick ist jetzt dran und ich habe ein: ls -l /dev/serial/by-id gemacht das erscheint:
root@FHEM-Server:~# ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 Aug 17 13:51 usb-SIGNALduino_433_MHz-if00-port0 -> ../../ttyUSB0
dann noch ein "ls -lisa /dev |grep USB" gemacht das erscheint:
root@FHEM-Server:~# ls -lisa /dev |grep USB
265172 0 crw-rw---- 1 root dialout 188, 0 Aug 17 13:51 ttyUSB0
mich wundert jetzt das es verschiedene Gruppen sind einmal "root" einmal "dialout" ich habe da ja noch nichts verändert.
Der Stick ist jetzt noch bei "disconnected" was sollte ich jetzt als erstes machen damit er auf "openend" geht, denn das ist ja erst einmal das eine Problem.
Bisher habe ich die Rechte des Symlinks nochmals bestätigt, obwohl die bei "777" sind, der Ordner Serial hat "755"
Werde jetzt bis jemand antwortet mir nochmals die udev anschauen und die rules Dateien
User root Gruppe dialout ist richtig!
Wenn fhem auch in der Geuppe dialout ist (Mein Befehl sudo addgroup fhem dialout
weiter oben)
Sollte fhem kein Problem haben denn Stick anzusprechen!
Also in fhem das normale define eingeben, da der Stuck die gleiche ID hat wie der alte solltest Du ja wissen wie es geht ;-)
defmod sduino SIGNALduino /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Tja der Stick geht nicht auf "openend" sobald ich fhem restarte ist er auf disconnected, wenn ich die Rechte in meinem FTP Programm einmal bestätige geht er auf openend.
Der symlink behält auch die rechte "777" während alles andere auf "755" somit kommt fhem nicht an den Stick und er bleibt disconnected... den symlink kann ich nicht auf die Rechte 755 bekommen, ist das evtl. das Problem..?
Zumindest blinkt dieser Stick jetzt erst einmal nicht.. ;)
hier war noch eine Frage von euch ich habe jetzt ausgelesen:
root@FHEM-Server:~# lsusb -s 02:07 -v
Bus 002 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 USB-Serial (UART) IC
bcdDevice 6.00
iManufacturer 1 SIGNALduino
iProduct 2 433
iSerial 3 MHz
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 90mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 433
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
stick sieht so aus:
defmod sduino SIGNALduino /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
Hi, verstehe ich nicht!
Wenn die Rechte root:dialout 775 sind kommt root und alle user der Gruppe dialout dran.
Wie sind die Rechte denn vorher genau? Und was sagt sudo groups fhem?
Äh, mach mal die rechte auf 070, geht es dann mit fhem immernoch?
Dann musst Du die udev Regel auf 775 ändern bzw. Einrichten.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Als Info vorab auf jeden Fall gehen jetzt beide Rollläden, dass ist doch schon mal etwas ;)
Hab die Rechte im FTP Prgramm einmal bestätigt und schon geht der Stick auf "openend"
Aber das Problem ist eben das er nicht von allein aktiv wird.
Ja ich lese die ganze Zeit im udev Wiki wie ich eigene Regeln anlegen kann.
Einiges ist mir noch nicht ganz klar... :-\
So wie penjob es beschrieben hat muss ich die in der Datei 99_irgendwas.rules anlegen.
Das habe ich auch schon gemacht.
Jetzt zu den Rechten ich kann die Rechte bis zu diesem Verzeichnis /dev/serial/by-id ändern, den Symlink kann ich nicht ändern.
Keine Ahnung warum..?
wenn ich eingebe "chown -R fhem:dialout /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600" kommt folgendes
root@FHEM-Server:~# chown -R fhem:dialout /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
chown: Zugriff auf »/dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600" nicht möglich: Datei oder Verzeichnis nicht gefunden
Obwohl ich es im FTP ja sehe, was kann ich noch machen?
Die Ausgabe groups sieht so aus:
groups fhem
fhem : fhem adm cdrom sudo dip plugdev lpadmin sambashare
Bin jetzt erst mal weg, bis morgen und den udev Regeln ;)
Also der Reihe nach:
1.) Dein chown kann nicht gehen, da Du kein sudo voranstellst und du als normaler user keinen Zugriff hast!
2.) Ein Symlink hat immer alle Rechte 777, wird aber dennoch begrenzt über die Rechte des Ziels. Die Rechte an den Ordnern /dev, /dev/serial, /dev/serial/by-id solltest Du überhaupt nicht anfassen (müssen)!
3.) Dein user fhem ist nicht in der Gruppe dialout! Also hat er auch keinen Zugriff über die Gruppenattribute an /dev/ttyUSB0, sondern nur über die Attribute aller User. Beispiel: 755=7(user root)5(user aus Gruppe dialout)5(jeder user), wobei 7 lesen+4,schreiben+2 und ausführen+1 bedeutet. Ziel ist also den user fhem in die Gruppe dialout zu bekommen und danach eine udev Regel zu erstellen, die /dev/ttyUSB0 mit 775 ausstattet.
Mein udev Beispiel oben sollte eigentlich passen, wenn ich Deinen lsusb Eintrag richtig gelesen habe! Wichtig ist, dass diese Datei nicht unter Windows erstellt wird und dann per ftp kopiert wird, sondern bitte direkt unter linux mittels sudo nano /etc/udev/rules.d/99-Signalduino.rules angelegt wird. Speichern mit CTRL-O, Return, CTRL-X
Wie man fhem in die Gruppe dialout aufnimmt habe ich auch oben schon geschrieben!
Startest Du fhem eigentlich mit dem user fhem?
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
@moonsorrox
versuch mal diesen Eintrag in deiner /etc/udev/rules.d/99-Signalduino.rules
# SignalDuino 1
KERNELS=="2-4.29", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0666", SYMLINK+="signal123"
SYMLINK+="signal123" <-- Name ist frei wählbar, aber keine Sonderzeichen usw..
vorher noch einmal ein lsusb -t damit du die richte Kernel-ID bekommst.
KERNELS=="2-4.29" <--- ich glaube die 29 kann entfallen, mal ausprobieren
root@FHEM-Server:~# lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/11p, 480M
|__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 4: Dev 29, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 7: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
in FHEM trägst du dann nur ein:
defmod sduino SIGNALduino /dev/signal123@57600 <--- ist einfacher und man macht weniger Schreibfehler.
pejonp
Guten Morgen, ich denke mal wir können jetzt dieses Thema hier beenden. ;)
Ich sage euch beiden pejonp und auch RaspiLED mal herzlichen Dank für all die Bemühungen.
Heute nun auf ein Neues angegangen und was soll ich sagen, ich stecke den Stick ab geht er auf "disconnected" den Stick wieder dran und sofort geht er auf "openend" ich denke alles so wie es sein soll.
Da ich die "99-signalduino.rules" erst noch anpassen wollte hatte ich sie gelöscht, jetzt funktioniert das also auch ohne.
Habe das System rebootet fhem gestartet und alles funktioniert.
Ich arbeite übrigens mit Notepad++ oder direkt mit nano auf der Konsole :)
Trotz alledem möchte ich noch ein paar Fragen von oben beantworten, kann ja hilfreich sein für die Nachwelt :)
Zitat von: RaspiLED am 17 August 2018, 15:57:56
1.) Dein chown kann nicht gehen, da Du kein sudo voranstellst und du als normaler user keinen Zugriff hast!
ich bin doch root somit entfällt eigentlich "sudo"
Zitat von: RaspiLED am 17 August 2018, 15:57:56
2.) Ein Symlink hat immer alle Rechte 777, wird aber dennoch begrenzt über die Rechte des Ziels. Die Rechte an den Ordnern /dev, /dev/serial, /dev/serial/by-id solltest Du überhaupt nicht anfassen (müssen)!
hab ich auch nicht geändert, wenn der Stick ab ist ist auch der Ordner "serial" mit allen Inhalten weg.
Stick wieder dran und die Rechte werden ja vom System vergeben, da habe ich also gar nichts gemacht, ich hatte nur probiert die symlink Rechte zu ändern was aber nicht funktioniert, denn so tief stecke ich nicht in Linux drin das ich das mit den 777 weiß. Also alles gut ;)
Zitat von: RaspiLED am 17 August 2018, 15:57:56
3.) Dein user fhem ist nicht in der Gruppe dialout! Also hat er auch keinen Zugriff über die Gruppenattribute an /dev/ttyUSB0, sondern nur über die Attribute aller User. Beispiel: 755=7(user root)5(user aus Gruppe dialout)5(jeder user), wobei 7 lesen+4,schreiben+2 und ausführen+1 bedeutet. Ziel ist also den user fhem in die Gruppe dialout zu bekommen und danach eine udev Regel zu erstellen, die /dev/ttyUSB0 mit 775 ausstattet.
genau das hatte ich als einzigstes heute noch gemacht den User fhem in dialout, dass war wohl das entscheidene Ding :)
Zitat von: pejonp am 18 August 2018, 10:54:10
# SignalDuino 1
KERNELS=="2-4.29", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0666", SYMLINK+="signal123"
SYMLINK+="signal123" <-- Name ist frei wählbar, aber keine Sonderzeichen usw..
vorher noch einmal ein lsusb -t damit du die richte Kernel-ID bekommst.
KERNELS=="2-4.29" <--- ich glaube die 29 kann entfallen, mal ausprobieren
der Kerneleintrag richtet sich also nach den Bus- und Portvorgaben..?
Da der sich wieder geändert hatte zu gestern hätte ich was anderes eintragen müssen
wenn lsusb -t so aussieht
root@FHEM-Server:~# lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/11p, 480M
|__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 3: Dev 6, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 7: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
sollte der Eintrag so aussehen, den ich eintragen müßte:
# SignalDuino 1
KERNELS=="2-3.6", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0666", SYMLINK+="signal123"
Ich glaube die 6 kann entfallen
KERNELS=="2-3",
Pejonp
Ein Phänomen habe ich übrigens noch welches sehr selten auftritt, aber gerade eben als die Rollläden im Beschattungsmodus gefahren sind... gibt es bei mir 3 Lampen wo sich immer mal die eine oder andere mit einschaltet :D
Diese schalte ich mit einer ganz anderen Fernbedienung.
Es sind 3 Funksteckdosen die ganz sicher im 433Mhz Modus arbeiten, obwohl mein sduino 433.420MHz eingetragen hat.
Dabei fällt mir ein das ich das sicher auch nutzen könnte für mich und Fhem ;)
werde dazu mal einen anderen Thread eröffnen wie man da die Signale heraus bekommt.
Wünsche ein schönes WoE ;)
Die funksreckdosen sind mit der Frequenz nicht so eng. Sie haben einen gewissen Bereich. Kann man bei dieser Steckdosen per dip-Schalter etwas einstellen ? Diese werden glaube ich unterstützt.
Pejonp
Nein, leider geht das nicht zu ändern, ich sehe nur die Firma da drauf Globaltronics Hamburg und anlernen geht mit Steckdose rein einen Knopf drücken bis die Anzeige blinkt und dann die jeweilge Taste auf der FB drücken.
Ich dachte man kann da irgend etwas beim senden auslesen, naja ist nicht so wichtig, wichtig das der Stick jetzt funktioniert.
ich denke der andere hat ne Macke weg. ;) denn soviel Schwierigkeiten sollte er nicht machen.
Doch geht bestimmt, hört sich nach Intertechno Version 3 Derivat an.
Die senden normalerweise auf 433.920 und nicht wie Somfy auf 433.420.
Also Frequenz ändern und Verbose auf 4 und Eventmonitor an und zweimal auf der FB auf On tippen und die Logs zeigen?
Du hast nicht jetzt schon einen Raum IT oder?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 18 August 2018, 14:02:20
Doch geht bestimmt, hört sich nach Intertechno Version 3 Derivat an.
Die senden normalerweise auf 433.920 und nicht wie Somfy auf 433.420.
Also Frequenz ändern und Verbose auf 4 und Eventmonitor an und zweimal auf der FB auf On tippen und die Logs zeigen?
Du hast nicht jetzt schon einen Raum IT oder?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
doch er hat mir ein Raum IT angelegt, logs habe ich auch schon 4 und natürlich devices 4 Stück ;)
Ich schaue mal den Eventmonitor
hier die log Einträge:
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 79 -> VTX-BELL_Funkklingel matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.08.18 14:20:41 3: sduino: Unknown code u27#ED7ACF, help me!
2018.08.18 14:20:41 4: Unknown, please report
2018.08.18 14:20:41 4: SIGNALduino_unknown converted to bits: 111011010111101011001111
2018.08.18 14:20:41 4: SIGNALduino_unknown Protocol: 27
2018.08.18 14:20:41 4: SIGNALduino_unknown rawData: ED7ACF
2018.08.18 14:20:41 4: SIGNALduino_unknown incomming msg: u27#ED7ACF
2018.08.18 14:20:41 4: Unknown, please report
2018.08.18 14:20:41 4: SIGNALduino_unknown converted to bits: 111011010111101011001111
2018.08.18 14:20:41 4: SIGNALduino_unknown Protocol: 27
2018.08.18 14:20:41 4: SIGNALduino_unknown rawData: ED7ACF
2018.08.18 14:20:41 4: SIGNALduino_unknown incomming msg: u27#ED7ACF
2018.08.18 14:20:41 4: sduino: decoded matched MU Protocol id 27 dmsg u27#ED7ACF length 24 RSSI = -76
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.18 14:20:41 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.08.18 14:20:41 4: sduino/msg READredu: MU;P0=-571;P1=453;P2=-1042;P3=939;P4=2913;P5=-6922;D=012123012301212121230123012123030121212124512121230121230123012121212301230121230301212121245121212301212301230121212123012301212303012121212451212123012123012301212121230123012123030121212;CP=1;R=252;
2018.08.18 14:20:40 3: sduino: Unknown code i128530, help me!
2018.08.18 14:20:40 4: sduino IT: msgcode "" (0) bin = 000100101000010100110000
2018.08.18 14:20:40 4: sduino IT: message "i128530" (7)
2018.08.18 14:20:40 4: sduino IT: msgcode "" (0) bin = 000100101000010100110000
2018.08.18 14:20:40 4: sduino IT: message "i128530" (7)
2018.08.18 14:20:40 4: sduino: Decoded MS Protocol id 55 dmsg i128530 length 24 RSSI = -76.5
2018.08.18 14:20:40 4: sduino: Matched MS Protocol id 55 -> quigg_gt1000
2018.08.18 14:20:40 4: sduino/msg READredu: MS;P1=1008;P2=-429;P3=328;P4=-1046;P5=-2271;D=35343434123434123412343434341234123434121234343434;CP=3;SP=5;R=251;m=2;
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 79 -> VTX-BELL_Funkklingel matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 64 -> WH2 matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.08.18 14:20:40 3: sduino: Unknown code u27#EEB74F, help me!
2018.08.18 14:20:40 4: Unknown, please report
2018.08.18 14:20:40 4: SIGNALduino_unknown converted to bits: 111011101011011101001111
2018.08.18 14:20:40 4: SIGNALduino_unknown Protocol: 27
2018.08.18 14:20:40 4: SIGNALduino_unknown rawData: EEB74F
2018.08.18 14:20:40 4: SIGNALduino_unknown incomming msg: u27#EEB74F
2018.08.18 14:20:40 4: Unknown, please report
2018.08.18 14:20:40 4: SIGNALduino_unknown converted to bits: 111011101011011101001111
2018.08.18 14:20:40 4: SIGNALduino_unknown Protocol: 27
2018.08.18 14:20:40 4: SIGNALduino_unknown rawData: EEB74F
2018.08.18 14:20:40 4: SIGNALduino_unknown incomming msg: u27#EEB74F
2018.08.18 14:20:40 4: sduino: decoded matched MU Protocol id 27 dmsg u27#EEB74F length 24 RSSI = -76.5
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.18 14:20:40 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.08.18 14:20:40 4: sduino/msg READredu: MU;P0=-537;P1=475;P2=-1025;P3=968;P4=2914;P5=-6925;P6=-30640;P7=328;D=01212123012301212301212123012303012121212451212123012121230123012123012121230123030121212124512121230121212301230121230121212301230301212121245121212301212123012301212301212123012303012121216;CP=1;R=251;
2018.08.18 14:20:40 3: sduino: Unknown code i1148B0, help me!
2018.08.18 14:20:40 4: sduino IT: msgcode "" (0) bin = 000100010100100010110000
2018.08.18 14:20:40 4: sduino IT: message "i1148B0" (7)
2018.08.18 14:20:40 4: sduino IT: msgcode "" (0) bin = 000100010100100010110000
2018.08.18 14:20:40 4: sduino IT: message "i1148B0" (7)
2018.08.18 14:20:40 4: sduino: Decoded MS Protocol id 55 dmsg i1148B0 length 24 RSSI = -76.5
2018.08.18 14:20:40 4: sduino: Matched MS Protocol id 55 -> quigg_gt1000
2018.08.18 14:20:40 4: sduino/msg READredu: MS;P1=338;P2=1055;P3=-436;P5=-1142;P6=-2286;D=16151515231515152315231515231515152315232315151515;CP=1;SP=6;R=251;m=2;
2018.08.18 14:20:35 4: sduino/msg READ: MC;LL=-2003;LH=1915;SL=-1016;SH=932;D=2AB236C;C=977;L=26;R=232;
2018.08.18 14:20:34 4: sduino/msg READ: MC;LL=-1993;LH=1915;SL=-1016;SH=934;D=915591AE;C=976;L=31;R=232;
2018.08.18 14:20:20 4: sduino/keepalive ok, retry = 0
2018.08.18 14:19:35 4: sduino/msg READ: MC;LL=-1980;LH=1917;SL=-1017;SH=946;D=48AAC8DB;C=976;L=32;R=234;
2018.08.18 14:19:35 4: sduino/msg READ: MC;LL=-1994;LH=1914;SL=-1014;SH=940;D=8AAC8D1;C=976;L=28;R=233;
2018.08.18 14:19:34 4: sduino/msg READ: MC;LL=-1983;LH=1917;SL=-1011;SH=960;D=22AB235C;C=978;L=30;R=233;
2018.08.18 14:19:20 4: sduino/keepalive ok, retry = 0
2018.08.18 14:18:34 4: sduino/msg READ: MC;LL=-1998;LH=1912;SL=-1008;SH=939;D=2AB23AC;C=976;L=26;R=233;
und hier der Eventmonitor ich habe nur den 1.Kanal der FB gedrückt
2018-08-18 14:20:40 SIGNALduino sduino UNKNOWNCODE i1148B0
2018-08-18 14:20:40 SIGNALduino sduino DMSG u27#EEB74F
2018-08-18 14:20:40 SIGNALduino sduino UNKNOWNCODE u27#EEB74F
2018-08-18 14:20:40 SIGNALduino sduino UNKNOWNCODE i128530
2018-08-18 14:20:41 SIGNALduino sduino DMSG u27#ED7ACF
2018-08-18 14:20:41 SIGNALduino sduino UNKNOWNCODE u27#ED7ACF
Hi,
Ich nehme an die vier Geräte im IT Raum schalten nichts? Schade!
Geht ein set sduino raw MU;P0=-537;P1=475;P2=-1025;P3=968;P4=2914;P5=-6925;P6=-30640;P7=328;D=01212123012301212301212123012303012121212451212123012121230123012123012121230123030121212124512121230121212301230121230121212301230301212121245121212301212123012301212301212123012303012121216;CP=1;R=251;?
Jedenfalls kann man diese Zeilen den Signalduino auch senden lassen ;-)
Also probiere mal ob das geht für die ganzen Kanäle Deiner FB.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ja da hast du Recht die schalten nichts, habe sie auch schon gelöscht.
Das andere mit dieser langen Adresse funktioniert auch nicht. :-\
Hi,
Auch nicht die vergleichbaren anderen längeren Zeilen?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Sendefrequenz ist laut Prospekt 433.92 MHz. Die Fernbedienung enthält den (anscheinend fest einprogrammierten) Code und die Dosen lernt man dann an. In jedem Fall kann man mit einem arduino die Sequenz auslesen und dann so übersetzen, dass der Signalduino damit schaltet. Wenn es dich interessiert, suche ich mal die Links heraus. Ist einmalig etwas Aufwand.
Gesendet von iPhone mit Tapatalk Pro
probiere ich noch mal die Tage, wenn etwas Zeit ist. 3 hatte ich schon getestet da ging nichts
Hi,
Du kannst es auch andersrum probieren. Eine definition in fhem für ein itv3 gerät und dann damit die Dose anlernen. Wenn dann das schalten geht wüssten wir auch mehr ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 21 August 2018, 14:52:03
Hi,
Du kannst es auch andersrum probieren. Eine definition in fhem für ein itv3 gerät und dann damit die Dose anlernen. Wenn dann das schalten geht wüssten wir auch mehr ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
damit beschäftige ich mich, wenn das Wetter etwas schlechter wird. ;)
Was mir gerade wichtig ist wie vermeide ich denn das schalten dieser Geräte, heute nun sind nämlich meine beiden SOMFY Rollläden auf Beschattung gefahren und gleichzeitig sind 2 Lampen angegangen und es war hell :-\ ;D ;)
Es gibt ja im sduino dieses attr blacklist_IDs, da habe ich "IT_" eingetragen, aber das bringt gar nichts. Das war ja der Raum der immer angelegt wurde. Jetzt wird der aber nicht mehr angelegt, evtl. muss ich das klein schreiben weil im Log finde ich das ja.
So ganz gefällt mir das mit dem sduino auch noch nicht weil er jede Menge Fehler macht, warum das jetzt kommt weiß ich nicht :-\
2018.08.23 20:59:04 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.23 20:44:00 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.23 20:29:03 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.23 20:28:56 3: sduino: Unknown code Ys5023A3A3F41F19, help me!
2018.08.23 20:28:56 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :5023A3A3F41F19:
2018.08.23 20:28:56 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :5023A3A3F41F19:
2018.08.23 20:13:59 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.23 20:13:56 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.23 19:58:55 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.23 19:43:57 3: sduino: Unknown code Ys5023A3A3F41F18, help me!
2018.08.23 19:43:57 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :5023A3A3F41F18:
2018.08.23 19:43:57 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :5023A3A3F41F18:
2018.08.23 19:43:57 3: sduino: Unknown code Ys5023A3A3F41F19, help me!
2018.08.23 19:43:57 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :5023A3A3F41F19:
2018.08.23 19:43:57 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :5023A3A3F41F19:
2018.08.23 19:43:55 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.23 19:28:54 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.23 19:07:12 3: sduino: Unknown code Ys52C3C7D2335EC4, help me!
2018.08.23 19:07:12 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :52C3C7D2335EC4:
2018.08.23 19:07:12 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :52C3C7D2335EC4:
2018.08.23 18:30:08 1: SOMFY Unknown device 6F6278 (DA 0C2C), please define it
2018.08.23 18:30:07 3: sduino: Unknown code Ys6CCF495CE0D1E6, help me!
2018.08.23 18:30:07 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :6CCF495CE0D1E6:
2018.08.23 18:30:07 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :6CCF495CE0D1E6:
2018.08.23 18:30:06 1: SOMFY Unknown device 6F6278 (D8 0C2A), please define it
2018.08.23 18:30:05 1: SOMFY Unknown device 6F6278 (D7 0C29), please define it
2018.08.23 18:29:28 3: sduino: Unknown code Ys594B42DA173780, help me!
2018.08.23 18:29:28 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :594B42DA173780:
2018.08.23 18:29:28 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :594B42DA173780:
2018.08.23 18:01:59 3: sduino: Unknown code Ys0010DB4B8907784001D, help me!
2018.08.23 18:01:59 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :0010DB4B8907784001D:
2018.08.23 18:01:59 3: sduino: Unknown code Ys500086DA5C483BC2000E8, help me!
2018.08.23 18:01:59 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :500086DA5C483BC2000E8:
2018.08.23 18:01:59 3: sduino: Unknown code Ys0010DB4B89077C40019, help me!
2018.08.23 18:01:59 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :0010DB4B89077C40019:
2018.08.23 18:01:59 3: sduino: Unknown code Ys578086A623B7C442000E8, help me!
2018.08.23 18:01:58 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :578086A623B7C442000E8:
2018.08.23 18:01:58 3: sduino: Unknown code YsAF010D4C476F88C40019, help me!
2018.08.23 18:01:58 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AF010D4C476F88C40019:
2018.08.23 18:01:58 3: sduino: Unknown code Ys5704032E2B3F4CC2000E8, help me!
2018.08.23 18:01:58 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :5704032E2B3F4CC2000E8:
2018.08.23 18:01:57 3: sduino: Unknown code YsAE08065C567E99C40019, help me!
2018.08.23 18:01:57 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AE08065C567E99C40019:
2018.08.23 18:01:57 3: sduino: Unknown code Ys568285E367F38042000E8, help me!
2018.08.23 18:01:57 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :568285E367F38042000E8:
2018.08.23 18:01:56 3: sduino: Unknown code YsAD050BC6CFE700C40019, help me!
2018.08.23 18:01:56 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AD050BC6CFE700C40019:
2018.08.23 18:01:56 3: sduino: Unknown code Ys5602079C180C7FC2000E8, help me!
2018.08.23 18:01:56 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :5602079C180C7FC2000E8:
2018.08.23 18:01:56 3: sduino: Unknown code Ys5602079C180C7FE2000C8, help me!
2018.08.23 18:01:56 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :5602079C180C7FE2000C8:
2018.08.23 18:01:47 3: sduino: Unknown code Ys558086DA5C483BC2000E8, help me!
2018.08.23 18:01:47 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :558086DA5C483BC2000E8:
2018.08.23 18:01:47 3: sduino: Unknown code Ys56021B697120EF880032, help me!
2018.08.23 18:01:47 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :56021B697120EF880032:
2018.08.23 18:01:46 3: sduino: Unknown code Ys550086A623B7C442000E8, help me!
2018.08.23 18:01:46 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :550086A623B7C442000E8:
2018.08.23 18:01:46 3: sduino: Unknown code YsAA010D4C476F88C40019, help me!
2018.08.23 18:01:46 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AA010D4C476F88C40019:
2018.08.23 18:01:45 3: sduino: Unknown code Ys5484032E2B3F4CC2000E8, help me!
2018.08.23 18:01:45 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :5484032E2B3F4CC2000E8:
2018.08.23 18:01:45 3: sduino: Unknown code Ys5484032E2B3F4CE2000C8, help me!
2018.08.23 18:01:45 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :5484032E2B3F4CE2000C8:
2018.08.23 18:01:44 3: sduino: Unknown code Ys540285E367F38042000E8, help me!
2018.08.23 18:01:44 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :540285E367F38042000E8:
2018.08.23 18:01:44 3: sduino: Unknown code Ys540285E367F38062000C8, help me!
2018.08.23 18:01:44 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :540285E367F38062000C8:
2018.08.23 18:01:43 3: sduino: Unknown code Ys5382079C180C7FC2000E8, help me!
2018.08.23 18:01:43 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :5382079C180C7FC2000E8:
2018.08.23 18:01:43 3: sduino: Unknown code Ys4E081E706031FF880032, help me!
2018.08.23 18:01:43 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :4E081E706031FF880032:
1.) Deine Dosen spinnen, nicht der Signalduino. Meine Vermutung ist, dass die auch auf sehr naheliegende Signale reagieren. Allerdings könntest Du auch die Sendestärke reduzieren, Stichwort patable
2.) Das sind keine FEHLER sondern ANSAGEN. Wenn der Sduino keine Geräte findet, weil Sie nicht definiert sind (oder wieder gelöscht wurden), so teilt er es einem mit. Bei hohem Verbose teilt er auch mit welche Protokolle alles nicht passten. Also verbose auf 2 oder 3 und Du hast mehr Ruhe im Log und Eventmonitor.
Um Dein Problem zu lösen, würde ich die Dosen an FHEM anlernen und zwar mit einem entfernten Code. Und zwar solange dich das nervt weil es Sommer ist.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
zu 1.) meine Einstellung ist ccpatable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
zu 2.) ich hatte verbose schon auf 3, dass habe ich jetzt mal auf 2 gestellt. Das sind diese ganzen Schalter der Fernbedienung nach der ich gefragt hatte... deshalb wollte ich die erst einmal ausgrenzen aber das geht wohl nicht.
Ja die Dosen hatte ich auch schon ein weiteres mal angelernt..! aber was ist jetzt mit "entfernten Code" gemeint..?
Dazu mal eine Anmerkung was ich festgestellt habe. Manchmal passiert es das er die beiden Rollläden nicht fährt, dann gehe ich in den Rollladen und lösche im Def den Codee hinter der jeweiligen Zahl also bei mir 0001 und 0002, das sind die beiden Rollläden. der Code (rollingcode) dahinter wird dann neu geschrieben und dann funktioniert das wieder.
Ist das normal so..?
Nein, das ist nicht normal. Bei mir war das die Signalstärke, es geht nur 10dB bei mir. Es könnte auch sein, dass sich die Sendefrequenz intern verstellt, prüf' die mal ab und an. (Ich musste dann eine neue Version hochladen, da war ein bug drin.)
Zitat von: andies am 24 August 2018, 16:32:48
Nein, das ist nicht normal. Bei mir war das die Signalstärke, es geht nur 10dB bei mir. Es könnte auch sein, dass sich die Sendefrequenz intern verstellt, prüf' die mal ab und an. (Ich musste dann eine neue Version hochladen, da war ein bug drin.)
Ok ich habe die jetzt mal auf 10db umgestellt mal schauen was er so macht, Sendefrequenz kontrolliere ich jedes mal wenn ich drauf schaue weil ich das auch schon hatte das die sich verstellt hat (aber nur 1x)
Zitat2018.08.23 18:01:57 3: sduino: Unknown code YsAE08065C567E99C40019, help me!
2018.08.23 18:01:57 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AE08065C567E99C40019:
Hast Du eine Telis 6 Chronis RTS Fernbedienung?
https://forum.fhem.de/index.php/topic,53319.msg763964.html#msg763964
Evtl hast Du keinen guten Empfang, evtl bringt es was den Standort vom sduino zu verändern.
Die Sendefrequenz kann sich bei SOMFY nicht verstellen, da sie bei jedem senden neu gesetzt wird.
Es ist in seltenen Fällen denkbar, daß sich beim Senden von SOMFY die Empfangsfrequenz verstellt.
Gruß Ralf
Zitat von: Ralf9 am 24 August 2018, 18:46:31
Hast Du eine Telis 6 Chronis RTS Fernbedienung?
https://forum.fhem.de/index.php/topic,53319.msg763964.html#msg763964
Evtl hast Du keinen guten Empfang, evtl bringt es was den Standort vom sduino zu verändern.
nein ich habe 2 Telis 4 RTS.
Ja das mit dem sduino habe ich auch schon probiert, ich habe dafür ein kürzeres und ein längeres USB_Kabel und habe schon einige andere Positionen getestet :-\
Nach der Umstellung vorhin auf 10db habe ich seit 18 Uhr nur noch 17 Meldungen bei verbose 3 im Log, dass war auch schon mal wesentlich mehr.
Zitat von: moonsorrox am 24 August 2018, 00:07:19
...
2018.08.23 18:01:58 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AF010D4C476F88C40019:
2018.08.23 18:01:58 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :5704032E2B3F4CC2000E8:
shl 1 => AE08065C567E99C001D0
2018.08.23 18:01:57 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AE08065C567E99C40019:
2018.08.23 18:01:57 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :568285E367F38042000E8:
shl 1 => AD050BC6CFE7084001D
2018.08.23 18:01:56 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AD050BC6CFE700C40019:
2018.08.23 18:01:56 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :5602079C180C7FC2000E8:
shl 1 => AC040F383018FE184001D
...
2018.08.23 18:01:46 1: sduino: SOMFY_Parse : Somfy RTS message format error (length)! :AA010D4C476F88C40019:
hast du eine Somfy Telis 4 Modulis RTS (mit Scrollrad) (https://www.amazon.de/Somfy-MODULIS-funkhandsender-Scrollrad-Katalognummer/dp/B074CG59HX/ref=sr_1_6?ie=UTF8&qid=1535146037&sr=8-6&keywords=somfy+rts+telis+4)?
die sendet 6 zusätzliche hex-digits, die wahrscheinlich das Scrollrad sind.
Nein, wie schon geschrieben habe ich 2 Telis 4 RTS, eine etwas ältere in Silber und eine neuere in schwarz.
Unterschied der beiden ist die neue schwarze brauche ich nicht jedesmal anwählen die behält die eingestellte Position welche Rollläden angesprochen werden sollen, die ältere muss ich immer wieder neu einstellen.
Das heißt wenn bei mir immer alle vier LED leuchten fahren zwei Rollläden gleichzeitig
Die Telis 4 (https://www.enobi.de/steuerungen/somfy-rts-funk/so0434?gclid=Cj0KCQjw2f7bBRDVARIsAAwYBBtxmj4cQuyZzcg-c_9BcS3EVPI_JURfc3dv_H1P0daTtPw5hrU_5W8aAkMCEALw_wcB) heißen zwar so aber trotzdem kann ich 5 verschieden Szenarien einstellen.
ZitatFunkhandsender Telis 4 RTS. Mit dem 5-Kanal Handsender können Sie einen oder mehrere Funk-Rollladenmotoren manuell bedienen.
Anscheinend gibt es doch noch mehr Versionen der Fernbedienung die 6 zusätzliche hex-digits senden.
Damit diese Fernbedienungen auch empfangen werden können, ist eine Anpassung im Somfy Modul 10_SOMFY.pm notwendig:
In der Zeile 489 muß
$ret = "Somfy RTS message format error (length)! :".$encData.":" if (length($encData) != 14);
durch folgendes ersetzt werden:
my $lengthEncData = length($encData);
$ret = "Somfy RTS message format error (length)! $encData (" . $lengthEncData ."), length should be 14 or 20" if ($lengthEncData != 14 && $lengthEncData != 20);
Im log sieht es dann bei falscher Länge dann so aus:
2018.08.25 15:52:41.897 1 : sduinoD: SOMFY_Parse : Somfy RTS message format error (length)! 56021B697120EF8800322 (21), length should be 14 or 20
Gruß Ralf
Zitat von: Ralf9 am 25 August 2018, 16:14:47
Anscheinend gibt es doch noch mehr Versionen der Fernbedienung die 6 zusätzliche hex-digits senden.
mal eine Frage dazu weil hier von Fernbedienung gesprochen wird... ich nutze die Fernbedienung sehr wenig... heute z.B. gar nicht und trotzdem sind diese Meldungen im Log.
Ich kann das trotzdem mal im Modul anpassen..!
Ich hatte ja vor einigen Tagen versucht die FB anzulernen, da wurde mir hier im Thread gesagt ich muss die Somfy Empfänger nutzen nicht die FBs.
Zitatich nutze die Fernbedienung sehr wenig... heute z.B. gar nicht und trotzdem sind diese Meldungen im Log.
Hat evtl ein Nachbar auch Somfy Rolläden?
Wenn Du aus der Whitelist die ID 43 entfernst, oder, falls Du keine Whitelist verwendest, die 43 in die Blacklist einträgst, dann kannst Du den Empfang von den Fernbedienungen unterdrücken.
Gruß Ralf
EDIT:// also in der Tat hat der Nachbar Somfy Geräte verbaut ;D ;D ;)
Zitat von: Ralf9 am 26 August 2018, 23:33:26
Hat evtl ein Nachbar auch Somfy Rolläden?
Wenn Du aus der Whitelist die ID 43 entfernst, oder, falls Du keine Whitelist verwendest, die 43 in die Blacklist einträgst, dann kannst Du den Empfang von den Fernbedienungen unterdrücken.
Gruß Ralf
werde ich mal nachfragen, weil mein direkter Nachbar hat erst vor einigen Monaten alles auf Motor umgerüstet...!
ich arbeite mit Blacklist und habe hier die ID 43 eingetragen das sollte reichen, oder.?
das habe ich noch im Log zur Zeit, wie kann ich das noch beseitigen..?
2018.08.28 07:32:28 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.28 07:32:23 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.28 07:17:31 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.28 07:17:23 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.28 07:02:26 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.28 07:02:23 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.28 06:54:17 3: sduino: Unknown code Ys6F7A721D141AA2, help me!
2018.08.28 06:54:17 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :6F7A721D141AA2:
2018.08.28 06:54:17 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :6F7A721D141AA2:
2018.08.28 06:47:29 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.28 06:47:22 1: SOMFY Unknown device 0DD6AF (A0 0000), please define it
2018.08.28 06:35:08 3: sduino: Unknown code Ys4D5BD381B684B3, help me!
2018.08.28 06:35:08 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :4D5BD381B684B3:
2018.08.28 06:35:08 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :4D5BD381B684B3:
2018.08.28 06:35:06 1: SOMFY Unknown device 6F419A (C3 1342), please define it
2018.08.28 06:34:55 3: sduino: Unknown code Ys4CDF5C50A72991, help me!
2018.08.28 06:34:55 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :4CDF5C50A72991:
2018.08.28 06:34:55 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :4CDF5C50A72991:
2018.08.28 06:10:58 1: SOMFY Unknown device 711CD2 (DC 07DC), please define it
2018.08.28 06:07:42 1: SOMFY Unknown device 711DE8 (DF 14D5), please define it
2018.08.28 06:07:14 3: sduino: Unknown code Ys6F666C06727CC4, help me!
2018.08.28 06:07:14 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :6F666C06727CC4:
2018.08.28 06:07:14 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :6F666C06727CC4:
attr <device> verbose 0
Zitat von: andies am 28 August 2018, 12:03:27
attr <device> verbose 0
ja klar, wollte es erst einmal abklären :) ;)
Es könnte sein, dass das gar kein Somfy ist, aber etwas vergleichbares sendet. Signalduino rechnet dann die checksum und stellt fest: Stimmt nicht. Schwer zu sagen, was das dann ist. Da sich das scheinbar alle 15 Minuten, würde ich auf einen Temperatursensor o.Ä. tippen.
Zitat von: andies am 28 August 2018, 14:11:20
Es könnte sein, dass das gar kein Somfy ist, aber etwas vergleichbares sendet.
doch es sind alles Somfy Geräte, habe ihn gefragt, wenn ich richtig gezählt habe sind es 4 Geräte die sich bei mir melden. :)
Ich frage heute nochmal wieviel er genau hat, kann sein das weitere Geräte auf der anderen Hausseite sind die mein sduino nicht erreicht.
Da die Zeiten von heute morgen sind, werden das die Rollläden sein die heute morgen hoch gefahren sind...!
Zitatich arbeite mit Blacklist und habe hier die ID 43 eingetragen das sollte reichen, oder.?
das habe ich noch im Log zur Zeit, wie kann ich das noch beseitigen..?
Da passt was nicht, dies dürfte im Log nicht mehr sein.
Damit die Blacklist funktioniert, darf keine Whitelist definiert sein.
Wenn Du in die Blacklist die 43 eingetragen hast, dann darf bei
list sduino
unter "mcIdList:" die 43 nicht mehr auftauchen.
mcIdList:
10
11
12
18
47
52
57
58Gruß Ralf
Dann darf ich wohl nur die "43" eintragen ich habe "ID 43" eingetragen, ich habe nur die Blacklist in Benutztung.
Ok dann ändere ich das mal...!
sieht jetzt so aus:
mcIdList:
10
11
12
18
47
52
57
58
jetzt muss ich nur noch die Somfy's vom Nachbarn eliminieren :) :-\