Create endpoint to expose device time

[Cyborg-Squirrel]

Streaming RGB data to Nightdriver can include a timestamp.

To ensure the current timestamp from the host doesn't end up being in the past, or otherwise de-synced, relative to the ESP32's time an endpoint to request the device time would be helpful.

Example function in webserver.cpp

void CWebServer::GetTime(AsyncWebServerRequest *pRequest)
{
    debugV("Getting current time...");

    timeval tv;
    gettimeofday(&tv, nullptr);

    auto response = std::make_unique<AsyncJsonResponse>();
    auto jsonObject = response->getRoot().to<JsonObject>();

    auto jsonDoc = CreateJsonDocument();
    jsonDoc["seconds"] = tv.tv_sec;
    jsonDoc["microseconds"] = tv.tv_usec;

    jsonObject.set(jsonDoc.as<JsonObjectConst>());

    AddCORSHeaderAndSendResponse(pRequest, response.release());
}

[robertlipe]

This isn't needed; it's at least not needed for that purpose. The premise is that everything runs with a common ground^Wtime. Using NTP, every device on the network has the same time reference.

If you allow each device to make up its own time and be a few seconds off, the server code gets crazy complicated because that one is UTC + 4.234 seconds and that one is UTC - 1.29 and my displays are on the county line where the TZ or DST line runs through the room. Above, you've ignored timezone.

It seems pretty fundamental that everything on the network stay in sync by having a common time, not having the server compensate for some device-relative drift.

Does understanding that solve the problem you're actually trying to solve? Do you have devices (with ENABLE_NTP set) that are drifting apart substantially? I'd be more interested in fixing that if that's the problem...

[Cyborg-Squirrel]

There are two problems I'd like to solve by querying the current time of the ESP32. I wouldn't need a set time endpoint and I get that could lead to a lot of wider design problems if a client could arbitrarily set the ESP32's time.

1. If I wanted to run Nightdriver clients on a private network without internet access would there be another way to keep the timestamp in sync?
2. Responsiveness. Getting the current ESP32 device time can give the PC streaming to Nightdriver an idea of network latency if both are using NTP (which I have configured). If I stream color data timestamped at the current time plus a few milliseconds that might work most of the time but, over WiFi this could result in that timestamp being in the past when it is received. Being able to add less time to the timestamp makes the process more responsive when I want it to start or stop.

[rbergen]

In response to this:

1. You can run your own NTP server if you can't access the Internet. And I think you'd have to use anything but the ESP32 as a common time source in your private network. Without the NTP time sync enabled, they do indeed tend to suffer from clock drift. Using the ESP32 as a time source would thus gradually derail the time keeping of your entire network.
2. I still don't think I fully understand the problem you're trying to address, but I think there are at least two fundamental issues with the solution you're suggesting.
   • Latency is not constant, certainly with WiFi networks. Which means that the deduction you make now about effective latency based on anything could be completely wrong 10 seconds later. Hammering the time endpoint for constant updates about the ESP32's time would not be a solution for this, because then you're adding another workload to your network and the ESP32, itself impacting the whole setup's performance.
   • The request for the current time on the ESP32 is a request-response interaction, with (possibly different) latency applying to both directions of communication. The color data streaming from the PC to NightDriver is one-way in all ways that matter, so you'd be comparing apples and oranges by definition.

When it comes to deciding on the gap between now and the requested display time of a packet, there's a trade-off: making the gap bigger decreases the chance of stutter, making it smaller gives you higher responsiveness. What works best for you over time is something you'll have to experience. And as long as the differences are in the ms range, I don't think the human eye/human time keeping can really notice it.

[rbergen]

I'm going to agree with @robertlipe on this one. If time sync between ESP32 device and anything else is important, they should both get their time from a reliable source using a proven protocol to align with that source, and that is NTP. It's also how the time syncing challenge has been addressed for a long time in every environment where an (Inter)network connection is available.

Also, if you were to establish that an ESP32 device with NTP enabled does show meaningful time drift, then we should really focus on fixing that.

I'll convert this Issue to a Discussion for house keeping reasons.