Hallo,
ich habe mir aus einem Arduiono und einem CC1101 Funkmodul einen NanoCul zusammen gesteckt und habe die SignalDuino 3.3.2.1-rc9 Firmware geflasht.
Ich habe mich an die im Wiki hinterlegten Anleitungen gehalten.
Bis zum anlernen eines Somfy RTS Aktor bin auch vermeintlich erfolgreich gewesen.
Device SIGNALduino habe ich anlegegt hier dazu ein LIST:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
DMSG nothing
DevState initialized
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
FD 64
FUUID 5daf389e-f33f-a358-fc8e-80da44b26747f10b
IDsNoDispatch 2,72.1,82
LASTDMSG nothing
LASTDMSGID nothing
NAME SignalDuino_TEST
NR 297
PARTIAL &( e@&P&��
STATE opened
TIME 1571764942.90261
TYPE SIGNALduino
sendworking 0
version V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01
versionProtocols 1.08
versionmodul v3.4.1_dev_20.10
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
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 ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[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
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
28:SD_Keeloq ^P(?:87|88)#.*
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:
2019-10-22 20:13:54 state opened
2019-10-22 20:13:54 version V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01
additionalSets:
flash
helper:
avrdudecmd avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>./log/SIGNALduino-Flash.log
avrdudelogs flashing Arduino SignalDuino_TEST
hex file: FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>[LOGFILE]
SignalDuino_TEST closed
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
Using Port : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0
Using Programmer : arduino
Overriding Baud Rate : 57600
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Arduino
Description : Arduino
Hardware Version: 2
Firmware Version: 1.16
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex"
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex auto detected as Intel Hex
avrdude: writing flash (24984 bytes):
Writing | ################################################## | 100% 12.83s
avrdude: 24984 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex:
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex contains 24984 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 10.87s
avrdude: verifying ...
avrdude: 24984 bytes of flash verified
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
SignalDuino_TEST reopen started
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
1
3
3.1
4
6
7
13
13.2
14
15
17
23
25
33
33.1
33.2
35
41
51
55
65
68
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
Attributes:
hardware nanoCC1101
room 1 TEST,Interface
Dazu habe ich ein Somfy Device mit dem Namen Rollo_Terasse angelegt:
Internals:
ADDRESS 000004
CFGFN
DEF 000004 AA 003A
FUUID 5daf3ca3-f33f-a358-4f8e-69d23bea7e8b2367
IODev SignalDuino_TEST
NAME Rollo_Terrasse
NR 331
STATE open
TYPE SOMFY
move prog
CODE:
1 000004
READINGS:
2019-10-22 20:09:29 enc_key AA
2019-10-22 20:09:29 exact 0
2019-10-22 20:09:29 position 0
2019-10-22 20:09:29 rolling_code 003A
2019-10-22 20:09:29 state open
Attributes:
IODev SignalDuino_TEST
model somfyshutter
room 1 TEST
Den Rollo bekomme ich mit dem originalen Wandsender in den Lernmodus.
Wenn ich aber nun
set Rollo_Terrasse prog
ausführe, tut sich nichts.
Ich habe das Gefühl als würde der Signalduino einfach nicht senden.
Im Log finde ich folgendes:
2019.10.22 20:18:54 3: SignalDuino_TEST/init: get version, retry = 1
2019.10.22 20:18:54 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 disconnected, waiting to reappear (SignalDuino_TEST)
2019.10.22 20:18:54 3: Setting SignalDuino_TEST serial parameters to 57600,8,N,1
2019.10.22 20:18:54 1: SignalDuino_TEST/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
2019.10.22 20:18:54 1: SignalDuino_TEST/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
2019.10.22 20:18:54 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 reappeared (SignalDuino_TEST)
2019.10.22 20:18:56 3: SignalDuino_TEST/init: disable receiver (XQ)
2019.10.22 20:18:56 3: SignalDuino_TEST/init: get version, retry = 0
2019.10.22 20:18:56 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.22 20:18:56 2: SignalDuino_TEST: initialized. v3.4.1_dev_20.10
2019.10.22 20:18:56 3: SignalDuino_TEST/init: enable receiver (XE)
2019.10.22 20:18:56 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.22 20:18:57 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.22 20:18:57 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.22 20:18:57 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.22 20:18:57 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.22 20:18:57 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.22 20:18:57 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.22 20:18:57 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.22 20:19:02 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.22 20:19:02 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.22 20:19:02 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.22 20:19:02 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 disconnected, waiting to reappear (SignalDuino_TEST)
2019.10.22 20:19:02 3: Setting SignalDuino_TEST serial parameters to 57600,8,N,1
2019.10.22 20:19:02 1: SignalDuino_TEST/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
2019.10.22 20:19:02 1: SignalDuino_TEST/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
2019.10.22 20:19:02 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 reappeared (SignalDuino_TEST)
2019.10.22 20:19:02 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.22 20:19:02 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.22 20:19:02 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.22 20:19:02 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.22 20:19:02 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.22 20:19:02 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.22 20:19:02 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.22 20:19:02 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.22 20:19:02 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.22 20:19:04 3: SignalDuino_TEST/init: disable receiver (XQ)
2019.10.22 20:19:04 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 disconnected, waiting to reappear (SignalDuino_TEST)
2019.10.22 20:19:04 3: Setting SignalDuino_TEST serial parameters to 57600,8,N,1
2019.10.22 20:19:04 1: SignalDuino_TEST/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
2019.10.22 20:19:04 1: SignalDuino_TEST/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
2019.10.22 20:19:04 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 reappeared (SignalDuino_TEST)
2019.10.22 20:19:05 3: SignalDuino_TEST/init: disable receiver (XQ)
2019.10.22 20:19:06 3: SignalDuino_TEST/init: get version, retry = 0
2019.10.22 20:19:06 3: Strom NOK message: �P&P&P&P&V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01
2019.10.22 20:19:06 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 disconnected, waiting to reappear (SignalDuino_TEST)
2019.10.22 20:19:06 3: Setting SignalDuino_TEST serial parameters to 57600,8,N,1
2019.10.22 20:19:06 1: SignalDuino_TEST/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
2019.10.22 20:19:06 1: SignalDuino_TEST/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600
2019.10.22 20:19:06 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 reappeared (SignalDuino_TEST)
2019.10.22 20:19:07 3: SignalDuino_TEST/init: disable receiver (XQ)
2019.10.22 20:19:08 3: SignalDuino_TEST/init: get version, retry = 0
2019.10.22 20:19:08 2: SignalDuino_TEST: initialized. v3.4.1_dev_20.10
2019.10.22 20:19:08 3: SignalDuino_TEST/init: enable receiver (XE)
2019.10.22 20:19:08 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.22 20:19:08 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.22 20:19:08 1: /dev/ttyUSB1 reappeared (Strom)
Andere Meldungen habe ich raus gelöscht.
Was mich verwundert ist der Begriff (Strom) im Log.
FHEM läuft auf einem RPI 3. 2 Weitere USB Geräte (Jeelink und HM-CFG) habe ich schon abgezogen, aber auch das brachte keine Änderung.
Das Netzteil hat 2,5A, sollte also eigentlich ausreichend sein oder verbraucht ein Arduino so viel Storm?
Über Hilfe zur Fehlerbehbung würde ich mich sehr freuen.
Vielen Dank.
Grüße
PS: Ich hoffe, dass ich nun alles notwendige schon hier erwähnt habe, ansonsten liefere ich das natürlich nach.
NACHTRAG:
Ich habe nun mal ein etwas besseres Netzteil angeschlossen.
Nun erhalte ich die Meldung ...... (Strom) nicht mehr im Log.
Trotzdem geht der SignalDuino immer mal wieder von Open auf Closed und wird dann wieder Open.
Ein anlernen des Rollo ist nach wie vor nicht möglich. :-(
Nachdem ich das Netzteil gewechselt, nach wie vor den JeeLink und den HM-USB abgezogen hatte, funktionierte nach mehreren Versuchen und Neustarts des RPI bzw. FHEM das anlernen von 2 Rollladen.
Soweit so gut.
Ich habe dann auch weder den JeeLink und den HM-USB angesteckt. Nun funktionierte das verfahren der Rollos nur mit Verzögerungen oder wiederholten Kommandos.
Im Log ist mir aufgefallen das scheinbar mein JeeLink mit dem SignalDuino kollidiert.
Der JeeLink lieferte keine Werte mehr von den Thermometern (LaCrosse).
Ich habe nun den SignalDuino entfernt und nach einem Neustart arbeitet der JeeLink wieder wie er soll.
Hier das List:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 14
FUUID 5da6ce0c-f33f-a358-1206-74bd2ff18ac5b4c7
NAME myJeeLink
NR 39
PARTIAL
RAWMSG OK 9 14 1 4 171 68
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.10.1e
myJeeLink_MSGCNT 130
myJeeLink_TIME 2019-10-22 21:24:50
settings @AutoToggle 30 Seconds / 868340 kHz
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s
7:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2019-10-22 21:24:50 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 30t 0a v
room Interface
Den Signalduino ist doch anders angelegt: lrwxrwxrwx 1 root root 13 Okt 22 21:29 usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 -> ../../ttyUSB1
als der JeeLink; lrwxrwxrwx 1 root root 13 Okt 22 21:17 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
Warum also diese Kollision?
Wenn ich mir diesen Beitrag anschaue: http://forum.fhem.de/index.php/topic,44926.msg446809.html#msg446809
erhalte ich folgendes:
pi@FHEM-EG:~ $ ls -la /dev/serial/by-path/
insgesamt 0
drwxr-xr-x 2 root root 80 Okt 22 21:39 .
drwxr-xr-x 4 root root 80 Okt 22 21:17 ..
lrwxrwxrwx 1 root root 13 Okt 22 21:39 platform-3f980000.usb-usb-0:1.1.2:1.0-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Okt 22 21:17 platform-3f980000.usb-usb-0:1.2:1.0-port0 -> ../../ttyUSB0
Haben die (wahrscheinlich) gefälschten FTDI also doch die gleiche Nummer?
Ich stehe da auf dem Schlauch und freue mich über erklärende Worte. :-)
normalerweise wird bei mehreren USB Geräten /dev/serial/by-id/ verwendet
z.B.:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9GFBXLP-if00-port0@57600
was ergibt ein
ls /dev/serial/by-id/
Gruß Ralf
Guten Morgen,
Zitat von: Ralf9 am 22 Oktober 2019, 23:28:50
was ergibt ein
ls /dev/serial/by-id/
Gruß Ralf
pi@FHEM-EG:~ $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Okt 22 21:17 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Okt 23 07:22 usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 -> ../../ttyUSB1
Grüße
Was spricht denn dagegen, als ersten Schritt auch den JeeLink "by-id" zu definieren?
Zitat von: Beta-User am 23 Oktober 2019, 09:48:40
Was spricht denn dagegen, als ersten Schritt auch den JeeLink "by-id" zu definieren?
Ich würde dir diese Frage gerne beantworten.
Allerdings bin ich wohl zu schwer von Begriff.
Folgendes:
mein Jeelink hat doch als DEV /dev/ttyUSB0@57600 und der Signalduino DEV /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0@57600 im FHEM eingetragen.
Ich habe ja vom JeeLink keine ID wie eben beim SignalDuino = A9E1TJZ3
Ich verstehe nicht warum es trotzdem zur Kollision kommt. bzw. wie das DEV aussehen müsste damit es funktioniert.
Klar wäre es mir wenn der JeeLink mit gleicher ID erkannt werden würde o.ä. aber so? :o
Was mir noch aufgefallen ist, wäre evtl. den SignalDuino auch für die LaCrosse-Sensoren einzusetzen. Dann könnte ich ja auf den JeeLink verzichten.
Das müsste ich mal noch testen, wenn sich keine andere Lösung findet.
Grüße
Doch, er hat eine "ID", nur ist die eben bei mehreren dieselbe.... Aber _ein_ Device mit CH340 ist kein Problem. Der "link" besteht ja auch beim SignalDuino nicht nur aus der Seriennummer, sondern aus dem gesamten String ;) . Er unterscheidet sich bei mehreren FTDI's dann halt (nur) in der Seriennummer.
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
AHHHH!
Danke, für die Erklärung.
Ich habe mich an die offensichtliche ID geklammert. Denn es gibt ja auch scheinbar Probleme mit gefälschten FTDI die dann auch tatsächlich die gleich ID (Seriennummer) haben.
Habe das große ganze nicht erkannt.
Ich werde das mal mit dem DEF testen und berichten.
Grüße
Das funktioniert so nicht.
Jetzt reagiert der SignalDuino bzw. die Rollos sofort auf die Kommandos aus FHEM und der Status ist auch dauerhaft Opened, aber nun zickt der JeeLink herum und wechselt innerhalb von einigen Sekunden immer zwischen opened, disconnect und initzialized.
Nach dem Neustart hat der RPI auch die Belegung geändert:
pi@FHEM-EG:~ $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Okt 23 11:07 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Okt 23 11:07 usb-FTDI_FT232R_USB_UART_A9E1TJZ3-if00-port0 -> ../../ttyUSB0
vorher war es anders herum.
Aber das sollte doch durch das DEF by-id keine Probleme bereiten.
Hast du noch was anderes da dran? Einen weiteren CH340-Arduino z.B.?
(ls -l /dev/serial/by-path/)
Wenn nein, würde ich annehmen, dass der JeeLink einen "Hau" hat (fehlgeschlagener Flash-Versuch oä) oder die Spannungsversorgung ungenügend ist. Bitte jeweils gesondert testen.
Was noch am USB hängt ist ein original HM-CFG-Stick. Der wird mir aber nicht angezeigt.
Wenn der JeeLink einen Fehler hätte, dann hätte er doch nicht die letzten 2-3Jahre funktionieren können!? Und zwischenzeitlich habe ich den auch nicht mehr "angefasst".
Stromversorgung= Ich habe mittlerweile schon einen Doppel USB Charge-Adapter um den RPI an einem USB-Netzteil zu betreiben. Also wenn das nicht reicht muss ich es wohl mit 230V auf Mini-USB versuchen (Scherz)
Aber im Ernst:
Im Log findet sich tatsächlich wieder:
2019.10.23 11:58:10 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.23 11:58:10 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.23 11:58:10 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.23 11:58:16 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.23 11:58:16 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.23 11:58:16 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.23 11:58:16 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.23 11:58:16 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.23 11:58:16 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.23 11:58:16 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.23 11:58:16 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.23 11:58:16 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.23 11:58:16 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.23 11:58:16 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.23 11:58:16 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.23 11:58:16 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.23 11:58:16 3: Setting Strom serial parameters to 9600,8,N,1
2019.10.23 11:58:16 1: /dev/ttyUSB1 reappeared (Strom)
2019.10.23 11:58:26 1: /dev/ttyUSB1 disconnected, waiting to reappear (Strom)
2019.10.23 11:58:26 3: Setting Strom serial parameters to 9600,8,N,1
Ich werde noch wahnsinnig.
Ein Arduino (Signalduino) dürfte mir doch nicht die Spannungsversorgung so in den Keller ziehen.
Zitat von: Knallfrosch am 23 Oktober 2019, 12:00:52
Was noch am USB hängt ist ein original HM-CFG-Stick. Der wird mir aber nicht angezeigt.
?!? Das kommt mir sehr spanisch vor... Das OS sollte den in jedem Fall "sehen" (im Zweifel: by-path). Und wenn es andere Dienste gibt, die mit USB-Geräten "sprechen", sollte man auch dort sicherstellen, dass der Zugriff auf die richtige Schnittstelle erfolgt. In der Regel geht auch dort "by-id/by-path".
Das OS versucht es scheinbar mit 9600 Baud. Das muß ja irgendwo herkommen. Trübe Glaskugel: gibt es eine "alte" CUL-Definition, für den (ehemaligen) nanoCUL?!?
Oha.....!
Ich bin ja echt clever. Der Begriff "Strom" im Log hatte nichts mit dem STROM in mA zu tun. *wie blöd*
Auf deinen Hinweis mit 9600 Baud habe ich mal die Fhem.cfg durchsucht und natürlich auch was gefunden.
Ich habe noch ein Device mit dem Namen Strom.
Internals:
Clients :OW2S0SLAVE:
DEF /dev/ttyUSB1@9600
DeviceName /dev/ttyUSB1@9600
FUUID 5da6ce0d-f33f-a358-9537-dbb2350fdd0e176e
INTERVAL 10
NAME Strom
NR 201
OWDEVICES 0
PARTIAL
STATE disconnected
TYPE OW2S0SMSGUARD
MatchList:
1:OW2S0SLAVE T.*$
READINGS:
2019-10-23 12:17:09 state disconnected
Attributes:
room 1 TEST
Da habe ich vor sehr langer Zeit mal mit einem 2wire Busmaster experimentiert, aber den Gedanken wieder verworfen.
Das Device aber nicht gelöscht.
Da kommen auch die 9600Baud her.
Ich lösche das Device und teste erneut.
Deine trübe Glaskugel ist besser als mein klarer Laptop Bildschirm. RESPEKT und DANKE!
Melde mich sobald ich weiter gekommen bin.
Hallo,
nachdem ich nun das ungenutzte Device gelöscht habe, funktioniert der JeeLink und der SignalDuino nebeneinander!
Vielen Dank nochmal für die Hilfe bei der Fehlersuche.
Grüße