From where does HAOS get its time sync?

Searched here and the docs without success.
Seeking to know if it can be reconfigured to look to a script, a command-line, or just pointed to a time server other than whatever is the built-in default.

Goal is to ensure that a system with no internal battery-backed clock can always obtain reasonably accurate time info (so the automations run at the proper times) even if it’s starting up during an Internet outage.

Here it is explained.

Thanks for the tip. I think I had seen that one but since it’s about NTP, it didn’t help.

The latest version of HAOS (as of yesterday) did not appear to be running an NTP daemon.
Rather, they’re using timesyncd, and I just now found its config there.

Looks like that at least has changed since some of the solutions on here were posted.

Still hoping there’s a script somewhere in there that I can hook and have it fetch time from a local RTC device.

I’ll keep digging, now that I at least know what tool it’s using for time.

I may have found my problem:
When I ssh to the system, I seem to be inside the containered HA instance, and not interacting with the underlying OS at all.

How does one gain access to it? (that’s a separate question, for which I’ll go hunting answers)

Ssh to port 22222.

Connection refused.
Port 22 gets me a shell inside the container, but can’t access the filesystem of the host OS, only whats in the container.

1 Like

Thanks. This is what I’ve been looking for, but hadn’t recognised what it was.

Once I got clued-in to the difference between this method, and the access provided by the add-ons, it’s working great and I’m at a host-level shell.
Thanks again.

Read my post please, u dont need any ntp daemon on haos.
Just read and have a look on the screen shots.
The NTP is running on router or maybe if u have any other server inside your network its fine also there…
My Home Assistance are 4 weeks old :slight_smile: I’m a new here and I just start learning.
Cheers!
Marius

When I got access to the platform OS and found the timesyncd.conf file, I see that it’s hardwired to look for an external timeserver, and I could find no supported way (i.e. exposed as a setting to the user) of changing that (i.e. if an update happens, presumably any behind-the-scenes changes I made to that setting would get set back to whatever the distro came with.

99% of the time that would be fine, however…
The use-case I’m trying to solve is:
When we are away on an extended travel, if all power goes out (for longer than my UPS can carry it) including Internet service, and power is restored but not Internet. So even my border router (which does supply my LAN with an NTP time source) won’t know what time it really is.
And the time/sunrise/sunset-driven automations would start triggering at really odd times (until Internet returned). In more than one case that has taken a few days.

Clearly, the proper solution for me is to buy a platform that includes a built-in battery-backed clock, because it looks like adding my I2C RTC board to HAOS on the RaspberryPi isn’t the proper solution (which I could do, except for the above unsupported-change problem).

Well, the HA Amber is based on a Pi4 compute module, and has a RTC hwclock. So I guess we will see support for a RTC clock in HA OS on Raspberry Pi eventually.

1 Like

Hi,
Well in this case I will search for esp8266 rtc+gps module and I will keep this device running on acu and charger. U can use this esp as a ntp server. I’m sure in case of power failure at your home a proper configurations for this esp can keep him alive for more than 2 days which should be enough I think.

Cheers!
Marius

1 Like

That’s a great idea.
Except … the Pi image of HAOS is hardcoded to use an Internet time service (I can’t recall which one at the moment), so to make a local one work I’d have to have a DNS redirect in place somewhere, like a local /etc/hosts file, but that’s not normally exposed for modification, either.
It seems there’s just not enough flexibility in how the time source configuration is exposed to the user, if at all. (at least for the Pi HAOS image).