time keeps getting reset

I just set up my new vera2 yesterday and the system date/time keeps getting reset to 01/01/2000 00:00:00.

The internet connection is active - all other elements seem to work fine. There is obviously some issue with an ntp somewhere but I have no idea how to resolve it.

I reported this issue to support (ticket) and have heard zip now - 2 days later (ticket #7343).

Does anyone have any ideas to resolve this? As you can imagine, it pretty much renders any scene that is time based useless.

Thanks in advance

bump

no ntp on my vera… how is the date getting reset…? Could someone at MCV tech support PLEASE get in touch with me??

Here’s what you need to do…

Update to the beta firmware 1.1.1062 by going to (BETA URL Removed)
After the update time has reached it’s maximum value wait 2/3 minutes after this and please refresh the page or power cycle the Vera (remove all cables from it, leave it 5-10 seconds and then put it together and try to connect).
After this, it should be resolved.

Hope this helps.

I have seen all these messages floating around about the time changing on the Vera’s and I wanted to help people get to the bottom of what is happening.

If you know better than me then please feel free to correct me, but here is my take on the situation.

Normally a Linux box has a hardware clock which keeps the right time even when the computer is switched off. During boot up Linux gets the current time from the hardware clock using the call ‘hwclock -s’ and during shutdown it stores the current time according to the operating system to that hardware clock using ‘hwclock -w’ to allow for any changes that have been made by software. The Vera being a router doesn’t have a hardware clock so although those commands exist and can be run from the command line neither of them will actually do anything for you.

As there is no hardware clock the Vera must get the correct time every time you switch it on and to do that it uses a little command called ‘rdate’. In brief the ‘rdate’ command is used as part of a hotplug event whenever the Vera connects to a network and a list of potential sources of time have been listed in the file /etc/config/timeserver, they are as follows:

ac-ntp0.net.cmu.edu
ptbtime1.ptb.de
ac-ntp1.net.cmu.edu
tick.greyware.com
ntp.xs4all.nl
ptbtime2.ptb.de
cudns.cit.cornell.edu
ptbtime3.ptb.de

I would suggest that the only reason that the clock would reset would be that your network connection has restarted and that could be a result of either strange network problems or your vera rebooting itself completely.

You can rapidly find out whether your Vera has completely rebooted by logging in via ssh to the Vera itself and typing the command ‘uptime’, which will give you something like:

16:27:48 up 14 days, 4:29, load average: 0.05, 0.14, 0.15

From this you can see that my Vera hasn’t been rebooted for 14 days.

However the question remains, why is the vera picking the wrong time. The answer to that must be that the rdate command is unable to get the right time, either because of an internet fault or a firewall. You therefore want to work out which timeserver is giving you the wrong time, or if any of them are giving you the right time. I would suggest opening an ssh connection to the Vera box itself and then running the following command:

rdate -p ac-ntp0.net.cmu.edu

See what you get, does it print the right time? If not you have found your problem, if it does give the right time then try the next timeserver in the list until you find one that gets it wrong. I believe the script that sets the time is coded in such a way that it will keep picking a timeserver to use at random until it gets a timeserver that tells it the time. If you have a timeserver in there that gives strange results then you will get it from time to time and your clock will bounce around.

Normally these sorts of problems are avoided by taking a couple of timeservers and checking that the times given match up, but rdate isn’t that advanced. As a simple bodge to solve the problem you could write a small script combining the ‘date’ command with ‘rdate’ to get the time in seconds since the epoch, download the time from two timeservers and compare the two. Having done that if the times look pretty close you could set the time. You might lose a few seconds of accuracy, but you could be pretty confident it was right.

If this answers the question please let me know.

Hi - thanks for the response. I have tried upgrading via this method three times now without success… I am still on 1.1.1047. Would it be possible to give me the direct url for this beta so that I can try directly from the Vera2 advanced interface?

Thanks in advance

Hi MTF - thanks for your response. My network is pretty solid (in terms of connection time)… uptime on the vera box will be misleading as I have bounced it a few times trying to resolve some of these issues.

However, if I run rdate - I am getting a “timeout connecting to time server” error message.

I am not running a firewall that would restrict this port between the vera box and the router (netgear WNDR3700 router).

I am running the vera with DHCP - but it appears to have full internet access otherwise - I can ping, telnet etc. There should be no reason for rdate not to work as far as I can see…

Any ideas?

Are any of the ntp servers working or do you get the same timeout message for all of them?

I got the following from my box:

root@MiOS_12490:~# rdate -p ac-ntp0.net.cmu.edu
rdate: cannot connect to remote host (128.2.1.20): Connection refused
root@MiOS_12490:~# rdate -p ptbtime1.ptb.de
Wed Dec 1 17:51:38 2010
root@MiOS_12490:~# rdate -p ac-ntp1.net.cmu.edu
rdate: cannot connect to remote host (128.2.1.21): Connection refused
root@MiOS_12490:~# rdate -p tick.greyware.com
Wed Dec 1 17:51:39 2010
root@MiOS_12490:~# rdate -p ntp.xs4all.nl
Wed Dec 1 17:51:40 2010
root@MiOS_12490:~# rdate -p ptbtime2.ptb.de
Wed Dec 1 17:51:40 2010
root@MiOS_12490:~# rdate -p cudns.cit.cornell.edu
Wed Dec 1 17:51:40 2010
root@MiOS_12490:~# rdate -p ptbtime3.ptb.de
rdate: cannot connect to remote host (192.53.103.103): Connection refused

It doesn’t appear to be a great list that they are using in conjunction with rdate, but you would hope that at least one would work assuming there isn’t some sort of network problem.

As far as I can tell (based on the source code) busybox rdate will use a tcp connection to the server on port 37 and wait for up to 10 seconds before giving the error you are seeing.

You should be able to test this theory by using something like:

telnet cudns.cit.cornell.edu 37

It should come back pretty much immediately with “Connection closed by foreign host” and a few junky characters just in front of that. You could also try doing the same thing with your computer to see whether it is purely Vera that can’t get through (assuming you have telnet installed somewhere). This is also interesting because rdate doesn’t use the ntp port it is using the time port instead.

You can also get similar problems if DNS itself is timing out attempting to resolve the hostnames, prior to making the actual call to the time-server.

I have, from time to time, seen Vera have that problem - notably trying to resolve DNS names for services as common as “google.com” (for the Weather Plugin)

Why that happens, I’m not sure.

guessed - dns seems ok… I can nslookup on everything I have tried… the internet connection seems fine.

akashk - I cannot seem to upgrade the firmware - I have tried the steps you mention several times without luck. I have also logged into the “advance config” via the eth2 port and tried the Flash Firmware… it all seems to be working, but the upgrade never takes.

I really need some help - perhaps an MCV tech can remote access the device?

mtf - rdate doesn’t work. I can telnet to rdate on the PC’s in my same network and can connect - but for some reason the Vera2 will not make a connection.

I am running 1.1.1047. I have even tried a “factory reset” but that just seems to wipe out the config and not reset the firmware…

Any other ideas please?

M

PS - I am starting to think that this particular device is a lemon.

If rdate doesn’t work then there is a network problem, but it still doesn’t really answer why the time is being reset because once you set it by hand it should remain correct unless the Vera is unplugged or reboots itself.

Vera also tries to keep the time right by setting the last modified timestamp on a file as it shuts down and setting the time using that timestamp as the default when it boots up. The file is “/etc/init.d/luci_fixtime”, so I am wondering what you get from:

root@MiOS_12490:~# ls -al /etc/init.d/luci_fixtime
-rwxr-xr-x 1 root root 323 Jun 13 20:17 /etc/init.d/luci_fixtime

As you will see I get a time of 20:17 13 June 2010, so if I pull the power on my Vera then prior to rdate doing its job I would expect to find that set as the default time and I can confirm that is exactly what happens for a few moments before the real time is obtained. [People experiencing strange switch on times may wish to consider what would be happen if their own Vera momentarily thought this was the correct time!] In your case because rdate isn’t working due to a networking problem I would expect your Vera to go back to the time shown on the file whenever it powers up.

Now if you aren’t pulling the power out on your Vera and it still goes to the wrong time I would guess you will find that the output of ‘uptime’ indicates that unexpected restarts of the Vera are occuring.

So there are three options from here:

  1. If your Vera is restarting on its own and you don’t really need it to restart then try to work out why and having done that just remember to correct the time when you power it down yourself.

  2. Work out the source of the network problem (which is almost certainly external to the Vera) and would no doubt be a very good thing

  3. Replace rdate with something that will work from your network, or put something else in place to set the date and time when the Vera starts up

To be honest I can’t really help you with options 1 and 2, but I can offer you a temporary bodge to deal with option 3.

Edit the file /etc/rc.local and put the following in it above the ‘exit 0’

date -D ‘%b. %d, %I:%M:%S %p’ -s “wget -q -O - http://tycho.usno.navy.mil/cgi-bin/timer.pl | grep -E 'EST|EDT' | cut -c5-24

In brief this command attempts to set the time using a web page provided by the US Navy. If you aren’t in the EST timezone you change it to CST, MST, PST, AKST or HAST. Sorry, but there isn’t an easy way to get any other timezones (except UTC). I wanted to try to make it work it out using the local timezone, but busybox doesn’t appear to take into account any timezones listed. You probably want to cut and paste to make sure no mistakes are put into the code. You can also run the command from the command line to check it works for you.

Please let me know how it goes.

Yes it does seem that the date associated with /etc/init.d/luci_fixtime is the date being reset back to.

In terms of rdate and “external networking issue” - I don’t buy it. From that vera box I can wget, telnet, ping… you name it. There is no port based block on my internet router/gateway - certainly not outbound… and so it just doesn’t make sense.

ok, it was more of a DNS failing-via-Vera situation, never worked out why it was timing out. DNS everywhere else (other machines) would be fine, but on Vera it woud periodically fail/timeout for some odd reason. Might have been during “that time” when Vera was overriding our DNS providers with a “special” one.

Any other ideas? I am really getting frustrated with this… the part where it controls z-wave devices seems great… but this other stuff is an unnecessary distraction at the moment and preventing me from using Vera at all.

This is a known issue with the 1047 firmware (per MCV tech support). I was having the exact same problem with the date resetting back with my new Vera2 UI4. From your home network, when you click on the link that I mentioned earlier, what happens? Are you able to click continue at the bottom of the page? After that it should be a pretty simple process.

The process is straightforward and very simple to follow (excellent in fact).

It identifies my Vera - says that it needs to be upgraded… I tell it to do so… it downloads and then gives me the 15 minute message with a timer.

After 10-15 mins it tells me it was successful. I see the Vera reboot.

Yet… nothing is updated.

I have tried many times both via the LAN (DHCP) connection as well as via directly connecting to the eth2 port from my laptop. Same result - process followed, but nothing updated.

I have also tried switching it off after it says successful myself - unplugging all cables - waiting 3 mins - and then hooking it all up again.

The firmware remains at 1047.

Looks like this one is for the Vera support team.

Dare I ask if you put the line in /etc/rc.local that should cure the problem by using something other than rdate at boot time that will work and keep your Vera with the right time?

We both have Vera2 with the same firmware installed. I have 3 of them and you have 1 of them. All of mine have a fully working rdate and yours doesn’t. Networking is clearly working on yours and mine, but your access to port 37 isn’t working and mine is. This smells of a network problem somewhere external to the Vera unless you have set some special firewall rules on your Vera?

Have you considered downloading a packet sniffing tool to see what your Vera is doing?

What is 100% clear is that if your date is defaulting back to the timestamp on that file then you have a Vera that is rebooting itself, either because you are pulling the power lead or there is a fault on it. That is a problem you will need help from MiCasaVerde with, but again it isn’t a problem I am seeing with any of my boxes.

Perhaps the easiest option of all is to take the Vera to a neighbour or relation’s house and just to plug it in there to see if rdate works on their network, especially if they use a different ISP and/or different hardware for their router.

Incidentally when rdate is hanging, what do you see if you type:

netstat -nt | grep :37

I would be interested to know what the last word is, do you see something like ‘ESTABLISHED’ or ‘SYN_SENT’?

HI MTF – I didn’t do it - only because my time is GMT (London) and although I have every confidence it would work… it would set to the wrong time and therefore wouldn’t solve my problem completely.

I am confident that my network is not causing the problem - I have 8 boxes of various sizes and shapes and none of them have problems. That doesn’t mean that networking is not the cause however. Could the problem be with the VERA firewall itself? I don’t know much about it - but as I am not blocking port 37 / rdate anywhere… perhaps VERA is?