Repository navigation
Conversation
bootstrapRTCfromContacts() set the clock to the latest contact time even when the RTC backup had already restored the right time, so every reboot put the clock back to the last advert heard.
Contributor
dkuenzel
added a commit
to dkuenzel/meshcore-home-gateway
that referenced
this pull request
Nov 12, 2026
…154) * release: 2.1.1rc2, the radio's clock set back after MeshCore's jump The open point of 2.0.0 (design section 12), whether a restart of the radio at most once a day keeps its clock on the host's, checked against what MeshCore's issues show since: - On nRF52 boards without a clock chip the firmware's clock jumps 100,663.296 s ahead every 48.5 days of uptime, as millis() wraps at 2^32 ticks of 1/1024 s (meshcore-dev/MeshCore#3565; the fix, meshcore-dev/MeshCore#3595, is not merged, and 1.18.0 has the bug in ArduinoHelpers.h:15-19). The gateway refused to set a clock that far ahead back ("more than an hour"). Whole jumps, within 10 minutes and up to 8 of them, are no wrong host clock: they are now set back at once. - The radio stamps a contact with its own clock at every advert and message, and a restart starts the clock at the newest contact time (meshcore-dev/MeshCore#3050). The gateway waited until no contact had changed for as long as the clock was ahead, which after a jump never comes. Before the restart it now reads the contacts again and writes back each time stamped ahead, as far back as the clock is ahead and at least 3 s behind the host's; ADD_UPDATE_CONTACT takes the time as its last field (MyMesh.cpp:194-215). A refused write stops the restart. Tests: the session against the emulated radio, which now takes a contact's time as the firmware does; the codec's frame; and on the real firmware a clock a jump ahead whose contact time an advert stamped ahead. Each new session test fails without its part of the change. doctor and the dashboard's clock card name the jumps beside the hour, with their German texts. design section 6.1, protocol.md section 5 and the guides follow; section 12 names what MeshCore has open: meshcore-dev/MeshCore#1349 and meshcore-dev/MeshCore#3195 would let a client set the clock back, meshcore-dev/MeshCore#3741 would stop the start from setting it back and so end the restart's effect. The drafts for MeshCore were checked again: no release after 1.18.0, neither main nor dev changes the code they cite, and nothing is raised on acknowledgements or the ADVERT push. Setting the clock back is requested already, so that draft became a comment on meshcore-dev/MeshCore#3195. The program changes after 2.1.1rc1, so 2.1.1 now ships this candidate's program, after the maintainer's use of it. * release: 2.1.1rc2 dated the day of its merge CI on the runners could not resolve Ubuntu's package mirrors from 2026-11-11 16:03 UTC for some hours; the merge moves to 2026-11-12, the day its tag is due (docs/development.md, Release). * fix: the clock a restart starts at a time written back is set forward The firmware test of the jump found the radio 2 s behind after its restart, and left there: B's advert came a moment before the gateway connected, the time written back was capped at 3 s behind the host's, the restart started the clock a second later, 2 s behind, and the simulated radio was back within a second. 2 s is not more than CLOCK_SET_THRESHOLD_S, so the next connect did not set it forward. The cap is now 4 s behind: the clock starts more than the threshold behind and is set forward however soon the next connect comes. A session test with a contact stamped this very second fails with the 3 s cap. --------- Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello all,
bootstrapRTCfromContacts()sets the clock to the newest contactlastmod+ 1 at every boot, even when the clock already has a later, correct time. On ESP32 boards without an RTC chip,ESP32RTCClockrestores the time from RTC memory after a reset, then the bootstrap moves it back to the last advert heard. The app can't fix it becauseCMD_SET_DEVICE_TIMErefuses to go back.Seen on a ThinkNode M5 with v1.18.0: each reset put the clock about 8 hours back. With this change it keeps the right time across resets. Tested on the M5 with v1.18.0, builds on dev.
Future
lastmodvalues (#3050) are a different case, handled by #3534. Both changes can go in together.