Python 3, but I don't recall Weewx version. One thing I wonder is whether it was conflicting with CumulusMX, which was also running on the same RPi (but those were the only two things running).
The rest of my systems are built to work with CumulusMX and all is well with them, so I think I'll likely just stay with that. Perhaps it will inspire me to learn Groovy. But I've heard much good about Weewx.
Yes, if you have both running at the same time, you will eventually hit a conflict managing the physical device. WeeWX will exit if it experiences a protocol error accessing or managing the device.
FWIW, getting data from CumulusMX to Hubitat might be a challenge. Learning Groovy isn't much of an issue, but you also need to extend CumulusMX itself, which is rather monolithic and not designed for extension.
Hmmm... I have extra RPis sitting here, so may just build one to run Weewx and swap out the entire RPi as a trial. CumulusMX has served me well, but if I can get Weewx to run reliably AND talk to the HE locally, that would be a better solution as both weather programs report to the same services (e.g., WU, CWOP, etc.). Thanks for letting me know about the conflicts.
Does anyone know if any of the rain gauges supported by WeeWX are event-driven, rather than requiring a scheduled poll? My Netatmo Rain Gauge only supplies data when it is polled by the indoor base station every 15 minutes, which doesn’t seem to be a user-configurable interval. Combined with the “tipping bucket” measurement mechanism that isn’t triggered until 0.3mm of rain is detected, this means that it might be (very) lightly raining for some time before WeeWX would report an “it is raining” event.
I don't personally know of any that are truly event driven. Some devices have a tipping bucket while others use ultrasonic detection. Either way, a very light rain generally takes some time before being reported.
The 15 minute polling seems wrong though. Taking a quick look at the Netatmo driver code, the driver itself has a default polling interval of 300 seconds (5 minutes), and is user configurable via the "poll_interval" variable. I can't speak to the communication between the sensors and the base station, but I doubt it's longer than 5 minutes.
You’re right, I re-checked the documentation, and the devices report every 5 minutes, but the base station only uploads to the cloud every 10 minutes. Since there’s no local polling API AFAIK, that’s the limiting factor.
I've been using this for about a year now, and it's been working great. I would like to know how to bring the outside battery status and possibly the wireless connection strength status in as well. Is it possible to modify the driver to include these additional attributes?
I'll look when I have a chance. One immediate issue I see is that the status items are not normally part of the data loop, so they would have to be done separately.
FWIW, WeeWX has a good battery alarm. Are you using it?
Thanks for the tip. I am not currently using the lowbattery.py notification. I will look into it. I have been moving more of my low battery items into Hubitat to centralize my workflow.
Thanks for this, @dennypage. Another in a collection of cool stuff you've done for HE/us.
An FYI for other noobs like me...if you're installing this to use w/an Ecowitt GW1000/GW1100, you'll also need to install the GW1000 driver from below, the GW1000 driver is not built into the basic install:
I installed the driver after installing WeeWX on my Pi, and then ran reconfigure to select it as the driver.
sudo wee_config --reconfigure
Then restart the service: sudo /etc/init.d/weewx restart