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.
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.
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.