Access time warp?

  • 1
  • Problem
  • Updated 1 month ago
I have been pulling my hair (what little I have left) out for over a week now because the data reported in charts on my dashboard don't match reality - what I see on the charts matches weather that occurred hours earlier.

Note that data going to Weather Underground seems to be spot on!

Don't tell me to delete, reset, and add my access and sensors again because I have gone through that process.

One thing that I have noticed is that if I browse to the IP address of my Access, I see times like this: 

   SIGNAL:433MHZ

   #TypeIdLast Time (UTC)SignalBattery
   0tower000072822018-02-28T01:22:533Normal
   1tower000006332018-02-28T01:22:202Normal
   25N1000035602018-02-28T01:22:383Normal

The problems are that 1. these readings were taken at about 6:05pm EST on 02-27 (over two hours earlier than the UTC listed); and 2, over time, the gap between the times returned and the actual time varies.

Another part of the problem is the Dashboard often shows the sensors offline when, in fact, data on Weather Underground does not skip a beat.

WTF is going on?
Photo of David Pushee

David Pushee

  • 30 Posts
  • 0 Reply Likes

Posted 5 months ago

  • 1
Photo of John Z

John Z

  • 903 Posts
  • 188 Reply Likes
David,


Access has an internal real time clock. It should be synchronized to network time by an occasional call to an NTP server. That doesn't seem to be working in your device. Hopefully nothing is blocking the NTP server response.


Data to MyAcuRite is getting incorrect time stamps. I think data is sent to WU without time stamps and is stamped by WU on arrival.


Let's see if you can force a clock update. Get into the Access internal web page. If the time shown there is incorrect, click the Save and Restart button, and recheck the time. Not sure if that helps, but it might. Note that it will take a few moments to reacquire your sensors, and you will likely have to refresh the Access page a few times.

This really should not be needed, and I suggest it more as a diagnostic rather than a remedy to be used and reused.
(Edited)
Photo of David Pushee

David Pushee

  • 30 Posts
  • 0 Reply Likes
John, That sounds like a reasonable explanation for what I have seen.  I did a reset of the Access via the diagnostic page and the time returned looked reasonably accurate.  

I suspect a problem in the internal clock of the Access unit as just 10 minutes after resetting, i did a refresh of the diagnostic page and saw times that were about 15 minute ahead of the actual current time.

I had a look at my router (TP-Link Archer C9) and it reports current times matching my cell phone clock.  I see that it does allow me to optionally specify time servers, but those have not been specified.  The router admin page does have a "get GMT" button, and that returns reliable times.  

Thanks for your help so far.  Do you know if the Access internally specifies the time server(s) to use?  
Photo of John Z

John Z

  • 903 Posts
  • 188 Reply Likes
No, David, I don't know. I suspect it is in the firmware. There are folks here equipped with packet sniffers that could probably answer that.

If you get a good time just after a reset, and then find that soon after , its wrong again, that sounds like a stability problem with the internal clock oscillator, as if the crystal there is not in complete control. I would watch and keep records on how often you need to reset. That might show a case for a replacement device.
Photo of David Pushee

David Pushee

  • 30 Posts
  • 0 Reply Likes
Thanks John.  Based on your replies, I tried an experiment.

I used the diagnostic page to restart the Access and at intervals refreshed the diagnostic page and noted the current time from my cell phone and the "last time" reported by the Access for sensor transactions.  

What I found was that over a period of about 2 hours and 20 minutes, the internal clock of the Access counted an elapsed time of about 6 hours.  At that point, the Access apparently contacted a time server and reset its clock to the actual current time.  Following that, the entire cycle ran again.

I also observed the MyAcurite Dashboard and noted that after each time reset, the "last update time" held at a clock time prior to the reset and stayed that way for about an hour and a quarter.  During this time, the status degraded from green to yellow to red and finally back to green..

It appears that MyAcurite accepts the data carrying time stamps 3 hours or more in the future and, when the Access resets its clock, MyAcurite rejects or ignores data carrying time stamps that are earlier than previously accepted data.  

I invite the engineers from Acurite to monitor my data stream and see what kinds of changes they need to make.
Photo of John Z

John Z

  • 903 Posts
  • 188 Reply Likes
David,

That's great work! Your results are very interesting.

Its sometimes happens that a crystal oscillator will refuse to run at its fundamental frequency, and will jump up to a third overtone. Maybe that is what is happening here.

It's clear your clock is running rogue, and I'm not sure there is any option but to replace the device.
(Edited)
Photo of Doug Barkus

Doug Barkus

  • 260 Posts
  • 42 Reply Likes
Mine has also consistently show UTC + 15-17 minutes since I got it back in January.  I assumed it was an Acurite time server issue.
Photo of David Pushee

David Pushee

  • 30 Posts
  • 0 Reply Likes
John,  I'm glad you mentioned the rain reset possibility.  I had noticed a few mid-day rain resets on WU.  One of them occurred on 2/24 and shows sometime around 9:15pm.  Looking at that day on MyAcurite, the rain total carries all the way to the last entry at 11:55pm.  I think your theory is correct.
Another, more recent, rain reset happened in mid-day when I did the full disconnect, power down, restart and reload process.  In the case of my unit, I think the reset would have to show up no earlier than about 3.5 hours before midnight as that is about how far ahead of reality the unit gets before it resets the time.
Photo of John Z

John Z

  • 903 Posts
  • 187 Reply Likes
Yeah, I'm still scratching my head on that one. I pulled it from my post because the more I thought about it the more confused I became. Still, there may be a connection.

Your data certainly supports that, but it may be a special case reset. I have seen other resets, but yours is the only reporting I am aware of where MyAcuRite and WU reset at significantly different indicated times.

BTW, hitting Save and Restart forces a rain reset, I think, so dont let that trip you up.
(Edited)
Photo of David Pushee

David Pushee

  • 30 Posts
  • 0 Reply Likes
John, I don't think I had done any resets on 2/24.  What I think is happening is that time stamped data from the access is accepted by MyAcurite at face value and stored in the database (even though the UTC time has not yet happened).  If it is the Access unit itself that resets the daily rain at (what it thinks is midnight), it is possible for my unit to hit midnight up to 3 hours and 30 or 40 minutes prior to actual local midnight.  On 2/23, I see that WU showed 2 rain resets (one at 8:36pm and one at 11:12pm).  Both of those resets were within the window that could be explained by the overclocking.  MyAcurite showed the rain holding until the last entry at 11:57.
I have a couple of earlier rain events, that seemed to reset at appropriate times, but I can't recall exactly when I replaced the Hub with the Access.  I ordered the Access on 1/31, but really can't recall exactly when I installed it and replaced the Hub.
I'll be contacting Acurite tomorrow to discuss getting a warranty replacement.  I'm expecting rain tomorrow and will be home so I'll monitor for rain resets.
Photo of John Z

John Z

  • 903 Posts
  • 187 Reply Likes
David,

Good luck to you. I think you have made your case with excellent logic and data.

For me, it is wonderful to find folks like you here who think and experiment and think some more.

Best wishes, JZ
Photo of John Z

John Z

  • 903 Posts
  • 188 Reply Likes
Doug,
I'm pretty sure Access reaches out to an NTP server. AcuRites' virtual machines are not the best time standards.

Not sure why yours reads so far off of UTC. Are you getting that result from the Access splash page? Right after Access recovers from a Save and Restart click?
Photo of Doug Barkus

Doug Barkus

  • 260 Posts
  • 42 Reply Likes
Yes to both.
Photo of John Z

John Z

  • 903 Posts
  • 188 Reply Likes
Puzzled, SMH.
Mine is tracking perfectly with cellular network time.

I wonder if Access pulls time from the AcuRite servers as a "Plan B" if an ISP or router has NTP servers blocked.
(Edited)
Photo of mike

mike

  • 15 Posts
  • 0 Reply Likes