You are reading a single comment by @Joakim and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@Joakim
@Gordon Aha, I see. Good to know.
About your suggestion here, I didn't know that a constant BLE connection used so much power. I assumed that since it's no longer constantly advertising it would use less power, but one should never assume. Again, should've RTFM :)
As it is, my current code does keep a constant connection. The node script scans for the button and connects to it as soon as it's found, returning to scanning again if the connection is dropped. When connected, it listens for data sent over the UART BLE service. It's unfortunate if that drains the battery, I'd like it to last as long as possible, this being a button that gets pushed only once a day :)
I looked into having the Puck be the central and the node script the peripheral with
bleno, but seems like that puts the heavy lifting on the Puck side? I read an article on making the most out of BLE's advertising mode, to create very low-powered sensors that transmit data using only advertisement packets – unidirectional broadcasting to any listeners.Would it be a good idea to have the Puck listen for a button push, and only then advertise the button push event (for the Node script to pick up), before going back to idle? Or maybe add a confirmation step by waiting for the node script to connect after receiving the advertisement and then immediately disconnecting again (with a timeout on the Puck)?
In general, what's the best way to have a Puck send an event to a node script, with long irregular intervals between each event, if one wants long battery life? I don't mind having the node script continuously scanning/listening, I'll use forever to make sure it always runs.