[Gelöst]Somfy RTS mit SignalDuino lässt sich nicht anlernen

Begonnen von Knallfrosch, 22 Oktober 2019, 20:25:24

Vorheriges Thema - Nächstes Thema

Knallfrosch

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. :-(

-FHEM auf Raspm B+ mit FHEM2FHEM auf einem weiteren Rasp B+
-LaCrosse über Jeelink-Clone und diverses HM über HM-USB.
-S0-Stromzähler und Reed-Gaszähler

Knallfrosch

#1
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. :-)






-FHEM auf Raspm B+ mit FHEM2FHEM auf einem weiteren Rasp B+
-LaCrosse über Jeelink-Clone und diverses HM über HM-USB.
-S0-Stromzähler und Reed-Gaszähler

Ralf9

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Knallfrosch

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


-FHEM auf Raspm B+ mit FHEM2FHEM auf einem weiteren Rasp B+
-LaCrosse über Jeelink-Clone und diverses HM über HM-USB.
-S0-Stromzähler und Reed-Gaszähler

Beta-User

Was spricht denn dagegen, als ersten Schritt auch den JeeLink "by-id" zu definieren?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Knallfrosch

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
-FHEM auf Raspm B+ mit FHEM2FHEM auf einem weiteren Rasp B+
-LaCrosse über Jeelink-Clone und diverses HM über HM-USB.
-S0-Stromzähler und Reed-Gaszähler

Beta-User

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

Knallfrosch

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
-FHEM auf Raspm B+ mit FHEM2FHEM auf einem weiteren Rasp B+
-LaCrosse über Jeelink-Clone und diverses HM über HM-USB.
-S0-Stromzähler und Reed-Gaszähler

Knallfrosch

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.
-FHEM auf Raspm B+ mit FHEM2FHEM auf einem weiteren Rasp B+
-LaCrosse über Jeelink-Clone und diverses HM über HM-USB.
-S0-Stromzähler und Reed-Gaszähler

Beta-User

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

Knallfrosch

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.
-FHEM auf Raspm B+ mit FHEM2FHEM auf einem weiteren Rasp B+
-LaCrosse über Jeelink-Clone und diverses HM über HM-USB.
-S0-Stromzähler und Reed-Gaszähler

Beta-User

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

Knallfrosch

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.

-FHEM auf Raspm B+ mit FHEM2FHEM auf einem weiteren Rasp B+
-LaCrosse über Jeelink-Clone und diverses HM über HM-USB.
-S0-Stromzähler und Reed-Gaszähler

Knallfrosch

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
-FHEM auf Raspm B+ mit FHEM2FHEM auf einem weiteren Rasp B+
-LaCrosse über Jeelink-Clone und diverses HM über HM-USB.
-S0-Stromzähler und Reed-Gaszähler