Best way to determine if another Electron is online

Cloud
1

Hi Particle community,

I’m wondering what the best method is to check if another Particle Electron is online.

Our scenario: Sound an alarm if a separate Electron sensor unit goes offline for more than 60 seconds.

At the moment, I’m using a Publish & Subscribe to share the current time and then compare the difference in seconds at the alarm unit.

From our testing, I have found it to be semi-reliable - but I get the impression the device gets booted off the pub/sub system sometimes for sending too many publishes (given we are doing 1 every 5 seconds - it isn’t hitting the 1 per 1 second rule… but I suspect sometimes a few of these messages bunch up on the network (bit of speculation - but can’t seem to identify why else it would drop off)

I’m wondering if anyone has found a better approach?

Would greatly appreciate any tips, ideas or suggestions - thank you

2

What if you do a longer period for your publishes? 30 seconds?

1 Like
3

Thanks @nrobinson2000 - Good thought, alas I can’t up the polling rate too high - we have to build it to determine in less than 1 minute (ideally even lower than 1 minute, but data usage is holding us back) if the device has been destroyed, damaged or inoperable to trigger an alarm. Given it is being used for an active safety alert system, they need a fast reaction time. A 30sec polling rate would mean we only have 1 chance per minute to get the message before we potentially trigger a false alarm. (The last message sent on the 60seconds would arrive too late at the destination).

I have been playing around with publish rates between 5 to 10 seconds, we might now try up to 15 seconds- at leas that gives us 3 tries per minute to validate if the device is alive. (I say 3 instead of 4 …with the last 15 seconds in the minute I assume arriving too late at the destination device).

I have noticed though - have been testing most of today, we are getting alarms at 91 seconds. So some publishes, when sent at 10 second intervals are not arriving and there is a 91 second gap between. I’m assuming this is the time it takes for the device to reconnect to the cloud… not sure yet.

PS: Have also tried Particle.Connected() to change LEDs to indicate if the device goes offline -I found it to not always be accurate and only showed offline after significant periods of time being offline. I also wasn’t sure if it contributed to the ‘polling’ count, so have removed it for the moment.

1 Like
4

Is your device registered as a Particle Product or as a Developer device?
The 1/sec rate applies to dev devices, for products you have other limits according to your tier.

1 Like
5

Would greatly appreciate any other ideas and thoughts you or any one else may have while I test out the 15 sec publish rate.

I’m also yet to discover how the alarm unit is going to handle with 4-5 ‘sensor’ units pushing time ranges at it every 15 seconds.

Are there are limits to subscriptions other than just 4 per any given moment? I’m assuming I can push Time.Now() from multiple units on the same ‘Publish’ name and embed an identifier and with some creative String manipulation, decouple the two pieces of data on the other end.

6

Thanks @ScruffR - looks like you posted about a second before me.

I’ll move the device into the product list and see if I have any better luck.

I’ve been sitting next to it all day while I’ve been working and it has been going on/offline all day. I’m hoping this will fix it.

7

Dang, that time it lasted about 3-4 minutes before it dropped off the network. (LED flashed Cyan quickly). It was the ‘monitoring’ electron that dropped out. So not the one that was doing the publishes every 15 sec…

Then I got a message via web console that the device has come back online, when that happens - it realises the time range is out and fires off the alarm. (Good thing I disabled the audio while testing…would be deaf by now!)

Any other thoughts on trouble shooting why a device listening to subscriptions would be knocking itself off the network?

8

Are you using Particle SIMs or 3rd party?

9

3rd party with

 void setup() {
    //Cellular Settings
    Particle.keepAlive(120);
}

and I’ve also included the revised APN

//Cellular Settings
STARTUP(cellular_credentials_set(“telstra.internet”, “”, “”, NULL));

10

Subscriptions are not limited, only publishes.

With that keepAlive you should be OK, but you can always try 30sec to be on the safe side.

Is your monitored device using SYSTEM_THREAD(ENABLED)?

That would have the opposite effect. Free tier products (and even most payed tiers) have a more restrictive limit than non-product devices.

I don't see such behaviour on my devices, so I'd suppose it has to do with your code and/or external circuitry.
Any chance to give us more background in that?

11

Thanks for the suggestions :smile:

I’ll give the 30 second keepAlive a shot and see how it goes for a full day.

Oh, I miss understood your last message. Although now I think about it, I’m probably better off trying it in the product tiers as we’ll be moving into those quite quickly. But I doubt we’ll hit the top tier in the first few months.

I’ll PM you the code now too - cheers for looking at it!