Is your BlueTooth OBD-2 interface emulating an ELM327 chip (itself a PIC chip with custom firmware, widely copied by Chinese cloners)? This is basically an UART connected to your carsā CANBUS via BlueTooth using a well documented standard OBD protocol. You send a query, and the ECU responds. Each car manufacturer is very tight lipped about their unique OBD extensions, and reverse engineering can be both tedious and rewarding.
A cheap BlueTooth OBD ELM style dongle is not your only hardware choice. Ones that use WiFi in serial UART passthrough mode also exist at similar prices to the BlueTooth ones, and ESP32ās have CANBUS pins that only need a simple bus interface chip to talk to your car at both high and low speeds, and the ESP32 radio supports WiFi, BlueTooth, BLE, and in more recent ESP models ZigBee and Thread, as well as most having a USB port with serial connection for programming and debugging - a very wide choice to pick from. How you get connected shouldnt matter to the OBD portion of your solution - it is the network layer and below and should be transparent to the application layer above it.
It sounds like you have issues with getting your connection going, and are not at the OBD protocol level yet, but the underlying physical connection level.
Care to share what code you have written and some more detailed logs, or a GitHub repository? Properly formatted for forum readability please (use </>).
What does your PC system error log say about your BlueTooth dongle? Is plug-and-pray (sorry) working reliably?
What is your development and test environment? Your target platform? Is your choice of third party libraries to glue it together the best? Are there alternatives? Stand on the shoulders of giants.
What error codes are you checking for at each step of the BlueTooth connection phase? Are the correct variables being initialised and retained during function calls? A gotcha: Detailed stepping through in debug mode should allow for BlueTooth timeouts to disrupt your train of thought.
My approach: Break it up into smaller chunks. Get each one going and then move onto the next once you are convinced it is going well. It appears you got your connection going at one point, but that has changed. You need to go back and test for that and overcome whatever the problem is, whether it is a driver problem at OS level, a connection problem at application level, a design issue with your code or initialise sequencing, or just simply your dongle is defective or unsuitable. In each and every stage, you should not make assumptions, but check return codes and have robust error logging, not just for yourself at development time, but potential users when things go wrong - they will!
Nordic have extensive documentation on the BlueTooth protocol. Worth reading their website for further understanding.
Many car enthusiast forums have projects for OBD software in various stages of development. Very tempting to roll your own, given the substantial prices of manufacturer and third party scan tools, and the tempting short list of standard OBD error codes, however when you realise that the car manufacturer holds their unique addons very close to their chest, and you are paying the third party scanner vendors for basically their reverse engineering skills, the enthusiasm tends to wane as the realisation of the scope of what you need to do to replicate this dawns on you.
If you break your code into the OSI layers, it becomes flexible to interchange your connection layer that can be transparent to the application itself, and it become more universal and adaptable as you can focus on the application, assuming the underlying layers just work. Swap your BlueTooth dongle for an interface that already exists in the vehicle - easy! Remote logging to your mechanic and diagnosis via a VPN connection over your cell phone - easy!
Best wishes. A simple OBD app well integrated into HomeAssistant is not impossible. See the existing car integrations already out there for ideas.
