Anyone know how to monitor a pre-determined MQTT topic and basically retransmit anything received on that topic using Particle Publish?
More Info
I already use MQTT on this Photon but it only searches the payload of the messages to check if the payload matches certain predefined values and takes different actions depending on the payload.
I want the Photon to continue to be able to do that but also monitor a specific additional topic and retransmit the payload out on Particle Publish
Why? Iām sending out a Unix timestamp on the local network using MQTT and want to retransmit the timestamp to my Cores using this Photon to set accurate time. There seems to be a bug with the Particle cloud and Cores whereby the time sync isnāt at all accurate.
Of course thatās possible.
You are already subscribing to the MQTT topics which will then trigger the callback, right?
Inside that callback you can check for the special topic and when found execute a Particle.publish() - not sure whatās not clear about that
However, the latency for receiving the MQTT message, āre-transmittingā and receiving it again will need taking into account whereby itās somewhat non-deterministic.
So you need to convert the received const char* to long int.
There are multiple ways to do that (e.g. atol(), strtol(), sscanf(), ...) which have been used all over the place in this forum already
Once you converted that string into a number you can use it as needed.
OK, thanks, Iāll do that - what I was observing was that my code was working but there was a consistent four second inaccuracy. OK, I thought, I know how to deal with this! So I did val = val + 4; but that hasnāt changed a thing, which I thought surprising. Still the same 4 second inaccuracy. Anyway four seconds I can live with!! haha
But irrespective of the root for the offset, you may want to look at what the Time.now() gives you after you tried to set it via Time.setTime().
This should give you some feeling what may be happening.
Firstly, at this point, this is purely āacademicā - Iām more than happy with a few seconds of inaccuracy - thatās fine.
That said, do Time.now() and Time.timeStr() use the same data/source? And do they perhaps only update once per loop or similar? Because Iām doing this:
void eventHandler1(const char * event,
const char * data) {
{
if (strcmp(event, "TIME") == 0) {
long val;
long val2;
val = atol(data);
val2 = val + 4;
Time.setTime(val2);
Particle.publish(DEVICE_NAME, Time.timeStr(), 60, PRIVATE);
}
}
}
and Iām finding that the Particle Cloud even though itās given a Unix timestamp, doesnāt seem to apply it properly - OR some kind of lag in the Core itself causes it to be applied but with the introduction of a couple of seconds delay.
Just to reiterate - this is academic and I am not bothered about improving the accuracy resolution of the time, just interested in understanding it.
Yes they do, but Time.timeStr()also takes Time.zone() into consideration, Time.now() does not. Time.local() would give you the same kind of data as Time.now() but also accounts for Time.zone().
The time is updated at the rate of the HW RTC. When you set the time you will place the new value in the RTC and it will then "accept" that value when it's safe to.
If you want to know what's going on with the RTC after you set the value it's no good to check in console as this will always add the extra latency you have no control over nor can exactly determine how big it actually is.
You need to go as close to the source as you can (e.g. Serial.print()) .
What you see in console can only be the time on the device when the event was sent off.
I'm not sure whether the "PUBLISHED AT" header in console is not misleading and should rather be "RECEIVED AT".
BTW, 1616754941 may be representing exactly 10:35:41 but being an int type you can never know whether the actual time was 1616754941.000000 or rather 1616754941.999999.