I know there's the time thing, but I thought I'd try this.
Question is, what's the best way to do this?
I could just unplug the Ethernet network cable from the Hub.
I also could deny web access to the Hub in my router.
Would this be equivalent to pulling the plug?
I would not go out of my way to update the time, as is possible via the browser in Settings, but could the hub do that on its own?
No, the hub will still have access to your LAN (for LAN devices like a Hue Bridge, Matter devices, and other integrations -- or even an NTP server so you don't have to worry about time) if you block Internet access from your router.
Pulling the cable will, of course, prevent all activity, regardless of source or destination.
So, even without Hue Bridge, Matter devices, NTP server, or other integrations, it is still possible that it could acquire the time from the LAN?
edit: And there it is on my router. So, I'd have to pull the cable. I don't know how long I'd be able to go without twiddling around with the rules, devices, etc, etc. 
I'm going to go as it is, with Hub internet access blocked, and see if the time drifts, sunset/sunrise rules/log behavior, etc, before pulling the plug.
If you have a local NTP server, configure the hub to use it, and do not have your router configuration or physical setup such that access to the server is not available, then yes.
No local NTP server, but the router still has access to time servers, see above clip.
edit: I do have an Ecowitt integration. Ecowitt gateway is connected to WiFi (and Internet).
If your router runs an NTP server (not sure most do), that would work; otherwise, this isn't very meaningful on its own unless you want to find some way to get it into the hub (e.g., custom code to scrape the data).
I'm not sure what the connection is here to time, if this is what you mean; you can certainly get data from the Ecowitt if you don't block access to it from your hub (as long as that device is accessible on your LAN from your hub, as above, regardless of where that device gets its data from).
You mentioned integrations. I had forgotten about that one.
But then, I recalled the router is accessing NIST servers.
It's looking like I'll have to actually pull the plug to see how the clock drifts over time, etc.
Based on this thread, blacklisting the hub might block access to NTP servers.
Why?
Thank you for your response.
OK, do as you please, but it’s an actual question.
Why block your hub from communicating with the internet?
Or why block it from communicating with your LAN (which is what will happen if you disconnect the Ethernet port)?
Thanks again for your concern.
As expected Pushover, Cloud Backup, etc not working.
Time still ok, apparently. Maybe it takes a long time?
Not sure if blacklisting network access on router was "good enough".
Network connection seemed to persist until hub was rebooted, although web was inaccessible.
Light green after reboot, but inaccessible on network.
Pulled plug at 9:30.
Red and green.
What does "Good Enough" mean, I'm unclear on what "success criteria" your using here.
It makes sense, that the NTP clock set (as the HE has no battery backed RTC), occurs on boot, and that clock drift/skew is fairly small and would take days/weeks to accumulate to meaningful time errors.
So if it boots, connected to the network, it gets an IP via DHCP (unless you have a static IP set - NOT a reserved address), and NTP initially sets, the clock - You can then unplug the e-net cable, and it will locally run along just fine doing Zwave/Zigbee things (matter will fail, as it's IP based, and any "offsite" stuff will fail as you noted).
If it's NOT plugged in (or no network access on boot), it will NOT get a DHCP address, not will it initially set it's clock correctly. - The router may still have a DHCP lease cached, until the lease time expires (as there is nothing on the network to reply with a NAK). With a static IP, you can work around the DHCP failure, and it should at least boot cleanly, but without setting the clock via NTP, no time based rules are going to work well (clock defaults to Jan 1, 1970 which is the UNIX epoch? - That's a SWAG on my behalf) - I would assume Z-Wave/Zigbee triggers on buttons/motion sensors/contacts/rules will still work fine without the clock being accurate. Obviously with no local GUI or web access.
But again, back to the beginning here - I'm unclear on your goal, everything above seems to make sense, given the lack of any IP access/connectivity, but what do you want to have happen to declare "success" or "good enough"?
Or you can leave it on your local network, an isolate it via a VLAN, and control what can talk to HE and vice versa via ACL's or FW rules - But that's all pretty much standard network security control stuff.
Or is there something in this thread that is unexpected to you, and your trying to work around some issue?
Thanks for the detailed response. My head hurts now. 
No, seriously, thought provoking, thanks.
I was just thinking how it could work in a place autonomously in a place where the web, or even lan, weren't available. Extended power outage, off grid cabin, etc.
Discussions of NTP, as I recall it, seem to be all over the map. I just thought I'd try it myself and see what actually happened.
So, as soon at it links to the network, it syncs to the network time. Even if internet access was denied to the hub, it would get a time from the router, whatever that would be.
I didn't have a feel for if the time drift would be fast or slow, as well. Network connectivity at hub boot up would be key then.
I'll have to shutdown, pull plug, and the re-power, lol. No, seriously.
And, you can't see what's going on with the Hub unless you connect it to the lan, and then time gets updated. Catch-22? Lol.
So considering the "cabin in the woods" use case - with no internet or router available - The only real problem is TIME and a lack of NTP server being available, to initially satisfy the HE's initial NTP request to set the clock on boot - In that sort of application, there is no DHCP/DNS so we're dealing with just a static private C address on the HE, and basically a single switch and connection to a NTP time server.
Which just happens to be easy enough to build you own, that's sourced from GPS time - that's available everywhere on the planet. - you can "roll your own" via a RPI - See: GitHub - domschl/RaspberryNtpServer: Stratum-1 time server with Raspberry Pi and GPS
That, and the HE are all that's needed, and the NTP server is there just to basically set the clock on the HE and keep it from drifting - You can have you local GUI, and have the device on your private network in the woods, and even have local dashboards, etc. -
That all said, I personally would add a Starlink to my cabin, as I don't think I could live with any internet access, but that's a personal choice, not driven by HE or NTP.
As for RTC clock drift, most machines have pretty poor clock crystals, and assume networks exist to set time - Things are worse on battery only (not booted), and temperature also impacts clock crystals - A good "rule of thumb" for PCs, is a min of drift per week. (not sure about HE, but I can't imagine the spent extra $$ for a good RTC, given it doesn't even have a battery) - Source: date time - How much clock drift is considered normal for a non-networked windows 7 PC? - Super User
FTW
I found a pre-built standalone NTP GPS server for cheap at one point but didn't pursue.
I was just experimenting at that time too.
Now, I need a cabin on a lake.
Or a van down by the river (SNL fans might get this).
RIP Chris Farley
Download the Hubitat app
