Mysterious dropouts

[NotThePainter]

I have a weewx station that has been running error free for several months. It runs on an older MacBook Pro that has been hardened to survive power failures and reboots. It is in a remote location and I never got around to setting up the remote shell access so I can debug it at all. (I'll be home in a few months so I can fix that!)

I use healthchecks.io to let me know if something is catastrophically wrong with the setup. Last night it went off line, twice, for about 90 minutes each time. This is not that odd, let's say the internet went down at that location.

What's odd is the pattern I'm seeing in the data collected. I use an ecowitt GW300 and it is setup to backfill data. The GW300 does have a battery in it.

The odd pattern is that it intermittently drops data for a few hours. Then it completely drops data for several more hours, except for one tiny sample. See the attached photo, it will be clearer

We do know the GW300 was running, since my data is correct on the Ecowitt servers. My data is missing on the wunderground servers.

Now I know this isn't much to go on, especially since there is no chance of any debugging, I can't look at error logs, can't do anything really. But I'd love to hear any wild theories, I'll hopefully be able to check them out when I get home, but I suspect my rotating logs will be aged out when that happens.

But it is curious!

[John Smith]

Does your sensor also have batteries?

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/ee71c2b0-1a40-44f4-86a8-92dfe86d2c7dn%40googlegroups.com.

[Vince Skahan]

Does the dropout always happen overnight when it's dark ?

Have you ever checked ecowitt servers when the dropout was in progress ?

Is your internet actually dropping during those time periods ?

[Mike W]

I have experienced similar dropouts. I believe, but have no means of confirming it, that it is caused by local interference degrading the RF link. In this area its probably caused by utility meter comms or IOT links, both use 800Mhz, 2.4Ghz and 5Ghz link comms.
I could only cure it by remoting the receive station to a better location and utilising VNC over SSH to view the display.
It might also be possible to employ a remote receive aerial using a coax cable connection to the receiver, YMWV. hth.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/CAGTinV5XbyG_1CqSJjC1SWDkr%2BmCXABmD_%2BtXQy3mOsRxiWz8Q%40mail.gmail.com.

[michael.k...@gmx.at]

Track the signal quality of the sensors. As far as I know, Ecowitt determines the signal quality for WN/WH3x humidity, barometric, and temperature sensors by comparing the expected transmissions with the values actually received from the sensors. These sensors transmit data every 61 seconds. If the signal quality drops, it means the gateway console has missed one or more transmissions from the sensors. There are many possible reasons for this, such as rolling down shutters, lighting interference, and similar factors.

[Paul Cezanne]

Thanks for all the help, this is a puzzler.

I did ask Claude.ai, it wanted to make sure I had fixed IP address, I did, the laptop didn’t sleep, it doesn’t and the laptop had had a software update, I have that turned off. :- (

On Apr 22, 2026, at 6:25 PM, John Smith <deltafo...@gmail.com> wrote:

Does your sensor also have batteries?

Both sensors have batteries. Both dropped in the same pattern, but the GW300 reported all the data to the Ecowitt server, which did not have a drop at all.

On Apr 22, 2026, at 11:05 PM, Vince Skahan <vince...@gmail.com> wrote:

Does the dropout always happen overnight when it's dark ?

Have you ever checked ecowitt servers when the dropout was in progress ?

Is your internet actually dropping during those time periods ?

It only happened once, so no pattern. I did check the next morning, the Ecowitt servers have complete data. I’m not at the site so I can’t tell if the internet dropped.

On Apr 22, 2026, at 11:46 PM, Mike W <pen...@gmail.com> wrote:

I have experienced similar dropouts. I believe, but have no means of confirming it, that it is caused by local interference degrading the RF link. In this area its probably caused by utility meter comms or IOT links, both use 800Mhz, 2.4Ghz and 5Ghz link comms.
I could only cure it by remoting the receive station to a better location and utilising VNC over SSH to view the display.
It might also be possible to employ a remote receive aerial using a coax cable connection to the receiver, YMWV. hth.

The GW300 is in an outbuilding, but that building does have wifi repeater. There is an external antenna on the GW300 also.

On Apr 23, 2026, at 2:12 AM, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:

Track the signal quality of the sensors. As far as I know, Ecowitt determines the signal quality for WN/WH3x humidity, barometric, and temperature sensors by comparing the expected transmissions with the values actually received from the sensors. These sensors transmit data every 61 seconds. If the signal quality drops, it means the gateway console has missed one or more transmissions from the sensors. There are many possible reasons for this, such as rolling down shutters, lighting interference, and similar factors.

How do you know the signal quality? And the gateway did not drop the data, it is on the Ecowitt server, my weewx dropped.

[michael.k...@gmx.at]

Then it is not an issue with the signal quality sensor <=> gateway. With the GW3000 driver the signal quality of the sensor should be mapped or at least be mappable to a obs_type. With logs, there might be an obvious solution visible.

[NotThePainter]

The dropout became permanent on May 8. I was still traveling. I'm back home now and had Claude Code (an AI) look at my scripts. It found two bugs. Here's what it said it did.

⏺ WeeWX stopped updating May 8 — two bugs in ecowitt_http driver v0.1.0a28

  ---

  Bug 1: Firmware update check kills the collector thread

  The driver checks for Ecowitt firmware updates once every 24 hours. It does

  this by calling get_version() on the gateway. On May 8, that call timed out,

  which raised an unhandled DeviceIOError inside the collector thread — crashing

  the thread permanently. The main WeeWX process stayed alive (and launchd

  didn't restart it), but with the collector thread dead, no data was polled and

  nothing was published. The process sat idle for 6 weeks.

  Fix: add to the [EcowittHttp] section of weewx.conf:

  firmware_update_check_interval = 0

  

  ---

  Bug 2: WeeWX crashes on restart due to missing api_key

  When WeeWX restarts after a gap, it tries to catch up missing archive records.

  The driver first tries to get history from the local device, which fails with

  a CatchupObjectError (caught gracefully). It then falls through to try the

  Ecowitt.net cloud API — but that requires api_key to be set in the config.

  Mine was commented out.

  The bug: the driver accesses self.api_key directly, raising AttributeError

  instead of CatchupObjectError. The exception handler only catches

  CatchupObjectError, so the AttributeError propagates all the way up and

  crashes WeeWX on every startup attempt.

  Fix: add to the [EcowittHttp] section of weewx.conf:

  [[catchup]]

      source = device

  This restricts catchup to local device history only. If the device doesn't

  support it, it fails with CatchupObjectError which is caught gracefully and

  WeeWX starts normally. If your gateway has an SD card (mine has 1GB), it will

  actually recover the missing history automatically on startup — which it did,

  recovering 6 weeks of data.

And the cool thing is, ALL the past data was available, I'm please with that.