Most recent activity
-
At this point I am nearly ready to throw in the towel and just create an nRF Mesh with the Sengled lamps. Easy, done.
Then use the nRF DKs to burn a Bluetooth Mesh Lamp Switch sample to the DK. Easy, Done.
Used the DK and SWD interface to send that same program with a new board style to the Feather. Easy, Done.
And..... throw the puck.js devices back into the junk drawer?
They are such nice hardware devices but I just can not figure out how to get them to do what I want then to do. Just turn the darn lamps on and off.
Productizing for the mass market takes a lot of engineering.
-
On my Sengled lamps, I can use their app to connect to the lamps and turn them off and on, easy peasy.
But... the Sengled app does not give me any engineering data such as device addresses or attribute stuff.
I can delete the lamps from the Sengled app and use nRF Connect to see what that can find...
-
@Gordon , this conversation and other jig discussions seem very old. I have a SWD breakout board from Adafruit https://www.adafruit.com/product/2743 and only want to program a couple of boards from the nrf52-DK. I have already done similar with other boards such as the https://www.adafruit.com/product/4062 .
The lab bench stuff works fine with the Feather but I would like to use some of these unused Pucks I have lying around.
I'd even be OK now with having someone else help me hold some wires against the SWIO and SWCLK flat pads on the puck.
Do you know what pins I would need to connect (manually or via jig) to program from the DK?
SWIO/SWCLK
GndDet / Gnd / Vref?
Thanks for any help. This type of stuff tends to sit around for years until I get back to some need. I just want a puck to turn on some Bluetooth Mesh Lights.
I used nRF Mesh on my phone to create a mesh of the lamps and programmed my DKs and Feathers to be a mesh light switch. That works.
I read that I should be able to find the regular gatt attributes/characteristics and bang away at that directly from a simple puck.js program but I could never diagnose what the attributes and values were in my Sengled Lamps. My tech terms could be off.
It really shouldn't be this hard but hacking is such as it is.
-
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.
-
- 6 comments
- 2,064 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.
Video of mesh with two lamps (I took the third lamp out of the network to try to get more old-school BLE to work).
https://youtu.be/exl_n-F5o-s
By the way, my two Thingy:52 devices are now paper weights because the batteries no longer charge. They are three-wire batteries and I don't want to spend over $10 each to replace them. I have five pucks that are not being used that I am trying to make work with my Sengled BT lamps.