When implementing my greenhouse control system, I didn't have to start completely from scratch. An older control system already existed with which I had a little experience. Building on this established setup, I decided to use power windows for the hinged skylights (Figure 1) and a fan to circulate the air in the greenhouse. Also, when nighttime temperatures dropped in the spring and fall, I wanted a heater to switch on automatically. In contrast, crops needed protection against excessive heat in summer.

Figure 1: The automatic greenhouse control system regulates when the skylights open and close.

An intelligent control system would also be nice to reference the outside temperature, allowing it to close the windows in time for cool evenings and build up a heat reserve for young crops during the night. At the same time, a reliable clock was essential to adapt to the lighting conditions of different seasons.

All functions should be remotely accessible, with the option to intervene over the web if thresholds were exceeded. Another requirement was an activity log to collect messages from ongoing operations for remote viewing without always having to check the display in the greenhouse. To implement all of this, I used a Raspberry Pi Pico W. In addition to the essential peripheral devices, it now provides the entire logic and a web server.

Getting Started

Unlike the single-board computers from the Raspberry Pi family, the Pico requires very little preparation. I used the WiFi version because the controller could not be managed remotely without a connection to the home WiFi network. I also needed a USB port for the programming. In the development phase, you need to feed the commands externally from the special Python Thonny integrated development environment (IDE) to the controller, and to finish the job, you need to transfer your code to the module permanently.

One advantage of microcontrollers over computers with filesystems is their robustness, with no risk of the SD card or hard drive being damaged by a power failure. You do not need to shut down your controller in a defined way beforehand when switching it off and can instead simply press the power switch. In return, you have to make do with fewer resources and without a battery-buffered real-time clock in the case of the Pico. Luckily, this restriction did not matter for my control system, because I designed in a real-time clock (RTC) to exchange information with a time server on the Internet. The project also had electrically erasable programmable read-only memory (EEPROM) to store the latest setting values.

Setup

The LCD display and the RTC are connected to Pico over an I2C bus and the temperature sensors over a 1-Wire bus. The transistors are connected upstream of the LEDs that occupy three ports. To allow the Pico to control the large consumers such as the window lifters and heater (230V), a relay board with six inputs was also controlled by the Raspberry Pi GPIOs. In this use case, the Pico sits in a housing and on its own small circuit board. All other components (see the "Parts List" box) were connected by plug connectors and put in a DIN top-hat rail housing (Figure 2). The idea was to keep things manageable for any service work and to be able to disconnect all the components easily.

Figure 2: The components in this setup are connected to the Pico board by plug connectors.

A 5V power supply powers the entire circuitry, and 12V is required for the window motors. In case of activity, the current there needs to be relatively high. To avoid the power supply being constantly idle, and to remove the need for DC/DC converters, the 12V motor power supply is only switched on with a relay when needed. Most of the time, I make do with a frugal 5V circuit to save money.

Most of the hardware is housed in a prefabricated enclosure – a fuse box with a weatherproof seal (Figure 3). I wanted to take advantage of a DIN top-hat rail housing to be able to arrange and exchange individual modules easily side by side. Whatever didn't fit beside the circuit breaker and power supply units was located in empty housings for the top-hat rail (e.g., LCD display, switches, and LED). Enough space was left in their housings to install the Pi, the relay board, and the rest of the electronics closer to the rear, resulting in an uncluttered front side.

Figure 3: All components are mounted on DIN top-hat rails in a weatherproof housing.

I then routed the wires out to the lift motors, fan, heater, door contact, temperature sensors, and network connection through the enclosure, making sure that everything was watertight. All of the outdoor wires first were routed to clamp connectors on the inside so the control and switch enclosure could be tested separately from the rest of the external installation and be easily assembled.

Control

If you take a look at the few alternatives available for purchase, you'll quickly discover that various controllers are often limited to thermostats only and are difficult to expand. However, I wanted to use my own accessories and be able to program everything. To operate the solution, I use a central control script main.py in the usual style for the Pico and added methods for the LCD controller and DS1307 chip to the source code.

Development occurred in the Python Thonny IDE (Figure 4), which integrates the Pico seamlessly. MicroPython was the programming language of choice. If you have a device without MicroPython, you first need to take care of loading the latest firmware. Numerous workable how-tos for this step can be found on the Internet.

Figure 4: The Python Thonny IDE was used to develop the code for the controller.

After applying the operating voltage, the Raspberry Pi initially checks to see whether all of the components are in place and whether all of the peripherals can be accessed by I2C or the 1-Wire bus. If this is the case, the system can be fired up. In the case of less serious events, such as a missing Internet connection or an inaccessible time server, the system continues and tries to establish contact at a later time. After that, the Pico lowers the windows to the stop position to adjust the zero points in case the windows were open. The window lifters have internal stop switches, so I didn't have to connect anything to the Pi.

The current operating values are queried in an infinite loop and checked for the designated upper and lower limits for switching the actuators, followed by appropriate actions. The system is really smart in this way because a variety of indoor and outdoor conditions play a role. For example, knowing whether the access door is open or closed is important for ventilation, and different switching values for everything depend on the time of year because climate parameters such as insolation will vary. The controller also provides different hystereses depending on the time of day, to avoid repeated switching. In the evening, for example, the windows are kept closed longer to store some heat for the night.

The script is also responsible for displaying the current values on the LCD display of the control panel on the outer wall and for writing logs, which you view in the web app. Scheduled actions are reported in the message log, as well as exceptions into a separate error log, such as a sensor failure or exceeding maximum or minimum temperature limits, because errors and warnings are retained for a longer period of time. At the end of the day, then, you can find out what has been going on with a quick check of the app or the LCD display.

The corresponding switching values are defined as constants in the source code by default. If required, the constants can be customized later in the EEPROM, which you can also write to from the web app. For the app to work at all, the script keeps trying to reconnect at regular intervals after a connection loss. The exact time is also resynchronized regularly. In general, the Raspberry Pi's MicroPython interpreter should never stop, if possible; you want it to keep things under control whatever else happens.

I worked with the uasyncio library to allow ongoing operations and web interface updates to take place in parallel. The library provides an asynchronous scheduler that assigns application time to both tasks, which makes it a great choice for this use case: to ensure smooth operations (short response time after pressing a button in the web interface) on the one hand and smooth processing of the program (avoiding long waits for requests from the web server) on the other.

Of course, you also want to be able to control all of the functions manually as an alternative. For this to happen, a multipole switch disconnects the actuators from the control system so that each of the two windows can then be set to the desired position without conflicting with the automatic system, and the fan and heater can be set. The LCD display backlighting also is manually switched on to make it easier to read in the evenings.