Event publish periodicity change - after a certain time(?)

Troubleshooting
1

Hi,
I’ve got a photon logging temperature and humidity from a connected sensor. I’ve noticed a a step change in the period of the events after a certain time, seemingly regardless of the specified period.

The first test I have data for is a period of 5 s and after approx. 18 hours the period switches to a little under 20 s. Prior to this the events were received at approx. 5 s intervals.
The second test is less clear because I was having some connectivity issues, but period was 10 s, again the events were received as expected, but yet after a period they also changed to the same ‘a little under 20 s’.

Have I misunderstood how many events can be published / received? Did I miss something in the documentation?
I realise I don’t include code, nor concrete data, but wanted to check first before investigating further, in a location other than “off in the weeds”.

Thanks in advance

2

There is no such throttling that I know of.

For developer devices (no PRODUCT_ID set in code) the only limit is the 1/sec publish rate.
What might cause this issue is most likely related to your device and network not the cloud.

3

@ScruffR - thanks for the confirmation, and as I kind of expected.

My problem continues, but this time I had something simpler in place and it started not to work after approx. 2.5 hours.

Basic outline:

  • Three timers running - every 2, 10 and 60 seconds.
  • Meant to simulate actual set-up - first timer updates a clock model, second timer updates a display, third timer requests a check of the actual time. (The actual periods are a little different in the application, but not of consequence.)
  • Event published for each.

Observed result:

  • Everything works fine for just over 2.5 hours - events received as expected, via particle console observation and a local python script.
  • After this there are only two records of the first event every 15 seconds.
  • The photon is breathing cyan.

The code used is as below:

void displayUpdateCallback();
void timeSecondCallback();
void timeUpdateCallback();

uint32_t const TIME_UPDATE_MS = 0xea60;
Timer timeUpdateTimer( TIME_UPDATE_MS, timeUpdateCallback );

uint32_t const TIME_SECOND_MS = 0x07d0;
Timer secondTimer( TIME_SECOND_MS, timeSecondCallback );

uint32_t const TIME_DISPLAY_MS = 0x2710;
Timer publishTimer( TIME_DISPLAY_MS, displayUpdateCallback );

STARTUP( WiFi.selectAntenna( ANT_EXTERNAL ) );

void setup()
{
	secondTimer.start();
	timeUpdateTimer.start();
	publishTimer.start();
}

void displayUpdateCallback()
{
	Particle.publish( "display_update", PRIVATE );
}

void timeSecondCallback()
{
	Particle.publish( "second_update", PRIVATE );
}

void timeUpdateCallback()
{
	Particle.publish( "time_update", PRIVATE );
}

Any thoughts on what might be going wrong?
I can imagine there’s a network problem but would not have the best idea on where to look for the issue. So any advice here would be appreciated.

4

Another piece of information that may be potentially relevant:
With the photon in the state described as above, upon attempting to flash it with the same / a new binary results in a time-out. The photon is showing solid magenta.

I searched for what this means but couldn’t find it on: https://docs.particle.io/guide/getting-started/modes/photon/#troubleshooting-modes
However I did find an old post indicating that maybe it gets stuck on a packet: Solid magenta after a few minutes of flashing magenta?

5

How does the device behave if you move the publishes out of the timers and rather just set a flag therein which you service in loop() to do the publishing?

BTW, the way you are setting your time constants is somewhat unconventional.
I do use hex notation too, but not for numeric values easier perceived in decimal (60000 just seems that bit clearer when denoting 60000ms ;-)).

Just out of inerest, why are you using uint32_t const instead of the more commonly used const uint32_t? This makes sense with pointers but for trivial numeric types I don't quite see the use :confused: (although both renders exactly the same effect).

6

@ScruffR - I’ve reworked the application and now just testing it. Thanks for the idea.
Good point in regard to the use of hexadecimal for time values, this certainly doesn’t aid readability.
As for the location of the const keyword, this comes from a coding guideline I used to have to adhere to. The idea is that regardless of type of variable one reads right to left regardless. It’s certainly different at first, but now I’m just in the habit.

1 Like
7

Hi again,
Everything now seems to be working fine. No lock-ups / delays observed, indeed the receipt of the events timing-wise is now spot on, whereas before even when “working” there was some variability.
So an important point: really do treat the timer callbacks like interrupt service routines! :wink:

Anyway, for completeness here is the reworked test code:

uint32_t const TIME_DISPLAY_MS = 10000;
Timer publishTimer( TIME_DISPLAY_MS, displayUpdateCallback );

uint32_t const TIME_SECOND_MS = 2000;
Timer secondTimer( TIME_SECOND_MS, timeSecondCallback );

uint32_t const TIME_UPDATE_MS = 60000;
Timer timeUpdateTimer( TIME_UPDATE_MS, timeUpdateCallback );

bool timeDisplayFlag = false;
bool timeSecondFlag = false;
bool timeUpdateFlag = false;

STARTUP( WiFi.selectAntenna( ANT_EXTERNAL ) );

void setup()
{
	secondTimer.start();
	timeUpdateTimer.start();
	publishTimer.start();
}

void loop()
{
	if ( timeDisplayFlag )
	{
		Particle.publish( "display_update", PRIVATE );
		timeDisplayFlag = false;
	}
	if ( timeSecondFlag )
	{
		Particle.publish( "second_update", PRIVATE );
		timeSecondFlag = false;
	}
	if ( timeUpdateFlag )
	{
		Particle.publish( "time_update", PRIVATE );
		timeUpdateFlag = false;
	}
}

void displayUpdateCallback()
{
	timeDisplayFlag = true;
}

void timeSecondCallback()
{
	timeSecondFlag = true;
}

void timeUpdateCallback()
{
	timeUpdateFlag = true;
}

Thanks for all the help!

(I’ve since retrofitted this technique into the temperature / humidity logger and it’s been working overnight with no issues.)

3 Likes