Giving panels a real clock (for media player progress, log timestamps, and more)

[jamesmulcahy]

Hi Tim,

I'd like your view on a direction before I build anything.

Motivation: media player position

I'm adding a progress bar to the media player page. To move it along correctly, the panel needs to know where playback is now, not where it was when the last state arrived. There are two ways to get that:

1. Frequent position updates pushed from the manager while something plays, every second or so. That's a lot of MQTT traffic and protobuf encoding for every playing player and every panel watching it, just to animate a bar. I'd rather not.
2. A timestamp to count from. This is how Home Assistant itself represents it. A media_player doesn't report position continuously. It reports media_position plus media_position_updated_at, and only updates them on play, pause and seek. Anyone displaying position computes media_position + (now - media_position_updated_at).

Option 2 maps directly onto HA's model, and I have a manager branch that passes those fields through to the panel. The catch is now: the panel has no wall clock. The panels' state is also retained, so a panel can receive it long after it was sent. Counting from when the message arrived is therefore wrong, and the panel needs the actual current time.

The existing status/time topic doesn't quite cover it. It's local HH:MM with no seconds, date or offset, published retained once a minute. It's fine for showing a clock, but you can't reliably turn it into UTC to compare with media_position_updated_at.

Two options

Either way, the panel only needs to be told the time occasionally. Once it calls settimeofday(), the ESP32's system clock advances by itself on its hardware timer. That adds no extra timers or wakeups, and drift is tens of parts per million, so a few milliseconds a minute.

A. Unix time over MQTT. The manager publishes Unix seconds on a new non-retained topic, something like nspanel/mqttmanager_<addr>/status/epoch, in the same loop that already publishes status/time every minute. The panel calls settimeofday() when it arrives. Because it isn't retained, every delivery is live, so the panel never applies a stale value after a reconnect.

B. SNTP on the panel. ESP-IDF's lwIP SNTP client is already compiled in. The manager sends an NTP server address in NSPanelConfig (a new ntp_server field, empty means off), and the panel syncs from it hourly.

	A: Unix time over MQTT	B: SNTP
Accuracy	± one-way MQTT delay, tens of ms on a LAN	~ms, corrected for round trip
Manager change	A few lines in publish_time_and_date()	New setting plus NSPanelConfig field
Infrastructure	None: the manager already has a clock	An NTP server the panels can reach. My router doesn't answer NTP or advertise one over DHCP, so I'd run chrony on the manager host.
Network traffic	Piggybacks on the existing minute tick	One ~90-byte exchange per hour
Flash	Negligible	+3.4 KB (measured)
Works out of the box	Yes	Only after someone configures a server

For a progress bar that ticks once a second, tens of milliseconds is far more precision than needed.

What else a real clock improves

• Log timestamps. Panel log lines currently carry only uptime. Wall-clock time would make it much easier to line panel logs up with manager and HA logs, especially across reboots and reconnects.
• Spotting stale retained data in general, not just media position. Weather, album art versions and the like could be ignored past a certain age.
• A more accurate clock display, and less dependence on the manager. Optionally, the panel could render the clock itself, changing exactly on the minute instead of at hh:mm:01 plus MQTT delay, and stop relying on the retained time/date/ampm topics. That's a separate, later step, and I'd keep the MQTT topics as a fallback.
• Local schedules later on, such as night-time brightness or screensaver hours, that keep working if the manager is briefly away.
• TLS, if we ever want it. MQTTS and HTTPS OTA both need a roughly correct clock to check certificates.

Timezones

The media position maths is pure UTC, so neither option needs timezone handling for that. Timezones only matter if the panel ever renders the local clock itself. Newlib has no tz database, so the panel would need a POSIX TZ rule such as PST8PDT,M3.2.0,M11.1.0. The manager already has what's needed: it reads the IANA zone from /etc/timezone, and the image ships tzdata, where every zone file ends with exactly that POSIX rule. The manager could read it and send it in the config. That's only needed for the optional clock-rendering step, not for this proposal.

Question

Tim, do you have a preference between these? I'm leaning softly towards A: Unix time over MQTT plus settimeofday():

• it's less to build
• there's nothing to deploy
• it works for every install without configuration
• its precision is comfortably enough for what we need

SNTP stays open as a later addition if something ever needs better accuracy. Happy to go either way, or with something else if you see a better fit.

[tpanajott]

A more accurate clock display, and less dependence on the manager. Optionally, the panel could render the clock itself, changing exactly on the minute instead of at hh:mm:01 plus MQTT delay, and stop relying on the retained time/date/ampm topics. That's a separate, later step, and I'd keep the MQTT topics as a fallback.

Yeah, I totally agree. Using a unix timestamp over MQTT is much less work for people that just want things to work and not have to setup NTP settings. Also, for people that want to run these without allowing access to the internet means NTP wont work without a local NTP source which is too much to ask. I quite agree that this is a good idea for many reasons and it would also be nice to have the time displayed even if the manager goes offline. It would also make it possible to allow creation of alarms or such that could be a nice added feature. Option A is my preffered option as is yours so it seems lik a a no-brainier.