如何使用 PySerial 重新连接蓝牙连接（算法问题）Raspberry Pi - 蓝牙设备

Question

Goodday programmers,

I'm working on a connection between a Raspberry Pi 3B+ and several Bluetooth devices, max 5 per Pi at this moment. I'm able to make the connection, do all the interaction with the device but struggle with reconnecting after the device lost connection for a longer period of time. Please lend me your great minds and assist me in making a bulletproof script that always connects the devices effectively.

Some info:

• Pi 3B+ running Raspbian Buster
• Bluetooth devices are paired using bluetoothctl and bound to a rfcomm[x] in rc.local (sudo bind ...)
• Python script uses PySerial to connect to the device, read and write using threading and queues.
• All devices connect when starting the script
• Main script is started with .config/lxsession/LXDE-pi/autostart
• Using PySerial to connect to Bluetooth devices results in a pretty long time to connect, about 2-3 seconds.

There are 3 threads running per device, Watchdog, Read, Write. The Watchdog adds a dummy message to the write queue about every 5 seconds (which is send to the device by the write thread), if it reacts (with incorrect command response) I know it's alive. If it doesn't react for about 30 seconds I know it's lost connection and I must try to reconnect. I have a variable that indicates the connectionstatus (connectionAlive) and can be 0, 1 or 2. 0 is inactive, 1 is reconnecting, 2 is connected. Read and write threads are only active when connectionAlive > 0. The problem is that when the devices loses connection by going on standby or shutting off to charge the batteries. The read and write threads are pretty straight forward so I think the algorithm to reconnect is the problem. I have added the Watchdog code below:

def Watchdog(self):
        logging.info('Start watchdog thread for: {}'.format(self.tool_id))
        while(True):
            if self.connectionAlive == 0:
                self.ChangeAlive(1)
                time.sleep(0.2)
            if self.wq.qsize() < 3:
                self.wq.put(['ping', ''])
            time.sleep(0.5)
            #if last alive longer than 20 ticks
            if (time.time() - self.last_alive) > 30: #or self.errorQ.qsize() > 0
                last_tick = time.time() - self.last_alive
                #if it was alive, tell thread its dead.
                if self.connectionAlive == 2 and self.com != False:
                    logging.error('Tool {} is taking longer to respond'.format(self.tool_id))
                self.ChangeAlive(0)
                if self.com != False:
                    try:
                        self.com.close()
                        time.sleep(0.1)
                    except:
                        #com wasnt alive (never connected since thread started)
                        pass
                self.connectionTryCount += 1
                try:
                    self.com = serial.Serial(port=self.comport, baudrate=9600, timeout=5, write_timeout=5)
                    #time.sleep(3)
                except:
                    if self.connectionTryCount < 2:
                        logging.error('Tool {} is unable to connect!'.format(self.tool_id)) #com port not available
                        #time.sleep(5)
            else:
                if self.connectionTryCount > 0:
                    logging.info('Tool {} connected after {} tries'.format(self.tool_id, self.connectionTryCount))
                    self.connectionTryCount = 0
                if self.connectionAlive != 2:
                    self.ChangeAlive(2)
                while self.errorQ.qsize() > 0:
                    self.errorQ.get()
                    time.sleep(0.05)

            time.sleep(4)

I think there's a problem with the threads sleeping and somehow making the window to connect and read an 'alive' message too small to stay connected with the result that it disconnects too fast to try to reconnect. The read thread has a sleep of 0.1 and the write thread a sleep of 0.05.

EDIT: The bluetooth devices are connected to a measuring device which needs parameters sent to it. The measuring device can go standby while the bluetooth part is still connected, but that means the device is not alive and is not ready to receive parameters, the device has no build-in queue.

Is my script poorly written or am I doomed from the start for using PySerial or a Pi at all?

Any input or advice is greatly appreciated!

Answer 1

rfcomm is one of 8 tools that has been deprecated by the BlueZ developers so I would recommend moving away from having rfcomm in rc.local.

On Linux the Bluetooth serial connection can be made with the standard Python sockets library as explained in this blog: http://blog.kevindoran.co/bluetooth-programming-with-python-3/

There is also functionality within the Bluedot library that might be helpful. In addition to the documentation there is also some examples .

Depending what your script is doing, you might want to look at using systemd to run your program at startup. I find the following blog a useful reference: https://blog.usedbytes.com/2019/11/run-at-startup-without-rc.local/