Sponsored By

How to Create a Smart Greenhouse with a DIY WiFi Timer/Controller

You can add IoT functionality to any size greenhouse. Here's how to build an Arduino-based timer/controller for controlling lighting, temperature, and humidity.

William Grill

March 8, 2018

12 Min Read
How to Create a Smart Greenhouse with a DIY WiFi Timer/Controller

Large and small grow facilities have special lighting, temperature, and humidity needs. Fans, coolers, heaters, and related venting or air flow controls have become standard requirements in most cases. A simpler, piecemeal approach might use outlet timers and one of a few available temperature and humidity sensor-based switch resources – like the Sonoff TH-16 WiFi base offering – and a simple thermostat solution for temperature maintenance.

Larger facilities, or facilities that are remotely monitored and controlled via a Wifi/Internet connection, suffer from the lack of a centralized control and flexibility, which would allow relative automation over longer periods of time. At the same time it would also offer the ability to dynamically adjust to a cloudy, wet or cooler day.

This project describes an Arduino based timer controller allowing DHT11 sensors, HC-05 Bluetooth, USB linkable configurations, based on a settable real time clock (RTC), and providing monitor reporting. When included, the report is also available on a serial HC12 transceiver link.

The application is coded to optionally include a WiFi link to a ThingsSpeak, IoT platform. This project provides multiple timed-enabled, sequenced switch controls that are configurable to be enabled manually, by temperature and/or by humidity at specific period defined over one of the serial access links.

All timers are based on 24-hour cycles and related timing parameters are entered in hour: minute of day format. The application is configured with RTC.

Three mister/fan outputs, labeled M3, 4, 5, qualified with unique enable start and disable stop timing, temperature and humidity trip values and outputs qualified with up to 2 sensors. Each also enables settable duty cycle (timing ton/toff) operation or a simpler temperature AND OR humidity switch. eg: each output can independently be set, for instance:

A mister application can be set for 10:00 AM to 4:30 PM, cycling 5 minutes on and off every 50 minutes, qualified by temperature over 76 degrees fahrenheit and humidity less than 42 percent.

A second fan set to operate between 11:22 AM to 3:33 PM, constantly on, no cycling, qualified by temperature greater than 81 degrees fahrenheit and the third remaining output used as a heater beginning at 6:30PM until 6:15AM, constantly on, no cycling, qualified only by temperature of less than 63 degrees fahrenheit.

An additional set of outputs, labeled P6,7,8 provides fixed over set/under set controls for each of the three M(ister/fan) outputs described above. Intended for cooler pumps or louver controls they are enabled with a fixed pre-delay of 6.5 seconds preceding each M qualified output when initially enabled and are disabled after a 2-second delay following each M qualified output being disabled. These may be used to stagger power on for swamp cooler or compressors or simply to enable related cooler pumps or over and close related vent louvers.

Two additional timers' functions, labeled L1, L2, each allow two sets of timing qualifications: starton/stopoff1 and starton/stopoff2. Each has an optional temperature trip. These are intended for main or grow lights and fixed time based fans. L1 and L2 temperature criteria are taken from ‘assigned’ sensor. S1 for L1 and S2 for L2 and are configured independently or may be not used at all. For example, a supplemental grow light can be configured to start at 7:00 AM, turn off at 10:00 AM and then on again at 4:00 PM and off at 8:30 PM. The second output could then be used for main lights or for a supplemental night fan coming on at 9:30 AM when the temperature is greater than 69 degrees, off at 12 noon and its second timer set on at 10:00 PM and off at 3:00 AM if the temperature is less than 65 degrees.

Parts List:


Digi Key#





1 Ardurino Nano


ESP-01  module optional


requires 3.3 volt related Interface

ESP-01 Header  module optional


provides 3.3 volt interface

1 HC-05 BT module



2 HC-12 module optional



1 RTC module




8-2 wire headers (single in line)


4-2Pin male header


2 NPN transistors (multiplexer)


9-4.7 K ohm resistor

805 SMT

8-180 ohm resistor

805 SMT

1-680 ohm resistor

805 SMT

1 1N4001 diode


33uF/25V capacitor


0.1uF  capacitor





Perf Board, single sided clad, 0.1” pattern


   OR custom PCB


see text

The Bluetooth and Arduino USB link can be used both to monitor the link report and to set operational parameters. All parameters, including the override settings, are stored into a non volatile EEPROM/Flash memory and are scheduled into a working register array at power up. (Set once and pretty much ‘forget’).

Each M(ister/fan) selects its temperature and humidity percentage criteria. Each mister/fan can configure up to 2 HCT11 sensors as their qualifying source. Each output allows either sensor, the average of both sensors, or neither sensor to be used. There is also a serial parameter entry to qualify each output with temperature and humidity trips settings and a third parameter to select whether both settings or either setting is required to be set for the M output to be qualified.

The L1, L2, M(ister/fan), M3 thru 5, and pump P6 thru 8 outputs are also coded to provide individual, serial link based override controls.

An alarm pin is asserted when the difference in sensor readings is greater than 8 degrees fahrenheit or greater than 8 percent humidity.

The WiFi uplink, when available, is dedicated to an associated ThingSpeak IoT platform channel, allowing results to also be graphed and monitored anywhere an Internet connection is available. The WiFi connect status is included in the link report.

Operational Parameters are used to configure all functionality. A ‘?’ lf/cr provides the parameters/list.

The 2 L1/L2 functions include 2 set of 2 timing parameters, followed by L1 temperature trip and the L2 temperature trip. The 3 M(ister/fan) functions each have 8 parameters.

In addition functions 10, 11, 12 and 13 allow WiFi and report schedules to be set, sensor temperature offsets to be included, and overrides to be implemented. There is an entry timeout and a ‘x’ lf/cr will also exit the menu(s).

For each Timer (Ltime1,2 outputs):

L1time1 TIME/Temp


Where set trips are: 0-ignore

                                  >0 greater than

                                  <0 less than

eg; 2$9:20$10:45$18:0$20:15$0$-67$

result in:

               func 2 L1 9:20AM to 10:45AM, tmr only

                                6:00PM to 8:15PM when less than 67 degr

For each of 3 M(istr/fan) outputs): TIME

eg: MistrTim3

         4$ start1Time $stop1Time $ on2Time $ off2Time$

              if Start=stop-> ignore if offTime=0->non cycled

              time qualification

eg; 4$9:20$10:45$6$20$ TRIP Qualification

results in:

func 4 (M3) 9:20AM to 10:45AM,cycled 6 minute on 20 minutes off

For each MistrFan(M outputs): CRITERIA

eg; 5$2$69$-40$0$

results in:

func 5 M3 Reference average of S1 and S2, Temp>69deg,H<40%,both trips must be met

JP1 may be shorted to use a single sensor for both S1 and S2 related criteria. (The sensors reads are staggered 30 seconds apart.)

Function 10: Report SCHEDULES


A 0 schedule will result in report or uplink only if outputs are changed(delta mode report). Time values is entered in minutes.

eg: 10$0$1$ results in

Function 10, WiFi uplink scheduled on change ONLY, serial based report sent every minute.

Function 11: OVERRIDE

eg; 11$55$ results in ‘disabling’ All overrides

11$99$ forces ALL to override = ‘in-active’

11$4$1$ forces MistTim4 to active

11$4$2$ releases override on MistTim4(only)

Function 12: Sensor Temperature Offset

12$0$-1.5$ results in S1 offset = 0 and S2 offset = -1.5

Offsets are added to sensor’s measured values and are reported and used in criteria.

Function 13: WIRELESS DATA

-generates a list of wireless characteristics to be set

Because Wifi name, password and Thingspeak key(s) are all unique variables they are also required to be set manually.

eg; 1$BobsmagicWiFi$

results in the wifi name being stored as BobsmagicWiFi.

All name data fields may be up to 30 characters and MUST be terminated with ‘$’ char.

14 Report : VIEW DATA

ViewReport(F(14)) forces the report to be displayed over the serial link(s) on demand.


The report request includes status for each output, alarm, other error indications and override statuses are also included in this report.

The WiFi report, when available, is uplinked to the ThingSpeak service. This a web-based platform providing both display charting of uplinked parameters and reporting features. A free registration is available as well as multiple other packages. The free version allows over 3 million data transfers per year. Each package offering, including the free version, are based on annual registration. This requires a registration with an email address. You would need to then request and open 2 channels, record the provided write keys for each channel, and then enter these into the Timer application as ThingKey1 and ThingKey2.

The graphed data may then be optionally customized with labels and names. The several other reporting features can also be added at no cost. These include tweets and emails based on criteria such as temperature too low or alarm set. It provides a MatLab-based language compiler to provide additional processing, if desired. Additional accounts and feature and resources are available with paid registrations.

The uplinked WiFi list includes average temperature and humidity, M(ister/Timer) output statuses, the L(ight/Fan) output statuses, a binary status byte reflecting the bits found in the report format, the MistrPump related statuses and the Wifi update timing setting.

The sensors inherently provide centigrade but I have included scaling, in code, to allow temperature to be read and reported in Fahrenheit. To disable the conversion to fahrenheit short the analog A6 pin, on the Arduino Nano. This is brought out as a pin on J2.

The HC12 transceiver (set) may optionally be added to the application. Intended for monitoring only, up to several hundred meters, currently, a provided jumper, JP3*,would enable the link also be used to configure the application remotely. This link can be configured to operate in 1 of 100 channels and requires paired and matched transceivers. Currently there is no (de)encryption provided on the application, beside that which provided by the HC12 module itself.

There are, of course, other pieces that will be needed to exploit these timers. There are several relay boards which include SPDT (Single Pole, Double throw), 10 amp contacts available on-line. These are inexpensive and configured with buffers or opti-couplers. Both the SSR modules and relays can then be driven directly from the board, which is coded with ‘low true’ outputs.

For compressors and coolers fans, heaters, pumps, and other AC based resources, 20/ 40A SSRs (Solid State Relay) are also available.

In combination using the relays and SSR, you should be able to drive nearly anything. There are a few instances that warrant attention. Some fans provide low, medium, and high settings using a multi-position switch. These switch power to alternate motor winding contacts to obtain fan speed. This can be provided by a simple digital(74HC138) decoder, with SSRs or relay logic, shown below, up to the contact ratings, using this timer application.

Aside from the coded controller board or assembly, the implementation relies on common modules which can be found on the Internet. A 4 and 8 relay board can be purchased online from Banggood, eBay, or Amazon. The other modules, RTC, HTC11 sensors, ESP-01 (and header) and the HC12 transceiver set are also available online through site like Digikey.

Before ordering anything be sure to have a plan. Know what your load requirements are so as to not switch a 15-amp cooler with a 10-amp relay

The WiFi code is already in the controller. The HC12 link requires each unit to be configured and matched for their data rate and channel. The Bluetooth HC-05 module requires nothing and this Bluetooth function is intended to be provided in lieu of a commitment of a laptop or PC to set the timer configurations. The HC-05 Bluetooth is always purchased with a simple ‘HC05’ username and ‘1234’ password.

Shown above was an assembly provided on a PCB. While I have several of those boards, the layout, shown below, is a ‘new and better’ version. This layout hasn’t been qualified with a prototype.

Depending on your comfort level, technical prowess, specific facility needs, and enthusiasm you can do nearly anything. Recall that the board and any pieces you purchase are NOT packaged in a box. This is, again, an issue that cannot be easily anticipated, and is in part why you need to plan. Swamp coolers, compressors, heat lamps, main and grow lights, pumps, and anything electrical will likely need wiring and a secure, weather proof infrastructure.

The 4 relay board, in the photo above, is an optically coupled unit that will be less expensive if purchased directly, online. For 120/220VAC, SSRs, come in 20, 30+ amps, and should always include a heat sink. These should be spec’ed with the 9-11 milliseconds of response time (/w zero crossing synch). These are available online for about $6-9 per set. The smaller SSRs can also be purchased for under $2-3 and provide AC switching up to 2 amps.

I have specified a DS1307 based TinyRTC. These use a DS1307Z (0-70degrC) chip. This is a bit older part, but much less expensive than the DS3231 based module. The modules are ‘almost’ completely compatible. Both boards have an available 32K I2C Flash memory chip configured on their modules, which I use to stash the override status. These memories have different I2C addresses. DS3231 is address 0x57 and DS1307 uses 0x50. To substitute the DS3231, you must either change the definition of eeADR, found above the setup{}, to 0x57 or short the A0,A1,A2 pads found on the DS3231 module.

I have coded for the use of DHT11(~2$) sensors and included the offset option for the temperature value. These are the less expensive brother of the DHT22(~4+$). These are less accurate and have a constrained operating temperature parameter(0-50degC) that will support a typical greenhouse environments. While the DHT22 does have the same electrical interface they DO NOT have the same binary encoded format. For applications that would require operation outside the DHT11 specifications you may use the DHT22, but you MUST change the following coded lines:

Change f = ((9*(R[2]+ float(R[1]/10)))/5)+32; // HCT11 degr F

To f = ((9*((R[2]*256+ float(R[1]))/10)/5)+32); // HCT22 degr F


Change f = (R[2]+ float(R[1]/10)); // HCT11 degr C

To f = (R[2]*256+ float(R[1]))/10; // HCT11 degr C


Change arrayc[r+1] = R[4]+float(R[3]/10); // H% no offset HCT11

To arrayc[r+1] = (R[4]*256+float(R[3]))/10 ; // H% no offset HCT22


The compiled controller is FULL, with less than 1% of its 30720 bytes available.


William Grill can be reached at: [email protected].

[All images courtesy William Grill]

Sign up for the Design News Daily newsletter.

You May Also Like