Hi. I am thinking to use puck.js for a project in uni and I'm new to all this and would like a little help. What I'd like to do is to have two or three puck.js that will be used to control bluetooth devices (light bulbs e.t.c.) and report temperature and things like that. One of the puck.js will be connected to a Raspberry Pi Zero W to upload data in Firebase to be used in a web app.
What I'd like to know is if it's possible for the puck.js to transmit data between them until it reach raspberry (and so that they have the same data on them), if we suppose that some of the puck.js are at some distance and could not establish direct connection with the raspberry? This would also make it possible to connect directly from the web app (when offline with a progressive web app and service workers) to the nearest puck.js and since all of the puck.js will share the same information, changes can be made and applied to all of them and stored to the raspberry also to update Firebase, right?
Of course the data that will be shared will be mainly one variable (on/off), temperature and generally small in size, and the system doesn't need to respond instantaneously to each change. So is this doable/viable with puck.js and raspberry? Thank you.
a good overview of Bluetooth Mesh – https://github.com/NordicPlayground/nRF51-ble-bcast-mesh/blob/master/docs/how_it_works.adoc
there are also a set of articles on bluetooth.com regarding Bluetooth Mesh, eg https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works/le-mesh
I didn't see an implementation for Puck.JS yet, but I am interested too as I have two Puck.JS that I want to put them to work ;)
Hi! As @tbd says there is a standard for this, which Puck.js doesn't implement yet.
However that doesn't mean you can't do it yourself - you can use advertising packets.
You can set each Puck to use NRF.findDevices(...) every so often, which will look for the advertising packets of other Pucks. You can then scan through those and aggregate all the data you see, and can use NRF.setAdvertising to then update the Puck's own advertising packet to reflect that data. After a while, all the up to date data will trickle through the system.
How often/how long you scan for is a trade-off on battery life, but 1 second every minute should still be pretty good and should make it last for a while.
At the Raspberry Pi Zero W end you've got Bluetooth LE already, so all you need to do is read the advertising packets it receives and you're sorted.
You might need a little thought on how to make sure you always have the most up to date info on the Pucks (each Puck that generates data might want a 'version' byte?). But honestly if you're doing this for a Uni project it gives you an interesting problem/solution to write about :)
Thank you for the replies. I think Bluetooth Mesh is more on less what I have in mind but hadn't read anything about it. I'd do some reading of what tdb linked above and see what can be done. Indeed the 'version' issue can be tricky, but you are right, there is a solution to be found for every problem. Thanks again and I may bother you again soon with a question or two :)
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem