Help request: Installing weewx on a DS918+ NAS using Docker (Davis VP2+), connecting to Wunderground

[WeatheredScientist]

Hello to all!

I have a Davis Vantage Pro2 Plus weather station that is up and running. This is a new system, so it comes with the iPad-like Weatherlink Live console.

I have tried using ChatGPT and Claude to get an instance of weewx running in a Docker container on my Synology NAS. I have not had much luck, which seems to be a common experience with this approach. I'm adept with technology and computers, but I am not a programmer, even though I have programmed a bit in the past.

Can this group provide steps to getting weewx set up in a container on the NAS, connecting to services like Weather Underground? I feel like I got close, but I am not even sure how to describe what the LLMs guided me to do. Largely, I was able to get weewx "installed", but seemed to be having problems with the config file. I did see at one point weewx outputing data, but it wasn't able to connect to wunderground, even though I had provided my station name and key in the right section (so maybe no using the right config file).

Happy to provide much more info, just need guidance on what.

[Vince Skahan]

Which docker image and driver are you trying to use?

[WeatheredScientist]

To be honest, I am not sure. I had Docker up and running on the NAS long before all this. When I look at the app in the NAS OS, it lists the Docker version as 20.10.3-1308.

[Vince Skahan]

Not which docker version. Which weewx ‘image’ are you trying to run via docker ?

[WeatheredScientist]

Haha I realized my mistake too late. To hopefully answer your question, I am trying to run felddy/weewx.

[Vince Skahan]

Looking at the DockerHub page at https://hub.docker.com/r/felddy/weewx the 'Running' section has the procedure for getting it working.

I have no idea how much compatibility there is for an old version of Docker on a NAS.  Sorry.

[WeatheredScientist]

Thank you. I am going to read through that. It turns out that my DS918 was running an older version of its OS than it should have been (long boring story). I updated it and all the packages, which included a swap out of Docker for what Synology calls "Container Manager". Lo and behold, I can see all the instances of weewx I tried to get up and running: 4 with ChatGPT, and one with Claude.ai. The last one is was still trying to run, and crashing within a minute, then auto-restarting.

After reading through the guide, I'll see what I can find, if anything, in the logs.

[WeatheredScientist]

What I've come to realize is that I have to intercept the radio signal from the ISS in order to do what I want with weewx.

To that end I've purchased an RTL-SDR v3 dongle, which may or may not be DOA (TBD!). But the idea is to use that as my receiver, then decode with the rtldavis driver for weewx. I'd like to demo it on my PC or macbook first before messing with a container just to get all the other hiccups (like no phase loop locking and apparently no detection of the ISS 1m away, see DOA TBD). I see that you (Vince) had a github repo with some resources for the same, but it doesn't accessible anymore. Has it moved somewhere else?

Getting there, slowly!

[Greg Troxel]

WeatheredScientist <pata...@gmail.com> writes:

> What I've come to realize is that I have to intercept the radio signal from
> the ISS in order to do what I want with weewx.
>
> To that end I've purchased an RTL-SDR v3 dongle, which may or may not be
> DOA (TBD!). But the idea is to use that as my receiver, then decode with
> the rtldavis driver for weewx.

My advice is to build the latest rtl_433 from git and listen on 433.92,
315, and 915, or something else depending on what country you are in
(and hence what the allowed frequencies are).

Also check which librtlsdr you have, but with a v3 (vs v4) it should be
ok.

You should see lots of things decoded, that you didn't know existed,
like temperature sensors, car TPMS and more.

Only when you can decode random other stuff should you try to listen to
your ISS.


The Davis RF protocol is vastly more complicated than everything else,
and needs synchronization, and you need to select the region-specific
hopping patterns. I think it takes a while to figure out where in the
cycle the pattern is and can then follow it. I haven't done this; I
just know there be dragons.


(You could also consider
https://www.meteobridge.com/wiki/index.php?title=Meteobridge_PRO2
which seems to mostly work but has awkward interfaces if what you want
is weewx. It's also real money compared to a RTL-SDR dongle.)

[WeatheredScientist]

Dragons indeed! I've gotten a copy of rtldavis working on a MacBook with the dongle. I now know my neighbor's water usage, which is great, but not the ISS :-)
The problem I seem to be having, grossly, is either locking onto the ISS in the first place (though I do seem to handshake at times) and sticking to it thru the hops, and then getting that feed interpreted into a usable format. I seem to get stuck with weewx just spitting out simulator data.

It's tough troubleshooting to me b/c I am using outputs as diagnostics, and there are "chained layers", in my own words. I wish I could see more than just a handshake with the ISS signal, but once it does that to have rtldavis spit out what it is receiving onto the command line. Happy to start over, just not quite sure how.

[Vince Skahan]

Can we keep it to one thread here for this please ?  I think the other one makes more sense FWIW.

[John Smith]

I seem to get stuck with weewx just spitting out simulator data.

Did you switch drivers in weewx.conf?

weeWX can spit out debug data from the configured driver on the command line too.

If that's not detailed enough, you could add extra logging lines to the driver, python isn't compiled in the same way as C code, so you just need to copy and paste similar logging lines and change variable names and then restart weeWX.

--
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/b338de45-20f3-4b4c-b988-7d596e80ae58n%40googlegroups.com.

[vhel...@gmail.com]

Hi,

I suggest you to use Virtual Machine Manager and install there simple basic Debian linux with weewx and passthrough the RTL-SDR usb device there. There has been problems with docker and usb devices in Synology NAS:es lately. 

[WeatheredScientist]

That's brilliant advice: I learned from Vince that his repo is built for Raspberry Pi, and (correct my words if wrong) assumes/prefers a Debian distro. I was planning on using container manager in the Synology OS, but perhaps the VMM solution is a better one for no other reason than permitting a simple Debian environment. TBH, I am not sure what container manager is using.

What would be useful for the community re: the mac? Is it worth trying to write-up what I did for future reference? Or too one-off to be worth it?
Next up before the Syno is my PC. I am hoping it will be quicker based on previous experience, though I did set up Ubuntu over Debian in WSL. If successful on the Win11, PC, again, worth a write-up? Or too outside of what most users here are interested in doing?

Thanks to all, especially Vince, for the immense help, guidance, and above all, patience.

-Mike

[John Smith]

Or too outside of what most users here are interested in doing?

The internet is a big place, someone somewhere will eventually stumble upon it appreciate it saving many hours repeating what you can short cut for them.

Above all it would be a handy reference for yourself when you need to revisit in future and can't quite remember exactly what you did the first time :)

--

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/7747bb27-ddf1-4159-841b-e941b245d44an%40googlegroups.com.

[Vince Skahan]

A vagrant/virtualbox VM or dockerized equivalent should be doable on either x86-64 or raspi platforms since they support accessing the physical RTLSDR stick attached to the host platform.

Passing a device to docker is easy. I do it for a zwave antenna into home assistant running into docker on a x86-64 box here.   I don’t remember if I have tried it on virtualbox.

I have no idea how to pass the device through to a vm or container on a mac but perhaps parallels or fusion support that now on m-series macs.  Virtualbox might still be limited on mac. Macs can be weird. Zero idea on anything NAS. Never used one,

[WeatheredScientist]

I got it working on the Mac, tried it on a PC, ran into issues with USB and the need to frequency hop (vague, I know, but bottom line didn't work) and then went for the NAS.

Created a github repo:
https://github.com/weatheredscientist/weewx-rtldavis

and a docker image
https://hub.docker.com/r/weatheredscientist/weewx-rtldavis

I ran into issues with the dewpoint and pressure due to how those are calculated, where and when. Long story short, to avoid null values being displayed, I had to prevent weewx from updating those fields, instead relying on WLL to supply those. That leaves pwsweather without pressure, but that is pretty minor unless you aboslutely rely on that for anything. I rely on it for nothing, but for giggles I might force my orbit b-hyve to do smartwatering based off my weather station and it's hyperlocal rainfall.

Please let me know if I've done anything wrong with the github and docker links and their content. I'm hoping to make it easier for anyone else looking to do this sort of thing. I get the sense that this is super specific to just me, but I'm guessing that as more people upgrade to the new console, this will become more of an issue.

Cheers!
Mike

[Vince Skahan]

Nice.

Looking at the dockerfile you could maybe shrink the size and reduce the number of layers by doing multistage builds,  chaining all your RUN steps into fewer steps with && and doing the copying a little differently if you wanted to try that.

But disk is cheap and it's easy to squash the layers I guess.  If it works that's fabulous.

Only thing I'd suggest adding might be a docker compose file with examples of how to pass the USB device through on a non-NAS typical box.

Very cool.  Victory beer worthy !

[WeatheredScientist]

I realized that there were still a few little minor annoyances, and probably more in the next few days and weeks. But I got the most immediate ones: dewpoint and pressure. The former is a calculation, the latter only comes from the WLL console. Since that updates WU every 15, there is pressure recorded, but the table data and live feed will show "--" because weewx has no pressure to report from its ISS feed. I got it to not report those fields, and just post a cached value from WLL till WLL has pushed a new value.

I've committed those most recent tweaks. I'll let it sit for a bit and then figure out any other big changes and how to optimize like you suggested. 

I hope it is useful! I am sorry that I couldn't get it to work on Windows, since there are a lot of Windows users out there.

[John Smith]

I ran into issues with the dewpoint and pressure due to how those are calculated

I vaguely remember way back when I was considering a Meteostick I didn't go ahead because, at the time, it lacked a pressure sensor and the ISS doesn't have one either.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/6fcd78fd-e838-4082-8a10-aa3562134f0en%40googlegroups.com.

[Vince Skahan]

I added a bme280 or bme380 on a little breadboard when I did my non-docker setup a while ago. I'll have to dig that up when I get a chance, but no idea if that can be dockerized too

[WeatheredScientist]

I have a nice powered breadboard to test that out on, did see the BME280 and they are cheap. It is dockerizable as well, but that is a future project.

[Vince Skahan]

A few questions/comments:

• why are you altering restx.py ?

• no need to git clone librtlsdr sources - they are in the src.tgz bundle you're already downloading and extracting to /tmp

• no need to copy anything into the venv at all, having the .py files in weewx-data/bin/user will work

• why are you running syslogd ?  Is it a NAS nuance ?
  • You can add a few lines to weewx.conf to get it to log to stdout and then 'docker logs' will show them, although the host will need to handle rotation
  • See https://www.weewx.com/docs/5.3/usersguide/monitoring/#logging-on-macos for what'll work in Docker too

• you might want to think about using ubuntu:26.04 to get the current os rather than a 4-year old 22.04

I got it to build just fine with ubuntu:26.04 as-is once I changed the python version references to match that os using python3.14

Don't have any gear I can test it on that's free, but dockerizing this thing is pretty slick.  Nice.

[WeatheredScientist]

@Vince, great questions. Keeping in mind, this whole build was heavily AI-assisted, i used claude to answer some of your questions, but i think the responses are reasonable. Please challenge if they are slop!

1. Two reasons: changed >APWEE5,TCPIP*: to >APRS: so CWOP packets appear on findu, and added a 2-second sleep after login before sending the packet so the CWOP server has time to process the login before receiving data. Both are bugs/limitations in the stock weewx CWOP implementation.

2. src.tgz contains the rtldavis Go binary source and the weewx extension; librtlsdr is the C library for the RTL-SDR USB dongle hardware. librtlsdr is a separate C library that must be compiled, it wouldn't be bundled in the weewx extension tarball.

3. Why copy .py files into the venv? weewx-data/bin/user/ should work since weewx adds it to the Python path. We copy into the venv because the Docker image doesn't mount weewx-data at build time — it's a runtime volume. So anything that needs to exist before the volume is mounted must be baked into the image. If you always mount the volume with the files pre-populated, you could skip the copies.

4. Why syslogd? Synology DSM doesn't have systemd journald inside Docker containers, so syslog is needed to capture log output from weewx which uses the standard Python logging → syslog handler. Without it the logs go nowhere. The entrypoint.sh starts syslogd before weewxd.

5. I have no good answers here and dislike Claude's response. I think the current version is fine for now, but it probably should be updated. I hope to keep adding to this (I already have later plans to build a complementary sensor suite for lightning and air quality, plus a non WL console-based barometer), so as time goes on and I extend this I hope to update it. Even now, I have plans to push to the repos, since I've added some other services and found a few issues in how weewx communicates with them that I've fixed and want to update.
For the record, Claude says Ubuntu 26.04 doesn't exist, which isn't true, it's just stuck in the past. Also thinks Python 3.14 is alpha/beta, which is news to even me. Maybe I am missing something.

[Vince Skahan]

Naaah  - Claude is delusional.

1 - not sure it's needed.  I've been sending to CWOP from weewx for over 10 years just fine with no edits required.  If there's an actual need somebody should open an issue vs. weewx itself about that if it's true.

2 - nope - I'm the person who built src.tgz so I kinda know what's in there.  If you look in /tmp you'll see the subdirectory for each piece, and if you look at my build script in the weewx-contrib repo you'll see it uses that to build the variant I cooked up.  The intent there is to have 'all' the pieces in that repo and not rely on the actual upstream developers to keep their repos available forever.

3 - disagree there - my belief is the volumes are mounted before the container's entrypoint exec happens

4 - again disagree  - just set weewx.conf to log to stdout and you don't need any syslogd in the image.  I typically log using stdout to a mounted volume ala /mnt/whatever/log so it's easy to see from the host itself.  The macos example I mentioned shows how to handle logging and rotating.   You need the first half of that example (log to stdout) for running in docker if you do 'not' have a syslogd in the image, but running multiple things kinda violates the one-process-per-container docker mantra for best practices

5 - baloney - I tweaked your Dockerfile to use ubuntu:26.04 and it (a) found it and (b) built an image based on it just fine, once I tweaked your hardcoded python references of course to match the os.  Again, I didn't get a chance to text it, I don't have any ubuntu pi currently.  If I get a chance I'll see if I can rebuild one of my unused pi and try it end-to-end with the RTLSDR and antenna here.

Regardless - if it scratches your itch, it's plenty good enough for you I'm guessing.  Pretty cool no matter how you look at it.  A docker container that does RTL-SDR is goodness no matter how you measure it.

[Greg Troxel]

WeatheredScientist <pata...@gmail.com> writes:

> @Vince, great questions. Keeping in mind, this whole build was heavily
> AI-assisted, i used claude to answer some of your questions, but i think
> the responses are reasonable. Please challenge if they are slop!

Different people have different norms, but I think it's not ok to ask
other humans to wade through and fix LLM output. It's usually overly
verbose, and wrong in ways that are harder to spot than an actual
confused human.

[WeatheredScientist]

I think it's interesting how far the LLM enabled me to go. Just setting up the configs was interesting, I saw it make a lot of the same errors I would have been likely to make (appending text strings instead of replacing, for instance). 

Ultimately, it's working, and I've shared it on github and docker. But it's fair to challenge what's up there to make it better, and make sure there isn't anything unnecessary or sloppy. If anyone is interested in helping, I'm open to learning and improving.

[Vince Skahan]

Interesting but risky. Having done this kind of stuff for so long my continued fear is minimally functional unsupportable garbage. It gave you a working solution ‘as a starting point’ which is fine but ‘shipping the prototype’ rarely ends well. 

And 100% of what it told you was fiction. You”ll not learn best practices not spot security or privacy holes, nor learn what good even looks like. If that works for you, cool. You scratched your itch, and thanks for the github repo which is always appreciated,

[WeatheredScientist]

I get it, wanting to do it right and understand what you are doing. I've worked as a metrologist, which has informed a lot of my interest in instrumentation, data collection, and data sharing.

At this point in life, it's a time thing for me: investing the time to get really good at coding and working with repos and containers is something I just don't have the bandwidth for. It's not a lack of interest, but the time for me to do those sorts of things easily was about 30 years ago, lol. So the AI provides not just a convenience but really the only realistic way for me to accomplish my goal in a reasonable time.

I have all sorts of reservations about AI. It has its places, its use cases. For me, this is was an acceptable use case: no one's life should be in danger, and it provides consistent, reliable data. It's sloppy, but probably way more functional than anything I could have gotten going any time this year.

It's a starting point. Hopefully it can be made better from there.

[WeatheredScientist]

It is meant to be a starting point. I'm bandwidth limited at this point in life, so can't just pick up the skills necessary to do it right. AI was not just a convenience but a necessity, despite my many reservations about it. This was an acceptable use case in my book.

[Vince Skahan]

Just one last update - I took your starting point and tweaked it a bit to do a multistage build to drop the size by 75% and added a docker-compose.yml file to bring everything up and save persistent storage under /mnt/weertlsdr/{archive,log,public_html} for non-NAS users.  Works fine here for me on a current raspios pi4 under docker.

https://github.com/weewx-contrib/weewx-rtldavis/tree/main/docker if you wanted to take a look.

Thanks again for posting the good starting point.

[WeatheredScientist]

Hi Vince (same user, new email). Thank you for doing that. I took that and used it as inspiration (again, lots of LLM, shameful I know, but what I can do is guide a somewhat amnesiac and hyperknowledgable employee) and managed to shrink my docker image by about the same amount you did, but using ubuntu 26 and python 3.14.

I've been busy adding little features and what not. With a goal of explaining it all and making it easy, I've put together a readme and create a new release (2.0) of my take on weewx-rtldavis. This is now the main/latest release now, though I am still tweaking a few things (e.g., working on monitoring dropped packets for a sense of RF rx quality, helpful for adjusting gain).

https://github.com/WeatheredScientist/weewx-rtldavis/releases/tag/v2.0-ubuntu26

I'd be very interested in everyone's feedback on the features, the explanations, the whole lot. Trying to make this the best it can be, albeit within my limits.

Apologies if I've overstepped in using your repo as inspiration.

[gary....@gmail.com]

Excellent write up!
I'm am passingly familar with this configuration, just not with docker.
Looks great.

[Vince Skahan]

Just to give credit where credit is due, I didn’t write the rtldaviis driver…..Luc did.

Please update the credits accordingly when you get a chance….

I just wrote a wrapper to install all the great upstream code a little easier.

Here were the upstream pieces and last commits from the various authors…

* librtlsdr - library to turn Realtek RTL2832 based DVB dongle into a SDR receiver
from https://github.com/steve-m/librtlsdr.git

commit ae0dd6d4f09088d13500a854091b45ad281ca4f0 (HEAD -> master, origin/master, origin/HEAD)
Author: Kacper Ludwinski <kac...@ludwinski.dev>
Date:   Sun Nov 9 21:56:53 2025 +0000

* gortlsdr - 'go' wrapper around librtlsdr
from https://github.com/jpoirier/gortlsdr.git

commit 075e50ef422cf3ba193d1ba6d79a0efea89491e2 (HEAD -> master, origin/master, origin/HEAD)
Merge: 8185285 956e97e
Author: Joseph Poirier <jdpo...@gmail.com>
Date:   Sat May 19 12:17:06 2018 -0500

* rtldavis - RTL-SDR receiver for Davis weather stations
from https://github.com/lheijst/rtldavis

commit b95d5d734e4666c90f3d7539d5e2acd9f80f7e43 (HEAD -> master, origin/master, origin/HEAD)
Author: Luc Heijst <ljm.h...@gmail.com>
Date:   Fri Jun 5 08:43:42 2020 -0300

* weewx-rtldavis - the weewx extension as of 12/20/2025
from https://github.com/lheijst/weewx-rtldavis/archive/master.zip

commit 2f3b4b344fd70ab253aabfa837b0ffc76570c075 (HEAD -> master, origin/master, origin/HEAD)
Author: Luc Heijst <ljm.h...@gmail.com>
Date:   Sat Jan 2 13:56:04 2021 -0300

[WeatheredScientist]

Thanks, Vince. I'll make sure to update it at next opportunity, hopefully tonight. Giving credit is super important to me too, I appreciate you clarifying what should be covered in the readme.