Arrêt brutal des remontées de sonde après une journée ou plus

Bonjour,

Depuis le 27 janvier, j’ai un « blocage » RFXCOM.Après plusieurs heures (>20 heures) de fonctionnement normal, les sondes ne remontent plus et la transmission des commandes est inopérante. Mon installation Jeedom/RFXCOM fonctionnait sans problème depuis décembre 2018. Depuis mon passage en Jeedom 4.0 puis 4.1 pas de problèmes majeurs. Aucun changement matériel (câblé USB ou serveur) donc j’écarterais bien l’hypothèse du câble USB défectueux, surtout que cela fonctionne pendant plusieurs heures. Pour faire redémarrer le deamon, il me faut débrancher et rebrancher le RFXCOM.

J’aimerais investiguer la piste logicielle, car ce problème est survenu après la mise à jour en 4.1.18 (faite le 26 janvier). Cependant, l’erreur dans les logs indique un souci matériel…

Ma config:

  • Jeedom Version : 4.1.18 dit
  • VM Debian 10.7 sur Synology VMM
  • RFXCOM RFXtrx433XL firmware 1043
  • Plugin RFXCOM version 2021-01-08 01:02:33

Voici les logs du plugin quand le deamon n’arrive pas a redémarrer :

log rfxcom erreur démarrage deamon.txt (14,7 Ko)

Avez-vous déjà rencontré ce problème ? Si vous avez des pistes…

Christian

On dirait un problème sur la liaison USB, voir sérial.
Quel version OS ! sudo uname -a | awk '{ print $1,$3,$4,$7,$8,$9}'
Un coup d’update et upgrade ?

Quel est la conf de ton rfxcom?

un SigTerm a été envoyé à 08:04 le 29, c’est normal ? C’est parce qu’il ne recevait plus rien?

[2021-01-29 08:04:34][DEBUG] : Signal 15 caught, exiting...
[2021-01-29 08:04:34][DEBUG] : Shutdown
[2021-01-29 08:04:34][DEBUG] : Removing PID file /tmp/jeedom/rfxcom/deamon.pid
[...]
[2021-01-29 08:04:37][DEBUG] : Open Serialport
[2021-01-29 08:04:37][ERROR] : Fatal error : [Errno 5] Input/output error
[2021-01-29 08:04:37][DEBUG] : Traceback (most recent call last):
  File "/var/www/html/plugins/rfxcom/resources/rfxcomd/rfxcomd.py", line 396, in <module>
    listen()
  File "/var/www/html/plugins/rfxcom/resources/rfxcomd/rfxcomd.py", line 222, in listen
    shared.JEEDOM_SERIAL.open()
  File "/var/www/html/plugins/rfxcom/resources/rfxcomd/jeedom/jeedom.py", line 241, in open
    self.port = serial.Serial(self.device,self.rate,timeout=self.timeout)
  File "/usr/local/lib/python3.7/dist-packages/serial/serialutil.py", line 244, in __init__
    self.open()
  File "/usr/local/lib/python3.7/dist-packages/serial/serialposix.py", line 336, in open
    self._update_dtr_state()
  File "/usr/local/lib/python3.7/dist-packages/serial/serialposix.py", line 713, in _update_dtr_state
    fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str)
OSError: [Errno 5] Input/output error

Est-ce possible d’accéder au logs os via dmesg -T?

lsusb sur l’équipement chez moi.

Bus 001 Device 008: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x6015 Bridge(I2C/SPI/UART/FIFO)
  bcdDevice           10.00
  iManufacturer           1
  iProduct                2
  iSerial                 3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0020
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    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
      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

Regarde comment est configuré le port sur le plugin , mode Auto ? ou en RXCOM Rfxtrx433XL(/dev/…) ou en /dev/tty…)
Alim du RPI, faiblesse de l’alim ou problème cable !
Sur quel port USB 3 ? (USB0 apparemment) en /dev/ttyUSB0 Voir si choix RFXCOM Rfxtrx…

Merci pour les pistes !

La version de Linux: Linux 4.19.0-13-amd64 #1 4.19.160-2 (2020-11-28) x86_64

Pas d’update/upgrade dernièrement et cela fonctionnait correctement depuis le passage à Buster Jeedom V4 stable.

Le plugin est configuré avec la valeur explicite :

Jeedom tourne sur une VM sous Synology Virtual Machine Manager. Donc pour l’alimentation je ne pense pas qu’il y ait un problème.

lsusb →

Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 001 Device 002: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

la commande « lsusb -s 001:005 » -v donne ceci:

Bus 001 Device 005: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x6015 Bridge(I2C/SPI/UART/FIFO)
  bcdDevice           10.00
  iManufacturer           1 RFXCOM
  iProduct                2 RFXtrx433XL
  iSerial                 3 DO2Y2V8Z
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0020
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    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 RFXtrx433XL
      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
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0000
  (Bus Powered)

@yofa : Le Signal 15 indiqué dans la trace vient de la tentative de redémarrage du deamon RFXcom, je suppose. Le souci est l’absence total d’activité à partir d’une certaine heure sans que le deamon ne bronche. Et le redémarrage est impossible sauf si je débranche le RFXCOM.

Concernant la commande dmesg -T voici ce qu’elle retourne (j’ai eu à nouveau le problème hier soir donc les timestamp ne collent pas avec ceux du log du plugin précédemment fourni mais c’est le même comportement):

[sam. janv. 30 23:03:29 2021] ftdi_sio ttyUSB0: failed to get modem status: -71
[sam. janv. 30 23:03:29 2021] ftdi_sio ttyUSB0: error from flowcontrol urb
[sam. janv. 30 23:03:29 2021] xhci_hcd 0000:00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 4
[sam. janv. 30 23:03:29 2021] xhci_hcd 0000:00:04.0: Looking for event-dma 0000000035527c40 trb-start 0000000035527c50 trb-end 0000000035527c60 seg-start 0000000035527000 seg-end 0000000035527ff0
[sam. janv. 30 23:03:32 2021] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[sam. janv. 30 23:03:32 2021] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[sam. janv. 30 23:03:32 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:03:32 2021] xhci_hcd 0000:00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 4
[sam. janv. 30 23:03:32 2021] xhci_hcd 0000:00:04.0: Looking for event-dma 0000000035527c40 trb-start 0000000035527c50 trb-end 0000000035527c70 seg-start 0000000035527000 seg-end 0000000035527ff0
[sam. janv. 30 23:03:32 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:03:32 2021] ftdi_sio ttyUSB0: failed to get modem status: -71
[sam. janv. 30 23:03:32 2021] ftdi_sio ttyUSB0: error from flowcontrol urb
[sam. janv. 30 23:05:12 2021] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[sam. janv. 30 23:05:12 2021] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[sam. janv. 30 23:05:12 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:05:12 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:05:12 2021] ftdi_sio ttyUSB0: failed to get modem status: -71
[sam. janv. 30 23:05:12 2021] ftdi_sio ttyUSB0: error from flowcontrol urb
[sam. janv. 30 23:06:54 2021] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[sam. janv. 30 23:06:54 2021] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[sam. janv. 30 23:06:54 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:06:54 2021] xhci_hcd 0000:00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 4
[sam. janv. 30 23:06:54 2021] xhci_hcd 0000:00:04.0: Looking for event-dma 000000003583a090 trb-start 000000003583a0a0 trb-end 000000003583a0a0 seg-start 000000003583a000 seg-end 000000003583aff0
[sam. janv. 30 23:06:54 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:06:54 2021] ftdi_sio ttyUSB0: failed to get modem status: -71
[sam. janv. 30 23:06:54 2021] ftdi_sio ttyUSB0: error from flowcontrol urb
[sam. janv. 30 23:10:12 2021] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[sam. janv. 30 23:10:12 2021] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[sam. janv. 30 23:10:12 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:10:12 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:10:12 2021] ftdi_sio ttyUSB0: failed to get modem status: -71
[sam. janv. 30 23:10:12 2021] ftdi_sio ttyUSB0: error from flowcontrol urb
[sam. janv. 30 23:10:12 2021] xhci_hcd 0000:00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 4
[sam. janv. 30 23:10:12 2021] xhci_hcd 0000:00:04.0: Looking for event-dma 000000003583a330 trb-start 000000003583a340 trb-end 000000003583a350 seg-start 000000003583a000 seg-end 000000003583aff0
[sam. janv. 30 23:12:30 2021] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[sam. janv. 30 23:12:30 2021] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[sam. janv. 30 23:12:30 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:12:30 2021] xhci_hcd 0000:00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 4
[sam. janv. 30 23:12:30 2021] xhci_hcd 0000:00:04.0: Looking for event-dma 000000003583a330 trb-start 000000003583a340 trb-end 000000003583a360 seg-start 000000003583a000 seg-end 000000003583aff0
[sam. janv. 30 23:12:30 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:12:30 2021] ftdi_sio ttyUSB0: failed to get modem status: -71
[sam. janv. 30 23:12:30 2021] ftdi_sio ttyUSB0: error from flowcontrol urb
[sam. janv. 30 23:12:30 2021] xhci_hcd 0000:00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 4
[sam. janv. 30 23:12:30 2021] xhci_hcd 0000:00:04.0: Looking for event-dma 000000003583a330 trb-start 000000003583a340 trb-end 000000003583a370 seg-start 000000003583a000 seg-end 000000003583aff0
[sam. janv. 30 23:15:12 2021] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[sam. janv. 30 23:15:12 2021] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[sam. janv. 30 23:15:12 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:15:12 2021] xhci_hcd 0000:00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 4
[sam. janv. 30 23:15:12 2021] xhci_hcd 0000:00:04.0: Looking for event-dma 000000003583a330 trb-start 000000003583a340 trb-end 000000003583a380 seg-start 000000003583a000 seg-end 000000003583aff0
[sam. janv. 30 23:15:12 2021] ftdi_sio ttyUSB0: failed to set flow control: -71
[sam. janv. 30 23:15:12 2021] ftdi_sio ttyUSB0: failed to get modem status: -71
[sam. janv. 30 23:15:12 2021] ftdi_sio ttyUSB0: error from flowcontrol urb
[sam. janv. 30 23:15:12 2021] xhci_hcd 0000:00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 4
[sam. janv. 30 23:15:12 2021] xhci_hcd 0000:00:04.0: Looking for event-dma 000000003583a330 trb-start 000000003583a340 trb-end 000000003583a390 seg-start 000000003583a000 seg-end 000000003583aff0
[sam. janv. 30 23:16:55 2021] usb 1-3: USB disconnect, device number 4
[sam. janv. 30 23:16:55 2021] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[sam. janv. 30 23:16:55 2021] ftdi_sio 1-3:1.0: device disconnected
[sam. janv. 30 23:16:56 2021] usb 1-4: new full-speed USB device number 5 using xhci_hcd
[sam. janv. 30 23:17:00 2021] usb 1-4: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[sam. janv. 30 23:17:00 2021] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[sam. janv. 30 23:17:00 2021] usb 1-4: Product: RFXtrx433XL
[sam. janv. 30 23:17:00 2021] usb 1-4: Manufacturer: RFXCOM
[sam. janv. 30 23:17:00 2021] usb 1-4: SerialNumber: DO2Y2V8Z
[sam. janv. 30 23:17:00 2021] ftdi_sio 1-4:1.0: FTDI USB Serial Device converter detected
[sam. janv. 30 23:17:00 2021] usb 1-4: Detected FT-X
[sam. janv. 30 23:17:00 2021] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB0

Peut-être un problème de câble mais alors pourquoi au bout de plus de 20 heures de fonctionnement normal? Cela me fait plus penser à un problème côté RFXCOM. L’erreur dans le dmesg semble bien indiquer un problème de communication sur le port USB. Et j’ai l’impression que c’est RFXCOM qui est « bloqué ». Qu’en pensez vous ?

Bonjour,
J’ai pas de piste, juste des idées plutôt communes

  • Essayes un autre cable (c’est plutôt commun comme câble usb)
  • Changes de port USB sur ton Nas (si possible pas un usb3)
  • Branche ton RFXCOM à autre chose (Rfxmgr sous windows) et regarde s’il n’y as pas un soucis. le fait de changer d’équipement fait parfois de la magie :wink: Je sais pas s’il y a moyen de faire un reset de la mémoire du RFXCOM…

J’ai eu un problème de câble avec un RFlink. Et le souci n’apparaissait pas de suite mais après une dizaine d’heures.
Au changement de câble, plus d’arrêt du RFlink.

Antoine

Comme je te disais plus haut , si effectivement le RFXCOM est branché sur l’USB0 et initié sur le port RXCOM Rfxtrx433XL(/dev/ttyUSB0) :

Merci pour vos réponses. Je vais essayer de remplacer le câble. Je vous tiens au courant.

Petite mise à jour.

Je n’ai pas encore changé le câble, ni ajouté un hub USB alimenté mais j’ai supprimé quelques protocole que je n’utilisais pas le 31 janvier (12 LaCrosse et 23 X10, de mémoire) car j’avais remarqué quelques unknown ID dans le log (une sonde LaCrosse, probablement chez un voisin). Depuis le RFXcom réponds toujours sans interruption. J’ai aussi ajouté le heartbeating à 5 minutes (il n’était pas activé précédemment) au cas où le deamon perde le lien… Donc cela tiens depuis trois jours…

Suite au prochain épisode.

Suite de la suite de la suite…

Mon RFXCOM s’est à nouveau arrêté hier après 5 jours sans interruption… De plus il s’est arrêté deux fois, une fois à 8h00 et une nouvelle fois à 21h30… J’ai changé le câble USB (remplacement par un neuf) et j’ai ajouté un hub USB ce matin. On verra si cela tient. Mais je reste très sceptique…

Une question additionnelle, comment fonctionne le heartbeating ? Quel événement déclenche le redémarrage automatique du deamon (que j’ai activé) ? Il semble que ce ne soit pas l’absence de remontée (sinon il aurait redémarré). A priori le problème de communication avec le RFXCOM n’est pas intercepté par le mécanisme…

Suite à l’installation du hub alimenté et du changement de câble, le problème est toujours présent et même plus fréquent (plus de remontée au bout de 5 à 6 heures). La commande dmesg -T fait apparaître une erreur, toujours de communication, mais différente de précédemment.

[lun. févr.  8 18:07:23 2021] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[lun. févr.  8 18:07:23 2021] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

J’ai débranché le RFXCOM du NAS et je l’ai branché à mon iMac avec une VM Windows 10 sous VMWare Fusion. Je laisse tourner RFXmgr, je verrai bien si le phénomène se reproduit… Mais je pense que ce sera malheureusement le cas, probablement une problème hardware du RFXCOM…

A suivre…

Dur dur …
Peux tu vérifier avec une cde « getstatus » ce que te remontes l’info du RFXCOM

[2021-02-08 19:24:29][DEBUG] : Firmware version = 0x2B
[2021-02-08 19:24:29][DEBUG] : RFXtrx433 operating at 433.92MHz
[2021-02-08 19:24:29][DEBUG] : Hardware major version = 0x03
[2021-02-08 19:24:29][DEBUG] : Hardware minor version = 0x01
[2021-02-08 19:24:29][DEBUG] : Output power = 10 dBm
[2021-02-08 19:24:29][DEBUG] : Firmware ProXL1

voici le get status à partir de rfxmgr :

================================================
08/02/2021 10:57:52:464= Get Status: 0D 00 00 04 02 00 1C 00 00 00 00 00 00 00 
------------------------------------------------
08/02/2021 10:57:52:512= 1401000402532B0004260003001C10595958434F4D
Packettype        = Interface Message
subtype           = Interface Response
Sequence nbr      = 4
response on cmnd  = Get Status
Transceiver type  = 433.92MHz
Firmware version  = 1043
Firmware Type     = ProXL1
Noise level       = 89
Transmit power    = 10dBm
Hardware version  = 3.0  RFXtrx433XL
Undec             off
Imagintronix      disabled
Byron SX          disabled
RSL               disabled
Lighting4         disabled
FineOffset        disabled
Rubicson          disabled
AE Blyss          disabled
BlindsTx          disabled
BlindsT0          disabled
Legrand           disabled
La Crosse         disabled
Hideki            enabled
AD LightwaveRF    disabled
Mertik            disabled
Visonic           disabled
ATI,Cartelectroni disabled
Oregon Scientific enabled
Meiantech         disabled
HomeEasy EU       disabled
AC                enabled
ARC               enabled
X10               disabled
HomeConfort,Fan   disabled
KeeLoq            disabled

Pour l’instant les sondes remontent toujours dans rfxmgr. Je vais laisser tourner jusqu’à ce que cela plante ou pas… A part mes volets pas d’autre automatisme important donc je peux me passer du RFXCOM pour 'l’instant.

Est-ce que tu vois la minor version dans le menu à droite ?
On dirait que tu es sous la 00 => 1401000402532B0004260003001C10595958434F4D
normalement on devrait être en 01

Merci pour la piste Doubledom. Je n’ai pas encore vérifié car j’ai rebranché le Rfxcom sur le NAS et donc remis en route le deamon du plug-in dans Jeedom. En effet, sur ma VM Windows 10 sur Mac, je n’ai pas eu de blocage après un peu moins de 24h00 de fonctionnement. Outre le changement de host (VM Debian buster sur NAS —> VM Win 10 sur iMac), je n’utilisais pas la même antenne. Je suspecte fortement l’antenne car quelques jours avant les premiers problèmes, j’avais remplacé l’antenne du Rfxcom par une antenne Ground Plane 433 Aurel installée dans mon grenier pour améliorer la réception. Or pour relier celle-ci au Rfxcom, en plus du câble de 2,5 m fourni, j’ai utilisé un câble additionnel de 5m avec des connecteurs BNC que j’ai « monté » et un adaptateur BNC-SMA. Un des connecteurs BNC du câble « rallonge » n’est pas soudé mais vissé et j’ai un gros doute sur ce dernier. Je ne suis pas électronicien, mais je suppose qu’une mauvaise connexion peut générer des interférences ou du bruit et peut, peut-être, bloquer le Rfxcom au bout d’un certain temps… je ne sais pas si quelqu’un a déjà rencontré ce genre de problème. … Je continue de surveiller et si cela tient, je tiens la coupable. Sinon je revérifierai la minor version sur Rfxmgr…

Toujours à suivre donc :wink:

:frowning_face: Ce n’est pas l’antenne… Nouveau « blocage » ce soir à 22h30 avec l’ancienne antenne, plus aucune remontée après plus de 24 heures de fonctionnement. Et à nouveau la même erreur dans dmesg :

[mer. févr. 10 22:31:05 2021] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[mer. févr. 10 22:31:05 2021] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

Je débranche le RFXCOM et ça repart…

Concernant la « minor hardware version » le log RFXCOM de jeedom indique au redémarrage du deamon :

[2021-02-10 22:59:34][DEBUG] : Firmware version = 0x2B
[2021-02-10 22:59:34][DEBUG] : RFXtrx433 operating at 433.92MHz
[2021-02-10 22:59:34][DEBUG] : Hardware major version = 0x03
[2021-02-10 22:59:34][DEBUG] : Hardware minor version = 0x00
[2021-02-10 22:59:34][DEBUG] : Output power = 10 dBm
[2021-02-10 22:59:34][DEBUG] : Firmware ProXL1

Mais que signifie cette information à part que la version du hardware est 3.0 ?

J’ai bien peur que le problème soit matériel. Je ne pense pas qu’il y ait un problème de sonde qui générerait une perturbation sur le 433MHz, comme j’ai pu le lire dans certains posts, car à chaque fois j’ai une erreur côté port USB Ftdi. Je ne sais pas trop quoi tester d’autre… Une idée ?

Est-ce que tu as essayé de Reflasher le Firmware ?

J’essaierai probablement ce soir même si je ne comprends ce que cela pourrait changer. La dernière mise à jour de firmware s’était déroulé sans erreur et sans problème et si je me souviens bien il y a une phase de vérification dans le processus…

A suivre…

Seulement pour voir si la minor version change !

comme plus haut
[2021-02-08 19:24:29][DEBUG] : Firmware version = 0x2B
[2021-02-08 19:24:29][DEBUG] : RFXtrx433 operating at 433.92MHz
[2021-02-08 19:24:29][DEBUG] : Hardware major version = 0x03
[2021-02-08 19:24:29][DEBUG] : Hardware minor version = 0x01
[2021-02-08 19:24:29][DEBUG] : Output power = 10 dBm
[2021-02-08 19:24:29][DEBUG] : Firmware ProXL1

Tu n’as pas d’autres log avant le plantage dans RFXCOM