I was recently told by the Particle support team that publishing an event from from Electron and having a second electron subscribe to it was not the most sure way of having the message delivered. Instead they suggested that I use webhooks with a 3rd party web service which I have since then.
So now, Electron 1 publishes an event to a webhook which makes a POST request to a database on my web service. My web service stores the data to a database and then sends the contents of the original message as the response to the original webhook which then gets pushed to an event that Electron 2 is listening on. And thus, Electron 2 gets the message that Electron 1 sent. And it’s also now stored on my server.
Can someone please verify that this is a more reliable solution for sending a message from one electron to the other? Because to me, this sounds like the same technology being used on the Particle cloud to actually send the response back down to the second Electron as my first example.
Also, if I independently publish an event from my web service to an Electron subscribing to that event, will that be as [un]reliable as my first example of pub/sub between two Electrons? I’m guessing the answer is yes for the connection between the cloud and receiving electron.
Is there a better/efficient way to be doing this? Any help is much appreciated!
Hello @pwewegama, my opinion is that when you are running the web service that stores the data and then sends it to the second electron you can somehow verify that the electron received the event, either by making the 2nd Electron publish another event acknowledging it (best in my case) and using a webhook to make another POST to the database or even posting directly from the Electron to your webservice, where you can flag the message as “delivered”… If you don’t get that acknowledgement then you know something went wrong and can act depending on how you want to handle.
Few examples:
Report it to the first electron (if it’s useful)
Retry X amount of times after X seconds/minutes/hours
Right now Particle’s platform doesn’t have the capability to retry sending a message to a specific device or the Electron can’t view past events in the case that it goes offline.
You are right: the fact that you are still using events to communicate to the 2nd Electron, is the same technology… But now you have that event stored where you decide what to do when something goes wrong. Without you storing that data the event will be lost forever if it’s not received by the 2nd Electron.
If you are able to tell us how critical those events are and your use case it might help us to direct you.
I guess this is a matter of wording.
I'd say for the case that both Electrons are permanently online, the most reliable way would be a direct publish/subscribe connection between the two with an acknowledge public/subscribe the other way round (like @Iv4n suggested already) and a resend if the ack doesn't arrive in time.
This cuts out the extra piece(s) in the chain that could break.
But if you can't be sure that both devices are online at the same time, you need someone in the middle that is always online to bridge the gap again with publish-receive-ack and back for both devices.
So I guess that was part of the discussion with support that lead to the above statement.
Just by itself you can't say the one is better than the other - the use case calls for either ... or ...
@ScruffR, @Iv4n - Thanks guys, this helps validate my assumptions. I was planning on sending Acks and checking at some interval for any missed messages and making them as complete afterwards.
Does 6-10 seconds for that trip from Electron A to Electron B using the architecture we described sound about right to you? Sometimes it’s 20+ seconds because I don’t think that the Electron is really ALWAYS listening with its CoAP over UDP protocol. Am I right to assume this?
The latency isn't always predictable, but it should be nearer the 5sec and if it's longer it's usually not due to the Electron system not listening but rather because connection as such is flaky or your code might occupy the µC some periodes which may delay the serviceing of the subscription handler.
For the latter you could use SYSTEM_THREAD(ENABLED).
For the former you can't do a lot, but the system tries to publish up to four times to get the event sent (without the NO_ACK flag set) which might add some time to the round trip (either side). You should check the return value of Particle.publish() tho'.
Thanks for that! And I know it's definitely not my code because I've tried decoupling the problem by just running a minimal piece of code on the µC that has a Particle.subscribe() to a hook response in setup() and a Particle.publish() to that hook happening every 10 seconds in loop()...pretty much the sample code they give you when you create a Webhook. And the time for a trip can still vary like I described...any way I can check to see what the 3G signal strength is?
I've tried SYSTEM_THREAD(ENABLED) in the past and it's resulted in a very difficult time when it came time to upload new firmware once a piece of code that had that line at the top was already running. It's like the entire Electron just stops listening to things like "holding Mode button down" to put it into firmware update mode. Have you had similar experience?
Any tips you can offer?
I've initally also had the feeling my OTA updates didn't work, but it actually only was my on impatients.
After the magenta blinking and a short RGB LED off, the original code still kept running for a few seconds, and since the new behaviour was not exposed, I tried a reset but still had the old code on the device.
But then I just got more patient and waited for a while and saw another RGB LED off and after that the new code was running - every time.
And for wired updates, I never use particle flash --serial (in Listening Mode) but onlyparticle flash --usb (in DFU Mode) - it's just that tad more reliable and gives me explicit feedback if something goes wrong.