I’ve not had any success with the built in Particle time sync maintaining accurate time on a daily, weekly, monthly basis.
Could I set time from a ‘master’ device on my network sending an MQTT or Particle Publish message at 12:00 and when it’s received by the Photon or Core, the Particle device would set its internal clock to 12:00 ?
I’m aware the above process is not infallible and does not have the built in NTP safeguards etc, but I’m willing to risk it.
Are you saying that Cloud time sync isn’t working? There may be an issue with the RTC on your Photon. I have not seen such an issue with near enough 1000 Photons.
How are you doing the time sync, using time and how often are you re-syncing?
Perhaps you could share the code that isn’t working.
Gen3 devices are a different matter - there is no RTC and thus an add-on is required which needs to be synced - with a device on mesh only this then requires a time sync service.
thanks armor. So, at 21:55, I set my Core to update its time. I know this code executed 'cos the sound file (mp3 5) played.
void SyncTime() {
time_t lastSyncTimestamp;
unsigned long lastSync = Particle.timeSyncedLast(lastSyncTimestamp);
unsigned long cur = millis();
Particle.syncTime();
// Wait until Core receives time from Particle Device Cloud (or connection to Particle Device Cloud is lost)
waitUntil(Particle.syncTimeDone);
// Check if synchronized successfully
if (Particle.timeSyncedLast() >= cur) {
// Print current time
myDFPlayer.playMp3Folder(5);
}
}
however, the next queued event, for 22:00:00, happened thirty seconds early, at 21:59:30. Again, I use time.is for an accurate reflection of the current atomic time. My computer is also in sync with time.is because Apple’s OS X NTP updates are in sync with time.is.
EDIT: There is an internal RTC in the STM32F103CB on which the core is based - so this is unlikely to be the issue and therefore as you state below must be related to code - if possible, share the whole app (or at least as much as presents the error) and I will test on my core!
Hi Shane - thanks, but that’s not the problem. The problem is that Particle.syncTime() which is being called daily, isn’t having an effect, probably due to my code! The Core’s software ‘clock’ only drifts at most a second or two a day. Thanks
In the meantime, does anyone know if I could set the time via an MQTT message sent from a server at (for example) 18:00?
Message sent with predetermined payload, received at 18:00 = Particle devices updates its clock to 18:00?
I realise there would be a couple of seconds (or possibly much worse in certain circumstances) deviance from atomic time with this method, but at the moment, it’s much, much better to what I have not working as things stand.
Exactly.
Unless you don't care about the date whatsoever. If you only want to implement a clock which doesn't care about the date noone would ever know if it's showing 18:00 of January 1st 1970 (64800) or the current date (1567965600) - the time portion of both will be 18:00:00
However, the MQTT even source would probably know the date and hence adding it shouldn't pose a problem.
So an approach I use is to use the internal time capabilities of the particle device to get time from particle when connecting (and it maintains it pretty well if a few seconds don’t matter) . If there is a display attached that needs local time - each device has an attribute saved that I update via MQTT when the device initialises and connects to the MQTT server - so it can show time local time on display but still send all timestamped data as UTC.
I'm using Cores as well as Photons and the Cores don't maintain time at all well. I've never managed to get a loop time sync to take (other than the initial setup one). (Did you get my email?)
I'll see if I can bodge together an MQTT unix timestamp time sync
Random thinking here - if you retrieved a web page with the core - the header has the time in it. Might be lighter than using MQTT (unless you need it for something else …)