What is the difference between a BLE central reading from a peripheral versus a peripheral notifying the central in term of resources drained?

[helpme]

Suppose a BLE central needs to get sensor data from 10 peripheral sensors. Given that there is a limit to the number of connections a BLE central can have, is it better for the central to read from peripheral because it uses lesser resources compared to notify?

[Hung Bui]

@helpme: Could you give me more information on why you think read command would use less resource compare to notify ?

As far as I know, sending notify is more efficient than read command when thinking of the number of packet needed to send data (1 packets vs 2 packet).

The only advantage of read command I can think of is that the client (central) doesn't have to wait for notification but has control of when to get it.

[EDITED] Another advantage of using notify is to avoid the delay by slave latency. The peripheral can wake up in the middle of the latency sleeping period to send notification, when with read, the central have to wait until the next wake up of the latency sleeping period to get the data which only comes on next connection event after the read command.

[Bill Siever]

Good points --- depending on what data is needed and why it is needed perhaps including it in the advertising would be a better option (which could use the long scan window and isn't at all constrained by the central's limitations on connections). Without knowing the specific use and requirements (Like: Is a lost measurement tolerable? How important is power on Peripheral vs. Central? What is the expected frequency of updates?, How many connections are expected? etc.) I don't think there's a clear answer that one approach is definitely better than the other.