NTP Server

[pete]

It would be nice to include an NTP server with optional internet or GPS connectivity. 

Today my preference is to utilize a GPS and NTP server here rather than the internet for my time sync.

Time is a bit of a hobby here with a few old clocks around.

[LGNilsson]

Shouldn't be too hard to do via OpenWRT if nothing else http://wiki.openwrt.org/doc/howto/ntp.client
However, as you can see from that page, most routers don't have a hardware clock, although the chip we're using in the Almond+ does support RTC.
The Almond+ won't have an internal battery backup, so in that sense, this might not be 100% useful.

[pete]

Thank-you Lars

Yup; here all of the little arm cpu's with embedded stuff boots up checking time before doing anything else.  Being a bit self time centric I don't let them go to the internet for time.  That and I have been attempting to close my automation interfaces (touchscreens) a bit such that they function without the internet. 

Asking myself what if I can't get my weather maps from the internet (another addictive hobby); decided to try to just pull them down manually from the NOAA weather satellites using radio as my failover.

I am doing this though sort of while I attempt to add load balancing to multiple external wan links; a contradiction of sorts.

Its just an exercise I guess as I am helping a friend a bit build his home in CO off the grid.  Yup and internet connectivity may be satellite or cellular.  So far no cellular phone access. No electric and no water.  That and he wants to manage his automation with a bunch of touchscreens.

[Patrick Wilson]

Shouldn't be too hard to do via OpenWRT if nothing else http://wiki.openwrt.org/doc/howto/ntp.client
However, as you can see from that page, most routers don't have a hardware clock, although the chip we're using in the Almond+ does support RTC.
The Almond+ won't have an internal battery backup, so in that sense, this might not be 100% useful.

The Router not having a RTC is exactly why NTP or GPS time solutions should be considered an "essential" service.  Some VPN and network security protocols need accurate time in order to function.  If the time between two end-points is off by too much (NTP can adjust for different time zones),  many of this protocols won't work at all. 



However you've already correctly identified that this will NOT be a problem with OpenWRT.  (Besides if the new Almond+ is going to support the Time and Weather Apps as the original Almond,  then having it actually display the "accurate" time would be highly desirable). 

[etijburg]

I agree.  if Hardware is not finalized I think the SecuriFi should consider adding a RTC chip.  Accurate time with be a requirement for Time based access controls, accurate logging and VPN access.

[Patrick Wilson]

I agree.  if Hardware is not finalized I think the SecuriFi should consider adding a RTC chip.  Accurate time with be a requirement for Time based access controls, accurate logging and VPN access.

If you'll forgive the observation.  Adding a RTC as "hardware" would drive up the cost of the unit,  and it really isn't necessary.  I know of no router that includes this functionality,  as it simply isn't needed.   All Routers I have ever used support NTP - Network Time Protocol

The original Almond already supports this,  so I believe it is safe to assume that the Almond+ will as well. 

[pete]

Here is a device which I have been playing with.  (well a few of these today)

That said it is a small HD IP camera board. 

[LGNilsson]

Difference scenario, as that needs to be able to keep time even if the internet goes down, as it can most likely record to a local server, which in turn could technically be the NTP server...

[pete]

Yes.  I am OK with just having the device getting its time from the local NTP server.

I do that today with my Ubiquiti AirOS wireless AP as the one wireless network is autonmous from the internet on its own network and another one doesn't touch ever touch the internet.

The NTP time sync time zone / DST / ST stuff; it is incorrect.  (not doing daylight savings time).

Grandstream does off the option of a manual entry which saves looking at a very long list of timezones

IE:

MTZ+6MDT+5,M4.1.0,M11.1.0

plus syncing to the inhouse NTP server.

[Patrick Wilson]

Yes.  I am OK with just having the device getting its time from the local NTP server.

I do that today with my Ubiquiti AirOS wireless AP as the one wireless network is autonmous from the internet on its own network and another one doesn't touch ever touch the internet.

The NTP time sync time zone / DST / ST stuff; it is incorrect.  (not doing daylight savings time).

Grandstream does off the option of a manual entry which saves looking at a very long list of timezones

IE: plus syncing to the inhouse NTP server.

To solve my issue with DST on my Almond,  I simply do a "echo PST8PDT7 >/etc/TZ" from a Telnet session.  This should be fixed in a future Firmware revision.  Unfortunately I need to do this manually after every restart of the Router. 

I live in the Pacific Time Zone"  we are UTC-0800 in the Winter,  and UTC-0700 in the Summer.



In 90% of Canada we observe "Daylight Savings Time".  Here in British Columbia,  Canada,  99% of the province,  including Victoria,  observes "Daylight Saving Time",  this means that in the Summer months we are UTC-0700 hrs,  while in the Winter we are UTC-0800 hrs.   (There are some exceptions,  including Creston, BC, Canada - See Wikipedia article:  Time in Canada (aka http://en.wikipedia.org/wiki/Time_in_Canada)

[pete]

Thanks Patrick!

I am a bit fanatical about time keeping here. 

At work a few years back changed all of United Airlines routers and switches time to my NTP server after working on another project and being somewhat picky about time in general.

While the other program involved flight vectors (catia) and some major timekeeping and gps coordinates.  I got bitten by the bug of having used a GPS system for this application (installed globally).  It is a neat program.

Changed it:

almond login: admin
Password:

BusyBox v1.12.1 (2013-06-21 19:05:13 IST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # echo CST6CDT5 >/etc/TZ
~ # date
Wed Aug 28 10:11:20 CDT 2013

Just as an FYI here relating to CST

[CST] US Central + [6] 6 hours off UTC + [CDT] + [5] + 5 hours off UTC

Today I have some 15 plus touchscreens in the house.  None touch the internet.  Each main screen shows a clock.  Some screens show live video with another clock such that I compare the live video clock to the touchscreen clock to the house clock; bored I guess.