Disable automatic publishing of device events?

Cloud
1

Does anyone know a way to stop a Boron from automatically publishing the particle/device/updates/forced or particle/device/updates/enabled data? It’s not really critical, but I’d like to not have a ton of useless (to me) data cluttering up my events feed on the cloud console…

2

Glad I’m not the only one! Since updating my Electron to 1.2.1 these two events publish up to every 5 minutes, although sometimes less… I have no idea what triggers it and it appears to be undocumented. Really need a way to turn this off.

3

I would be interested in this also…

4

Same experience with the Photon. I’d be very much interested in the solution too. Thanks

5

We’re starting to see these on our integration webhooks - which is erroneous (I think) as they are now being raised on a webhook that’s only for specific events, and they are getting passed through to our web service endpoints which then spit them back out and complain in our web logs on our service endpoints.

Any determination as to what’s going on here? They are becoming a real problem.

6

I have the same question but see no answer… tiresome

7

Same here, data usage is up around 50% for some of my devices on account of these events. Using OS V 1.4.0
Has anyone found where in the OS these are generated?

8

If you go to https://docs.particle.io/reference/device-os/firmware/electron/#particle-publishvitals- you’ll see what you need:
Particle.publishVitals(0); // Publish immediately and cancel periodic publishing

1 Like
9

That worked, thanks!

1 Like
10

I’ve tried messing around with the publishVitals settings but it’s still publishing these events every time my electron wakes from sleep (it’s only sleeping for 10-60 seconds), is there some other setting I’m missing?

11

If you are sleeping for less than 10 minutes you should always use stop mode sleep with SLEEP_NETWORK_STANDBY. This leaves the cellular modem on, and when waking up from sleep mode, execution continues on the line after the System.sleep call with local variables still set.

The reason is that without SLEEP_NETWORK_STANDBY, the cellular modem will reconnect to the tower each time (technically, establish a PDP context). If you aggressively reconnect, your mobile provider may block your SIM from reconnecting to the cellular network. If you sleep for at least 10 minutes on average you’ll be fine.

Using stop mode sleep (pin + time) with SLEEP_NETWORK_STANDBY:

  • Does not publish vitals on wake
  • Allows for short sleep durations
  • Very fast wake with no blinking green phase
  • Allows for short wake/publish/sleep cycles (under 2 seconds)
2 Likes
12

Sorry I should’ve said that I’m sleeping with SLEEP_NETWORK_STANDBY, but I am using the ‘classic’ sleep format as I can’t seem to get the new SystemSleepConfiguration to work?
Here’s what I’m currently doing:

System.sleep(WKP, RISING, sleep_for, SLEEP_NETWORK_STANDBY);

When I try:

....
SystemSleepConfiguration sleep_config;
sleep_config
    // STOP + NETWORK_INTERFACE_CELLULAR equivalent to SLEEP_NETWORK_STANDBY
    .mode(SystemSleepMode::STOP)
    .network(NETWORK_INTERFACE_CELLULAR)
    // in milliseconds but on Gen 2 (electrons) can only sleep in whole second intervals
    .duration(sleep_for * 1000)
    // not used but must be specified
    .gpio(WKP, RISING);
SystemSleepResult result = System.sleep(sleep_config);
Log.info("Sleep result: %d", result.wakeupReason());
Log.info("Sleep error: %d", result.error());
...

The errors I’m getting are:

0000029084 [app] INFO: Sleep result: 0
0000029084 [app] INFO: Sleep error: -120

I’ve had the same results for the vitals and new sleep with OS v 1.5.2 and 2.0.0. I wasn’t having the vitals problem before OS V 1.5.2?

13

Error -120 is “not supported.” I’m not sure why you’re getting that error with the new interface, but I also realized I didn’t scroll all the way to the top and the events you were interested in are particle/device/updates/forced and particle/device/updates/enabled, which cannot be disabled, so the sleep API and SLEEP_NETWORK_STANDBY won’t make a difference for that.

14

@rickkas7 Don’t those system event publishes cost significant data though? I did some quick math and figured that if I had a (measure > publish > sleep 10min > wake) cycle on the device, those system event publishes would cost you 1.5MB / month.

My assumptions were that:

  • {“particle/device/updates/forced”:“true”} publish event is ~ 170 bytes.
  • {" particle/device/updates/enabled":“true”} publish event is ~ 171 bytes
  • 10 minute interval data
  • 144 of each of these system events per day, 4320 per month
  • 4320 / month * 2 system messages @ 170 bytes each = 1.5 MB/month

I’m testing with the newest production version 2.0.0 on E402.

Example of these system message in my console:

image
image1538×1468 232 KB