I am working on a project for university in which we are developing a smart automation grid aimed to reduce energy costs in home. We are using openHAB as the main control system for automation aspects.
We are also using InfluxDB+Grafana for storing and plotting data from our sensors. Because system is being developed on campus we cannot have our local area network connected to WAN because of university network security. So all of our sensors, controllers, etc work properly using just a WLAN network and mainly MQTT based wifi devices. However, because the server is not internet connected, the server time and the influxdb timestamps are incorrect. When trying to plot values in grafana, the data is outside of the time range because the data being currently sampled and saved to influxdb is being saved under timestamps that are almost a month ago. That was likely the last time I brought the r-pi server to my residence and connected it to my personal wifi in order to do updates.
I’m wondering if there is any possibility to manually update the server time rather than relying on it to update via internet query. For our proof-of-concept demonstration, we will be simulating different loads and want viewers to be able to see real-time changes as well as longer-term changes that we have collected data for. Realistically, as is, we can set the time query to plot data that is being currently updated however we have to manually set the date and time range of that query to the current timestamps in influxdb. I would like to have a way to manually update time after the server has been disconnected from the internet for x amount of time so that new plotted data will be immediately available under, say, “last 5 minutes” range, referring to data acquired in the 5 minutes since the server was rebooted. This is how it works for my personal server at my house so I’m assuming the main issue is the “offline” nature of the server we are working on.
I hope this was explained thoroughly. Any help would be appreciated.
Hmm - normally a larger internal network provides an internal timeserver which you could probably use.
Another way would be to use a USB DCF77 receiver and build your own timeserver.
Is it not possible to simply write a command to the server to change the current server time? I’m under the assumption that this is exactly how it works when openHAB has an internet connection.
Correct me if I’m wrong but when openHAB first boots I assumed it queries an internet server somewhere with my chosen time zone and then returns the current time.
Currently, when shutting my rpi off and turning it back on, the time stamp difference between the shutdown and reboot sequences in the log have only a few seconds difference even if openHAB had been shut off for a long period of time.
For example, I just booted the openHAB server after 18 hours of it being unplugged…
From the log:
2018-03-01 06:20:41,357 [vent.ItemStateChangedEvent] - Watts changed from 43.8 to 44.0
2018-03-01 06:21:46.856 [INFO][el.core.internal.ModelRepositoryImp1] - Loading model home.items
Those two time stamps actually had 18 hours between them. The first time stamp was the last sensor update before I shut down the server yesterday and the second time stamp is when i booted the server today. But the server time only increases while the server is running (unlike, say, a PC that has a CMOS battery that helps keep csystem time even when powered off). You’ll also notice the server date is March 1 whereas I just booted the server on March 27.
Unfortunately OpenHAB is my first rodeo with linux-based systems. I often find myself seeking OpenHAB-specific answers when the actual solutions I need are more linked to the linux side of things.
That being said, manual changing of the system date/time is just the same command that would be used for other linux or ubuntu based systems: sudo date MMDDhhmmYYYY
There was a time when I thought too it is that simple …
But in fact it isn’t. It is true that the current UTC time is queried from a time server. But the process of adjusting your servers time has to take into account the network latency (time between the correct time was sent by the time server and is received by the querying time client) and the amount of the time drift of your local clock.
I was really surprised how complicated - and somewhat fascinating - NTP is.
