This is a project following up on the previously printed Weather Station design (https://www.thingiverse.com/thing:2849562) published about March 2018, I have rearranged the sensors and electronics, and used a 433MHz wireless connection between the remote sensors and the receiving console. The weather data can be be displayed in a number of ways eg on an LCD Screen (20x4), or serially printed directly to the Arduino IDE terminal, or sent as a CSV string to a Raspberry Pi for database and graphing display. (Console LCD not essential in that case).

You will find a short demo video of the printed parts and electronics working at Youtube Link: https://youtu.be/bPasvq7NFdE

The wireless design is based around 433MHz transmitter/receiver combo, and the packets are sent using Manchester protocol. This is explained fully in the Arduino source code (use with mono-spaced typeface). The algorithm decoding the Manchester format has been revamped considerably, and is now much easier to understand (and repurpose!). The Arduino programs are not long or overly complicated and should be a good starting point for medium skilled builders.

For the 3-D printer parts (and a demo Arduino Uno setup) please refer to my Thingiverse project:
https://www.thingiverse.com/thing:2849562 (this project's prints are all reusable here)

For more detail on how Manchester protocol works, please refer to my GITHub site:
https://github.com/robwlakes/ArduinoWeatherOS

For an example of what can be done with a Raspberry Pi and CSV weather data, please refer to my website:
http://www.laketyersbeach.net.au/weather.html
(Disclaimer: note that this site uses commercial sensors, Oregon Scientific, but does use an Arduino to feed CSV files to the RPi from the intercepted 433Mh signals).

I have attempted to calibrate the rain gauge, but have not successfully calibrated the anemometer. When I get the right equipment I will publish a conversion factor. At the moment the transmitter simply transmits the number of 'clicks' the rain gauge and anemometer make. It is best to apply a conversion factor in the receiver console. The temperature data in the packet has been deliberately reduced in precision. One byte is used to store the outside temperature, and an offset of +20 added to allow for negative temperatures. Using a DHT22 sensor for temperature and humidity will improve accuracy and would warrant sending more accurate temperature.

The 433MHz is definitely "old School" these days but is still a robust, very economical choice and I leave it up to others to add more sophisticated interfaces like LoRA, BT or WiFi.