56: Hoop House Temperature Control

A hoop house is the plastic film version of what was once called a greenhouse. These things can be big: 30' by 200', for instance. They can get overheated in the sunshine. I have two granddaughters who have become farmers. Between them they have 4 hoop houses. The daily temperature range inside a hoop house can vary by 70F (e.g., 50F to 120F -- these places are not kind to electronics). Vents with fans are an obvious way to prevent overheating but that spins the electric meter. So the common way to control the temperature is to roll up the plastic film sides. This is generally done with hand cranks. But you have to be on-site to do it. There are also slow-rotating DC electric motors to do the cranking but generally you still still have to be there. I have built and programmed Photon microcontrollers to help keep track of things in a hoop house. This currently includes multiple temperature and humidity sensors, soil moisture sensors plus control of irrigation valves. The user interface is a smartphone oriented web page. For the moment, you can see this at http://afarm.farmiot.net

This saves my granddaughter some concern and some work but the big saving would be to automate the roll-up/roll-down of the hoop sides. So I bought a couple motors from China (the only place they are manufactured, I think). The instructions seemed to be from auto-translated Chinese. Nearly useless, but I mostly figured things out. The nicest feature of the motors is that they have a mechanical limit that protects against over rotating. The idea is that you set (by screwdriver) the physical number of rotations, then apply 24v to the red wire to rotate clockwise or 24v to the green wire for counterclockwise. There is no built-in feedback from the motors. Generally these things are controlled from a power supply that includes a simple 3-position switch:

clockwise / off / counterclockwise.

This power unit also contains an overload fuse: the roller can jam!

My current test setup includes the following:
2 rollup motors (rated 24v DC, 60 watts, about 3 rpm)
1 Power supply (120v AC to 24v DC, 150 watts)
1 4-relay opto-isolated switch
1 ACS714 Hall-effect current sensor (30 amp) spliced-in between the power supply and the switches
1 Temperature sensor
2 Override switches (down button, up button) in case of failure of Internet
UPS (battery backup) with enough juice to roll up or down
1 Particle Photon web-connected microcontroller (i.e., computer) that runs my test software

In small quantities, the motors are very pricy -- esp. shipping and "inspection" (whatever that means).

The ACS714 provides me some feed back from the motors. After extensive (time-consuming) testing, I can detect the following states:

a) motor running
b) motor stopped (the motor's mechanical dial stop setting reached)
c) motor jammed (my program will notice, turn the motor off and send a warning text message)

I still lack "real world" data about jamming since I won't actually install the first system until warmer weather.

Here's what I envision as the smartphone interface for 2 hoop houses/4 motors (subject to change):

password protected, of course

55: Use a Photon as an Arduino

"Arduino Mode": Who needs it? Well, I have -- a couple of times. Here are some reasons:

3. A Photon is a 32-bit computer. It is 2x+ faster and has 4x program memory. About the same footprint as an Arduino Nano.

2. Photon analog ports are 12 bits to Arduino's 10 bits = higher resolution readings.

1. Most important: So you can test a Photon setup before Internet has been installed. This is why I've needed Arduino-mode!

I recently had to try a Photon setup "out in the field" and ended up reprogramming it for a Nano. I commented out the Cloud stuff, re-did the analog values, found that I had an "int" overflow (changed it to "long". And had to move the breadboard wires to fit the Nano (and later back for the Photon).

So I complained to Particle and was advised to try MANUAL mode, like this--

SYSTEM_MODE(MANUAL); // this kludge has to be before setup()

void setup() {
    Serial.begin(9600); // you'll need to talk to it
    . . .
}

void loop() {

    . . .
    if(!Serial.available()) {
        delay(1000); // some number
        return;
    }
    // read a command
    ch = Serial.read(); // get 1st character
    if(ch == 'c') { // some value: switch back to connected
        // so you can later flash new code without reset
        Particle.connect();
    }
    . . .

So, for $19 you can have a bigger, better Nano.

54: Rangefinder Breakthrough?

Back in dicks-raspberry-pi.blogspot.com, post 68, I described my frustrations with rangefinders. I've moved on from my urge to create an electronic "white cane" for the visually impaired, but just maybe an adequate device is now available. It's described at
www.maxbotix.com/Ultrasonic_Sensors/MB7051.htm. Pricy though, over $150.

A secondary problem I mentioned in the old post was that an Arduino Nano wasn't fast enough to keep up with both the rangefinder and the 3-axis accelerometer. Well, if you replace the Nano with an equally small but faster Particle Photon that issue (probably) goes away.

53: Particle Web IDE Failings

Complain, complain! I may have mentioned this before but I have an "issue" with Particle's browser-based program development. I'd give it an "A" for looks but lower marks for the rest.

The worst feature concerns error message feedback when you make a dumb mistake in source input (Sue me! I make mistakes). A recent example: for a 1-letter typo in a function name: 20 lines of error messages, none of which point out even the right line number. I've taken to copying such source to my on-line Raspberry Pi where I try to compile it with GCC; there, I can get a reasonable error message. Errors get an "F".

Another easy user mistake you can make: If you compile source meant for a Photon when the device you selected (usually left over from compiling days before) was a Raspberry Pi (or vice-versa) you get the usual slew of messages, none useful. Grade "D-".

When you have written 20 or so programs, the listing of their names can become an issue. Most recent sketch is always the bottom of the list (oldest to newest). You can't use alphabetical, newest to oldest, or best yet, be able to group them in folders. Grade "C-".

52: About Particle Cloud for Raspberry Pi

I'm covering this in my RPi blog at:

http://dicks-raspberry-pi.blogspot.com/

See posts 108 through 110 (for the moment).

51: Yet More About Relay Switches

I've discussed relays in earlier posts, but I keep learning more. I used 4 relays to swap cold/heat on a Peltier device. Now I need to switch polarity on 2 motors using a single Particle Photon. However, the Photon only has 8 digital GPIOs. My 4-relay plan would use all of them. So I asked around and came up with this arrangement:

This wiring works and takes only 2 GPIOs per motor. I tested with a multimeter. Here's a bit of code:

#define SW1  D1

#define SW2  D2

. . . 

void setup() {

   pinMode(SW1, OUTPUT);

   pinMode(SW2, OUTPUT);

. . .

}

void loop() {

. . .

    // blue wire +

   digitalWrite(SW1, HIGH);

   digitalWrite(SW2, LOW);

. . .

   // green wire +

   digitalWrite(SW2, HIGH);

   digitalWrite(SW1, LOW);

. . .

   // all OFF

   digitalWrite(SW1, LOW);

   digitalWrite(SW2, LOW);

. . .

}

50: Particle Cloud (Photon) Time Functions

PHP and C programmers, beware: day-of-week numbers start at 1 instead of Sunday==0. Also, there is no provision for Standard vs. Daylight time. At my granddaughter's farm, a Photon turns a powerful deer fence on and off. To keep from zapping workers, it is important that the schedule be reliable. I covered the Linux side of this at my Raspberry Pi blog (http://dicks-raspberry-pi.blogspot.com) post 91. Currently, (because of power-fail reboots) I execute a crontab statement every night at 4am (the code from post 91). If the UNIX/Linux world can keep the time change straight, then Particle could, too.