No recovery from USB Errors
Closed this issue · 1 comments
I am running sml2mqtt on a Raspi, with Debian 11.3. On a regular basis something goes south with USB. dmesg
reports:
[225619.631907] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1020769.568833] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1065317.638338] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1070715.658488] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1072567.870241] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
sml2mqtt reports:
[2022-06-16 01:14:23,731] [sml.ttyUSB0 ] ERROR | Crc error: 13951 != 62811
[2022-06-16 01:14:23,733] [sml.ttyUSB0.status ] INFO | CRC_ERROR
[2022-06-16 01:14:24,727] [sml.ttyUSB0.status ] INFO | OK
[2022-06-16 04:02:07,774] [sml.ttyUSB0 ] ERROR | Crc error: 43792 != 8418
[2022-06-16 04:02:07,775] [sml.ttyUSB0.status ] INFO | CRC_ERROR
[2022-06-16 04:02:08,779] [sml.ttyUSB0.status ] INFO | OK
[2022-06-16 07:26:57,922] [sml.ttyUSB0 ] ERROR | Crc error: 31688 != 57124
[2022-06-16 07:26:57,924] [sml.ttyUSB0.status ] INFO | CRC_ERROR
[2022-06-16 07:26:58,927] [sml.ttyUSB0.status ] INFO | OK
[2022-06-16 09:32:46,982] [sml.ttyUSB0 ] ERROR | Crc error: 42302 != 28876
[2022-06-16 09:32:46,984] [sml.ttyUSB0.status ] INFO | CRC_ERROR
[2022-06-16 09:32:47,989] [sml.ttyUSB0.status ] INFO | OK
[2022-06-16 09:50:50,987] [sml.ttyUSB0 ] ERROR | Crc error: 2534 != 4207
[2022-06-16 09:50:50,989] [sml.ttyUSB0.status ] INFO | CRC_ERROR
In this situation, no messages are sent to MQTT anymore, eventhough "INFO" seems to report "OK", which would make me believe the tool has recovered the problem successfully but in fact it did not.
The only remedy here is to manually:
service sml2mqtt stop
service sml2mqtt start
I know it is not sml2mqtt's fault in the first place. There is rather something rottin' in the USB susbsystem on that Raspi but let me just ask: Is there any chance sml2mqtt could detect that situation and recover gracefully from it such that it can continue to deliver messages to the MQTT broker?
Update: Since it is very unlikely that sml2mqtt
can recover from the error described above, I eliminated the pl2301 based USB to serial and wired the IR probe directly ro the GPIOs of my Raspi. I am now using /dev/serial0
and most likely the frustrating errors are now gone. Using a Raspi, and going the USB-to-serial path wasn't a really good idea in the first place. This path is perhaps ok if controllers are used that don't have a GPIO accessible serial port.
I am closing the issue ....