My Raspberry Pi will be Controlled from a Web Page

My Rpi now has a web page. It is still very crude and will only be available at my convenience.

The UNIX/Linux cron daemon (runs programs per a schedule) automatically sends sensor updates to the site.

See
raspi-online.info

More about Extending Raspberry Pi Sensor Wiring

It's been pointed out (by Ted Hale) that using regular 3-prong extension cords offers the chance of someone plugging an end into a 110V circuit resulting in a fried Pi. So I looked for alternatives.

How about Cat5 (ethernet) cables? They contain 8 wires; generally stranded, in twisted pairs; sometimes shielded; in 22- 24- or 26-gauge. Pre-made cables come with RJ-45 plugs on the ends. Some cables go straight through and some (older?) swap the normal transmit/receive pairs. Straight through is better.

To break out for GPIO/sensor wiring the following neat device is available:

Note that you can connect by either screw terminal or the 8 pins. I've seen prices for these between $8 to $12.

Bulk cable is the best deal. You can cut it to exact lengths but you also need to buy male plugs (50 for $20) and a crimp tool ($20 and up). Prices for 1000 feet of 22-gauge are all over the place — $.10 to $1.50 per foot.

Note: getting a good plug crimp can take some practice.

I'm going to give this a try.

Post 21: Solenoid Success At Last

Thanks to Joe Dohm, my water valve now works! I should have looked up the pins on the transistor. Here's the image Joe sent me from a Fairchild web page:

And here is my revised (and working!) wiring diagram:

It helps to know what you are doing.

A different topic -- and my first practical use of my Rpi:
Several time a week my Frontier-supplied, Netgear-built DSL modem/wifi stops working. The Frontier complaint guy explained my problem as a "feature" rather than a failure. Apparently, there are a limited number of locally-assignable IP numbers and sometimes a number gets reused on a connected device that really hadn't gone away (merely quiet for a while). When the sleeping gadget wakes up the modem doesn't know what to do, so it stops working (forever?). Cycling power to the Netgear fixes things -- but it takes a few minutes and is irritating. Now, I admit that my immediate neighbors and I may sometimes have a dozen computers, phones and tablets connected -- all at once. But, so what?

The solution I dreamed up is as follows:

Leave the Rpi "on" 24/7 running the following BASH script (appended to the .profile file):
 ps ax >/tmp/j
 grep 'python ping.py' </tmp/j >/dev/null
 if [ $? -ne 0 ] ; then
   nohup python ping.py &
   echo starting DSL test
 fi

The first two lines above are to avoid starting another copy of the ping program.

Here's ping.py:

import time

last = 0

res = 9

res2 = 9

def post(msg):

tm = time.strftime("%y, %m/%d:%H:%M:%S")

s = "echo "+msg+": "+tm+" >>stats/DSL"

os.system(s)

post("Rpi Up")

while 1:

time.sleep(60) # probably 300 sec. would be better

res = os.system("ping -c 1 google.com >/dev/null")

if res != 0: # internet failed?

    os.sleep(5)

    res2 = os.system("ping -c 1 yahoo.com >/dev/null")

    if res2 != 0: # 2nd failure?

       if last == 0: # previously ok

        res2 = os.system("ping -c 1 www.wired.com >/dev/null")

        if res2 != 0: # 3rd fail

  post("DSL Fail") # turn modem off/on!

last = 1

else:

    if last == 1: # just stopped failing

        last = 0

post("DSL Up")

# don't print repeat messages but keep looping

I was planning to attach a 110V switch to the Rpi  to cycle the modem power (see "DSL Fail" line above). But since I started letting this run, have had NO failures. No doubt my pinging is resource-piggy, but they brought it on themselves.  A few lines of code added to the Netgear's software could fix the problem but the Telcos are probably saving bandwidth the way things are.

As mentioned in the code, I probably should increase the sleep time. Also, I chose to ping google.com because the site gave me quick echos. Very casual sampling, however.

More Solenoid Frustration

Well, I drew a new diagram:

And wired it that way (things spread out):

As soon as I connect the 9V wires the solenoid clicks. Running the program makes no change. Here's my Python code:

import time
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
Solenoid_pin = 7

GPIO.setup(Solenoid_pin, GPIO.OUT)


for x in range(5): # wait 5 sec
time.sleep(1)
print x
GPIO.output(Solenoid_pin, GPIO.HIGH)
print 'Valve OPEN.'
for x in range(5): # wait 5 sec
time.sleep(1)
print x
GPIO.output(Solenoid_pin, GPIO.LOW)
print 'Valve CLOSED.'
for x in range(5): # wait 5 sec
time.sleep(1)
print x

GPIO.cleanup()

Nothing tricky. I even tested my GPIO pin 7 with an LED -- worked fine.

Comments, anyone?

Raspberry Pi vs. a Solenoid-operated Water Valve

I've had a few problems with GPIO devices up till now, but not like this dratted solenoid. I got mine from Adafruit ($6.95 for plastic). I also ordered the suggested transistor, diode and 9V power supply.. To be extra careful and protect the Rpi from the wrong voltage, I also bought a second breadboard and a multimeter. I wired up the breadboard following (as best I could) the seemingly-identical diagrams below.

(both borrowed from the Web)

Anyway, when I try it, the solenoid activates as soon as I connect the 9V+ and –. Changing the poles of the TIP102 doesn't work.

I need help. Any suggestions?

Raspberry Pi Status

I've done much of the simple GPIO stuff. LEDs, buttons, temperature sensors, PIR motion sensor, photosensor. I've also learned (the hard way) about protecting the Pi and backing up the work I've done.

Now I'm about to break into transistors, higher voltage and a more interesting device, e.g., a solinoid-operated water valve.

If any of this confuses you, you should scroll back a few episodes in my blog.

Raspberry Pi Photo Resistor (light sensor)

I ordered 2 of these a couple weeks ago along with the capacitors listed at Adafruit plus heat shrink tubes and extra breadboard wires. Anyway, these things are so tiny I thought they'd been left off the order. But before complaining, I went through my Pi stuff again and found them.

(a dozen of the sensor bit would fit on a dime)

I had a couple problems getting this device to work:

1. I wired it up like the Adafruit lesson shows (1 mF capacitor and GPIO on the ground side), straight to 3.3V pin on the other side. That didn't work. Looking around some more, I found--

   http://www.raspberrypi-spy.co.uk/2012/08/reading-analogue-sensors-with-one-gpio-pin/

Their example added a resistor on the ground side of the circuit. This eventually worked.

2. My batch of assorted resistors from Radio Shack comes with a list of how many of each kind in the package but the taped-together strips are not labeled. The "pi-spy" interface to the photo sensor added for a 2.2k resistor on the 3.3V side of the circuit. I did a google for "resistor 2.2k" but the color coding shown didn't match anything from my Shack assortment (after a non-trivial search using a magnifying glass). The on-line color-band "calculators" seem difficult, but then I found a "resistor widget" app for my Mac.

The user interface to the widget could be better: you click on the bands repeatedly until it adds up to the value you want. But it's better than the alternatives. Guess what? I found that code among the Shack's jumble.

Here's my Python test program ("adapted" from various sources):
#!/usr/bin/python

import RPi.GPIO as GPIO, time, os

PHOTO_pin = 22

GPIO.setmode(GPIO.BCM)

def PStime (pin):
        reading = 0
        GPIO.setup(pin, GPIO.OUT)
        GPIO.output(pin, GPIO.LOW)
        time.sleep(0.1)

        GPIO.setup(pin, GPIO.IN)
        # Takes about 1 millisecond per loop cycle
        while (GPIO.input(pin) == GPIO.LOW):
                reading += 1
                if reading > 1000: # don't loop forever!
                        return -1
        return reading

for x in range(20):
        print PStime(PHOTO_pin)
        time.sleep(2)
GPIO.cleanup()

The printed results are kind of counter-intuitive. The darker it is, the more loops it takes to get a reading. My setup prints the following values--

  100+ a darkish room

  50     medium interior

  30     light interior

  10     pretty bright

What am I going to use this for? I want my Pi to send a warning if the main 110V power fails. So I'll set it up as follows:

a. UPS backup battery plugged into 110V.
b. Pi and Internet modem plugged into UPS.
c. Photosensor (above) pointed at an LED that's plugged into non-UPS 110V.
d. When external power fails a little Python program (which runs once per minute) notes the sensor change and sends out a text message and an e-mail before shutting itself down.

BTW: Are you familiar with the Linux (and UNIX before it) scheduling service "crontab"? If not, you should learn about it.

Door Sensor Working

I finally got the Magnetic Switch / Door Open sensor working. My wiring isn't "exactly" like anything I saw on the Web.

There are 2 undifferentiated wires out of the device. In the try that worked I connected:

wire 1 to 10K resistor to GND

wire 2 to a GPIO pin (e.g., 25 for code below)

Here's a messy pic:

Here's my crude (but working) Python code:

#!/usr/bin/python

import time

import RPi.GPIO as GPIO

GPIO.setwarnings(False)

GPIO.setmode(GPIO.BCM)

DOOR_pin = 25 # 1 wire->10kRes->GND, other->GPIO25

LED_pin = 17

GPIO.setup(DOOR_pin, GPIO.IN)

GPIO.setup(LED_pin, GPIO.OUT)

tm = 0

changes = 0

last = 0

h = 0

for x in range(20): # tries

        m = GPIO.input(DOOR_pin)

        if m:  # Mag. sw open detected

                if last != m:

                        GPIO.output(LED_pin,GPIO.HIGH) # LED on

                        tm = time.strftime("%y, %m/%d:%H:%M:%S")

                        print tm #temp -- should log

        else:

                if last:

                        GPIO.output(LED_pin,GPIO.LOW) # LED off

        if m==1 and last==0 

                changes += 1

        h += m

        last = m

        time.sleep(2)

print "m's:", h

print 'changes:', changes

GPIO.cleanup()

The 2 halves of the sensor have to be about .5" apart to register "ON" (HIGH).

Now for my photo sensor.

My Raspberry Pi — Extending Sensor Circuits

I've been wondering what the best way to do this is — and how far you could go. Here's my inelegant solution:

- I bought a 3' 3-wire extension cord
- I cut the cord part in half
- I also cut 3 M/F breadboard patch wires in half (a black, a red and a yellow)
- I stripped all cut ends (12, in all)
- I soldered the female patch wires to the female half of the of the 3-wire cord
- Ditto, the male with the male
- I chose to color code as follows: red=current, black=ground and yellow=GPIO control
- Heat-shrink tubes and electrical tape finished the job.

Above: female end connected to a PIR motion detector.

After I made sure that the short cord worked I added a 50' 3-wire extension between the 2 plugs shown above.  Guess what? That worked too.

So much for good news — what are the down sides?

1. These cords and plug are heavy and stiff. I have to be careful not to bend patch wire pins.
2. 14-gauge wire is over-kill.

But, so what.

After Disaster!

My Raspberry Pi

(if you are new to the site you might want to scroll back a ways)

Lady Bracknell: To lose one parent, Mr. Worthing, may be regarded as a misfortune.
To lose both looks like carelessness.
The Importance of being Ernest,
by Oscar Wilde

Lady B. would have chided me, too. I managed to crash the Linux filesystem on my Pi's SD card. Again! But this time I had a backup image of the entire 16gb card and I have copied individual files back to my iMac, occasionally. But not often enough. My SD image was a month old and the last time I copied files was a week ago.

You might ask, "Why did your Pi's filesystem go bad?" Because I was plugging wires from the GPIO pins to my breadboard while the Pi was powered up. Bad idea! I saw the Pi reboot -- must have grounded a power wire. Afterwards I couldn't talk (via SSH) to the Pi. When I say I "saw" it restart, I mean that the status LEDs went dark and then only the PWR light stayed on. Here's what my LEDs look like, normally:

The REAL info on the Pi's status LEDs:
http://elinux.org/R-Pi_Troubleshooting

Anyway, my SD card backup/restore procedure:

From my Mac's Terminal app (PCers use Putty)--

Backing Up

- Shutdown your Pi
- Pull the SD card and plug it into your USB flash memory reader
- Determine what the device name that has been assigned to your SD using diskutil:
   $ diskutil list  (you should be able to tell by the size in GB)
- Then you have to unmount it:
  $ diskutil unmountDisk /dev/disk2 (yours may not be "disk2")
- Now the copy -- you have to be superuser (be very careful):
 $ sudo dd if=/dev/rdisk2 of=raspberry-pi-backup.img bs=1m

Note I copied from the "raw" device (rdisk2) instead of the "block" device -- it's faster. Also, I used "bs=1m" (block size = 1MB), also faster. When I say faster -- the difference for a 16gb SD versus using "bs=1024" is 6 hours!

Restoring (with care you may never have to)

- Plug the same sized SD card into your flash reader (it's good to have a spare)
- Find the /dev name (diskutil list, as above)
- Also like the above, do the unmount
- Now the copy swapping "if" and "of" (in-file & out-file)
 $ sudo dd of=/dev/rdisk2 if=raspberry-pi-backup.img bs=1m

More about the limitations of copying individual files back to the SSH host: You can't usually copy system updates or things like crontab entries. If you don't know about crontab, you should! Try--

  $ man crontab

Raspberry Pi GPIO Devices

Disclaimer: I'm a programmer, not an engineer. I've been playing with a Raspberry Pi for the last few months and have learned some things and formed opinions. What I've written below may sound like “information” but it's really just my observations and opinions. Dick Haight, 6/26/13

GPIO devices can be mostly separated as inputs (sensors) or outputs (switches). But first, a few remarks about the practical limits of the Rpi. Here's a picture for Rpi B, rev 2.

The left-most diagram shows the physical pin numbers in the center two columns and what the pins might be used for in the outer columns. The pins (3 and 5) labeled “I2C” can be used to control an I2C add-on bus which can control up to 16(?) more devices. The “SP10” pins are still a mystery, but probably work somewhat like the I2Cs. Pins 8 and 10 can be used for old-fashioned serial I/O (but why not just use USB?). “DNC” simply means “do not connect.”

The middle diagram shows using as many pins for GPIO as possible. 17 is probably enough.

The right-edge Rpi photo shows the 26-pin header plus 8 more possible GPIOs (blue loop). The green line circles the socket for the digital camera ribbon cable.

A word about how many devices an Rpi can reliably handle:

1. Outputs have negligible software overhead.
2. Input device overhead is directly related to how often each one needs to be checked. A door-open sensor has to be tested every few seconds; temperature readings could be 100^th as often. The photocell (below) has the highest software overhead of the devices listed: many tests .1 second apart.

Basically, a normal mix of a dozen input sensors should be no problem for an Rpi.

Here are some Rpi input sensors that I find interesting:

Temperature/Humidity DHT22, $10

This simple device appears to provide reliable temperature/humidity readings. I also tested the more expensive waterproof thermometer (DS18B20, temp-only); $16. I need to check how long the connecting wires can be and still get accurate readings.

Rpi CPU temperature

According to Asimov's third law of robotics, “A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.” (which involve protecting people). Therefore, each Rpi has a CPU temperature sensor built in. I read on the Internet that the Rpi can tolerate operating temperatures up to 80C. The testing software should warn (by text message?) at 70C and halt the processor at 75C.

Motion sensor $10

This sensor needs to be tested about every 4 seconds (motion detection seems to stay “hi” for 5-6 seconds. It is supposed to measure out to 25' or so. My device seems to notice movement over about a 90 degree arc. The two adjustment “pots” (green arrows, above) probably change those values.

Range-finders

There is a large variety of these devices. Some ultrasonic, some IR. They cost $25 and up. They typically have a narrow angle of view and a restricted maximum reading.

Digital Camera $30

I haven't looked into this yet, but it could be used as a combo motion-sensor/rangefinder. Or webcam.

Open door/window switch $4

Photocell (power fail) sensor $1

These things are intrinsically analog devices. So the software requires many timed probes (.1 second apart) to get a reading. I hope to use one of these a a cheap way of detecting power failure. Most backup UPSs have a light that goes on when the battery kicks in. Stick a photocell over that lamp and you have a power-fail sensor.

Soil moisture $10

Prices of these things are all over the place. Since the info is analog (voltage leak between the tines of the fork), programming is likely to be like the photocell.

Water level $40

Probably meant for swimming pools. different models can detect up to 12" changes. No code yet for the Rpi. It's another analog thing.

GPS $30

What every traveling Rpi needs. But I don't, for now.

Internet and Text-message inputs

If your Rpi is wifi to a cellphone modem (e.g., Verizon “Mifi”) then it has a phone number and can send and receive text messages – which means that you can control the Rpi from any old smartphone, etc.

Keypad $6

Cheap, but uses a lot of GPIO pins. Why not use a USB device?

Rpi output devices:

LED character displays

Switch 110V AC devices $25

The device shown can handle up to 500W. E.g., operate a fan, etc.

Irrigation control: 8 – 16 valves $150 – 200 (rayshobby.net)

This is an ambitious device for handling up to 16 water valves. Timing can be controlled by a Google Calendar file in the “Cloud.” Such an irrigation schedule can be modified by the file's owner from anywhere. The 24V power supply ($40) and the actual valves are extra. I believe that this takes 6 of the Rpi's GPIO pins and uses the I2C extension.

My RaspBerry Pi adventures

chapter 13

Old business:
I had yet another wifi failure with the Frontier DSL modem -- again
ethernet-connected devices continued to get Internet (including my iMac and the Pi)
iPhones and iPad indicated the wifi was available but it didn't work.

So, it looks like a Frontier problem -- not the Pi.

New business:
I need my Pi application to have Internet access. The cheapest option seems to be
by using a cellular modem (e.g.: Verizon Mifi). The best deal at the moment seems
to be a company called Karma (is it bad karma to mess with that name?). It's a
no-contract deal: buy the modem/wifi device and buy megabytes as needed.
However, its coverage doesn't work for me. Not as cheap but Datajack or Virgin no-contract
plans show good 3G where I need it. Down side: I had Verizon Mifi for a while; it wasn't
terribly reliable.

Sensors:
I got my motion sensor working (PIR device from Adafruit). Like some of the other
devices, it has odd personality quirks. 

What I learned:
* You only have to poll the device about every 5 seconds -- the device keeps returning
"true" for 6 or more seconds after the briefest movement.

* The angle of detection seems to be a bit over 90 degrees.

* The room I'm testing in isn't big enough to tell what the maximum sensing distance
is.

BTW: In case my text formatting looks strange on this page -- well, today blogger.com
doesn't do automatic text wrap -- so I've typed my own line returns. Strange!

My Raspberry Pi (continued)

Oops. Yesterday my DSL wifi died again, but the Pi had never been connected. So my previous post may be hooey.

A possible Raspberry Pi-induced WIFI problem:

Since I started playing with my RasPi I've noticed that wifi for the whole house seems to stop working some hours after the Pi has been connected. My wifi comes from (with) a DSL modem with Frontier branded on the box. My iMac is two feet from the modem and is wired to it by ethernet cable. Everything else, iPhones, iPad and of course, the Pi used wifi. After the tenth (or so) time I had to power cycle the DSL to get wifi working again I decided to pull the USB wifi dongle out of the Pi and replace it with ethernet wire to that same modem. Guess what? 'Haven't had a wifi failure since. BTW: I had tried two different wifi dongles with the Pi.

Anyway, this is irritating. Especially since I'm planning a Pi application that depends on reliable wifi. I had two dongles to try but I lack an alternate wifi access point to experiment on. There is a lot of noise on the Web about dongle configuration problems (I had none) but nothing I've found about the Pi locking things up.

Any suggestions?

My RaspBerry Pi

(Hint: if you are new to the Raspberry Pi you might want to review my earlier posts)

Since an early disaster with the Pi's Linux filesystem I have been pretty careful about backing up any programming work over WIFI to my iMac. The last time I downloaded the full Linux image I also retained the file on the Mac. The one thing I had not done was to back the whole SD card. It turns out that my original stuff only took up about 2GB on my 16GB SD. But since then I have downloaded a lot of new software. This includes the the latest Linux updates, GPIO libraries, drivers for devices, and most recently, software to read weather reports as text from the Internet.

This AM when I booted the Pi up, my usual SSH (secure shell) from my iMac didn't work. Scary! Also, the activity light on my USB wifi dongle wasn't blinking. So I pulled the SD card out of the Pi, plugged it into a flash card hub on the Mac and immediately made a literal copy with the old UNIX DD command. I'm going to do that regularly from now on. Anyway, after I moved the wifi dongle to a different port on the USB hub everything worked again. So, no big deal. But now I'm fully insured against disaster.

I'm now waiting for some spring-clip connectors for breadboarding. Much less trouble than soldering pins on to flimsy wiring.

If you are new to the Raspberry Pi you might want to start back to my earlier posts.

Got 3 things from Adafruit today:

1. Many more assorted M/M jumper wires (you really want lots of lengths and colors).
2. A DHT22 temperature/humidity sensor.
3. A POS-type motion sensor.

In a mere hour I have the DHT working. I'm getting better at this! However, there were some wrinkles to work out.

• The best info on how to use the Adafruit wiring plan and code was in French at http://www.manuel-esteban.com/lire-une-sonde-dht22-avec-un-raspberry-pi/ -- luckily I still remember enough francais from 60 years ago to get by.
• The sample program did the hard part of reading the DHT22, but it didn't suit me otherwise. More luck: that program was written in C Language. While at the old Bell Labs and Clemson U. I programmed mostly in C from 1972 to the late '90s. I simplified the program down to what I needed and fixed a small bug: the code as I found it returned success even when the DHT22 was read incorrectly. 

I still have the motion sensor to conquer. But who's worried.

I'm still working toward a vegetable farm automation system. While pawing through Raspi references I found--

   http://rayshobby.net/blog/?page_id=562#ospi

Ray (assuming it's a person, probably male) has developed an add-on interface board for the Raspi that can control an 8-station irrigation setup. It costs about $150, plus the Pi, plus the irrigation parts. For another $50 you get 8 more hose valve controls. There is even code for controlling every valve from the Internet. Or -- it can be operated from a Google calendar. 

Here's my messy setup du jour:

Things I've got working so far (Python programs):

1. LEDs (probably always the first try).
2. Buttons, button to turn LED on.
3. Read the CPU temperature (and Halt the processor if it gets over 80C).
4. Read an MD80C20 temperature sensor. This gave me some trouble because the waterproof version connected by a 30" cable came with no clues about which of the three colored wires corresponded with the pins on the bare MD80... I finally found it: red=3.3V, black=Ground, white=Data. Probably obvious to most Rpi users. Also, I had trouble connecting the 3 wires to the breadboard. The ends of the wires were tinned but only stripped back about 1/8". I stripped another 1/4" back but the wire was too flexible to make a decent connection to either the breadboard or to the female end of a jumper. So I cannibalized wire bits off an LED and soldered them to the flimsy MD80 wires. Voila, it worked.

I'm waiting for motion and humidity sensors. Also getting a larger selection of jumper wires. To keep sane you need a variety of colors and lengths. In addition, I ordered several multi-wire spring-clip connector blocks -- would have saved me some soldering on the MD80.

What next to buy?

• Rpi camera board: $30
• A stepper motor: $5 and up
• A "power tail switch" to switch 110V/500W: $26
• Controls for turning on garden/farm irrigation pipes.

6: Electricity?

My only exposure to electrical theory was 60+ years ago in 10th grade physics. My practical experience did not run to breadboards, jumpers, LEDs (see my previous post), etc. Internet content is great for ease of access but can occasionally be wrong. The breadboard images below make things pretty clear. The left side is less interesting than how the holes are really interconnected underneath.
The bad info I got stated that the vertical outer columns were NOT connected across the gaps that occur every 5 rows. I did some really dumb jumper-ing while I momentarily believed that.

I had not sprung for a DC voltmeter which could easily tested from top to bottom of a column. But then I realized I could make my own:

In around 1956 I bought a cheap soldering iron so I could assemble a Heathkit amplifier. It has been (literally) gathering dust in my workshop since then. The image above shows my crudely soldered voltage tester (cheap LED and matching resistor, pretty useful). This gimmick immediately disproved the false info I mentioned above. The underside breadboard diagram shows that the left and right sides of the board are a) totally separate, b) the outer 2 columns run the length of the board (and could care less which one is positive or negative), and c) the center 5-pin rows are horizontally connected. The red lines I drew on the left breadboard image above are to suggest that it might be cool to connect Pi GPIO pin 1 (3.3V) to the left-most column and GPIO pin 2 (5V) to the "+" column on the right side. I also drew a blue line to the left side minus column (from GPIO pin 6). This I also jumper on over to the "-" side of right edge. Just my way of keeping sane (-ish).

Because of age-related presbyopia I could really use a "large print" version of the breadboard. But that's never going to happen so I keep the magnifying glass close.

5: I have added some gear:

1. a full-sized breadboard
2. some F/M jumper wires

3. some LEDs (with matching resisters) and button switches

I added the GPIO software to my Pi (via the dangerous "sudo apt-get install ..." method, but this time backing everything up).

My first attempt was the obvious "make an LED blink" program. My first four attempts didn't work. Guess why-- nobody told me that LEDs care which wire is positive. Four tries and I never guessed right! Finally got the hint from a Youtube lesson. The longer wire on the LED has to be the positive side. Duh.

I got some button switches too. They work (sort of) with my Python code but not reliably. I've tried testing button depressed, button edge down, button edge up. Also, different sleeps between tests. Not reliable yet.

Here's a confusion: GPIO pin numbering. There are at least 3 schemes. Two are shown below.

If your Python shows:
import RPi.GPIO as GPIO
. . .
GPIO.setmode(GPIO.BOARD)

You will use actual pin numbers (they aren't numbered on the 26-pin connector, you have to count). Those numbers are in the 2 center columns, above. But if you replace the 2nd line of code above with:
GPIO.setmode(GPIO.BCM) 

Then you are using the"GPIO" numbers shown in the outer 2 columns. I'm not getting into the third scheme, yet.

In the meanwhile, I've ordered more jumpers (can't get by with M/F) a wide assortment of resisters, plus temperature and motion sensors.

4: Since my last post:

I tried adding software by the--

  sudo apt-get ...

method. And I learned (again) that doing things as super-user (i.e., "sudo") is inherently dangerous. The last such download (wish I remembered what it was, exactly) corrupted my flash filesystem. I only found out when I rebooted. Anyway, it was back to downloading a new copy of the OS. This time I am doing a better job of backing up the Pi to a folder on my Mac.

When I initialized the system, this time I set up the US keyboard the easy way and added SSH at the same time. Now my Pi sessions go as follows:

1. Power up the Pi.
2. Start SSH from my iMac Terminal app:
      ssh pi@192.168....
3. Mount the Pi "Home Folder" on the iMac.
4. Play with the Pi
5. Copy any new Python code to a backup folder on the iMac. 
6. Shutting down:
      sudo shutdown 1
7. Pull the power plug.

Here's a little Python program that prints the CPU temperature:

#cputemp.py
import commands
import re

str = commands.getoutput('/opt/vc/bin/vcgencmd measure_temp')

r = re.match(r'.*=(\d+\.\d)', str)
c = r.group(1)
c = float(c)
f = int(( c * 1.8) + 32.0)

print "Pi CPU temp=", f, "F, ", c, "C"
if c >= 80.0:
    print("Don't fry your Pi -- 80C is the max. safe CPU temp!")

My Pi runs at a little over 40C in its plastic case.