Functional app requires some fine-tuning

Greetings,

I have an app that is not quite ready for prime-time. You can see from the screenshot that, when it works, it works. The problem is that sometimes, one or more BLE devices fail to connect on the first go. I am certain it is all a matter of timing (kind of like life;) but I am unable to orchestrate and direct the four BLE players. To be clear, this app reads data from four BME280 sensors, each with their own ESP32C3 processor.

I am attaching the .ala file and copies of the BLE data from my Arduino-coded ESP32C3 microprocessors, as well as an image of the block code. As you can see, the UUIDs match and the screenshot shows that the app works . . . but not flawlessly. Would someone please point out where I am failing in my logic?

It was also pointed out to me that this can be done with only one BLE extension, and I have been graciously referenced to "relevant" material, only to find that I do not have the skills to translate any of these examples to fit my need.

If someone would be so kind as to look over my code and suggest improvements to it, or a modification that allows four devices on one BLE. For this, I just need a partial example using a service UUID and characteristics UUID. Thank you to all and have a great week!

BLE1_to_BLE4.aia (1.2 MB)




A comment and a question:

Procedure Millisecond_Delay does not delay.
It changes a couple of global variable contents, but that's all.
Not that the rest of your code even looks at the contents of those variables.
So why bother even calling that procedure?

Another data dead end:

TinyDB1 tag "Stored_Connection" is rewritten each time one of the four procedures LEn_Connect is called from
Clock1 Timer
Why bother? No code refers to TinyDB1, and the remaining value under the tag will always be just Service4UUID.

Hi,

A very good question which deserves an answer. I was looking at that, originally as a way to buy time between the BLEs connecting but you are correct, it did not help matters and, to be fair, since I removed it, the app has been rather well-behaved.

So . . . let me get this straight. When my procedure called BLE1 and then called delay milliseconds before calling BLE2, are you saying that there was no 2000ms delay between those two BLE calls? I thought I copied someone else's example to the letter. If I may ask, since I got it wrong, how would I instigate a 2 second delay between BLE calls, assuming I still wanted to do that for the dramatic flair of a one through four power up, instead of a random explosion of data? Thanks for the observation, two more eyes were all I needed.

Use a clock timer and a counter, to action each connection, one after the other, preferably once the data from the first connection has been received.

For the list management aspect of a timed sequence, you need a table of BLE components, uuids, and names.

That's a four row three column table.

Each row has enough data to feed a general connect procedure using a generic BLE connect block replacing your 4 connection procedures.

I prefer to remove row 1 after using it to connect, to avoid having to deal with an extra index variable.

Stop using the table after emptying it.

You might want a separate Clock Timer just for this process.

P.S. if you make the BLE connected event generic, it could replace the clock Timer for calling the procedure to get the next connection parameter set.

Thank you, something new to learn while recuperating (tables;). I am typing left-handed as I went to the hospital this morning and returned with a new reversed right shoulder joint and a repaired rotator cuff. I ain't gettin' older, I'm gittin' fixeder.

The fun never ends.