# 05-06 Async JS
Transmission of results to the backend works fine. Measurement collection is kind of tacky because I do not know how JS program flow really works.
# Problem
Javascript's Event Loop makes program flow a bit different than other languages. I am having issues as a result, since JS executes some code and continues without without waiting for any results. After discovering servers, I instruct the code to find servers indefinetely. The code does not wait for servers to confirm connections and disconnections.
Discovered 4 Servers
storing server 24:6f:28:7a:41:3a
Stop Scanning
Iteration counter:1
Trying to connect to server 24:6f:28:7a:57:02
Trying to connect to server 24:6f:28:7a:45:8e
Trying to connect to server 24:6f:28:7a:42:a2
Trying to connect to server 24:6f:28:7a:41:3a
adding measurement -55 from 24:6f:28:7a:57:02 to queue of length 0
Disconnected from 24:6f:28:7a:57:02
noble warning: unknown handle 65 disconnected!
adding measurement -45 from 24:6f:28:7a:45:8e to queue of length 1
Disconnected from 24:6f:28:7a:45:8e
adding measurement -39 from 24:6f:28:7a:42:a2 to queue of length 2
Disconnected from 24:6f:28:7a:42:a2
noble warning: unknown handle 64 disconnected!
adding measurement -64 from 24:6f:28:7a:41:3a to queue of length 3
Disconnected from 24:6f:28:7a:41:3a
RAM: 62% or 6.9236907958984375MB of 11.08203125 MB
Uptime: 7 seconds
The async foreach that iterates over discoveredServers and instructs them to connect and collect RSSI does not wait for the promises of server connections. It goes ahead and calls the next server in array to connect. The RSSI collection sequence at least seems to be in correct order, but I do not want concurrent connections like this. The following is the expected result.
Discovered 4 Servers
storing server 24:6f:28:7a:41:3a
Stop Scanning
Iteration counter:1
Trying to connect to server 24:6f:28:7a:57:02
adding measurement -55 from 24:6f:28:7a:57:02 to queue of length 0
Disconnected from 24:6f:28:7a:57:02
Trying to connect to server 24:6f:28:7a:45:8e
adding measurement -45 from 24:6f:28:7a:45:8e to queue of length 1
Disconnected from 24:6f:28:7a:45:8e
Trying to connect to server 24:6f:28:7a:42:a2
adding measurement -39 from 24:6f:28:7a:42:a2 to queue of length 2
Disconnected from 24:6f:28:7a:42:a2
Trying to connect to server 24:6f:28:7a:41:3a
adding measurement -64 from 24:6f:28:7a:41:3a to queue of length 3
Disconnected from 24:6f:28:7a:41:3a
RAM: 62% or 6.9236907958984375MB of 11.08203125 MB
Uptime: 7 seconds
# Possible Solutions
# await promise.all on array.map()
With map and promise.all, the code waits for all the function calls to finish before moving on.
# Await async foreach
This also looks alright, the asyncForEach takes a callback and iterates over it in a for. This seems less elegant than the first option though.
const start = async () => {
await asyncForEach([1, 2, 3], async (server) => {
await connectToServer(server);
});
console.log('Done');
}
start();
# setTimeout()
After connecting and disconnecting I can possible sneak in a small timeout that will reduce congestion. I think this might be an issue here since I am calling the connection event without pause.
# connect concurrently
I can also rewrite code to connect concurrently and use the updateRSSI() event to get the latest RSSI from the peripheral. I just am not really sure what the hardware limitations of this are, since it might be a bit memory hungry. This Github issue suggests that up to 14 simultaneous connections are possible, which is more than enough for me at the moment.
# Further actions
I guess I will just give the first two of them a shot. If that does not work I will switch back to concurrent connections as originally planned with the ESP32. The reason why I wanted subsequent connection and disconnection events is because the code should also be able to support as many clients as possible. But assuming that it is really possible to handle so many connections, I will go ahead. If that fails I will switch to bluepy since this project seems really crappy and uses deprecated tools.