The current OH binding has classes that support Bluetooth client functionality, where OH is the client reading from- and writing to- another remote Bluetooth device.
By contrast I have an application where OH needs to play the role of a Bluetooth Server, where another remote Bluetooth App makes read and write requests on OH as the server.
Is there anyone in the developer community who can advise how to add such Bluetooth server functionality on top of the existing Bluetooth client functionality (or otherwise)?
I am pretty sure that OH bluetooth transport / api is limited to client side (receiving data/communicating with existing devices) rather than emulating complete devices.
Your case is not alone, a while ago there was discussion about modbus slave interface, which is conceptually similar to yours.
For bluetooth, if we speak of linux, a little help can be provided by bluez which is already integrated through java-dbus interface. You might look at this tutorial to see how to proceed further:
Having a BT device interface is quite interesting for i.e. handheld setup and commissioning which can be conducted using mobile device. Good luck!
The application which I am working on, is one where the manufacturer has an App to control the devices. And I would write an OH binding to emulate that App (i.e. a kind of ‘fake’ App). This can already be done by the existing OH Bluetooth binding code. The difficulty is that the real App uses encryption and the fake OH App has no way to learn the encryption key. So I would implement also an OH ‘fake’ device that could get the key from the real App, and then add that key to the config for the OH ‘fake’ App to command the real devices; this fake device would be used one time only during discovery, and once the key is known, it can be put to sleep…
Another – perhaps easier – approach is for the OH binding to sniff the BLE traffic (like Wireshark) and observe the data exchange when the App adopts a device. An adoption process comprises four read/write transactions between the App and the device; where the fourth transaction contains the encryption key. The binding PR is as shown below…
