I have a very simple application. One Argon is acting as Internet gateway and a bunch of Xenon devices are measuring data and should send that data to the internet. It’s not a “real” mesh because the Xenons are in deep sleep for 60 minutes and only wake up for a few minutes to measure and send data, then they go back to sleep.
As far as I understand, I have 2 options:
a) The Argon can be a “dumb” gateway without any actual functionality. The Xenons will directly connect to the Particle cloud through the Argon and will be able to call Particle.publish.
b) The Xenons can collect their data and only use Mesh.publish. The Argon is a bit less “dumb”, listens to that data and sends it to the Particle cloud on its own.
What is the more efficient solution? What are the pros and cons of each?
Apologies for brevity I am typing this on a phone.
I think you are asking the wrong question. The choice is between a simple setup on the Argon which is a silent gateway (the device OS handles everything for a Particle Publish) and a more complicated solution on the gateway and the sleepy endnodes. If you want to manage your endnodes - monitor battery, and crucially sync time then you need a more involved solution on the gateway and on the endnodes. Deep sleeping on the endnodes is only possible using a RTC with an interrupt and alarm function. I can’t give you the link now but find the project share/tutorial from rickkas about Fram and RTC.
Thank you @armor. I already have nodes setup with an RTC. They do their own battery monitoring with an external fuel gauge and publish that information to the cloud. They also sync time to the RTC from the Particle cloud.
I currently have a type (a) setup – the Argon is a “dumb” gateway and the nodes are directly publishing JSON data using Particle.publish.
I don’t think I’m asking the wrong question but currently I don’t see a huge benefit of (b) as opposed to (a). Thus my question.
Note: currently there might be a benefit because the Xenons sometimes have trouble connecting to the internet. This might be because of the way my home network is set up and will probably/hopefully be solved by a firmware update.
If you don’t intend to have the Argon aggregate and/or compress data before submitting it to the cloud, I’d go with Particle.publish() on the Xenons. This way you could also check successful delivery of the event at the source of the event (aka the Xenon).
I'm trying to find the benefits (or drawbacks) of Mesh.publish and a more complex code on the Argon however.
Compression and aggregation are both good points I have not thought of (mainly because it's not a lot of data yet). One thing I have thought of (and which is currently handled in a web application) is checking if any of the nodes are no longer checking in. This is something that could be handled on the Argon and which could be visually represented to the end user.
Is Mesh.publish faster? Will it save power on the Xenons?
A single Particle.publish() on a Xenon will cut out some overhead compared to a chain of Mesh.publish() -> Mesh.suscribe() -> Particle.publish().
With the latter, your event would need to be exposed to the application in order to link the steps. When your application is not really interested in any of the intermediate steps the device OS can do all that invisibly/transparently for the application in the background.
Sorry I didn’t explain myself- brevity! What I was trying to express is that there is a lot of complexity with a mesh pub-sub that isn’t there with the Particle.publish from the endnode. If you want to have a guaranteed send mechanism then you need a send buffer and retry - in case a. on each endnode rather than once in the gateway but that is not too much of a problem.
Mesh.connect is much faster than Particle.connect and uses less power but best to design for integrity of data first and then optimise power consumption.
So only network problems are something that could be mitigated by a Mesh.publish as opposed to a Particle.publish (the Argon never loses its Internet connection but the Xenons currently fail to connect 4 out of 5 times – probably because of IPv6 on the network).
Am I correct in assuming if that if the Xenons never connect to the Particle cloud, they can also not receive firmware updates? And System.updatesPending() is only available for products, right?
As I have been expanding on the initial answer - a mesh with endnodes and gateway solution using pub:sub is a lot more development and testing work. Thus going back to your original question - which is more efficient - that depends upon what you are trying to optimise! If it is your time then go with a. If it is endnode battery life then b.
To answer your question about OTA updates - I have a command that the gateway acts on to wait for woken endnodes and to tell them to breakout of their normal sleep cycle/sensor reading duties and Particle.connect and switch on OTA / pull a queued update. You can set up a product for free if you want to take advantage of the functionality clearly only worthwhile once you have many devices.
I’d say the efficiency for development is better when you use the xenons connecting directly to the cloud, so they can also receive pending firmware-updates, the downside is that they are longer awake, so they consume more power and produce more data-overhead, but that shouldn’t be a problem, when there’s WiFi available. The plus for me would be that I only have to maintain one firmware, and the gateway could maybe easily act as an additional sensor-node (because it has nothing else to do). I also think it might not be that critical, that all nodes are time-synced, they just publish their data when they are ready, so the gateway doesn’t have to wait for all nodes to send their stuff before he’s transmitting the data to the cloud.
The only scenario I would more likely choose the „smarter gateway“ option is, when there is a limited cellular data-budget and you have many nodes, so the gateway could collect all data and send it all together (and/or maybe less often).
I’m no professional, just some practical thoughts …
Actually they don’t receive pending firmware updates. They have to be online the moment you press the flash button which makes flashing them kinda awkward.
…