[bbangert]

Summary

Found on hardware: the Pi boots with its clock at the system image's build date (2026-08-23), and nerves_time steps it forward shortly after boot. A boot trace (polled every 2 s) showed the OS clock already correct by 17 s of uptime. The Resolver's last_seen, though, stayed on August until about 62 s. ERTS updates System.time_offset only when it detects the step, about 45 s later, and last_seen was converted with that offset. The Bluetooth page showed "Seen 71 d ago" for about a minute after every boot, and HA's "Last seen" sensor got the same wrong time.

• A new UniversalProxy.TuyaMesh.WallClock converts monotonic to wall clock with System.os_time - System.monotonic_time, the same clock DateTime.utc_now/0 uses. The offset is rounded to whole seconds so read jitter can't cause republishes. The Resolver (last_seen) and MeshSync (live_of, for the HA timestamp sensor) both use it, so the 5 s tick corrects last_seen within one tick of the step.
• The Resolver also monitors time-offset changes (:erlang.monitor(:time_offset, :clock_service)) and republishes on them. That covers an idle mesh, where nothing ticks.
• A :time_offset_fun option makes the conversion testable.

Test plan

• mise run test: 2399 passed. New: a tick-only test (the OS offset steps and the next tick republishes the corrected last_seen), a :CHANGE-only test (periodic publishing disabled; fails with the handler removed), and WallClock unit tests.
• format, compile --warnings-as-errors, credo --strict, dialyzer, Argus (0 new)
• HW: reboot the Pi and poll; last_seen is never more than one tick behind the OS clock

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The test’s recurring timer can mask a missing :CHANGE handler or race with status flushing and cause timeouts, so it does not reliably verify notification-triggered publication.

1 open issue

• Disable periodic publishes when testing the CHANGE handler · New

What changed in this PR

Updates the Tuya mesh Resolver to refresh wall-clock last_seen timestamps after clock adjustments, correcting stale values shown in the Bluetooth page and Home Assistant after boot.

Changes:

• Monitors Erlang time-offset changes and republishes updated mesh status.
• Adds an injectable time-offset function for testing.
• Adds a regression test simulating a 71-day clock step.

File	Description
test/​universal_proxy/​tuya_mesh/​supervisor_test.exs	Tests timestamp correction and status publication after a simulated clock step.
lib/​universal_proxy/​tuya_mesh/​resolver.ex	Handles time-offset notifications and makes timestamp conversion testable.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Stateless offset rounding can turn boundary jitter into alternating last_seen values, triggering unnecessary broadcasts and Home Assistant updates without a new report or clock step.

1 open issue

• Rounded clock jitter triggers spurious status updates · New

1 resolved since last review

• Disable periodic publishes when testing the CHANGE handler

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The remaining Pi reboot check must validate hardware-specific OS/ERTS clock divergence and confirm Bluetooth UI and Home Assistant timestamps recover within one tick after the actual nerves_time clock step.

No open issues 🎉

1 resolved since last review

• Rounded clock jitter triggers spurious status updates

_{Review effort: Balanced}