Designing a Multifuction (Greenhouse) Controller


Hello fellow Particulates,

I am a hardware guy and my firmware skills are limited such that I could, at best, be called a bit banger. Never the less, I have been toying with the idea of making a greenhouse controller for some time now. Basically, the controller is just a collection of inputs and outputs (both analog and digital). I am in the process of spec’ing out a multifunction I/O board the Photon will plug onto.

The controller I/O will comprise of:
Optically isolated digital inputs (120V tolerant)
Digital outputs (relay 250V / 10A)
Digital outputs (SSR for 24Vac irrigation valves)
Temperature inputs (10K thermistor)
High CM analog inputs (0-10V)
Analog outputs (PWM 0-10V)
Chopper drive (variable speed for single phase induction motor/fan)?

The controller will measure and / or control:
Soil moisture
Multizone temperature
Water flow meter
Solenoid valves for misting and drip watering
Damper control with position feedback
Lighting based on sunrise / sunset times
Optional OLED display?
Optional water conductivity?
Optional pH?

I know the Photon lacks the I/O but I can add a CPLD with an I2C slave instantiated in it to act as an GPIO expander. The CPLD can also have the flow meter totalizer as well as a solar radiation integrator (using the PAR sensor). All inputs will be ESD protected in accordance to IEC/UL 60730. The board will fit into an industry standard DIN enclosure with plug in style connectors.

Why am I posting this? There is a lot of commonality between greenhouses, aquariums, terrariums and aquaponics. Perhaps this controller can be leveraged to other application areas with a firmware change and the right combination of I/O.

Are there others out there that could use this controller for themselves?

Are there any additional measurands that should be included?

I am happy to share all the design files. Heck, I will even give you a board if someone wants to help on the firmware side!

More heads are better than one …. right?



This purpose is entirely why I just ordered my first particle with maker kit and some other goodies :grin:

There’s a fella on YouTube who did an Arduino greenhouse controller, very near build. He had soil heating, automatic louvers, irrigation etc. I’m super interested in hearing about any progress on your project!



@Wlavoie: Please post a link to the YouTube video – that would be cool to see. I am actually on the path to building a, hopefully, simple drip irrigation system for our green house.

@geato: Have you made any process since your post? I’d be willing to assist with some programming. I’ve got my hands on an Electron and Photon. I’ve managed to setup I2C between a SparkFun Red Board (5V) and the Electron (3V3) so I can pass around weather info from the SparkFun Weather Shield.


Hi cermak,

I am working on hardware at the moment. I have also been setting up an MQTT broker in my BeagleBone so I am able to run Node-Red. The reason for going with this combination is in addition to the greenhouse, we have some plants scattered around the yard that are protected over winter with cloches and (old style) incandescent xmas lights as heat sources. The xmas lights will be controlled locally with an ESP-01 which is subscribed to the MQTT broker. I was originally going to use a Photon in the cloches but I don’t need all the I/O it has.

The MQTT server brings all the data together which I can access on the Node-Red Dashboard served up on the BeagleBone. With Node-Red I am able to create all the control logic. There is a very nice “node” timer function which I have been testing to control lighting and watering times. There is a built in function to control lights with sunrise / sunset times.

As far as the hardware is concerned, I have the function blocks designed (schematic). I am also thinking of making a plug in for the ESP8266-12 as well as the Photon. I also have the I2C slave running in the CPLD. This gives me all the GPIO I need as well as flow metering and extra UARTS if needed. I have eliminated the OLED display as once can just browse to the web page with their phone or tablet.

I think in the future I will replace my Open Sprinkler and bring control into Node-Red.

Chipping away at it slowly …



Happy to collaborate where possible. Looks like the first thing I need to do is update my spare BBB and look into Node-Red – the Big Timer looks interesting. I will start a separate project thread for yet another greenhouse project and link to this post (in the next couple of days). Node-Red and MQTT would definitely be better than the way I am pushing data around now. It has been very interesting Googling information on the components you mention.

There was one interesting hit for ESP-01 and MQTT (and Arduino) that might be of some interest:

There was this other item that an example of a Spark-Core with MQTT and Node-Red:

Definitely, one step at a time. Rob

Another greenhouse/weather station project (off-grid, very custom); MQTT; Node-Red


Thanks for the links!

If there is one recommendation I can offer, I highly recommend checking out Random Nerd Tutorial. Rui Santos has a paid for tutorial ($25) on Build a Home Autmation System for $100. Rui does an excellent job of walking you through setting up an MQTT broker and getting your feet wet with Node-Red. He focuses on the RPi but the process is identical to BBB. He uses the ESP8266-12 as the client but a Photon can be used.



Very impressive. Thanks for the recommendation. It was worth the $25. A lot of great material there. Rui has a good deal of code out on Github too. I’ll share that link here for completeness.


Which distribution are you running on the BBB? It shouldn’t matter much, but I might want to consider using the same one you are using. I also want to ensure I2C is operating between the BBB and some other device.


I am using Debian. In fact, the newer releases of Debian comes with Node-Red.


@cermak this is the arduino greenhouse controller which inspired me to start learning about these boards and electronics only a month or two ago lol, I’m a big newbie. So far my dht22 is uploading to freeboard and I haven’t had a lot of time to monkey with it yet

He has some other videos of it functioning, and uses it in a couple locations. Videos are dated but I just discovered this world of electronics so I also feel dated lol…


What are you using for the mqtt server?

I have Node Red up and running. I have ordered a BBBW (beagle bone black wireless). The wireless for the regular bbb is not as stable as I like.

Just found this. It connects a lot more of the dots (Sensor -> MQTT -> DB, etc).


Thanks for sharing the video. A very nice box he put together. I like the layout and the different bus voltages. Full on reuse and recycle.


@cermak Nice find .I will go through it later. I am using Mosquitto. I am not 100% sure on this but I think it was pre-loaded with the Debian build. I have not used the BBBw but I certainly feel your pain keeping the regular BBB connected on WiFi. Fortunately I am using LAN but when the connection gets long, I use Dlinks DHP-309AV.

@Wlavoie My setup will be similar however I will be putting the electronics in an DIN enclosure like this: This enclosure will mount inside a PVC IP67 (Nema4x) electrical box. I am keeping the electronics together because it makes it easier to add ESD protection on the points of entry,


@geato: It turns out one does not need to run mosquitto. We should be able to inject right into Node Red service using the MQTT client (port 1883). Mosquito may be important if you also want to use secure transmission with TLS between devices.

EDIT: mosquitto is needed as Node-Red for input (IE: subscribes to feeds at the mosquitto server.) That is a drag since that means one more service to run on the BBB.

This is the main source that has been pulled into the Particle library and is up to date. He has a particle library (as master) and an Arduino branch for using with the ESP hardware or whatever, it is just the MQTT portion, you provide the network connection.


There is an amazing blog full of MQTT and/or Node-Red items, this is just one link:


@cermak - I am using the “Big Timer” node from Scargill. Agree, he is a wealth of information on Node-Red.

Right now I am in a holding pattern waiting for parts. I should learn to just pay the price and order from North America. It takes a month to get stuff out of China.

For temperature, I was going to use thermistors but I thought I might check out the DS18B20. I am an analog / mixed signal guy so my preference is for thermistors because I can easily recalibrate and or validate the operation simply by using reference resistors. Once I get my DS18B20’s (from China) I will toss them into a calibration bath to see how they perform.


I am currently wiring that sensor and a YL-69 to a Mega 2560. Since there isn’t a lot of pins on the Electron, I decided to vet the sensors on the Mega 2560. I’ll have some stable code to compare against the particle library. Somewhere, I acquired a YL-69 moisture sensor. I haven’t found any real calibration for it. Once I know the total amount of sensors I want to deploy, I can do some balancing between the Electron and the Mega 2560. I’ve figured out the wiring needed to get the SparkFun Weather Shield operating on the Mega 2560. With I2C operating between the two I can have the Electron pull data via I2C with the sensor attached to the Mega 2560. Why use the Mega 2560? The Particle Relay Shield just ate 4 of the digital pins.

The one thing that bothers me about the sensor libraries using I2C is each one seems to create a master in their constructor: Wire.begin(). That isn’t going to sit well if I’m going to be using I2C at the top level to communicate with other devices. If I am trying to read a sensor over I2C and another device triggers any other event then there is a collision.

So, there will be four things to balance at least:

  • Serial events
  • Interrupt events (sensors that are collecting pulses over time; wind/rain)
  • I2C events
  • Particle function events
  • Other network events: tcp, udp (if used)

JTOL (just thinking out loud): The function events can be queued for later processing. The command could be captured and a response sent back to the cloud (positive integer indicating number of messages in the queue). That would keep those sections of code short and sweet. The queued actions would take place when possible.

Takes me back to the days when I was playing with a Campbell Scientific data logger.

Anyway. Let me know if there is something specific that needs investigation.


Hello, I would love to learn more about your project. I am designing multiple systems for hydroponic controlled environments.

I’m very active with this group called the Open Agriculture Initiative, we are focused specifically on open source plant science. I have built my own V2 “Food Computer” and am now developing the Minimum Viable Product version and looking at using a Photon for the controller.

Short video explaining OpenAg:

Longer video by founder Caleb Harper:

Let me know if you wanna chat/share ideas.


Another greenhouse/weather station project (off-grid, very custom); MQTT; Node-Red

@Webb.Peter - sorry for the late responce. Was travelling and got back to a garden out of control. I will have a look at OpenAg and yes, certainly interested in sharing ideas.

@cermak - The YL-69 will not last very long as the exposed metal areas will corrode quickly. (Even quicker if there is a net DC bias on the electrodes). The Catnip Electronics version is capacitive and the metal is covered with solder mask. I suspect the moisture will eventually wick into the edges of the board and cause delamination but I that will be over the course of years. It’s a few bucks more but worth it IMO.


@geato - Good to know about the YL-69. The [SHT10] ( looks promising. My project has kinda turned into a reuse and recycle project with existing sensors on hand. I won’t :cry: if the YL-69 kicks the can. There are plenty of forum posts here and at the OpenAd site about sensors – so easy to get distracted. Will probably look through more thoroughly once things are up and running. @Webb.Peter: Happy to help where and when possible.