Bluetooth Mesh Network to cover puck.js movement through larger areas

Getting this thread started in case there are others out there interested in this.

I'll post my progress here and hope that others want to play along.

Just out of curiosity, are you doing this to learn about Bluetooth Mesh, or do you actually have a large area you want to cover? If the latter, how large is it?

My goal was to learn more about BT Mesh while gaining the extra range of puck coverage.

I think my range was limited by the possible low antenna performance of the pi-zero-w computer that was hosting the BT/MQTT Hub service.

From what I have learned so far about BT Mesh is that all of the devices in the mesh need to be playing along with the new mesh protocols. It is not a transparent extension mechanism for devices.

This means that in order for the puck to become part of the mesh network it has to use the mesh protocols.

Following up on the last part of the above post...

The Puck.js product seems to be the marriage of excellent hardware design && the Espruino javascript interpreter that is flashed onto the hardware. The combo gives the great solution that we have all been enjoying.

In order to move to the BT Mesh tinkering it seems that one would need to take the puck hardware and flash a totally new firmware to it using the Zephyr ecosystem tools. The Nordic chipset seems like it would be compatible.

Not sure I want to go there now but I will continue looking into it.

I think you can get a Bluetooth Mesh stack that isn't based on Zephyr.

However this has been covered a few times on the forum but as I understand it Bluetooth Mesh is designed primarily for smart lighting. As such the mesh nodes have basically limitless power, and the mesh is designed around mesh nodes listening all the time which takes around 12mA of power constantly.

Maybe the situation has changed now, but it'd mean that for a Puck to be a fully-fledged mesh node the battery will only last 1 day.

BT Mesh can still communicate with non-mesh BLE devices though, so there's no reason a Puck can't be controlled from a BLE mesh. I'm just not sure it makes sense for it to be a node

The models that I am reading about is best visualized by the smart light example.

In that scenario, the lights have unlimited power and form the backbone of the mesh but there are BLE devices that are low power and wake only when programmed. In the lights model they often use the switches as the battery powered BLE activator of lighting control messages.

The Mesh model has a concept of "Friend" nodes where the friend node acts like a queue for their respective registered BLE friends. When the BLE wakes, the friend gives it all of its queued messages. With security being a big part of the Mesh specs, there are keys required to participate. BLE devices have all of their messages queued by their friend and if there is a key change they get their queued key messages and can still participate.

In my Puck model, I would have several (depending on the area desired to cover) powered nodes. They could be anything from small dev boards to smart lights. They would form the backbone of the mesh.

The pucks would then wake only when programmed and grabbed their queued messages (actions, mgmt or security messages)

This whole concept has now become a learning exercise for me. I bought a few Mesh devices to start my experimentation and will then take one of my four pucks and try to reflash it be a Mesh device. Worst case, I ruin one puck. Best case is that I learn a lot about Mesh :)

edit - yes, there are proxy nodes that can let standard devices participate in the Mesh. I just haven't gotten to that part yet.