Here's hoping that hardware version.next has a proper RTC with battery backup. And a future platform version has NTP configurability built in. 
3 Likes
we have this 'problem' throughout the Community. A suggestion is made. A response is made to say, in effect: "asked, discussed, nothing new to report." Not as Hubitat employees, but as fellow Community members. Some way or another that gets a hackle or ten to rise. It's a problem with repetition, I believe. On the 8th or 10th repeat, a summary lacks that something and it tips over into a perceived "you can't talk about that"
There's less than 0.5% that have earned the Troll badge.. and no one in this list has it. Nor are they close to earning it. So.. if you feel like it's become personal, I'm suggesting it's not intentional. Typos get made, words get left off.. etc. But it happens too often.. perhaps I'm the one this time 
not intentionally, I know that.
4 Likes
Well said. And don't get me wrong - I agree with you @alexdelprete . I think NTP configuration should be in the base platform. I also would like it to have a proper RTC w/battery backup.
3 Likes
You are free to ask me anything, but you're not free to tell me what or how I should answer. 
I think I've been clear in my previous post: this driver works, in parallel to the internal process that is not configurable. That's why this thread exists.
It's not simply an opinion. Is there really someone here that says this is the way to do it? An automation hub that wants to be internet/cloud independent (that's why I chose it), that doesn't have an internal battery, cannot rely solely on the internet to sync its clock. It's a bad design, not an opinion, but a fact. The workaround would've been to put a couple of ntp options in the settings, and that doesn't require hw retrofitting.
But I'm repeating myself. Sorry.
No, I don't think anyone is saying that.
All I was saying is that when there are easily implemented, functional workarounds then taking engineering time to redo the base platform, versus adding new features and bug fixing, is typically a lower priority.
That's all. I'll leave it at that.
Absolutely you don't seem to be one. I've been, and are, on a lot of forums and I know the dynamics. Since I'm in IT since I was a kid, and now I'm 47, I tend to have a very precise idea about tech products and I always try to contribute constructively when I see something I don't like, it's my way to try to contribute to a community. And I'm sorry if I annoy experts here that always read the same stuff. It was not intentional.
I really like the spirit of this community, lot of great people that help everybody. This, and the product itself, made me a happy customer and community member.
I think Hubitat 'kicked it between the uprights' -- maybe a little close to one of them, not a great kick, but adequate. They save a lot of costs, not shipping lithium, not having to create a mechanism for replacing it.. worse if they had to add a door. Documentation on how to, even if it's difficult. Yea, I'll say it's an acceptable trade off. Woz would have loved it.
Well, we'll agree to disagree there. But I acquiesce that the existing situation is tenable.
1 Like
Had I been the Architect, I probably would have just automatically, without considering the points I made, added a battery... but I wasn't the Architect/Designer. But Lithium is a big deal because in quantity... a pallet full of hubs, each with a battery, needs those extra forms filled out and special everything for shipping.. so.. maybe after all, I too would have altered the design to get rid of it. Can't say for sure.. but it has me thinking aloud.
1 Like
I perfectly agree with you. But the workaround would have been putting the 2 options to configure the internal ntp client, not developing a second ntp client on top.
Thanks for this discussion, and I'm sorry if I talked about this old issue, I can understand it can be frustrating sometimes reading the same things over and over. But please be patient with newcomers like me.
3 Likes
No worries at all! Always room for more polite discussion / debate.
I only tune out when the name calling starts (which is rare, but unfortunately not never).
1 Like
I perfectly agree with you here, and that's why I thought it was intentional decision. But when I went into the options and found out there was no way to configure ntp I thought: "that's a tradeoff without a soft landing for users".
If I had found those 2 options in the settings, I wouldn't have even bothered looking on the forum for my problem with the clock.
Probably I would have agreed to get rid of the battery. But I would have told the architect: let's make ntp configurable though, otherwise we'll have some problems in case of power-loss and/or no internet connectivity.
1 Like
I'm here to learn and discuss about HE and automation. That's all.
1 Like
For anyone looking to make a Raspberry Pi into an NTP time server, this is absolutely the best guide I have found:
https://www.slsmk.com/how-to-setup-a-gps-pps-ntp-time-server-on-raspberry-pi/
In particular, the NTP configuration lines he provides will allow NTP to properly sync and stay locked to the GPS receiver with NO outside time server sources for a reference required, hence the server will sync up without an Internet connection. All other configuration instructions I found would result in NTP flagging the GPS time source as a "bad ticker" and removing it from use. There are a few critical flags and settings that need to be set to give the serial time data and 1 pulse-per-second signal time to converge properly.
Setting up the Pi involves setting a hardware configuration flag to activate the serial port and 1 PPS signal on the GPIO pins on the Pi, and installing the GPSD and NTP packages, then configuring them.
GPSD reads the serial port and 1 PPS pin and makes the timing information available to NTP over a low-latency shared memory interface that presents the data to NTP as pseudo-IP addresses. GPSD also combines the timestamp and 1 PPS data in a way that NTP can use.
From there, NTP uses the 1 PPS pulse to discipline the serial data stream from the GPS, which contains absolute time. The 1 PPS signal precedes the serial timestamp by a few hundred milliseconds. The leading edge of the 1 PPS signal represents the precise time. NTP calculates the correct offset to correct the timestamp dynamically.
The NTP service on the Pi restricts use to the Pi itself, by default. A few lines in the /etc/ntp.conf file need to be changed to allow the server to make the service available to other devices on the LAN.
Regards,
Don
2 Likes
Have you looked at this one? https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/
I'm asking as I'm about to put an NTP server together and the one from NTP sec seemed comprehensive (and has a script to help with configuration), but I don't have experience with NTP so can't judge which is better.
I have looked at that one!
It is a comprehensive guide, but a bit out of date.
He describes a lengthy process for compiling a custom version of NTP with PPS kernel support, but I found that the version of NTP that is installed with the latest Respbian with "apt install ntp" works fine out-of the box, including running properly at boot time.
The link I mentioned has a custom ntp step too. It is NOT needed.
Also, his ntp.conf setup in the link you reference is not adequate to prevent NTP from eventually flagging the GPS as unusable. His setup also requires at least one outside world trusted NTP server to allow syncing up the GPS. The configuration lines in the link I mentioned do not, and allow full stand-alone, Internet-free operation and quick convergence.
I am not a fan of scripts that try to set up something this complex. I think it is better to understand and carry out each step manually. That way it is easier to troubleshoot if something goes wrong.
Best,
Don
Looks close to the project I did with my son about a year or so ago. Since my pi is in my basement I had to run a GPS antenna to the first floor for a good connection. My son was able to create a new case lid expanding the case for the GPS module to make sure everything was self contained.
Neat! I wanted to fit the GPS and antenna inside the case, but I had already fitted a shutdown/reboot button to the GPIO pins and there wasn't quite enough room. I also wanted access to the USB connector on the GPS module for configuring it with the PC U-Control software from U-Blox. I just tacked the module, antenna and lead to the top of the case with few spots of hot melt glue after a light sanding of the case and wipe with alcohol.
I'm surprised you didn't run into issues with a long cable run from antenna to GPS. The attenuation of most cables is pretty terrible at GPS L1 frequencies. At Motorola, we used Oncore GPS receivers to provide timing for cellular base stations and frequently needed to use inline amplifiers on long cable runs. Hardware and antennas have gotten better since then, I'm sure.
I wanted an SMA connector on the GPS so I could use a remote antenna. An adapter pigtail is sold to go from the weird micro-connector on the board to SMA female. I may add that later and use an antenna with a longer cable.
Time offset with this setup, after fooling with the NTP configuration to get the reference selection and PPS application right, is pretty stunning, less than a microsecond compared to the local Raspberry Pi clock. It takes about an hour after starting NTP for the algorithm to slew the clock into compliance.
Don
I made a GPS time server today too. No real reason why, but thought it would be something to do, and kind of cool... Took maybe 30-60 minutes, including the gps hat pin soldering, rpi setup, update/upgrade of packages, and ntp config.
Used this guide, and used that bill of materials:
http://www.gregledet.net/computers/building-a-stratum-1-ntp-server-with-a-raspberry-pi-4-and-adafruit-ultimate-gps-hat/
Never could get a gps lock without putting the antenna by a window. Tried in 4 different places in my house, leaving it in each location >1 hour. Maybe my stucco is made of lead. 
Luckily I have a room where it is easy to put the antenna by a window anyway, so no big deal. With it there is locked in about 10s.
But just a word of caution - don't assume that you won't need window access for the gps antenna...
1 Like
