seeMote Cube initialization failure
Stephen.Morgan 2026-08-06 16:09:43 287 Views5 Replies Hello DFROBOT,
I recently purchased a seeMote Cube and posted an issue in your GitHub repository regarding the use of it, today.
- https://github.com/DFRobot/seeMoteCube/issues/1
Please kindly provide solutions or relevant information on my issue.
It would be appreciated if you would add comments in the GitHub itself, so that accessibility to the useful information be guaranteed to more developers who are interested in Spatial Accessory Tracking with Apple Vision Pro.
Best regards,
To summarize,
1. Trying a new trained model & suggested workaround with seeMote sample app
- On visionOS 27 Beta 4, I tested again with a newly trained .referenceaccessory generated locally using Xcode 27 Create ML from the supplied USDZ, with the same public UTI (com.dfrobot.seemote.cube).- Like the bundled file (cube.referenceaccessory), the new cube-v4.referenceaccessory is confirmed to be present in the installed app bundle and referenced by UTTypeReferenceAccessoryFile, declared with com.dfrobot.seemote.cube.- Accessory Tracking authorization is allowed, and haptics continue to work. However, Accessory(device:) still fails with ARKit.AccessoryTrackingProvider.Error code 1: Unable to load accessory, and so does AccessoryAnchoringSource(device:).- I also tested the Bluetooth power-cycle workaround, but the issue remains the same. Could you please advise on the required Cube firmware revision, the exact visionOS 27 Beta 4 build tested, and any device-side configuration required for Accessory(device:) to resolve successfully?
2. Test with Apple Official Sample App [Working with Generic Spatial Accessories]
- We reproduced the identical failure using Apple’s official “Working with Generic Spatial Accessories” sample, not only the seeMote sample app. The retrained cube-v4.referenceaccessory is confirmed to exist in the installed sample app bundle, and the imported UTI is com.dfrobot.seemote.cube. Button input and haptics work, but both Accessory(device:)and AccessoryAnchoringSource(device:) fail to load the same connected seeMote Cube. This appears outside of the app implementation and reference-file bundling configuration.
3. About Uniform Type Identifier (UTI) & ASA
- What exact UTI list does the Cube firmware advertise through the Apple Spatial Accessory Bluetooth characteristic? Vision Pro Debug View shows com.apple.asa.dfrcubev4, while the supplied .referenceaccessory file and sample app use com.dfrobot.seemote.cube. Is this difference normal? If so, how does visionOS map these two identifiers when resolving the reference accessory file?
What ASA Version payload does the firmware advertise, and what Host Version payload does visionOS write back? Does the firmware report NO_COMMON_PROTOCOL or gate any spatial accessory services after that write?
4. Update to visionOS 27 Beta 5 still brings the same issue described so far.
gumpmv On visionOS 27 Beta 4, I tested again with a newly trained .referenceaccessory generated locally using Xcode 27 Create ML from the supplied USDZ, with the same public UTI (com.dfrobot.seemote.cube).
Like the bundled file (cube.referenceaccessory), the new cube-v4.referenceaccessory is confirmed to be present in the installed app bundle and referenced by UTTypeReferenceAccessoryFile, declared with com.dfrobot.seemote.cube.
Accessory Tracking authorization is allowed, and haptics continue to work. However, Accessory(device:) still fails with ARKit.AccessoryTrackingProvider.Error code 1: Unable to load accessory, and so does AccessoryAnchoringSource(device:).
I also tested the Bluetooth power-cycle workaround, but the issue remains the same. Could you please advise on the required Cube firmware revision, the exact visionOS 27 Beta 4 build tested, and any device-side configuration required for Accessory(device:) to resolve successfully?
gumpmv We reproduced the identical failure using Apple’s official “Working with Generic Spatial Accessories” sample, not only the seeMote sample app. The retrained cube-v4.referenceaccessory is confirmed to exist in the installed sample app bundle, and the imported UTI is com.dfrobot.seemote.cube. Button input and haptics work, but both Accessory(device:) and AccessoryAnchoringSource(device:) fail to load the same connected seeMote Cube. This appears outside of the app implementation and reference-file bundling configuration.
Two more things to ask.
What exact UTI list does the Cube firmware advertise through the Apple Spatial Accessory Bluetooth characteristic? Vision Pro Debug View shows com.apple.asa.dfrcubev4, while the supplied .referenceaccessory file and sample app use com.dfrobot.seemote.cube. Is this difference normal? If so, how does visionOS map these two identifiers when resolving the reference accessory file?
What ASA Version payload does the firmware advertise, and what Host Version payload does visionOS write back? 4. Does the firmware report NO_COMMON_PROTOCOL or gate any spatial accessory services after that write?
Your setup looks solid — the BLE/HID path and Info.plist declarations all check out.
The seeMote Cube requires visionOS 27 or later; it won't initialize on 26.x even if the accessory pairs over BLE. If you're on visionOS 27 beta, there's a known Beta 4 bug where tracking fails to initialize on first Bluetooth pair — power-cycle the accessory or toggle Bluetooth as a workaround.
The com.apple.developer.accessorytracking note in the GitHub repo is outdated — visionOS 27's standard Accessory Tracking capability is sufficient, no separate entitlement approval needed. Your retrained .referenceaccessory from Create ML is worth testing too — the bundled file may have been generated against an earlier firmware revision.
Jason.Miao 