61: Hoop House Rollup Motors

I described this system back in post 56. I meant to get this done early in the summer but things got in the way. I had 4 hoops to do and would have preferred to just install one first to get the wrinkles out but because it was already September I did them all at once. And we got to experience the problems times 4.

Here's what the smartphone web page looks like at the moment:
                                                                                  
Hoop fmX Sidewalls:
9:50PM: Hoop Temp: 40°
Auto Temp: OFF
Motors: Left=DOWN, Right=DOWN
Weather: Temp: 38.8°, Wind: N 1.1 MPH

Change?
Auto Temp Mode: Turn ON

Both Sides: Roll UP

Left Side: Roll UP

Right Side: Roll UP

Stop Motor!

Reload Page
                                                                                  

Here's a pic of a motor and the 196' long rollup pipe:

In the web page: info above the word "Change" shows the current state of the system. If you click any of the next 4 items below that the wording will change accordingly.

Here are some of the problems I have run into:
1. We had to use WIFI extenders because of the distances involved. It took a few tries to get them placed properly.
2. Flakey Internet service caused me to add manual UP/DOWN buttons to the Photon system enclosures.
3. Two of the 4-port relays I use to switch the 24v DC between the wires to the motors have failed.
4. The ACS714 current sensors are a disappointment so far. The analog readings are inconsistent (as they are currently wired). This means that rollup/down operations have to use worst-case wait-times. Very irritating.
5. It turns out that the rotation settings on the motors have to be adjusted after a few up/down cycles. Perhaps because wrinkles in the plastic get smoothed out with the uniform running speed of the motors.
6. Adapting the motor shafts to the hoop rollup pipes was challenging.
7. Getting  "Auto Mode" to work properly was a trial. At first I had the auto UP temperature too close to the auto DOWN temperature. So, the sides roll up, temperature drops immediately and the sides roll back down; over and over. Placement of the temperature sensor is tricky and the UP/DOWN thresholds have to be over 15 degrees apart.
8. Local temperature and wind is boiled-down from wunderground.com for the zip code. It is updated every 15 minutes by a Raspberry Pi.
9. An Rpi running Particle-agent sends and receives messages (via publish/subscribe) from the Photon systems.

More to come.

60: Particle Photon Esoteric Hints 

(must previously have installed particle-cli)

1. When your Photon is not ready to accept a new flash: If (as I do) sometimes purposely load a program that is meant to run without the cloud then you can have a problem when you need to flash new software -- because the Photon is not connected. The following info is in Particle Docs, but not all in one place.

a. To get back to "breathing cyan" so you can flash:

Hold down RESET and SETUP, release RESET and continue to hold down SETUP while the main status LED blinks magenta until it blinks yellow, then release.

b. Then load a sketch that exists as part of the particle-cli package. In Terminal app on Mac OS:

$ particle flash --usb tinker # Photon connected to USB (of course)

It's not that you want to use tinker. It's just harmless software that allows you to then flash your own code.

2. What if you want to set up a Photon for a wifi network that is elsewhere?

a. First, the device must be in "Listening Mode". To do this hold down the SETUP until the RGB LED blinks blue.

b. Of course the Photon must be plugged to a USB port. Here's the command:

$ particle setup --usb
(output back: blah, blah)
Claim code set. Now setting up Wi-Fi
...
Attempting to configure Wi-Fi on /dev/cu.XYZ
? SSID name-of-the-network
? Security Type WPA2 (selected, not typed)
? Cipher Type AES+TKIP (ditto)
? Wi-Fi Password your-pw
Done! Your device should now restart.
! It doesn't look like your Photon has made it to the cloud yet.
? What would you like to do? Check again to see if the Photon has connected
... (took a while)
> It looks like your Photon has made it happily to the cloud!

And so you've made it (with luck).

3. What about where several Photons are running the same program but you need to identify them individually? You could do this messily by using a C++ "#define" statement -- a 1 line source change for each Photon: pretty certain to lead to errors. A better way would be to get the Particle cloud to tell your program the device name that you gave the Photon. It would be nice if Particle provided a call like: "Particle.deviceName()" that returned the name as a char array. The good news is that you can get the name but it is not so straightforward. Here's code that works:

char DevName[20];
...
void getname(const char *topic, const char *data) {
    strcpy(DevName, data);
}

void setup() {
    ...
    Particle.subscribe("spark/device/name", getname);
    Particle.publish("spark/device/name");
    delay(5000); // DevName won't get filled in for several seconds
    ...
}

Note that while Particle lost use of the name "spark" a couple years ago they have never changed all of the sparks to particles. Not nice, Particle!

59: Particle Photon "Persistent Data"

Up till now I have handled the problem of getting data to persist between reboots by sending it daily to-and-from a Linux (Raspberry Pi) system. And I will continue to handle Daylight Savings that way. But now I'm going to try Particle's EEPROM memory storage scheme. The Photon provides 4096 bytes of flash RAM that presumably/seems-to persist between power outages. The hitch is that you have to manage storage space allocation on your own. So if you want to store a C++ int you have to know to offset the next variable by at least 4 bytes (higher number). Reminds me of my first assembly language compiler from 1961.

Here's a sample program.

#define VAR1 0 // first address in eeprom -- 32-bit int
#define VAR2 4 // leaving room for the previous value
int Var1;
int InitialValue = 123; // whatever...

void setup() {
EEPROM.get(VAR1, Var1); // copy from eeprom to RAM data
if(Var1 == -1) { // hex "FF"s first time, not initialized
   EEPROM.put(VAR1, InitialValue); // load starting value
   ...
}
 // might also want to check for reasonable "get" value!
}

void loop() {
// use or change eeprom values as needed
}

More/better info at--
https://docs.particle.io/guide/getting-started/intro/photon/
Search for "EEPROM".

58: Time Change Season

March 12, 2017 (first day of daylight savings): I use Particle Photons to monitor and control things at my granddaughter's hoophouse. One Photon reports 3 temperature sensors, 2 soil moisture sensors and 1 humidity sensor. A second Photon (50 feet away) controls 2 irrigation valves. It also switches a powerful electric deer fence that surrounds the 12-acre volunteer-staffed garden area. The fence is turned on at 6pm and off at 7am -- eastern U.S. time, modified by daylight savings. Months ago, I complained to Particle that their built-in Time functions failed to provide a "daylight time" indicator. This is something that every UNIX or Linux system has provided for many years. Anyway, I was surprised recently to find a new (unadvertised, firmware v0.60 added) function "Time.isDST()" which is supposed to return 0 for Standard and 1 for Daylight. So last night I ran a program just to check on this new feature (my Photon running v0.61). Well, 2am came and went and Time.isDST() still returns 0 -- as it does now at 4pm. Luckily, I was still providing time zone info from a Linux computer that sends EST or EDT every day at 3am. (Has to be done every day because a power outage restart can happen at any time.

57: Photon Error Recovery

Recently I compiled and flashed source with an error not detected by the compiler (I accidentally backspaced away the proper length of a "char" array variable). When the program ran I had just 1 second until the program wrote too many characters into the variable. As it happens, this caused a "Hard Fault" (see Particle Docs Guide).

I fixed my source error but could not flash the new version--the Photon switched to blinking red too quickly. I eventually went through the "Safe Mode" actions (a few times). I had the "particle" command loaded on my iMac. The thing that finally worked (in Mac Terminal) was--

First, hold down both the SETUP and RESET buttons. Then release the RESET button and wait for the LED to blink YELLOW. Then:

$ particle update
$ particle flash --usb tinker # Photon wired to USB port!

I wasn't interested in tinker but it allowed me to flash my corrected code.

My advice: do the Safe Mode and skip directly to USB download. Save yourself an hour.

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-".