Reproducible bug - Time gets off by 5 minutes every 30 minutes

So I just upgraded my new VERA to 1.0.979

Today, I noticed at 18:00 that Vera showed 14:00.
My timezone is EASTERN.
I sshed into the box, and changed the time to 18:00

I checked my VERA again at 19:00, and it shower 18:50

I put it back on time at 19:00

I checked at 19:30, and it showed 19:25

I put it back on time

I am checking it now at 23:27, and it shows 22:56

So I don’t know if I am the only one, but it does not keep its time.

Is this a known bug ?
Is there a fix ?
Should I send it back and get a new one ?


I’m running the 1.0.988 firmware, and my Vera doesn’t have this problem, so you might be able to fix the problem by upgrading to the newer firmware. Then again, I didn’t have this problem when I was running 1.0.979 either.

So given what you’ve posted, it sounds to me like Vera still believes you’re on some other timezone than you do. Unix/Linux time-service stuff tries to “nudge” the time to what it should be, rather than doing it all at a wallop…this is done mostly to avoid creating big time discontinuities for services, logs, etc on the box. I suspect if you looked closer, you’d find that it’s actually nudging things a few seconds every minute, crawling towards what it believes to be the truth.

If you go in through the web GUI, what does it show for your timezone? Is it what you expect? If not, change it–brute-force changing the time without fixing the timezone would give you very much the behavior you’re seeing on any Linux box I’ve worked with that was running a NTP client.


Hi ,

I do not believe it thinks I am on a different time zone.
After I did the upgrade a couple of days ago, I set it up to the correct time zone, with correct time being displayed in the LOCATION tab.

Some days later is when I noticed the time difference.

Even after I brute-force the time using the date command, it loses 5 minutes per half hour.

Nothing to do with the time zone here I think. Some can say it’s because VERA does not have an internal hardware clock. I still think my unit is [profanity redacted] up, or the kernel was not compiled with -nopic or some other funky options…

can you ssh in your box, type ‘date’ and post the full reply? it really seems to be a timezone issue

root@HomeControl:~# date
Thu Mar 4 14:03:38 EST 2010

I told you… there is another issue with this box.

as rlmalisz said, this is typical behavior when the NTP (network time protocol) has some ideas and you brute-force something else. First you have to figure out what is it trying to do, and why.

check “[tt]date -u[/tt]” and “[tt]date -R[/tt]”. The first one should show UTC time, and the second one shows local time in a more ‘regular’ format, where the timezone is expressed as a number and not by name.

Remember that the internal clock works on UTC time and NTP synchronizes only that. The localtime is converted each time to show using the timezone info. If it somehow got a bad definition of ‘EST’, or if it’s wrongly applying summer time, or anything else…

root@HomeControl:~# date
Fri Mar 5 18:09:07 EST 2010
root@HomeControl:~# date -u
Fri Mar 5 23:09:09 UTC 2010
root@HomeControl:~# date -R
Fri, 05 Mar 2010 18:09:10 -0500

it’s all good…
I will stop the ntpclient in crontab and see what happens again…

As of now, so far so good. weird…

So if all is well–does this mean you still have ntpclient offline?



I commented it in my crontab 2 days ago, and it still looks good.

root@HomeControl:/tmp/log/cmh> crontab -l
*/1 * * * * /usr/bin/ #Rotate_Logs
#1 * * * * /etc/init.d/ntpclient restart

I wish I could have a trace of what tech support did, to see if they changed anything else.
But so far so good.