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.

49: IoT* for Farming

As I have mentioned in earlier posts I have put some Particle Photons to real work. Between them, my grandkids have 6 hoop houses (hoop houses are the plastic film version of the old greenhouses). So far I've only worked on one of them. I started out with a single Photon handling both the sensors and the switches. That was a mistake. The long-ish wiring runs were unreliable and the cables cost more ($90) than an extra Photon ($19).

So right now the 2 Photons work as follows:

Sensor-Photon: Connects to 2 soil moisture sensors**, 2 DS18B20 temperature sensors (stuck in ground for soil temperature), 1 DHT22 temperature/humidity sensor*** 3' off the ground.

Control-Photon: Keeps track of time, permits smartphone controls of 2 irrigation valves and a deer fence (enclosing 12 acres around the hoop house; normally on an automatic schedule, but can be overridden).

100 miles away, a Raspberry Pi running Linux keeps track of the Photons. This is mostly handled by tasks scheduled by the cron program. Note that I had planned to use a Raspberry Pi for all of this but the cloud access and Arduino-like ability with analog sensors made me choose Photons for the hoop house computers.

The main link to the Photons is a web page (optimized for smartphone) that reports on the sensors and allows control of the switches.

BTW: Turning things on and off requires login/password.

My next challenge is to provide web control for rolling up the sides of the hoop house. The hoop can be cooled by exhaust fans but that just runs up the electric bill. Rolling up the long sides of the house is effective and cheaper. My trial China-manufactured motors are being a chore to program (instruction manual computer-translated from Chinese?). This will be the main labor saver of my system, since the internal temperature will be controllable from a distance.

--------
* IoT (Internet of Things): This term doesn't really work for me.

** To avoid shorting out, the fork-shaped sensors wiring had to be coated in non-conductive caulk.

*** As mentioned in earlier posts, apparently humidity sensors stop working at 100% RH (I've tried several kinds). I finally had to put the DHT22 in a box with a tiny fan blowing on it. It still quits working at 100% but recovers in a few hours.

48: Particle.io Cloud Interface for Raspberry Pi

Among my "IoT computers" or "smart controllers"* (needs a better name) are 7 processors from Particle: 1 Core (now superseded by Photons), 5 Photons and 1 Electron.  Particle Photons are rather like souped-up Arduinos with built-in WIFI and cloud services. This cloud provides not only the expected variable/function and publish/subscribe services but other handy UNIX-like functions like date/time. Since the summer of 2015, I have had 2 Photons operating in the real-world in my farmer granddaughter's semi-automated hoop house. I had planned to use Raspberry Pi's for this but the Photon/cloud was just too handy. However, an RPi keeps track of things from 100 miles distance.

Anyway, back in August, I emailed Particle.io support that they should provide their cloud interface for the Raspberry Pi. I was probably not alone in this. And now, I just signed up for their beta-test RPi cloud interface. It should be very convenient for me and even if 1% of the 10M RPi's sign on, it should be a good deal for Particle.

---------
* I also have 4 Raspberry Pi model B (from earlyish to most recent) and 4 Arduino Nanos. To those not in-the-know, an RPi B is $35 (well, $50 with flash card, etc.); my Nanos cost $7 and Photons are $19. My Particle Electron (Photon with built-in cell modem) was time and $ wasted, for me.

47: Did You Know?

—That your Arduino sketch can re-execute the setup function:

void setup() {
  . . .
  Serial.begin(9600);
  . . .
}

void loop() {
  // Some code
  . . .

}

So, if there is no serial connection when the Arduino powers up then the code will proceed to the loop. However, say you later connect to it with Coolterm (or equilalent command) then the setup will be executed again (for Serial.begin). I think it causes a hardware RESET.

Note that while a Particle Photon is Arduino-like, setup does not get re-executed in the above circumstance.

Probably doesn't matter, but it might.

46: Linear Stepper Motor -- More
-- revised 9/15/16 --

Below is a very messy circuit drawing for my Arduino setup. Should also work with Particle Photon or Raspberry Pi. It uses external 5V to power both the relay switch and the motor. The reason for the relay is that the steppers draw power constantly. So in my program when I want to move the linear screw I turn the power ON, delay(100), operate the stepper, delay(100) and turn the relay OFF. When you power a stepper off the rotor can move freely (no brakes). But with the linear screw that won't happen (its own friction). My cheap stepper has about a 3" movement. Even with counting steps, I will use a door/window sensor to recalibrate the initial position. I plan to use this to dispense dog treats. See post 41.

Revised: I bought a second EasyDriver and motor. They look exactly like the above. After the irritating soldering adventure I hooked it up to an Arduino Nano and loaded the same script that I used with the first pair. With the first set, 350 steps move the length of the spiral screw; the new one takes over 1500. No clue as to why.

45: Some Obvious info about Opto-isolated Relays

For isolated wiring:
- external 5v to Relay JD-VCC pin (the usual label) and GND
- digital Arduino pins to Relay IN1, etc.
- Arduino 5v or 3.3v to the Relay VCC (next to IN pins)

Isolation comes from NOT connecting GND from the Arduino.

Most switches are "normally open". This would not be my first choice.

See the relay photo.

Wiring A: 
Switch is initially OFF.
digitalWrite(pin, LOW) turns it ON.

Wiring B:
Switch initially ON (even with no power input).
digitalWrite(pin, HIGH) turns it ON.

Wiring B is appealing because HIGH = ON but having even a momentary initial ON is irksome.

So what I do is use Wiring A with the following #define's:

#define SW_ON   LOW     // digitalWrite(pin, SW_ON) -- turn ON
#define SW_OFF  HIGH    // digitalWrite(pin, SW_OFF) -- turn OFF

Otherwise, chaos!

P.S.: Essentially the same goes for Particle Photon and Raspberry Pi.

44: Read line from USB

I'm not fond of C++ so try to pretend it's just C. So the supplied readline() doesn't fit. Doing a readline that worked for me took a few tries. So, I'll share it. (I'm sure it could be better)

#define spr(x) Serial.print(x)
#define spl(x) Serial.println(x)

char Buffer[80];

int readline(char *buffer, int len)
{
  int pos = 0;
  int tries = 0;
  char ch;

  while(tries < 200) { // arb. time out
    if(pos >= len) return -1;
    ch = Serial.read();
    if(ch > 0) {
      switch (ch) {
      case '\n': // Ignore new-lines
        break;
      case '\r': // Return on CR
        return pos;
      default:
        if (pos < len-1) {
          Buffer[pos++] = ch;
          Buffer[pos] = 0;
        }
      }
    } else { // no input ready
      delay(50);
    }
    ++tries;
  }
  // No end of line has been found, so return -1.
  return -1;
}

void setup() {
  Serial.begin(9600);
  delay(3000);
  Serial.println("Read line");

}

void loop() {
  int ct;
  if (readline(Buffer, 80) > 0) {
    spr("L:");spl(Buffer);
  } else {
    spl("timed out");
  }
}

43: Linear Motors -- Arduino
revised 8/26/16

I got a stepper working after I bought one with the control interface card. But for my "Dog Treat" system I decided that a linear motor would be most reliable for spitting out dog treats. I bought 2. Here's #1:

#2:

                        top of #2                   under side     control board

                                                        of  #2             for 28B...

Right away, problems. My 28BYJ-40 stepper has 5 wires to the little board. My linear #1 only has 4 wires (blue, yellow,black, red). Will the little interface work? How do I wire it? Ditto for #2 (after I figure out how to solder the tiny contacts).

REVISION:
To get motor #1 to work I bought an "Easy Driver" through Amazon. After the nasty soldering and a couple wrong-headed examples from Googling "arduino stepper..." I got "SparkFun Easy Driver Basic Demo" code & wiring to work.

Motor #2: Soldering to those tiny contacts? First off, I shorted 2 and had to de-solder & start over. Then the same code & Easy Driver worked -- except -- forward and backward are reversed (but then the contacts weren't labeled). Also, #2 spiral gear is "coarser" so a small motor rotation moves much farther. Actually (ignoring soldering), I like #2 better -- the 2 screws will make it easier to connect to something useful.

Also: what's the best way to avoid running the plastic piece past the end of the screw? 

42: DHT22 Update of Post 39

Well, my sensor inside a cut-off water bottle failed after a couple days. So I put the next try inside a opaque plastic box that is sealed except for 2 screen-covered 1" holes. But the thing that makes it work (I think) is the tiny fan that blows directly on the DHT22. It still stops working briefly when the humidity reaches 100% but it then recovers after an hour or so. To make this work I had to increase the 5v power to the Photon to 2.4 amps.

I also tried the HIH-4030 sensor in the same environment. Guess what: it stops working at 100% RH, too.

41: Stepper Motors

I have a mad urge to build an interactive amusement for the left-at-home dogs in my extended family. Yeah, I know other people have-done/are-doing this. So what. Details at http://dicks-raspberry-pi.blogspot.com/, post 99.

Anyway, one feature has to be the ability of the device to spit out doggie treats. I expect the main computer for this will be a Raspberry Pi. And I started stepper programming in Python on the Pi but realized quickly that precise timing is a problem again. Mostly because I want to be able to calibrate the motor position using a photo sensor. Reading such a sensor on the non-analog Pi is slow. So I'll add an Arduino for the motor and the photo sensor chore.

Stepper 28BYJ-48 5V DC + ULN2003 Driver Board

-- don't buy without the driver board --

(otherwise the wiring will drive you nuts)

Here's some C++ I'm currently using (9th try from downloaded sources, I forget which):

int motorPin1 = 8;    // Blue   - 28BYJ48 pin 1

int motorPin2 = 9;    // Pink   - 28BYJ48 pin 2

int motorPin3 = 10;    // Yellow - 28BYJ48 pin 3

int motorPin4 = 11;    // Orange - 28BYJ48 pin 4

                       // Red    - 28BYJ48 pin 5 (VCC), not used

int bits[8] = {B01000, B01100, B00100, B00110, B00010, B00011, B00001, B01001};

int photo = A5;

void setup() {

  //declare the motor pins as outputs

  pinMode(motorPin1, OUTPUT);

  pinMode(motorPin2, OUTPUT);

  pinMode(motorPin3, OUTPUT);

  pinMode(motorPin4, OUTPUT);

  Serial.begin(9600);

  pinMode(photo, INPUT);

}

char ch;

void loop() {

  // wait for any typed character

  if(!Serial.available()) return;

  ch = Serial.read();

  spr(ch);

  clockwise(128); // not exactly 1 rotation

  delay(1000);

  anticlockwise(128);

  delay(1000);

}

void clockwise(int n) {

  for(int j = 0; j < n; ++j) {

    for(int i = 7; i >= 0; i--) {

      setOutput(i);

      delay(2);

    }

  }

}

void anticlockwise(int n) {

  for(int j = 0; j < n; ++j) {

    for(int i = 0; i < 8; i++) {

      setOutput(i);

      // read photo pin & stop on overrun

      delay(2);

    }

  }

}

void setOutput(int out)

{

  digitalWrite(motorPin1, bitRead(bits[out], 0));

  digitalWrite(motorPin2, bitRead(bits[out], 1));

  digitalWrite(motorPin3, bitRead(bits[out], 2));

  digitalWrite(motorPin4, bitRead(bits[out], 3));

}

==============

To be added to Arduino code: serial command from the Pi.

Question: anyone know how to change the steps per rotation?

40: C++ map() function vs. the HIH-4030 Humidity Sensor
-- revised 5/22/2016 --
-- re-revised5/25/2016 --

So I got my expensive HIH sensor (explained in post 39).

tiny, isn't it

According to Honeywell's graph there is a straight line relationship between voltage output (at 5v, 20C) and relative humidity. I.e., 0.8v = 0% to 3.75v = 100%.

So I wrote this Arduino sketch:
=============
#define spr(x) Serial.print(x)   // because I'm a slow typist
#define spl(x) Serial.println(x) //      " "

void setup() {
  pinMode(A1, INPUT);
  Serial.begin(9600);
  delay(5000);
  spl("HIH-4030");
}

void loop() {
  int r = analogRead(A1);
  spr("raw: ");spr(r);
  float v = r * (5.0 / 1023.0);
  spr(", V: ");spr(v); 
  float rh = map(v, 0.8,3.75, 0.01,100.0);
  spr(", rh%: ");spl(rh);
  delay(5000);
} 
============
This produced the following output (from Mac Coolterm):
============
raw: 297, V: 1.45, rh%: 33.00
raw: 305, V: 1.49, rh%: 33.00
raw: 289, V: 1.41, rh%: 33.00
raw: 224, V: 1.09, rh%: 33.00
raw: 651, V: 3.18, rh%: 100.00 *
raw: 526, V: 2.57, rh%: 66.00
raw: 367, V: 1.79, rh%: 33.00
raw: 322, V: 1.57, rh%: 33.00
raw: 291, V: 1.42, rh%: 33.00
raw: 278, V: 1.36, rh%: 33.00
============ * I breathed on the sensor
The "33", "66", etc.  made me suspect that while the C++ map() function happily accepts float arguments, it treats them as integers. So I wrote my own float version:
============
#define spr(x) Serial.print(x)
#define spl(x) Serial.println(x)

float mapf(float value, float istart, float istop, float ostart, float ostop) {
    return ostart + (ostop - ostart) * ((value - istart) / (istop - istart));
}
void setup() {
  pinMode(A1, INPUT);
  Serial.begin(9600);
  delay(5000);
  spl("HIH-4030");
}

void loop() {
  int r = analogRead(A1);
  spr("raw: ");spr(r);
  float v = r * (5.0 / 1023.0);
  spr(", V: ");spr(v); 
  float rh = mapf(v, 0.8,3.75, 0.0,100.0);
  spr(", rh%: ");spl(int(rh));
  delay(5000);
}
============
Here's the "mapf()" output:
============
raw: 295, V: 1.44, rh%: 25
raw: 294, V: 1.44, rh%: 24
raw: 293, V: 1.43, rh%: 24
raw: 318, V: 1.55, rh%: 29
raw: 449, V: 2.19, rh%: 52 *
raw: 378, V: 1.85, rh%: 39
raw: 306, V: 1.50, rh%: 27
raw: 293, V: 1.43, rh%: 24
raw: 291, V: 1.42, rh%: 24
============ * hot breath, again
Nasty! I wonder whether the provided map() code protects against divide-by-zero? It could happen.

Now I just have to worry about why my HIH-4030 values are screwy -- readings around my house are in the 40s, at the moment.

Later: Then I moved the program to the Particle Photon. The only source change was for the 12-bit analog return (4095 instead of 1023). The Particle C++ map() function bug ("feature") was the same. But, for some reason the results were correct!
============ code:
#define spr(x) Serial.print(x)
#define spl(x) Serial.println(x)
// sensor to Photon: 5v to Vin, 0v to A1, GND to GND

float mapf(float value, float istart, float istop, float ostart, float ostop) {
    return ostart + (ostop-ostart) * ((value-istart) / (istop-istart));
}

void setup() {
  pinMode(A1, INPUT);
  Serial.begin(9600);
  delay(5000);
  spl("HIH-4030");
}

void loop() {
  int r = analogRead(A1);
  spr("raw: ");spr(r);
  float v = r * (5.0 / 4095.0);
  spr(", V: ");spr(v); 
  float rh = mapf(v, 0.8,3.75, 0.0,100.0);
  spr(", rh%: ");spl(int(rh));
  delay(5000);
}
============ ok results?
rawh: 1674, V: 2.04, rh%: 42
rawh: 1576, V: 1.92, rh%: 38
rawh: 1607, V: 1.96, rh%: 39
rawh: 1562, V: 1.91, rh%: 37
============
Finally, about the HIH readings: they vary a lot between samples so my latest code reports a weighted running average -- 3 previous readings and the latest one doubled.

Revision: I soldered the tiny board to wires -- trying to keep from frying it in the process. I found new software on Github. Now the Arduino is right (seemingly) and the Photon is too high*. The HIH-4030 is a pain. The mounting board should be bigger just to protect the sensor part.

* Because the Photon analog pins are only rated for 3.3v. It's in their Docs -- but not obvious. Forget my code. Use the more accurate code from github.

39: Problems with DHT22 Temperature/Humidity Sensors

For the past month or so I've tried DHT22s in my granddaughter's hoop house. With them I can provide her with useful humidity and dew point data. As I've mentioned in an earlier post, the hoop house is a rather hostile environment for electronics. If the spring sun is out, the temperature/humidity mid-day can be 90F/25% and at 2AM 40F/99% (dew point 40F). I've tried three different DHT22s and they have all failed after a few nights of 99% humidity. For my latest attempt I housed the DHT inside 16oz water bottle (bottom cut off, sealed at the top). It lasted 2 nights. BTW: they recover after a couple days away from the hoop.

Now I've ordered an HIH-4030, humidity-only sensor (much more expensive). I'll pair it with a cheap TMP36 (cheap & reliable). Unlike the DHT22, the HIH provides a simple analog output.  I won't have to use a mysterious software library -- but I'll have to run 2 sets of wires instead of 1.

Anyone have similar problems?

38: Particle Electron -- Bah, Humbug.

-- see post 36 --

After waiting months, breaking the first one and wasting 30 hours trying to get the 2nd one to work reliably, I've given up on the Electron. It seems clear to me that a cheap cell modem & cheap month-to-month service connected to Particle Photons is cheaper and much more reliable. Too bad I didn't figure that out before I blew $150 plus hours of effort!

38: Search for the Perfect Connector

Here's some recent purchases:

The white spring clips are cheap, easy to use, fairly secure, not waterproof. I've had some of the 2-wire type for a year. They are useful while you are messing around. Generally better than alligator clips.

The lower set are pretty much the opposite: secure, waterproof and not cheap. And once you snap one of these suckers together it's work getting them apart. But really waterproof. Also, they could use a screw-down hole like the white clips.

The search goes on...

37: Raising an "Exception" in a Particle Photon or Electron

Let's say that that you have a remote Photon that is monitoring a temperature sensor and it reads a value that is out of range (too hot, too cold, whatever). I have a Raspberry Pi Linux system (could be any other Unix or Linux computer) that needs to be notified. One way would be for the Linux system to "ask" (i.e., "poll") the Photon every few minutes for the current temperature value and then to test for out of range for itself. A plausible action would be to send a text message to a (hopefully) responsible human.

A better procedure would be for the Photon to decide what is out of range and to send an alert message directly to the Linux on its own. The Particle programming interface offers a neat way to do this between that Photon and another Particle device. The sending device "publishes" a uniquely named message (up to the "cloud") and the receiving device can "subscribe" to it. Note that Particle has gone and gotten metaphorical on us: overloading the words "publish" and "subscribe" with new specialized meanings.

This is good for Particle Photons or Electrons but the interface to a Linux doesn't seem so straightforward. Linux/Unix systems like to receive this kind of message by reading a named device. So, until Particle provides such an interface, the simple solution is to publish/subscribe between 2 Particle devices and have the receiving computer pass the data on through the USB cable. In Linux shell this statement could record the message;

$ my-pgm </dev/ttyACM0 # program "hangs" waiting for data

Note that the single subscribing device could be used to receive messages from several publishing devices. And these could be either Photons or Electrons. The Photon receiver would cost a negligible $20.

36: Early Experiences with the Particle Electron
-- Revised 4/16/2016 --

See https://docs.particle.io/guide/getting-started/intro/electron/ for a full description. But, briefly, the Electron communicates with the cloud via cell service instead of wifi & your Internet connection. Also, it's costs more than the $19 Photon ($80 for the developer setup). In addition, you need to have cell service -- starting at $2.99/mo (initial 1MB).

I hadn't bought in to the Kickstarter campaign so I waited a while for my first unit. See post 32. In a single day I managed to break it twice: first I mangled the tiny brass antenna socket (but I repaired it with the help of a strong magnifying glass). Next, I broke the USB plug off the board -- I was moving the Electron around trying to get it to connect to cell service & pulled too hard on the cord (Warning: not very hard). BTW: Particle did not give me a replacement.

Irksome. But I thought I still needed the cell-connection feature. So I ordered another one. Quick delivery. I'd learned a couple lessons (you can, too): I was patient and got the antenna connected at the cost of only 15 minutes of teeth-gnashing. Then I taped the whole setup to a board and used a USB extension cord so I never have to plug/unplug directly to the Electron's socket.

Programming is nearly the same as the Photon (there are some Electron-only cell service functions). But here's a few differences: I have pretty reliable AT&T cell service (2 or 3 of 5 bars on my phone). But while a Photon connects to my wifi in a couple seconds the Electron can take 1 to 5 minutes (thats what led me to break my unit #1). Also, it appears to me that orientation of the provided antenna matters. When the antenna is lying flat (edge on to the signal) connection is less reliable than if the upright (flat on to the signal). I've written a C++ program to test this & I'll post the results.

REVISION/ADDITION
I haven't had a lot of joy with the Electron. The place I was going to install a few appears to have good FreedomPop cell modem service. Current price is: Modem $0, 1 GB LTE data/month $15. Particle Photons are $19 (plus cell modem), Electrons $69.

My test program was no fun. I wasted most of my month's data just trying to download versions of the code (download often failed but data was used, anyway). Downloading via USB seldom worked.

Also: I sometimes get the blinking red light "hard fault" signal. Hard fault is not explained. Lately I've had a LED signal not described in the online Docs. The usual sequence when you power up a Particle device is--

1. blinking green (looking for signal)
2. blinking blue (signal found, working on logging in, etc. -- this reminds me of dogs sniffing each other's butts)
3. breathing cyan (you are in!)

-- but in my case it's solid cyan (not useable).

35: My Arduino Nanos

I currently have 4 fully working Nanos. I recently installed one in a real-life situation for one of my granddaughter-farmers. At the time this left me with only one that I could download new code to. So I ordered 2 more cheap ones ($7 and change each). When they arrived they seemed to be working but the Coolterm app on my Mac couldn't detect their USB ports. I tried downloading a new driver and when that didn't work I send them back (too much trouble for the price). Unfortunately, I'd done the cheap Nano bit before ($3 each that time). Those 2 also didn't play nice. When will I learn? I now have a price point that maybe helps. I replaced the latest non-working pair with 2 from Sainsmart (via Amazon) for $12-ish each. They work fine.

I also have a Nano that Coolterm "sees" but which fails half way through downloading code from the Arduino app. So, essentially broken. And, I have literally burned 2 out through wiring mistakes. Best not to reverse connecting to VIN and GND (right next to each other, 2.5mm apart).

So, I bought 10 Nanos & have 3 working. You could probably do better.

34: A Real Installation -- Practical matters

Some things I've learned since I first installed a Photon system in My granddaughter's 100' x 30' hoop house last summer:

1. The environment is tough. The temperature swing in a single day can be over 50F. Humidity often approaches 100%. UV attacks plastic, e.g.: the heat-shrink tubing over the wire splices.

2. I have wire runs over 70'. I've learned to use only stranded wire: solid conductor can break -- and it has.

3. I used a single Photon ($19) in the hoop. It's backed by a Raspberry Pi 100 miles away. Attached to the Photon are 3 temperature sensors, 2 soil moisture sensors, plus switches for an outside deer fence and irrigation valves: about $90. But the wiring cost more. I should have used multiple Photons and shorter cable runs. More complicated programming, simpler/cheaper cabling.

The Photon has been reliable. Not the rest. For my initial cabling I ran two Cat5 8-conductor cables (solid copper) to the middle of the hoop house and spliced (solder/heat-shrink/non-conductive caulk) 2 or 3 wire cables to the sensors.  That failed -- not always hard failed, some intermittent. Been replaced with straight (unspliced, more expensive) runs.

33: Computer Farming

If you've followed my blogs you'll know that I involved myself in the Raspberry Pi and Arduino initially help grandchildren who insist on farming. See my post 2

I've recently come across the dirtless farming work done at MIT. See--

http://openag.media.mit.edu/

and

http://www.ted.com/talks/caleb_harper_this_computer_will_grow_your_food_in_the_future?utm_source=tedcomshare&utm_medium=email&utm_campaign=tedspread

The MIT system is open source so I visited their github site and downloaded the source code. Interesting. There's a bit of overlap with my much more modest setup. I haven't finished snooping, but it appears that I have used the same sensors as they have -- temperature, humidity, soil temperature, soil moisture, irrigation switching. For testing, I have also programmed a CO2 gas sensor and photo sensor. They also have code for a pH sensor. I've been thinking about that one. There's a big range of prices.

Their system utilizes Arduino Megas and a Raspberry Pi. My system uses Particle.io Photons and a Raspberry Pi. Note: the Photon is as powerful as a Mega. Because of the Photon's "cloud" my Pi is 100 miles away.

Anyway. Their setup is worth studying.

32: Particle.io Update

My current Particle position is: 1 Core, 5 Photons and as of yesterday, 1 Electron.

nice packaging

I didn't order during their Kickstarter campaign but right after. Today, I went to https://setup.particle.io to get started. Authorizing the SIM card seemed to go fine. My first problem was trying to connect the cell service antenna. Very tiny plug, very difficult, especially with trifocals. Finally seemed to work -- don't know how.

Left to right: USB power cable, battery, Electron, wifi connector (taped down 'cause I don't want to have to do it again), antenna wire and antenna.

Second problem: My phone shows AT&T 2 or 3 bars (probably 4G, but probably 3G as well). But as in above image, the Electron doesn't connect. The green LED just blinks.

31: Peltier Cool/Warm Device Experiment

See my discussion on my Raspberry Pi blog: http://dicks-raspberry-pi.blogspot.com (post 94).

I'm interested in comments about wiring the switch.