Closed Nelson-Christensen closed 2 years ago
Hey Nelson, thank for the info. Sadly though, without matching hardware or software I won't be able to do much to assist with this (other than give you ideas on how to provide me what is needed). With regards to your comments, I've seen things like this within my own companies hardware (or at least the hardware that we work with). The process of:
generally happens when the original connection was not shut down properly. For example:
In my case though, transmission of data generally works. It's just that double connection that happens when the Device doesn't correctly release the RFCOMM socket properly.
With regards to your To reproduce how exactly are you connecting to the macBook/macMini? You have their MFi Protocols? Without those you're going to run into a lot of random issues with the communication. If you have them (I've never been able to find them) can you email me directly and maybe I can give it a shot? You'll be able to connect using the Mac address (yes) but you'll never be able to send/read data from the device.
Are you experiencing the same issue while connecting to an Android, Windows or SBC device? These will not be limited by the MFi protocol requirement for communication.
Thanks for the quick response Ken. No I don't have any MFi protocols. I wasn't aware that those were necessary since I can read the packets correctly on my macBook/macMini through a packet sniffer (I've sent strings that I've been able to read whenever the connection works properly).
I'm currently testing it against a Windows PC, I'll update my post here with information of how that goes.
Ok, sorry, let me back up a step. I might have gotten confused with regards to what you're doing.
React Native Device
If this is the case, then you DO NOT need MFi protocols. But your original comments said
Manually connect to a computer(macBook/macMini) by its macAddress.
Which if you're connecting to a macbook you absolutely do need the MFi protocols and you can only do this on IOS. So if you're attempting to connect VIA bluetooth from Android to MacBook, you will never get this working. I've tried it numerous times and was never successful. The MacBook seems to accept the connection, but never does anything else.
If you're connecting from Android Pie to Windows PC, then this should definitely work (although untested by me). You can also attempt to connect Android Pie to another Android, this should also work (I have tested numerous times).
You'll need to actually debug the writeToDevice
to see what's going on, and where the data is getting dropped?
You're just talking about bluetooth on mac a whole bunch, and that will never work.
No you're correct, sorry for the confusion. The React Native Device is an Android, but its trying to connect to a macBook over bluetooth.
I've tested it a bit more against a Windows PC instead of the macBook as the BT target device and that seems to work correctly.
I've managed to establish a connection (although unreliably) and send messages over which the macBook can read through a packet sniffer, but maybe it will always remain unreliable unless I have the MFi protocols.
Thanks for your quick responses and help. Are you aware of any other way of sending data between an android device and a macBook? I'll continue digging and update this post if I find a solution.
Yes. It will definitely be hit or miss while attempting to connect from React Native (this library) to a Mac/IOS device. This is solely MFi related. I'm going to close this off since it's working as designed as per the documentation and the limitations of MFi.
With regard to your other question, I would use a more standard method of communication. A regular socket using normal communication over a network. Or use BLE instead of RFCOMM.
I managed to get it to work with BLE by spinning up a BLE peripheral server (GATT server) on the computer and using a BLE library on the RN app to handle the connection. Thanks for pointing me in the right direction Ken.
Mobile Device Environment
Application Environment
Describe the bug Manually connecting to a specific macAddress seems to be inconsistent. Sometimes when it connects it doesn't actually pass along any data through the bluetooth connection even though the connect/disconnect/writeToDevice returns true as if it were successful.
The app I'm developing needs to connect to a specific macAddress which is always known beforehand (so I don't need to scan/startDiscovery). So to connect I just call the
RNBluetoothClassic.connect(macAddress)
. However sometimes even when the connection is successful (RNBluetoothClassic.connect(address)
has returned true and when checkingRNBluetoothClassic.isDeviceConnected(address)
it also returns true) none of the data transmissions functions (disconnect, writeToDevice) actually transmits any data to the receiver, even though they return true as if they were successfully called.I have used the xCode bluetooth packet logger to view incoming transmissions from my macBook, which is how I can see that it sometimes doesn't send anything. What I've noticed from the packet logger is that it sends a "Connection Request" but as soon as it has successfully connected it sends a "Disconnection Request" and then another "Connection Request", I'm not sure if it could be that it has a reference to the closed socket (just guessing here, I have no idea how the BT works behind the scenes).
Whats interesting is that it sometimes work. For example if I reinstall the app and connect and send messages I can see that everything works and is transmitted correctly. But if I disconnect and reconnect it will never work to writeToDevice. None of the methods throws any errors and they all return true as if they were successfully accomplished which is why I'm so confused.
Worth noting is that the device I'm connecting to is not displayed in the discovered devices whenever I call a startDiscovery. However the device is in the pairedDevice's list and it successfully works to connect it.
To Reproduce
Expected behavior It shouldn't say that the connection and writeMessage are successful when nothing is sent.