PyBluez and HC-05/HC-06 bluetooth serial devices ignore each other's valid services #65
Description
What I'd expect to see is that Pybluez could inspect the services offered by
HC-06 modules, and that HC-05 modules in Master (Initiator) mode would be able
to scan and identify Pybluez-advertised services. However neither seems to be
able to see the other. Pybluez can list its own services (such as those hosted
on another laptop via Pybluez) and HC-0x modules can list their own services
too, but never the twain shall meet.
I have proven successful discovery and connection between HC-05 with address
00:13:04:10:07:85 and HC-06, with address 00:12:12:21:28:63 using the following
steps...
AT
AT+ORGL
AT+RESET
AT+UART=9600,0,0
AT+ROLE=1
AT+INIT
AT+INQM=0,16,32
AT+INQ
# this returns a string like... +INQ:12:12:212863,1F00,7FFF
AT+INQC
AT+FSAD=12,12,212863
AT+PAIR=12,12,212863,30
AT+LINK=12,12,212863
The final command reports OK, and bytes can be sent across the link. It
demonstrates that these very cheap and simple bluetooth devices are advertising
sufficient bluetooth classes, profiles and protocols to negotiate an RFCOMM
connection between each other. I would expect Pybluez with a class 1 USB
bluetooth adaptor to do the same, but it cannot connect to the HC06, and the
HC05 cannot seem to connect back to the USB either.
My USB (pybluez) device is Bus 005 Device 003: ID 0a12:0001 Cambridge Silicon
Radio, Ltd Bluetooth Dongle (HCI mode)
With bluetooth visible on the laptop, run discover_devices() from a second
laptop, which reports...
['00:12:12:21:28:63','00:13:04:10:07:85','00:15:83:54:25:49']
...corresponding with the HC-06 in slave mode, the HC-06 in master mode, and
the USB key of the laptop
Run [(x,find_service(address=x)) for x in discover_devices() if x!=
'00:15:83:54:25:49'] to report services offered by the HC-06 and HC-05
(excluding all the services hosted by the USB key of my laptop) returns these
empty results...
[('00:12:12:21:28:63',[]),('00:13:04:10:07:85',[])]
If the live service on the HC-06 module (address 00:12...) could be reported,
then I could be sure that the next step was advertising services with the right
class etc. but nothing is visible at all.
Next is to try connecting back the other way from the HC-05 module in master
mode to the laptop's USB. On the laptop, launch a python shell and run the
initial lines of rfcomm-server.py as follows...
from bluetooth import *
server_sock=BluetoothSocket( RFCOMM )
server_sock.bind(("",PORT_ANY))
server_sock.listen(1)
port = server_sock.getsockname()[1]
uuid = "00001101-0000-1000-8000-00805F9B34FB"
advertise_service( server_sock, "SampleServer", uuid)
client_sock, client_info = server_sock.accept()
However, on a scan initiated from the HC-05 module, you only see other HC-06
modules' services, a single dial-up networking service on the laptop's USB
(which reports as +INQ:15:83:542549,420100,7FFF) and no Pybluez services at all.
What I'd expect to see is that Pybluez could inspect the services offered by
HC-06 modules, and that HC-05 modules in Master (Initiator) mode would be able
to scan and identify Pybluez-advertised services. However neither seems to be
able to see the other. Pybluez can list its own services (such as those hosted
on another laptop via Pybluez) and HC-0x modules can list their own services
too, but never the twain shall meet.
Perhaps there's something over-specified or under-specified in my pyBluez
calls, something with class, protocol, profile, RFCOMM vs. L2CAP so that the
HC-0x modules services are not seen and they cannot see the pyBluez services.
However, I've tried every combination I can think of.
The modules are described in a number of PDFs online...
https://www.google.co.uk/search?q=hc-05+AT%2BLINK+bluetooth+filetype%3Apdf
...in case others have the knowledge of which identifiers need to match.
Original issue reported on code.google.com by c...@cefn.com on 1 May 2014 at 11:29