Error 515: Not connected to a Bluetooth device

I'm sorry to say, that as a bluetooth and AppInventor
newbie, I didn't understand the solution you provided.
I changed out the HC05 and left it un-powered while I reloaded the Arduino code but it made no difference.

What solution?

I posted a video to show you how to download your blocks and post them to this board.
The sample blocks I used were from a long time ago, for a different poster, and saved for people who don't know how to download blocks and how to post them to this board.

Those old blocks were not a solution to your specific problem.

Post your code and your blocks.

Thanks, I'll try to download my blocks.

I have three blocks in 3 png files in my Download directory. How do I upload the .png files so they are useful to you?

Start a Reply, and use this icon:
Capture

to remove this post

This means that the problem code is probably in the event that responds to the slider moving.
Could you upload that event block here?

btw your clock example blocks from the screenshot will not help you to find out, if there still is a connection...

as the bluetooth protocol was designed, there is no way to detect, if a connection still is alive, therefore you have to send regularly (i.e. poll) some data to the device. And if you get an error, then you know, that the connection was lost…

also this


does not make any sense... just set Label1.Text to "Is connected" there

Taifun


Trying to push the limits! Snippets, Tutorials and Extensions from Pura Vida Apps by Taifun.

@eugenejasper968 add an if condition like this

if BluetoothClient.IsConnected
then Send1ByteNumber...

Taifun

Is this what you had in mind....
.

yes, exactly
Taifun

@Taifun your wrote: 'as the bluetooth protocol was designed, there is no way to detect, if a connection still is alive'. What is then is the purpose of
grafik ?

M

From the documentation Connectivity

IsConnected

Returns frue if a connection to a Bluetooth device has been made.

Taifun

Thank you for your quick response.
To me these two statements contradict each other:

  • 'there is no way to detect, if a connection still is alive' (your statement)
  • 'Returns frue if a connection to a Bluetooth device has been made'

There must be some sort of semantic difference that I do not understand. As I am struggling with BT connections and designing the logic around them, I would very much appreciate if you could explain why there is no contradiction.

Thank you for your reply and the many previous posts you have made which I find most valuable.

This means, once there is a connection, the property IsConnected stays true even if the connection is lost.

As already said earlier

Taifun

Welcome, is this a question?

Taifun

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.