Names and time

The address you wrote down is a loan

Open both links, then reboot the router and try them again.

The router lends addresses out. Your board gets one when it joins, keeps it for a while, and can be given a different one after any reboot — yours or the router's. Nothing warns you; the link in your notes just stops loading.

mDNS fixes it without a server. The board claims the name esp32.local on the local network, and when your laptop asks — by shouting the question at everything on the network, because there is nobody to ask — the board answers with whatever address it has today.

if (!MDNS.begin("esp32")) Serial.println("mDNS failed");
MDNS.addService("http", "tcp", 80);   // now findable, not just reachable

Three things to know before you rely on it:

• .local only works on the same network. It is not on the internet and it does not cross a VPN. That is a feature — nothing you did just became public.
• macOS, iOS, Linux and Windows 10+ resolve it. Older Android does not. If a phone is the client, give the board a fixed address from the router's DHCP reservation table as well.
• The name must be unique. Two boards flashed with the same sketch both claim esp32.local, and the one that wins is the one that booted first.

The clock the board does not have

There is no battery-backed clock in an ESP32. On power-up its counter starts at zero, which the C library reads as midnight on 1 January 1970 — so a logger that timestamps before syncing files everything under a date fifty-six years ago. And once it is set, it drifts: the crystal is accurate to about 20 parts per million, which is a second or two a day awake, and far worse across deep sleep, where the counter runs from a cheap internal oscillator instead.

NTP is the fix and it is two lines:

configTime(0, 0, "pool.ntp.org");          // UTC, from the public pool
setenv("TZ", "AEST-10AEDT,M10.1.0,M4.1.0/3", 1);  // then your local rules
tzset();

• Store and log in UTC. Convert to local time only where a human reads it. Daylight saving is a display problem, and turning it into a data problem is how a logger gets an hour of duplicated readings every October.
• Sync at boot and once a day. More often is pointless; never again is how the drift above adds up.
• Wait for it. configTime returns immediately and the answer arrives a moment later over the network. Check that the year is sane before you trust a timestamp:

struct tm t;
if (!getLocalTime(&t, 5000)) Serial.println("no time yet");