We have to realize at this price point we are dealing with toys. That's why many of us have to tweak the product to get it to work more like higher-end weather stations. Most people probably never even check their data, that's the customer's Acurite probably wants and likes. We are probably a thorn in their side. Of course with the smartHUB the stations work pretty darn well. The Access puts more in the toy category.
If you want a more robust system you'll have to pony up the cash and get a Davis or something from Ambient Weather. Even through the Acurite will have the more expensive Atlas I wouldn't touch it as it will use the same defunct Access we all have trouble with thus, putting it back in the toy category, and an expensive toy at that.
If your dead set on the Atlas, give it a year or two and see if they can fix the Access issues first.
When your Access goes offline, do both sensors go offline at the same time always or does it seem one does more than the other? I have one 5 in 1 sensor and 6 other sensors using the Access unit. For me, sometimes they ALL go offline at the same time. Mostly, the alerts appear randomly from different sensors in clusters of 3 to 5 sensors at a certain time and sometimes alerts will be reported across a 2 to 15 minute period. There generally appears to be about 6 hour window in-between the alerts events.
Do the sensors come back online by themselves or do you have to do a power cycle to get them back up and running? The repaired Access unit worked fine for about 3 weeks and then the alerts started. The sensors seem to be reporting data fine even with the alerts. I did a full power-off of the Access unit. Power, Ethernet cords and battery removal for about 30 minutes. It worked fine for another couple of weeks and started up with the alerts again. Like some others, I believe that it started sending alerts after a power failure. I cannot be sure since the sensors and the Access unit are at another location. The outages must have been brief because a few clocks had to be reset but not long enough for our backup power generator to come online and report a power outage.
If you are sending to Weather Underground, do you lose connection to WU as well? I do not send data to WU.
What building material is between the Access and the sensors? The walls are 2 by 4 construction with interior drywall and outside vinyl siding. Floors are 2 by with plywood and rugs. The sensors are distributed all around the house. 3 sensors and the 5 in 1 are on the same floor as the Access unit. The remaining 3 are on the floor below.
What is the make and model of your router? Are you using a switch? TP-Link AD7200 Wireless Wi-Fi Tri-Band Gigabit Router (Talon AD7200). The Access unit connects to a TP-Link 8 port Gigabit Switch port and the TP-Link Switch is connected to a router Gigabit Ethernet port.
What brand of batteries do you have in your Access? I'm using Duracell which I've replaced twice and still have the same issue.
Do you have the Access within 3 feet of any major electronics, router and smartHUB included? If so, please move the Access away from the electronics as far as the Ethernet cable will allow you. I have finally moved the Access unit as far away as I can with the Ethernet cord you provided. The older bridge was much closer to the router using a 2 foot cable (The old bridge sat on top center of the wireless router surrounded by 8 802.11xx antennas) for a year and did not ever have this problem.
I also extensively use 2.4 GHz 802.11N Leviton smart switches and wireless Philips Hue Smart Bulbs throughout the entire house along with a couple of TP-Link Access Points. Again, no problem with the old bridge.
Q1 - how much time elapses before you notice this problem?
Q2 - what sort of firewall policies do you have in place?
I ran some netcaps to see what my Access was doing and learned a few things:
On startup, the Access does this:
a. requests an IP address using DHCP. If this is successful,
b. spends a few seconds validating that the IP address it wants to use is really available
c. sends a name request to the configured DNS server for pool.ntp.org. If this is successful,
d. <IMPORTANT> sends an NTP query to one of the addresses it received for pool.ntp.org.
f. sends a name request to the configured DNS server for atlas-firmware.myacurite.com
g. connects to one of the IP addresses for atlas-firmware.myacurite.com using TLS 1.1 and they exchange data
h. sends a name request to the configured DNS server for atlasapi.myacurite.com
i. connects to one of the IP addresses for atlasapi.myacurite.com using TLS 1.1 and they exchange data
..lather, rinse, repeat steps h and i about every 3-5 seconds
If you've properly configured your device for Weather Underground, you'll also see:
- name request to the configured DNS server for www.weatherunderground.com
- connection to one of the IP addresses for www.weatherunderground.com
- data transfer using cleartext HTTP 1.1
..this cycle repeats about every 10 seconds.
1. If your configured DNS server fails to respond, the Access will try to make name queries to Google public DNS servers at 22.214.171.124 and 126.96.36.199. If your firewall policies disallow this, then time sync and reporting will be broken.
2. If you disallow outbound NTP to the Internet, then time sync and reporting will be broken.
3. because these overlapped reports occur at relatively short cycles, if your firewall tries to be smart about detecting malicious traffic, the Access requests may appear as malicious traffic and get blocked. This will, of course, cause reporting blackouts (at least).
4. Setting DHCP option 42 (NTP servers) in your environment will not change the Access behavior, because it doesn't request DHCP option 42.
I've been capturing data from the Access all day, and so far, I've only seen two NTP requests in 5 hours, but the netcap will be running all night, so I should get a better sense of the cycle in the morning.
Before sending in, I turned off all the firewalls on the router and my Macintosh system firewall without a change. I even tried DMZ and the Access was plugged directly into my Spectrum router. My DNS servers are the Google ones. None of that made any difference. Besides, you really should not have to turn off a standard firewall to get a new piece of equipment working properly.
In my case the drifting starts right away, but going OFFLINE happens after about 3 hours. When that happens the time drift from UTC is about 5-6 minutes.
Here're my firewall settings....
The Access unit has a static IP.
When the lease time is 24 hours(default) the drift takes the unit OFFLINE.
When the lease time is 60 minutes the drift does NOT happen.
Changing the lease time is what got MY unit back to providing reliable service.
Great detective work!
It's disappointing to hear of units being returned for this issue and they come back to the owner with the same problem.
Interesting idea about the Ethernet controller injecting noise into the clock circuit. I'll have to move my unit to see if the drift rate changes.
My guess is that not a large fraction are seeing this clock issue, but that those who are consistently report .
It may be that only those devices that have processors or Ethernet controllers on the "hot, fast" end of the performance distribution are involved. Speculation, of course, and we may never know the answer.
Hope you are strong and well.
We have had a few users experience the same difficulty, and this step has proven to improve the situation in some of these cases. We would recommend that you rotate the Access, say 90-180 degrees at a time until you can find a spot that works well. After rotating, leave the Access in the location unless you go back offline. If you do go offline try rotating again. The best experience we have found that if the Ethernet port is 12 o'clock and the blue light is 6 O'clock, between 6 and 12 facing the 5N1 outside provides the best reception.
Please contact us again if you need further assistance.
BTW, I don't have a 5N1, I have three separate sensors located in various places around my house so rotating the Access to cover all 3 according to their suggestion, is impossible.
Probably time to give up on this and seek a different solution.
I decrypted the update traffic from the Access and was amused to find yet another case of protocol abuse. The Access sends an HTTP POST request with content-length:0 and all of the data as query parameters. <sigh> That's a GET mechanism, folks... ..and it populates the HTTP Host field with atlasapi-development.myacurite.com - completely different from the atlasapi.myacurite.com it places in the server_name_indication field or the DNS query it issues for that service. IOW, it just doesn't care who its talking to as long as it responds "HTTP/200 OK" to it's traffic (if it cares that much).
More interestingly to the assemblage herein, the Access *does* communicate time to the MyAcurite servers as a "dateutc" field, which is expressed in UTC format to the whole minute, i.e., YYYY-MM-DDTHH:MM:00 (seconds are always 00). In contrast, it only sends the text "now" in that field to WU.
Although Acuparse was useful in simplifying the setup for decryption (thx, George), it's not displaying the data and apparently not forwarding to myacurite.com properly (unit shows as offline after a few minutes). Acuparse does connect to and communicate with the MyAcurite servers, they just don't seem to like what it has to say. I'll have to engage in a bit of troubleshooting before I can set up another time drift test to see whether the MyAcurite servers are rejecting the Access update request when the Access time > 5 minutes.
Yes, a timestamp is sent by the Access to myAcuite. That's well-known. Wunderground uses "now" for simplicity, but you can send a timestamp if you need to report older (or unreported) data.
I'm not sure what you mean by "protocol abuse". The reporting method used by Acurite, wunderground, and a few other weather networks are closely related. They have evolved over time but still retain traces of their legacy. This is not at all unusual.
Acurite has different APIs for different purposes. That is not unusual, either.
The Ubuntu Apache reverse proxy is set up and my device shows green on the MyAcurite dashboard. I can see what the device sends, and how the service responds.
There are a couple of Apache configuration tweaks specific to this traffic that took some sorting, but it's all good, now. I'm happy to package up the .conf files and the configuration details if anyone wants it.
I'll respond tomorrow (it takes that long for my Access to drift far enough to fail) with my results, assuming it repro's again.