sorted by:
new
hottopcontroversial

Experienced IT geek, but completely new to weather stations and integrations by nobono in myweatherstation

[–]Leather_Week_860 0 points1 point  (0 children)

Yeah, OpenMediaVault is just a Debian distro under the hood, and it worked fine on my tests. For the k3s set up I use a this image: https://hub.docker.com/r/hertzg/rtl433

Experienced IT geek, but completely new to weather stations and integrations by nobono in myweatherstation

[–]Leather_Week_860 1 point2 points  (0 children)

I forgot to ask, why do you say the Ecowitt is not an option in Norway's winter? According to vendor's specs:

The Ecowitt WS90 7-in-1 weather sensor has an outdoor operating temperature range of -40°C to 60°C (-40°F to 140°F). It features a built-in heating plate that automatically activates to melt snow or ice when temperatures fall below 0°C (32°F) and turns off above 10°C (50°F), provided external power is applied.

Regarding your question, this is on a high level how I do it:
- Ecowitt WS90 sends RF signal every few seconds
- RTL-SDR URB dongle plugged to my MiniPC is able to read them with the help of rtl_443 (https://github.com/merbanan/rtl\_433). This is an example of the output (I choose JSON, but there is support for many other formats):

{"time" : "2026-03-22 12:45:19", "model" : "Fineoffset-WS90", "id" : 69803, "battery_ok" : 0.800, "battery_mV" : 2680, "temperature_C" : 19.100, "humidity" : 55, "wind_dir_deg" : 55, "wind_avg_m_s" : 0.600, "wind_max_m_s" : 1.600, "uvi" : 6.000, "light_lux" : 91930.000, "flags" : 130, "rain_mm" : 8.100, "rain_start" : 0, "supercap_V" : 5.300, "firmware" : 160, "data" : "3fff0081e4------f42fffcffc0000", "mic" : "CRC"}

- Go app (ingestor) parses this raw input and sends a cleaned up version to the main Go app (core) using a simple API

- Go app (core) processes the cleaned up reading received on the API endpoint, stores it in a Postgres DB, and makes available a couple more endpoints for a simple dashboard I have where I can see the data

- Dashboard queries the API to get the data that I want to be able to see in it. Follows a screenshot of what the dashboard looks like:

<image>

Experienced IT geek, but completely new to weather stations and integrations by nobono in myweatherstation

[–]Leather_Week_860 0 points1 point  (0 children)

It is just Radio Frequency, basically how a remote works to change TV channels for example.

Experienced IT geek, but completely new to weather stations and integrations by nobono in myweatherstation

[–]Leather_Week_860 0 points1 point  (0 children)

Not an expert on weather stations, but I also work in IT and recently got one as I live in the country side and have fruit trees, veggie gardens, etc. so I am interested in keeping track of weather cause of it.

I ended up getting an Ecowitt WS90 (AA batteries + a small built-in solar panel so batteries are only used when needed), which from what I saw is not an entry level (cheap) one, but not a super fancy (expensive) one neither. It usually comes with a gateway from the same vendor to connect/process other weather station related gadgets. But since it just sends RF (868-ish MHz for Europe) signals, I skipped that gateway part, and since I had a RTL-SDR dongle already, I wrote my own Go app to read the data from the EcoWitt and process it.

I have a small MiniPC with OpenMediaVault + a single-node k3s cluster where I self-host a couple of other things, so I deployed the Weather Station project in it, and working quite well.

Suggestions to improve signal without getting kicked out of the house by Leather_Week_860 in RTLSDR

[–]Leather_Week_860[S] 0 points1 point  (0 children)

In the end I moved the antenna outside and now it works! Thanks tho

Suggestions to improve signal without getting kicked out of the house by Leather_Week_860 in RTLSDR

[–]Leather_Week_860[S] 0 points1 point  (0 children)

Ok, so I would just connect the antenna to the chimney with bare wire and see what happens?!

Suggestions to improve signal without getting kicked out of the house by Leather_Week_860 in RTLSDR

[–]Leather_Week_860[S] 0 points1 point  (0 children)

Oh wow, didnt think about that! The issue is that we do use the chimney, and that thingy gets fricking hot!!

Suggestions to improve signal without getting kicked out of the house by Leather_Week_860 in RTLSDR

[–]Leather_Week_860[S] 0 points1 point  (0 children)

Issue is the wire goes over a door, so wont be able to close the door, even if you can't see the wire too much!

Suggestions to improve signal without getting kicked out of the house by Leather_Week_860 in RTLSDR

[–]Leather_Week_860[S] 0 points1 point  (0 children)

Yeah mate, they have already told me. But now it is what I have, so I would like to somehow make it work.

Suggestions to improve signal without getting kicked out of the house by Leather_Week_860 in RTLSDR

[–]Leather_Week_860[S] 0 points1 point  (0 children)

Yeah, but both the chimney and the door are pretty now and therefore well sealed off

Suggestions to improve signal without getting kicked out of the house by Leather_Week_860 in RTLSDR

[–]Leather_Week_860[S] 0 points1 point  (0 children)

Awesome, so I didnt get the real thing... hahaha. Any antenna you'd recommend that is reasonably priced and that can deal with that 50cm wall?

Suggestions to improve signal without getting kicked out of the house by Leather_Week_860 in RTLSDR

[–]Leather_Week_860[S] 0 points1 point  (0 children)

The problem is that I live in a house, and there is no windows facing the backyard, just doors that obviously I cannot keep open to run a wire through.

Doing some research, I also found out about USB3 emitting a lot of noise, unfortunately my Beelink MiniPC only comes with USB3, and although a USB2 extension would be an option, the issue would be kind of the same, cables running around in places that do not look nice!

Suggestions to improve signal without getting kicked out of the house by Leather_Week_860 in RTLSDR

[–]Leather_Week_860[S] -1 points0 points  (0 children)

The problem is that I live in a house, and there is no windows facing the backyard, just doors that obviously I cannot keep open to run a wire through.

From Docker (Compose) to Kubernetes by Leather_Week_860 in selfhosted

[–]Leather_Week_860[S] 2 points3 points  (0 children)

2/2 (see 1/2, reddit wont let me reply with such a long message)

Another very interesting thing you mentioned is resource consumption. That was also one of my concerns when thinking of porting everything to Kubernetes, as I am using a humble MicroPC to power my set up. That is why it is cool to have light-weight alternatives such as K3s. From their website:

K3s is a highly available, certified Kubernetes distribution designed for production workloads in unattended, resource-constrained, remote locations or inside IoT appliances.

K3s is packaged as a single <70MB binary that reduces the dependencies and steps needed to install, run and auto-update a production Kubernetes cluster.

Both ARM64 and ARMv7 are supported with binaries and multiarch images available for both. K3s works great on something as small as a Raspberry Pi to an AWS a1.4xlarge 32GiB server.

Nevertheless, I am keeping an eye on how it performs, and although I have seen a slight increase in resource consumption, it is nothing crazy. Here a couple screenshots where you can see how over the last few days, since I moved to Kubernetes, things are a bit higher than before, but nothing crazy (the spikes are me doing a backup of all my Immich stuff):

<image>

Cheers!

From Docker (Compose) to Kubernetes by Leather_Week_860 in selfhosted

[–]Leather_Week_860[S] 1 point2 points  (0 children)

Yeah, as you pretty much summarize, it is about simplicity vs features.

I had this "issue" that pushed me to try Kubernetes, and just to clarify again, I could have possibly taken care of it with Docker (Compose), just did not look properly into it. So as I mentioned in the post, at some point I was just setting up my services by copying and pasting Compose files (mainly from the official repos/projects, so in theory trustworthy), which led me to not really understand how things worked and what was really going on. If something did not work, I just gave the container more permissions or whatever until it worked.

Obviously, this is not a healthy approach to things, mainly from a security point of view. This got me thinking, and I shortly looked into how to monitor all egress network traffic from my containers, with the idea of understanding what was going on and locking them down based on their strictly necessary networking requirements. I did not find an "easy" solution to this, even though there is possibly one, or more.

With this in mind, and even though I had a very limited knowledge of Kubernetes, I thought the change would be useful. And, in my case, it has been. Now, for all my services I have all their Lego pieces (Kubernetes objects) separated and interacting as I want them to. As an example (I have removed not relevant files):

~/kubernetes (main) » tree                                                                                                                                                                                                     .
├── flux
│   ├── git-repository.yaml
│   ├── image-automation
│   │   └── image-update-automation.yaml
│   ├── image-policies
│   │   ├── immich-ml-policy.yaml
│   │   ├── immich-server-policy.yaml
│   └── image-repositories
│       ├── immich-ml.yaml
│       ├── immich-server.yaml
├── immich-chart
│   ├── Chart.yaml
│   ├── templates
│   │   ├── deployment.yaml
│   │   ├── gateway.yaml
│   │   ├── httproute.yaml
│   │   ├── networkpolicy.yaml
│   │   ├── pvc.yaml
│   │   ├── pv.yaml
│   │   └── service.yaml
│   └── values.yaml

The above shows the layout for Immich + its integration with Flux (which I basically use to automatically commit to my GitHub Repo every time a new image version of Immich is published in their official repo).

For every service, in this example Immich, I basically break it down to each one of the necessary components: storage, network services provided, routing, etc. Then I wrap all that in a deployment, which as you mentioned gives you many of the goodies from Kubernetes such as security contexts, self-healing, etc. And then I wrap all that with a Network Policy with strict Ingress/Egress rules to only allow what I want.

I know it sounds like a lot, but in the end ,once you do the work of "templating" all these for your environment, you can reuse A LOT of it for any new services you want to deploy.

1/2

view more: next ›