I think your code is good, should not have broken the App as you put it, but presumably it means that the first data send takes more than one second somehow?
My bad. I wrongly expressed myself. I meant, it is possible for data to be sent and received on the hardware Serial channel without requiring an extra Serial port via Software Serial library. This works in this case since in every loop, the incoming data (command sent from the app) is first read from the Serial port and then sensor data from the Arduino is sent to the app via the same Serial port. Hence, from my understanding, there is no possibility of conflict. So, no need for an extra Serial port.
I think it should be OK, but you do have very short time intervals. That could be trouble on the App side because it is using Android's timer service, which is low priority and can be unreliable.
1 Like
Concerning the no show of data, I think it's possible that the sensor takes more than 1 second to produce the first value? You could have a one-off delay in the Sketch, to ensure that the sensor is given a little bit of time before streaming the data.
I managed to solve the disconnection by using this code hack: Bluetooth HC-06. Arduino. Send. Receive. Send text file. Image
But there is a time delay of 5-10 seconds before the disconnection error appears.
That is a big delay, considering your fast clock interval.
Can you list here:
- Phone Make and Model
- Exact Android Version
- Bluetooth version of the phone
- Version of Uno
The HC-06 should be BT v2.0 + EDR
Let's see if Evan Patton can think of any reason why recognition of disconnection should take so long.
1 Like
- Phone Make and Model: Samsung S8 SM-G950F (perfectly working condition)
- Exact Android Version: Android 9 (stock version, never modified nor rooted)
- Bluetooth version of the phone: Bluetooth 5
- Version of Uno: R3
There was a mistake in the "If Then Else" block of BluetoothClient1.IsConnected under the Clock1.Timer. I fixed it so the app now works but still, the disconnection is not detected if the Bluetooth module is removed, so the error count is actually never incremented. From my research, it seems like this is a limitation of AI2 or maybe Bluetooth 2?
AI2 only has a limitation on older Android and the BT Classic functions are aimed at v2 to v2.1 Bluetooth.
Since you have a BLE 5 phone, you might like to use BLE instead (see my chart of BLE compatible modules). AI2's MIT BLE extension has more to offer but is just as easy to use (well, almost 
).
https://www.professorcad.co.uk/appinventortips#TipsBluetooth
1 Like
The issue isn't with App Inventor, but with how the Android implementation of BluetoothSocket works for Bluetooth classic. The socket state is only reset to closed when the close() method is called. This state is never transitioned to automatically. In App Inventor, if you have DisconnectOnError set to true and you attempt to read/write the socket after the remote device has gone away, it will call Disconnect for you and then the IsConnected property will be false. So long as you never attempt to interact with the device after removing the Bluetooth module, the Android socket will happily report it is still connected.
1 Like