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.
On Friday, 24 April 2026 at 02:45:23 UTC-4 [email protected] wrote:
> 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.
>
>
> Paul Cezanne schrieb am Donnerstag, 23. April 2026 um 17:53:04 UTC+2:
>
>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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, '[email protected]' via weewx-user <
>> [email protected]> 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.
>>
>>
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/weewx-user/e041921c-778a-474f-8d86-29fe7b2a6441n%40googlegroups.com.
