Most recent activity
-
- 6 comments
- 1,376 views
-
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.
-
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.
-
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.
-
Thanks, I'll look into the process for using a dongle BT receiver on the Pi-Z-W.
Adding that would probably be the quickest and most effective solution in my specific case. Doing a mesh type model might be a good theoretical exercise for me to learn more but to get running quickly the antenna is probably easiest.
I think I am right on the edge. When I tried the same system model using a Pi-4 (more capacity than needed for this simple scenario) it seemed to perform a bit better. Maybe the Pi-4 internal antenna is just different enough from the Pi-Z to give me that little extra margin I needed.
Then again, a Pi-z with antenna might be equal in price to a Pi-4. Hmmm. I'll test with the 4 again to see how often that one is out of range.
-
Thanks, I'll get back this later and report out on my findings.
-
- 3 comments
- 833 views
-
FYI - to determine if both the system and my Mom are OK, I look at things like
- Temperature of the puck (higher when she is wearing it as opposed to lying on the counter top)
- Motion, obviously
- RSSI changes as she is in one room versus the other
- Presence, obviously
- Temperature of the puck (higher when she is wearing it as opposed to lying on the counter top)
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.