Where does openHABian get time from?

openhabian
time
Tags: #<Tag:0x00007f01451eda00> #<Tag:0x00007f01451ed898>

(sonko) #1

Hi,
I’m using openhabian on my RPI 0W that does not have any battery powered RTC and I would like to know where does openHAB get the time from?
My guess is probably somewhere from internet but what will happen when we are offline?
I have a few astro rules and I want to know how they may behave in worst cacase.

Here is a sample scenario:

  1. we are online and everything is fine
  2. a blackout comes - everything turns off
  3. power comes back on but we have no internet connection (with “outside world”, local is ok)

How will OH behave in terms of current date&time ? Because when the time is wrong astro rules will trigger in wrong point in time and that can be a problem :confused:
Will OH update its date&time automatically when the internet connection comes back?

Can I somehow simply check if I have a valid internet connection?


(Angelos) #2

I don’t know the answer to your question, but I can tell you with a high degree of certainty that OH2 doesn’t contact any remote hosts to obtain time info (e.g. ntp). Most likely, it uses system time from the host. You can configure ntp on your host to sync an external ntp server if you would like.

The entire concept of openHAB revolves around the “Intranet of Things” with special care not to allow unnecessary connections to external cloud services (unless explicitly configured by the user).

rPi0 is too small to host OH2 imho

This can be easily done with a rule. check the forum for examples


(Scott Karns) #3

My instance of openhabian running on an RPi 3 has the NTP service installed and enabled. I don’t recall whether or not I had to manually install the NTP service or it was part of the original installation, but I suspect it was part of the initial install.

The NTP daemon will use internet accessible NTP servers when the internet is available. I also see that the fake-hwclock package is installed. I don’t know anything about it, but I think it may help regulate the local system’s time keeping when the internet connection goes down.


(Scott Karns) #4

All I had to do was check apt:

~$ apt show fake-hwclock
Package: fake-hwclock
Version: 0.11+rpt1
Priority: extra
Section: admin
Maintainer: Steve McIntyre <93sam@debian.org>
Installed-Size: 32.8 kB
Depends: init-system-helpers (>= 1.18~)
Suggests: cron | cron-daemon, ntp
Download-Size: 7,126 B
APT-Manual-Installed: yes
APT-Sources: http://archive.raspberrypi.org/debian stretch/main armhf Packages
Description: Save/restore system clock on machines without working RTC hardware
 Some machines don't have a working realtime clock (RTC) unit, or no
 driver for the hardware that does exist. fake-hwclock is a simple set
 of scripts to save the kernel's current clock periodically (including
 at shutdown) and restore it at boot so that the system clock keeps at
 least close to realtime. This will stop some of the problems that may
 be caused by a system believing it has travelled in time back to
 1970, such as needing to perform filesystem checks at every boot.
 .
 On top of this, use of NTP is still recommended to deal with the fake
 clock "drifting" while the hardware is halted or rebooting.


(Angelos) #5

clarification here (just to avoid any misunderstandings with regards to the “Intranet of Things” concept): openHABian is not openHAB

openHABian is just a set of (very complex) scripts that help Linux users to configure the underlying Operating System (Raspbian = Debian). One of the several configuration assistance that it provides is the proper setup of NTP.


(Scott Karns) #6

Valid, good point, @Dim.


(Rohnny Swennen) #7

I think the question is where Openhab gets the time from is a relevant one. While it is your system time I too struggle with date/time issues (just FYI see Time incorrect in log file in docker).

My Openhab not on Openhabian but docker runs perfect, rules use perfect local server time but the log files seem to be off. So there seems to be even a difference of time within Openhab of what the time is (at least a difference between rules and logs in my cse)


(Angelos) #8

I saw the other thread… from what I understood: those problems are related with Timezone configurations (other tz in host, other tz in java, other tz in frontail)

other than tz diff… do you have time sync issues? (seconds/mins off? (not hours))


(Rohnny Swennen) #9

No the difference is exactly a multitude of hours so that seems to make sense that the actual time is the same but different parts of OH assume to be in different time zones.


(sonko) #10

my bad I was thinking of openhabian but wrote openhab :confused: I have edited the title

why? only thing I would add is exnternal wifi antenna connector, it is not speed deamon but once everything boots up it runs just fine :slight_smile:

here is what I came up with at this momment:

  • play around with network binding and get working to check if for example 1.1.1.1 is available so I will know if I’m online
  • add RTC with battery backup to RPI (have ds3231 laying around)
  • add rule at start-up to check if online
  • if not then get current date&time form RTC and set it as current system date so openhab will run current date&time

NTP should automatically kick back in once internet comes back up, right?


(Rich Koshak) #11

The typical drift for a PC without NTP enables you will see a clock drift of around 10 seconds a day. On an RPi I would expect slightly worse, maybe 20 seconds a day but I couldn’t find anything online to definitively say that. When the network comes back it should resync the time immediately, but be aware it doesn’t usually do it all at once. It slowly adds/removes microseconds over time to bring the system clock to match the ntp server time. So, depending on how off it is, it might take awhile to correct.

The big limitation is lack of RAM. It only has 512 MB of RAM and OH typically requires well over 400 MB of RAM leaving not much left for the rest of the OS and other services. Exceptionally slow load times and occasional thrashing as RAM is swapped in and out to the page file makes an RPi 0 non-performant in almost all use cases.


(Angelos) #12

yes. you can modify this in /etc/systemd/timesyncd.conf (assuming that you are on Raspbian Stretch (cat /etc/os-release and systemctl status systemd-timesyncd.service)

check: https://github.com/systemd/systemd/blob/master/src/timesync/timesyncd.conf.in

I run a local NTP Server on my Debian hosting OH2 and I sync all LAN devices with it. The NTP daemon is synced with the debian.pool .


(sonko) #13

to be honest I’m confused now because as we can read here

(…)
openHABian v1.2 brings full support for the Pi0W in unattended/headless mode. Read about Wifi setup below.

The Raspberry Pi Zero W is powerful enough to run openHAB and to control your small and mid-sized home / home automation system. (…)

so why we are supporting a device that we know is at the edge of its possibilities? Wouldn’t it make more sense then to just say that openhabian is compatible with RPI 0(W) but because < insert a reason here > we don’t recommend it?

So you are saying RPI 2/3 model B is basically the only way to go when it comes to SBC? - I don’t know much (if anything) about Pine64, how popular it is, how bad or good is its support.


(Angelos) #14

I don’t think that the authors of openHABian should change these statements. They are true for (small and mid-sized HA systems).

Our suggestions and recommendations are influenced by our personal experiences.
For example, I have so much stuff (addons, rules, transformations, etc, etc) running on my OH2 and I use 2 RAM “hungry” persistence services with extra bells & whistles that I can’t ever imagine running my setup on a rPi0W.

If you are planning to have only MQTTv1 and some basic addons enabled: then rPi0W will do fine.

On the other hand… If you want to enable advanced stuff (for example: Homekit/Google Home/Alexa on top of Hue and KNX), I would recommend something as powerful as the rPi2/3.

If you want to enable even more stuff (e.g. InfluxDB with Grafana) I would consider a NUC (to avoid SD card I/O).

It all depends how many subsystems you will enable in your HA system powered by openHAB2.