[Feature proposal] Purpose of facilitating client reconnection process about nimble-arduino HOT 11 CLOSED

nkolban's API was the default =true behavior and I was only confused when porting from an old sketch.
I really don't think it should be =true.

from nimble-arduino.

Hi @wakwak-koba, I understand what you want to do here and I will comment in the same order.

1. uint8_t NimBLEClient::getPeerType(). Yes this is something I've been meaning to do as well, but would be more appropriate to store the type in NimBLEAddress, as the type is specifying the peers address type.

2. The ::getAttribute() methods used to work this way regardless of the parameter passed to them, if the respective vector was empty they would retrieve all the attributes. That functionality changed in #71 and it wasn't thought of to change the default parameter at the time.
   I'm not too sure about changing it now, retrieving the whole database from the peer by default is a huge resource drain for both energy consumption (bad for battery devices) and heap use. I think it would be better left to the user to make a conscious decision to do this, however I'm open to discussion. Perhaps @Jeroen88 would like to comment on this?

3. I could see something like this being useful but a more generic way would be to use the NimBLEAddress in the constructor (assuming 1 above is implemented as in my comment). This would allow for presetting the address in setup, perhaps from flash storage or hard coded, and calling connect() without the need to scan.

from nimble-arduino.

With regards to calling connect() without the need to scan, would this be a good time to look at introducing a non-blocking connect (with an isConnecting() method of course)?

from nimble-arduino.

@elguiri That would be a question better asked in its own issue, but the short answer is it’s questionable. Feel free to open an issue to discuss it.

from nimble-arduino.

Thanks for considering my suggestion.

I will add about 3.
Another purpose is to reuse the previous connection information when reconnecting after disconnecting.

I wrote a sketch example assuming that createClient(NimBLEAdvertisedDevice* device) and connect() were implemented
https://github.com/wakwak-koba/NimBLE-Arduino/blob/develop/examples/NimBLE_CatchNotifiesReConnect/NimBLE_CatchNotifiesReConnect.ino

1.Connect with isCanNotify device
2.Catch Notify
3.Attempt to reconnect when the device is disconnected due to sleep, etc.

from nimble-arduino.

About 2, maybe I do not understand the question, but the change not to retrieve all attributes on first call was made on purpose. The functions should remain the way they are now.

To get the requested functionallity is simple: get the pointer to the vector by calling the function without parameter. Call the function again with parameter 'true' if the vector size is zero. The first call is 'cheap': it just copies the pointer.

from nimble-arduino.

@wakwak-koba I looked at your example and refactored it a bit so you can see how you can currently do what you're looking for.

If we store the address type as in 1, the reconnecting will be easier.
catchNotify_reconnect.ino.txt

from nimble-arduino.

@Jeroen88

Thank you for reply.

Yes, because when the vector size is zero, that is, it has never been called in the past, there is no reason to work with refresh=false.

Whenever you call getServices() without any arguments, refresh=true is expected because it is expected to always be refresh=true.

On the other hand, if the vector size is not zero, I thought refresh=false would be desirable, where the programmer should decide whether to clear the cache.

@h2zero

Thank you for the sample.

However, getDisconnectedClient() does not serve its purpose....
When the first three connect and then two disconnect, the second will not reconnect unless the first successfully reconnects.
In order to solve it, there is room to consider whether to newly establish getDisconnectedClients()

from nimble-arduino.

Yes you are correct getDisconnectedClients() should return a count and new methods added to get them by index. I also think the client should have a reconnect method.

from nimble-arduino.

@wakwak-koba though I think it is a minor issue, but I still think you shouldn't change an api if not strictly necessary. Further more I think the default should still be false

from nimble-arduino.

Just merged PR #106 and PR #104 was merged a few days ago. Those PR's in combination implements this request with some minor changes.

from nimble-arduino.