De temps à autre, lorsque pyHeatpump est activé, le device “ttyUSB0” disparaît et se transforme en “ttyUSB1”. Voici les logs corespondant :
137240.259397] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[137240.260089] usb 1-1.3: Detected FT232BM
[137240.261145] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
[137373.375308] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[137373.375382] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[137373.431288] usb 1-1.3: USB disconnect, device number 77
[137373.431527] ftdi_sio ttyUSB0: error from flowcontrol urb
[137373.431893] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[137373.431945] ftdi_sio 1-1.3:1.0: device disconnected
[137374.243657] usb 1-1.3: new full-speed USB device number 78 using dwc_otg
[137374.399746] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 2.00
[137374.399770] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[137374.399785] usb 1-1.3: Product: Carel USB-RS485 Converter
[137374.399799] usb 1-1.3: Manufacturer: Carel S.P.A.
[137374.411429] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[137374.412110] usb 1-1.3: Detected FT232BM
[137374.413292] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1
[137377.015308] usb 1-1.3: USB disconnect, device number 78
[137377.016565] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[137377.016704] ftdi_sio 1-1.3:1.0: device disconnected
[137377.563756] usb 1-1.3: new full-speed USB device number 79 using dwc_otg
[137377.719841] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 2.00
[137377.719865] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[137377.719880] usb 1-1.3: Product: Carel USB-RS485 Converter
[137377.719894] usb 1-1.3: Manufacturer: Carel S.P.A.
[137377.731796] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[137377.732974] usb 1-1.3: Detected FT232BM
[137377.734607] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1
[137412.074089] rpi_firmware_get_throttled: 9 callbacks suppressed
[137412.074097] Voltage normalised (0x00000000)
[137482.795003] rpi_firmware_get_throttled: 10 callbacks suppressed
[137482.795014] Under-voltage detected! (0x00050005)
[137489.034926] Voltage normalised (0x00000000)
De temps à autre, lorsque pyHeatpump est activé, le device "ttyUSB0" disparaît et se transforme en "ttyUSB1". Voici les logs corespondant :
```
137240.259397] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[137240.260089] usb 1-1.3: Detected FT232BM
[137240.261145] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
[137373.375308] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[137373.375382] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[137373.431288] usb 1-1.3: USB disconnect, device number 77
[137373.431527] ftdi_sio ttyUSB0: error from flowcontrol urb
[137373.431893] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[137373.431945] ftdi_sio 1-1.3:1.0: device disconnected
[137374.243657] usb 1-1.3: new full-speed USB device number 78 using dwc_otg
[137374.399746] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 2.00
[137374.399770] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[137374.399785] usb 1-1.3: Product: Carel USB-RS485 Converter
[137374.399799] usb 1-1.3: Manufacturer: Carel S.P.A.
[137374.411429] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[137374.412110] usb 1-1.3: Detected FT232BM
[137374.413292] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1
[137377.015308] usb 1-1.3: USB disconnect, device number 78
[137377.016565] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[137377.016704] ftdi_sio 1-1.3:1.0: device disconnected
[137377.563756] usb 1-1.3: new full-speed USB device number 79 using dwc_otg
[137377.719841] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 2.00
[137377.719865] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[137377.719880] usb 1-1.3: Product: Carel USB-RS485 Converter
[137377.719894] usb 1-1.3: Manufacturer: Carel S.P.A.
[137377.731796] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[137377.732974] usb 1-1.3: Detected FT232BM
[137377.734607] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1
[137412.074089] rpi_firmware_get_throttled: 9 callbacks suppressed
[137412.074097] Voltage normalised (0x00000000)
[137482.795003] rpi_firmware_get_throttled: 10 callbacks suppressed
[137482.795014] Under-voltage detected! (0x00050005)
[137489.034926] Voltage normalised (0x00000000)
```
I discovered what was causing this ‘error’ for me. My program was leaving the /dev/ttyUSBN serial port open. I rebooted and changed my software to close the port after use (Previously, it was left open in one of the error cases). After doing this, I no longer saw the dmesg or syslog errors. Hopefully this helps.
EDIT : Cette issue semble être très reliée aux cas que nous avons experimentés avec le convertisseur non-carel
[Issue github](https://github.com/raspberrypi/linux/issues/2406)
Réponse :
> I discovered what was causing this 'error' for me. My program was leaving the /dev/ttyUSBN serial port open. I rebooted and changed my software to close the port after use (Previously, it was left open in one of the error cases). After doing this, I no longer saw the dmesg or syslog errors. Hopefully this helps.
EDIT : Cette issue semble être très reliée aux cas que nous avons experimentés avec le convertisseur non-carel
Ce problème est assez bloquant car il fait planter pyheatpum_fetch.service . Il faudrait voir si l’ont peut timer les services sur l’arrêt d’un autre, quelque chose du style :
Une autre voie pour corriger ce problème serait de poser une règle “udev” sur le la signature du matériel attendue pour forcer l’utilisation de ttyUSB0 sur celui ci. Les signatures du matériel peuvent différer selon le chipset, mais à priori, on sera soit sur de la FTDI soit sur de la CH340.
Ce problème est assez bloquant car il fait planter pyheatpum_fetch.service . Il faudrait voir si l'ont peut *timer* les services sur l'arrêt d'un autre, quelque chose du style :
```
t0 - START pyheatpump_fetch
t1 - STOP pyheatpum_fetch
t2 - START pyheatpump_supervise
t3 - STOP pyheatpump_supervise
```
Une autre voie pour corriger ce problème serait de poser une règle "udev" sur le la signature du matériel attendue pour forcer l'utilisation de ttyUSB0 sur celui ci. Les signatures du matériel peuvent différer selon le chipset, mais à priori, on sera soit sur de la FTDI soit sur de la CH340.
Voir : https://git.yannweb.net/nas/Supervision/issues/61
UDEV rules : https://noctis.de/posts/2006/03/23-howto-fixed-name-for-a-udev-device.html
looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0':
KERNELS=="ttyUSB0"
SUBSYSTEMS=="usb-serial"
DRIVERS=="ch341-uart"
ATTRS{port_number}=="0"
Il faudra bien une règle UDEV défférente
Sur le raccord usb non carel :
```
looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0':
KERNELS=="ttyUSB0"
SUBSYSTEMS=="usb-serial"
DRIVERS=="ch341-uart"
ATTRS{port_number}=="0"
```
Il faudra bien une règle UDEV défférente
De temps à autre, lorsque pyHeatpump est activé, le device “ttyUSB0” disparaît et se transforme en “ttyUSB1”. Voici les logs corespondant :
Issue github
Réponse :
EDIT : Cette issue semble être très reliée aux cas que nous avons experimentés avec le convertisseur non-carel
Ce problème est assez bloquant car il fait planter pyheatpum_fetch.service . Il faudrait voir si l’ont peut timer les services sur l’arrêt d’un autre, quelque chose du style :
Une autre voie pour corriger ce problème serait de poser une règle “udev” sur le la signature du matériel attendue pour forcer l’utilisation de ttyUSB0 sur celui ci. Les signatures du matériel peuvent différer selon le chipset, mais à priori, on sera soit sur de la FTDI soit sur de la CH340.
Voir : #61
UDEV rules : https://noctis.de/posts/2006/03/23-howto-fixed-name-for-a-udev-device.html
FTDI Chip
La partie intéressante semble être celle-ci :
On va donc créer une règle qui match la chaîne suivante :
Commande pour “re-plug” le port usb sans avoir à le faire à la main (FTDI) :
Règle udev pour link vers /dev/rs485
Fichier : /etc/udev/rules.d/42-rs485.rules
Recharger les règles udev :
Test :
À testé et à déployer sur mon banc de test
Pour les archives, port série non carel :
Sur le raccord usb non carel :
Il faudra bien une règle UDEV défférente
Comme indiqué, la règle udev :
/etc/udev/rules.d/42-rs485.rules
Sur le banc de test :
La modification est effective
Il semble que le problème vienne de l’alimentation, il suffit d’alimenter la machine connectée par une alimentation d’origine raspberry pi.