Displaying received Bluetooth information

Hello!

I am trying to categorize received Bluetooth information and displaying it accordingly to the desired labels.

So if the received data starts with “s”, it will be displayed through FIRELABEL. If not, it will be displayed through ENTRYLABEL instead.

As of right now the default text in the labels does change when it receives data, but it is blank, which is not supposed to be the case. Below are images of the code block, default and changes of the labels.

Code block:

Default labels:

[FIRELABEL] Label change when data is received:

[ENTRYLABEL] Label change when data is received:

Many thanks if we could figure out this problem!

Here is standard advice on using BlueTooth Delimiters:

Please see the Delimiter article in FAQ

Be sure to use println() at the end of each message to send from the sending device, to signal end of message. 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.
BlueToothClient1_Properties
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.

(end of standard advice)

Be sure to ask to receive the text only once per Timer event, and feed it into a variable for subsequent analysis.

P.S. I recently thought of an example for why message delimiters are much better than timing ...

Sunday I spent an hour pulling my wife's hair out
(wait for it)
(wait for it)
(wait for it)
(wait for it)
(wait for it)
(wait for it)
(wait for it)
(wait for it)

from the bathtub drain.

Hi!

Thank you for your reply.

The program I am running to send data to my application is through Python instead of Arduino. While it could have been due to the Delimiter, I have just managed to solve my problem after lying on my bed for hours trying to figure it out hahaha.

Still, thank you very much for your input!

I also think best that way.

My teachers and employers were not understanding.