Your data stream looks like a coal chute, with lumps of coal sliding down separated by '!' at the word level.
You did not set up a higher level scheme to package the lumps of coal together into commands and files.
You have two Timers,
- Clock1 runs very fast and does nothing but announce connected/disconnected.
- Clock2 runs slow (2000 ms) but does all the work, grabbing the entire buffer each cycle.
You do not take advantage of the BT Delimiter facility to group your incoming data into complete self contained multi-word messages. That leaves you open to having to worry about timing, where messages and words might be cut off at the whim of the Clock Timer.
I recommend using a BT Delimiter of 10 for message level commands.
I also recommend adding a global variable or two for the purpose of remembering whether or not a file transfer is in progress across multiple Clock Timer cycles, and possibly to hold the target file name, the number of lines expected, or the end-of-file marker expected.
You have TWO BT read commands in your Clock2 timer. That's a bad idea. That sends your logic into a multiple personality disorder state, fighting over the data stream.
Instead, use those extra global variables to remind you at each incoming message whether you are in the middle of a file transfer or not.
Here is my stock BT Delimiter advice:
Be sure to use println() at the end of each message to send from the sending device, to signal end of message.
Only use print() in the middle of a message.
Be sure not to println() in the middle of a message, or you will break it into two short messages and mess up the item count after you split the message in AI2.
Do not rely on timing for this, which is unreliable.
In the AI2 Designer, set the Delimiter attribute of the BlueTooth Client component to 10 to recognize the End of Line character.
Also, return data is not immediately available after sending a request,
you have to start a Clock Timer repeating and watch for its arrival in the Clock Timer event. The repeat rate of the Clock Timer should be faster than the transmission rate in the sending device, to not flood the AI2 buffers.
In your Clock Timer, you should check
Is the BlueTooth Client still Connected?
Is Bytes Available > 0?
IF Bytes Available > 0 THEN
set message var to BT.ReceiveText(-1)
This takes advantage of a special case in the ReceiveText block:
ReceiveText(numberOfBytes)
Receive text from the connected Bluetooth device. If numberOfBytes is less than 0, read until a delimiter byte value is received.
If you are sending multiple data values per message separated by | or comma, have your message split into a local or global variable for inspection before trying to select list items from it. Test if (length of list(split list result) >= expected list length) before doing any select list item operations, to avoid taking a long walk on a short pier. This bulletproofing is necessary in case your sending device sneaks in some commentary messages with the data values.
Some people send temperature and humidity in separate messages with distinctive prefixes like "t:" (for temperature) and "h:" (for humidity).
(That's YAML format.)
The AI2 Charts component can recognize these and graph them. See Bluetooth Client Polling Rate - #12 by ABG
To receive YAML format messages, test if the incoming message contains ':' . If true, split it at ':' into a list variable, and find the prefix in item 1 and the value in item 2.
...
