I have one of those cheap (-ish) outside-the-house weather-stations that reports the weather data (windspeed, rainfall, etc) over a wireless link to an inside-the-house display unit. My inside-unit is a display only; there is no way to get the data into a PC or an online weather service.

For a long time, I have wanted to build a device that decodes the wireless data and can then forward that data to an online service.

A bit of reading showed that my system is a local re-brand of a common Chinese brand. The outside-unit transmit data over a 433 MHz link and it not encrypted or secured in any way.

One night, I realised that I am unlikely to be the first person in the world to have this idea. A bit more searching showed that there are a number of open-source software-defined radio projects, and, in fact, one, rtl_433 that can decode data from almost all 433 MHz transmitters: garage door openers, alarm systems, and … weather stations. I happened to have a suitable SDR dongle lying around from a previous project.

Welcome to rtl-weather.

Still, there is a long way between decoding the weather-station data and getting it to appear on a graph on a website.

It turns out that a single Linux pipeline can do it. It took a few hours with a bash-terminal to get each part to talk to the next, but we now have weather data

The pipeline consists of

  • rtl_433, to sniff the 433 MHz band and decode any data it hears, reporting it in JSON format
  • jq, to modify the JSON data into a format suitable for the online service
  • mosquitto_pub, to connect to a remote MQTT broker that accepts the re-formatted JSON data

I already had access to a Thingsboard IoT system. It would not be very hard to modify the script to also report the data to a service that uses an HTTP API, such as MetOffice Weather Observation Website or OpenWeatherMap.

It turns out that I had to add two other things to get it to operate properly:

  • mosquitto_pub does not recover if the remote MQTT broker disappears then re-appears. I had to add a ‘watchdog’ process that looks for output from mosquitto_pub that it has actually sent data to the broker. If is does not see this message after a while, it kill the pipeline.
  • a system service (systemd, etc) to ensure that the weather-reporting service starts when the computer starts, and restarts it if it fails.

I also found that calculating average wind-direction is not the trivial averaging operation – if you naively average east-of-north with west-of-north, you get south. Most IoT service offer only this trivial averaging operation.

To calculate the average correctly, you need to decompose the direction into N- and E-vector components, average these components, then calculate the average direction from the averaged components.

One more stage in the pipeline solves this problem, at the expense of additional storage on the server (2 direction components rather than 1 direction angle) and complexity on the server (calculating the direction from the components when display a graph, table, etc).