Raspberry Pi Greenhouse Controller – Part 2

In part one, we put together the basic hardware for our solar-powered, Pi-controlled, greenhouse fan. This time, we’ll look at how to actually control the fan with Python on a Raspberry Pi.

Preparing the Raspberry Pi

There are plenty of resources online about getting up and running with a Pi, and that’s not really my objective here, but I’ll describe the high-level steps. I used the Raspbian Lite image, though other distributions can work as well. Installing it is just a matter of writing the image to an SD card, adding an empty ‘ssh’ file to the boot partition to turn on SSH, connecting it to Ethernet, and SSH’ing in. Once you’re connected, you can configure WiFi and unplug the cable.

The Motor Controller

Using the motor controller itself is pretty simple. The Pi controls it through pins on the yellow connector, it’s powered through the green connector, and it connects to the motor with the black connector.

The yellow connector has 5 pins: a 5V power supply (the Pi documentation says that we more than the 0.5a it can provide, so we can’t use it to power our Pi), three I/O pins, and a ground. The I/O pins are control the state of the motor as described in the following table:

By controlling the power supplied to IN1 and IN2, we can switch between braking, dangling (spinning freely), forwards, and backwards. For example, if IN1 and IN2 both have power, the motor is off, but if we turn on IN1 and turn off IN2, the fan will spin forward. The PWM pin, described more below, is used to control the speed, if used. If it’s not used, it can just be directly connected to power so that it’s effectively always set to full-speed.

Controlling the Fan State

The Raspberry Pi has a number of GPIO (general purpose input/output) pins. Essentially, each pin can be set to either input, where we can read if there is power on the pin, or output, where we can supply power on the pin (or not). GPIO on the Pi works at 3.3 volts, so you’ll need to make sure any devices you want to use can accept that voltage. Some require 5 volts, for example. The motor controller we’re using operates from 3-5 volts, so we’re good!

First, we’ll control the motor without speed control. I connected the motor controller’s IN1 and IN2 terminals to GPIO 12 and 16, respectively. Here is some Python using the wiringpi library to control the fan speed. Running it will cause the fan to spin forward at full speed.

#!/usr/bin/env python3
import wiringpi

fwd_pin = 12 # IN1
bwd_pin = 16 # IN2

def fwd():
    ''' 
    Make the motor spin forwards
    '''
    wiringpi.digitalWrite(fwd_pin, 1)
    wiringpi.digitalWrite(bwd_pin, 0)
    
def bwd():
    '''
    Make the motor spin backwards
    '''
    wiringpi.digitalWrite(fwd_pin, 0)
    wiringpi.digitalWrite(bwd_pin, 1)

def off():
    '''
    Turn of the motor (dangling)
    '''
    wiringpi.digitalWrite(fwd_pin, 1)
    wiringpi.digitalWrite(bwd_pin, 1)

def brake():
    '''
    Brake the motor
    '''
    wiringpi.digitalWrite(fwd_pin, 0)
    wiringpi.digitalWrite(bwd_pin, 0)

# Initialize the wiringPi library
wiringpi.wiringPiSetupGpio()

# Set both of our pins into output mode
wiringpi.pinMode(fwd_pin, 1)
wiringpi.pinMode(bwd_pin, 1)

# Turn on the fan
fwd()

Speed Control with PWM

Pulse-width modulation, briefly, controls the percentage of time that the pin is on, called the “duty cycle”. If the pin is high half the time, the duty cycle is 50%. The rate of these pulses is the frequency. You can picture this as a square wave. In this case, you don’t really need to know too much about PWM to use it.

The Raspberry Pi’s hardware can generate a PWM signal on GPIO 18, so that’s what we’ll use. We’ll connect GPIO 18 to the PWM input on the motor controller, and modify the above code. The motor controller’s manual suggests a 20khz signal, so we’ll aim for that. Here’s a snippet of code showing the PWM setup on the Pi:

pwm_pin = 18 # GPIO 18 supports hardware PWM
clock = 4    # Must be at least 2
max_range = 240  # 19200000 / 4 / 240 = 20000 (20khz)

# Just for verification
# It's not actually required that we calculate this.
freq = 19200000 / clock / max_range
print("Frequency:", freq)

# Configure PWM on our pin
wiringpi.pinMode(pwm_pin, 2)
wiringpi.pwmSetMode(wiringpi.PWM_MODE_MS)
wiringpi.pwmSetClock(clock)
wiringpi.pwmSetRange(max_range)

# Actually start the PWM signal at 50%
duty = 120
wiringpi.pwmWrite(pwmPin, duty)

The formula for calculating PWM frequency on the Pi is 19200000 / clock / range. The ‘range’ supplied is the maximum value that can supplied to pwmWrite(), so with the above code we can set the duty anywhere from 0 to 240. We’ve hardcoded the value 120, which will run the fan at 50%.

Here’s a more complete version, one that allows us to specify a percentage on the command line:

#!/usr/bin/env python3

import wiringpi
import sys

fwd_pin = 12
bwdPin = 16
pwmPin = 18
clock = 4    # Must be at least 2
max_range = 240  # 20khz

# Sanity checks
if clock < 2:
    print("Clock must be at least 2")
    exit(1)

if len(sys.argv) < 2:
    print("Usage: %s <Duty Percent>" % sys.argv[0])
    exit(1)

#
# Our control functions
#

def fwd():
    ''' 
    Make the motor spin forwards
    '''
    wiringpi.digitalWrite(fwd_pin, 1)
    wiringpi.digitalWrite(bwd_pin, 0)
    
def bwd():
    '''
    Make the motor spin backwards
    '''
    wiringpi.digitalWrite(fwd_pin, 0)
    wiringpi.digitalWrite(bwd_pin, 1)

def off():
    '''
    Turn of the motor (dangling)
    '''
    wiringpi.digitalWrite(fwd_pin, 1)
    wiringpi.digitalWrite(bwd_pin, 1)

def brake():
    '''
    Brake the motor
    '''
    wiringpi.digitalWrite(fwd_pin, 0)
    wiringpi.digitalWrite(bwd_pin, 0)

# Setup wiringpi and GPIO
wiringpi.wiringPiSetupGpio()
wiringpi.pinMode(fwd_pin, 1)
wiringpi.pinMode(bwd_pin, 1)

# Convert the requested percentage to
# a value between 0 and 'range' (240)
duty = int(max_range * (int(sys.argv[1]) / 100))

# If 0 is given, just turn it off.
if duty == 0:
    off()
    sys.exit(0)

# Configure PWM
wiringpi.pinMode(pwm_pin, 2)
wiringpi.pwmSetMode(wiringpi.PWM_MODE_MS)
wiringpi.pwmSetClock(clock)
wiringpi.pwmSetRange(max_range)
wiringpi.pwmWrite(pwm_pin, duty)

# Enable power
fwd()

Next time, we’ll add a temperature sensors to control the fan automatically.

Raspberry Pi Greenhouse Controller – Part 1

In this project, I’m using a solar panel to charge a 12v Marine/RV battery, which will power a Raspberry Pi and an exhaust fan for an off-the-grid greenhouse. My first goal was just to have an exhaust fan that keeps the temperature in the 80-85°F range, but it’d also be cool to add a web interface for climate and power stats, automatically control lights, water plants, etc. First, we’ll just start off with the exhaust fan.

The first thing we needed was a fan. I installed a 20″ DC Snap-Fan with the help of my father-in-law. It operates on 12 to 24 volts, with more speed as the voltage increases. To test it out, we just hooked it up to a small timer and a 12 volt battery. (The fan blades look strange in the photo because it’s running.) With the timer in place, the fan would stupidly run during the daytime, no matter the temperature. Time to make it smarter!

The Pieces

An enclosure. This is just a nice box to house all of our electrical components.

A Raspberry Pi to act as the brains. Mainly we need it for WiFi and GPIO (general purpose I/O), but they also have USB, HDMI, a GPU, and they’re fairly cheap.

A MPPT solar charge controller to charge the battery. This connects to a solar panel and a 12v RV battery, and keeps the battery charged. I like this one because it has an RS-485 port, so we can talk to it from the Pi.

A DC-DC step down converter. Our battery is 12 volts, and the Raspberry Pi needs 5 volts through a micro USB plug. This will bring the voltage down and provides the micro USB plug needed by the Pi.

A small fuse block, just to make it the wiring little nicer.

A pi-ezconnect hat. This just sits on top of the Pi, and breaks out all of the pins into easy to use wire terminals. Not completely necessary, but nicer than just sticking all of the wires into a breadboard.

A motor controller board. This board lets us easily control the fan from the Pi. We’ll talk more about how to use it in the next post.

The Puzzle

Above is my assembled product. The solar charger terminals are connected to the battery, and the load terminals are connected to the fuse panel (through an inline fuse on the positive wire.) The fuse panel is connected to both the DC-DC step down converter (which powers the Pi) and the motor controller. The Pi and the motor controller are both mounted to the wood using nylon stand offs. You can also see a USB to RS-485 adapter plugged in to the Pi, but ignore that. I ended up using something else, and I’ll explain it later.

Next, we mounted it to the actual greenhouse wall, under the fan:

I’ll talk more about the specific components, and how to make them work, in part 2.

Controlling a Ceiling Fan with HackRF – Part 1

For my first HackRF project, I thought I’d try to create a replacement for the remote controls used by my two Hampton Bay ceiling fans. First, we’ll have to understand how the remote communicates with the fan, which is what we’ll do in this post. These remotes let you control the light level and fan speed. The other features, like timers and temperature-based fan speed, are all processed on the remote itself; it just tells the fan the speed and light level to use. There are four dip switches under the batteries that let you “pair” the remote with an individual fan.

To find the remote’s transmit frequency, I looked up its FCCID on the FCC’s website, which told me it uses 303.85Mhz. With that knowledge, I used hackrf_transfer to record a sample of the remote telling the fan to go to “high” with the lights turned off. The command I used is as follows:

hackrf_transfer -r fan_high.iq -f 303000000 -s 8000000 -b 1

After it was running, I pressed the button on the remote to turn the fan on, waited a moment, and stopped the recording. I opened the file in baudline as a “raw” file,  with a sample rate of 8000000, 2 channels, quadrature and flip complex checked, using a an 8-bit signed decode format. Some older blog posts will claim that the data is unsigned, but that was changed in more recent firmware updates.

Looking at the signal in baudline’s waterfall view, you can see some kind of simple modulation going on. The transmission is broken up into short (~300 microsecond) and long (~600 microsecond) pulses, with a ~300 microsecond pause between each pulse. It looks a lot like binary to me. I assumed (correctly) that a short line was a 0, and a long line was a 1. It’s not shown below, but the remote actually transmits this pattern several times, with a delay between each packet.

BaudlineFanRemoteSignal

The above signal (read from top to bottom) is 0111110011111111111001.

GRCAnalysis

The analysis flowgraph

Now that we know that the signal looks like, I made a quick flowgraph in gnuradio companion for analysis. I didn’t want to perform the above steps, reopening the file in baudline every time I wanted to try a different setting on the remote. The graph listens on the remote’s frequency, and then uses the AM Demod block and a WX GUI Scope Sink to show the signal.

 

GRCFanRemoteSignal

The same signal as before, but on a live scope plot

With the flowgraph running, I can see the waveform immediately, and examine the individual bits after each button press. You’ll need to turn off autorange, and increase your seconds/counts per division until something useful appears. After pressing a button on the remote, pause the scope to see the packet.

Next, I made small configuration changes on the remote, just to see which bits would change for a particular setting. By analyzing the remote in a lot of different states and recording my findings, I was able to determine where each setting was in the packet, and how to interpret it.

Can you believe I’m not even a graphic designer?

FanRemoteDipSwitches

Only four switches. I guess I won’t be able to get that 17th ceiling fan.

The preamble is consistent for every single packet, so no big mystery there. The dip switch bits correspond directly to the physical switches, albeit reversed: the left-most switch controls the right-most bit. The lowest light level the remote would transmit was a 22 (010110), and the highest was a 62 (111110). A 63 (111111) turns off the light completely. The two fan speed bits represent low (00), medium (01), high (10), and off (11). Two of the bits are mysteriously always set to 1 in every combination that I’ve tried, so we’ll just ignore those. The checksum was easy to recognize: it varied wildly with different settings, but was consistent when the same settings were used.

So now we know basically how to talk to the fan. To actually send a packet, we’ll need to know how to compute the checksum, but more on that next time. In the next post, we’ll build a class in C++ to generate the actual packet structure.