A Pi in the Househttps://rpihouse.wordpress.com
Using a Raspberry Pi for home monitoring and automationSun, 11 Feb 2018 11:40:33 +0000enhourly1http://wordpress.com/https://s2.wp.com/i/buttonw-com.pngA Pi in the Househttps://rpihouse.wordpress.com
Action at a Distance (Pi/Arduino RF controlled lights)https://rpihouse.wordpress.com/2013/01/05/action-at-a-distance/
https://rpihouse.wordpress.com/2013/01/05/action-at-a-distance/#respondSat, 05 Jan 2013 21:30:50 +0000http://rpihouse.wordpress.com/?p=76In the previous post, we sniffed the on/off codes for RF controlled outlets. For this post, we’ll program an Arduino to transmit the codes and have that controlled by a Raspberry Pi.

Hardware

Because some precise timing is needed for the transmitter, an Arduino will be used to control the RF transmitter itself. The MagPi article mentioned in the previous post connects the transmitter directly to a Raspberry Pi, and says that the code must be sent several times to ensure that it works. That’s because the Pi runs Linux, which is not a real-time operating system. At any given time, the process that is sending the on/off code through the transmitter may be preempted by some other linux process or service, messing up the code. Instead, we’ll use an Arduino based microcontroller and connect that to the Pi via USB. The Pi will send a signal to the Arduino, which will transmit the code (guaranteed to not be interrupted) and then send an acknowledgement back to the Pi. I happen to have an old Arduino Duemilanove sitting around doing nothing. It’s nice to be using it again.

Below is a picture of the Arduino set up. The Duemilanove is clearly seen connected to a half breadboard. The long yellow wire is the antenna for the transmitter (read more below). The USB cable connects to the Pi not in the picture. Actually, it is plugged into a 7 port USB hub for the Pi. A close up of the breadboard is below.
There’s more on the breadboard than just the transmitter. On the far left there’s a Dallas One-Wire DS18B20 digital temperature sensor (a remarkable device that deserves its own post soon) connected to the Arduino. Next is the transmitter. It’s very easy to connect – it has only four pins. One goes to +5V from the Arduino, another to ground, another for the data (green jumper wire that goes to pin 3 of the Arduino), and the antenna. More about the antenna later. The rest of the board has the receiver and the audio jack used in the previous post to sniff the codes (I pulled the +5V connections so the receiver is not powered, but it was useful to still have it hooked up for debugging).

Arduino firmware

The next part is coding up the Arduino and the Raspberry Pi. All of the code is on GitHub. The Arduino code is in the arduino/HomeControl.ino Arduino sketch. This sketch also retrieves the temperature from the one-wire temperature sensor, so to run it as is the OneWire library is needed. The code also can transmit a signal to toggle on/off the light on the ceiling fan in my daughter’s room. I tend not to use that, because it’s a toggle and if the signal is missed, then the light will do the opposite of what it supposed to do at the next signal.

FanTransmitter and RFOutletTransmitter are classes that send signals to the RF transmitter (they really should inherit from a common base class). They basically send highs and lows to the transmitter for certain periods of time, based on the code sniffing explained earlier. Each class has some constants that specify the timings (e.g. a longTime for the RF outlet is 1750 microseconds). The transmitCodeString method accepts a string of letters, parses it, figures out the high and low transmit times, and then calls the transmit method with those times. transmit actually pulls the transmitter data pin high or low for the specified amount of time. It also lights an LED on the Duemilanove board while transmission is occurring.

FanCode and OutletCode construct the complicated strings that represent the transmission timings. Then, these classes are instantiated with the specific on/off codes. For example, to turn on outlet one, the code is,

where “M”, “A”, “B”, and “L” are different timings of high and low for the transmitter.

The loop of the sketch waits for a “command” to come on the serial port (USB). The commands (different from the transmission codes above) are, for example, “A” to turn on outlet one, “a” to turn off outlet one, “B” to turn on outlet two, and so on. The code then waits half a second (can probably remove that wait) and sends back an acknowledgement on the USB. Looking at this code again, I see some places for improvements (e.g. the transmission code is constructed for each transmission instead of once, but that’s not a big deal).

So basically, the Arduino sits there waiting for a command to come over the USB. When the command comes, it fulfills it, sends an acknowledgement, and waits for the next command.

Raspberry Pi software

The Raspberry pi code is in Python and sends commands over the USB to the Arduino. Two python libraries need to be downloaded and installed: pySerial and lockfile. The easiest way to install them is to use the pip command,

pip install pyserial
pip install lockfile

pySerial is needed to communicate with the Arduino over USB. lockfile is needed to ensure that only one linux process is sending USB commands to the Arduino at a time. Before accessing the Arduino over USB, the code will attempt to acquire a “lock”, and will wait if another process has the lock already and won’t proceed until the lock is “freed”. The process of acquiring the lock is complicated (it involves creating a file and then making a “hard link” to it), but it is all contained within the lockfile library.

There are four python files (click on the file names to see the files):

pi/logfile.py gives a common log file for the other programs. See the python documentation for logging

pi/transmitter.py does all of the work of talking to the Arduino. Its send function takes the command to send, acquires the lock as mentioned above (note the with lock: line), opens the serial connection, sends the command, and waits for the acknowledgement. You can run this file directly. For example, to turn on outlet 1, do ./transmitter.py A

pi/homeCommand.py is a convenience command to immediately turn on or off an outlet with a human-readable line like ./homeCommand 1 on to, for example, turn on outlet one.

pi/homeDelay.py is the same as homeCommand.py but waits for a random delay before issuing the command. The maximum delay in minutes is given as the third argument. So ./homeDelay 1 on 90 will turn on outlet one after waiting for a random amount of time, up to 90 minutes.

Pi crontab file

To make a vacation light timer, we need to turn on and off lights at certain times, or with slightly randomized times. Running linux commands at specified times is a job for cron. You write a special “crontab” file to specify when lights should turn on and off. You can see the currently active crontab file with the crontab -l command. You can write this out a regular file with crontab -l > myfile. Alter this file with your editor (pico or vi). You then have to install it into cron with crontab file where file is the name of the file. You can also edit the crontab file “in place” with crontab -e See pi/cron.lights for an example crontab file.

More about locking (and using a Ram disk)

The lockfile library mentioned above makes a regular file, and then attempts to make a hard link to it. The hard link is necessary because that is an atomic operation (the file system will allow only one process to create the hard link, making others wait). This eliminates race conditions. For example, say you did locking this way: Check if file “A” exists. If not, “acquire” the lock by creating file A, doing whatever, and then relinquishing the lock by deleting file “A”. If file “A” had existed, then block (wait) until file A is deleted before proceeding. Naively, this would work fine, except in the situation where process 1 acquires the lock by creating file “A”, BUT process 2 comes along while the file system is creating file “A” before it appears in the directory. Process 2, not seeing the file, would the proceed as well, thinking that it had acquired the lock too. The “hard link” creation process is “atomic” for the file system – it will not allow another process to make or check a hard link while it is creating it.

Having all of this file activity occurring on the SD card of your Pi is silly and perhaps detrimental to the card. Fortunately, the Pi has a few special directories as “RAM Disks”. These are filesystems completely in memory (so don’t put anything important there). One such directory is /run/lock which seems to be made just for lock files. You can verify that it is a ramdisk by doing

tmpfs is the filesystem type for a RAM Disk. So we’ll use that directory for our lock file. See pi/transmitter.py

Experience

We just got back from a two week trip. Using the circuit and software described here, I had the Pi controlling three “timer” lights. Before leaving I did quite a bit of testing. To make the signals reliable, I added a quarter wave antenna (9″ wire) to the transmitter (the long vertical yellow wire in the picture above). That made the lights respond to every command every time. As far as I know, everything worked great (we arrived in the evening, and all of right lights were on).

I put some lights on timers whenever we travel. A few lights in the house are on permanent timers (I had bought Aube TI035/U timer switches for the outdoor lights – they work nicely), but most of the indoor lights only need to be on timers when we’re away. You can buy fancy digital temporary light timers, but we have the old mechanical types. I really don’t like these things as they are pretty inaccurate and if there’s a lengthy power failure, the lights will turn on and off at the wrong times once the power comes back on.

So instead, I thought it would be interesting to have the Raspberry Pi control some lights using RF controlled light switches. Home Depot has these. They seem to be especially popular around Christmas time as they can be used to control decorative lights. The package contains a remote fob and three outlet boxes. The outlets boxes are numbered #1, #2 and #3 (though the first package I got had two #2’s and a #3 – I exchanged it) and the fob has three sets of push buttons: an on button and an off button for #1, #2 and #3. This seems perfect – the remote has separate on/off switches (not toggling on/off) and each outlet can be controlled individually. So with one package you can control three outlets (you plug the outlet box into the wall and then plug your lamp or whatever into the box). It also looks like you can control even more as each package is marked with a sticker saying “set A” or “B”, up to “E”. The outlet boxes have the same sticker. So if you, say, buy an “A” package and a “B” package, you can have six individually controlled outlets.

The remote works at 315 MHz. So the task ahead is to somehow “sniff” each code that is transmitted from the remote fob to the box and set up a transmitter so that the Pi can transmit the same thing. If the Pi can send the same code, then the outlet should react as if the corresponding button were pushed on the remote fob.

Sniffing the codes

There are several online articles that describe sniffing RF codes. See here and here. There was also a pretty good article in the Mag Pi magazine, issue 8.

The basic idea is that you have to buy a 315 MHz transmitter/receiver set. You hook up the receiver to an audio plug that you plug into the line-input jack of your computer (a PC or a Mac – not your Pi). Using an audio capture program like Audacity, you record the signal coming out of the receiver when you push a button on the remote fob. This will give you the code for that button. You then use the transmitter and play that code back and voila, you’ve got control of your lights from your Pi.

Wiring it up

Here’s a Breadboard view and a schematic of the little sniffer circuit.

R1 is a 500K ohm resistor between the receiver output and the audio cable line (the MagPi article suggested 1M ohm). Although the breadboard picture shows the receiver as a chip, it is in fact a very slender PC board with some pins soldered to the bottom. You simply plug it into your breadboard. The pins are all in one row.

Below are some photos of the set up. The first is of the whole thing connected to my Macbook. Power comes from an Energizer 4Ah portable charger (e.g. emergency charger for your cell phone) that has a USB port. I got a Sparkfun Hydra USB power cable (a very clever cable with USB on one end and various plugs on the other for power – including the alligator clips used here. Just make sure they never touch and short out the power source!). The bottom picture is a closeup of the circuit. Note that the receiver has a few more connections to +5V and ground not shown on the schematic. Fortunately, they are labeled on the little receiver board. Note that there’s no external antenna needed.

Trying it out

So now it is time to capture some codes! Power the circuit, plug the audio cable into the line-in jack, and launch Audacity. Make sure Audacity is set to record from line-in. I set the “Project Rate” to 48 KHz (not the default). I pressed a button on the transmitter fob and saw the following:

If you actually play the sound on Audacity, you here a lot of static, then tones (!), then more static. Very cool! Something is working! To see the actual signal, zoom in between 0.80s and 1.20s.

The start of the code is the long pulse high at the beginning. Note that it ends with the very long low signal.

You definitely see some repetition in the code. Zooming in on one of the “blocks”,

you see a pattern of highs and lows. Stare at this long enough and you can determine the code for the various buttons on the transmitter fob.

The next blog post will show how to build and code up the transmitter.

If you are using the Raspberry Pi to monitor or control something in your house while you are not home, it may be important for you to login to your Pi from the internet (e.g. on the road). To do this you need a port on your Pi that is exposed to the outside world and some way to find your Pi on the world wide internet.

To do the latter, you need a dynamic DNS service. Here I assume that your Pi sits behind a router (maybe wireless) and gets a local IP address. Your router is connected to your ISP and it has the internet IP address that is accessible from the outside. You could memorize your router’s IP address, but your ISP may change it from time to time and so that IP address will go out of date. Dynamic DNS services solve this problem. You run a little program (called ddclient) on your Pi that every few minutes figures out the internet IP address of your router (it in fact does this by going to http://checkip.dyndns.org (try it yourself). It then contacts your Dynamic DNS service and reports this IP address. The Dynamic DNS service provides you with an internet address that will take you to this IP address (e.g. blah.dnsdynamic.com).

Next, you need your router to forward a port to your Pi for access. I will forward port 9622 on the router to port 22 on the Pi. Port 22 is the ssh port. So that means from the outside world I can do ssh pi@blah.dnsdynamic.com -p 9622 and I can ssh to my Pi!

Realize that exposing a Pi port to the outside world is somewhat dangerous, because other people can find it and try to hack into your little Pi. That could be really bad. So to try to prevent this, I’m only going to expose the ssh port, and I’m going to forward it to an obscure port number on my router. This will be the only port I expose (so I’m going to do ssh port-forwarding if I want to look at a web server on my Pi). A malicious user would need to do a full port-scan to find my obscure port (this does happen – where I work new machines are port scanned by someone on the outside within minutes of being attached to the network). And then I’m going to have my ssh server locked down very tightly. More on this below.

Setting up a Dynamic DNS service

There are several free dynamic DNS services. The one that seemed to work the best and was easy to set up was http://www.dnsdynamic.org/. After making an account there and creating a name for your address (e.g. blah.dnsdynamic.com), you then need to install the ddclient program. I followed the instructions at http://wellsb.com/post/29412820494/raspberry-pi-vpn-server#router which worked pretty well. Just follow the instructions for dynamic DNS, not the other stuff (e.g. don’t do VPN nor clients). The nice config screen only comes up when you are installing ddclient. If you mess this up, it is hard to get it to come back. To make that happen, completely remove the ddclient software with sudo apt-get purge ddclient. The config program should run again when you reinstall ddclient. Be sure to follow the directions about editing the config file. That’s important. When you are done, you should be able to access your router using the address that you set up with dnsdynamic.

Opening and forwarding a port on your router

You now need to open a port on your router and tell it to forward to port 22 on your Pi. Hopefully, you know how to do this on your router. Be sure to pick a large router port number (like 9000 <= your number <= 9999). You'll have to remember it though. Once this is set up, if you ssh to the machine name (e.g. blah.dnsdynamic.org) and that port, your Pi’s ssh daemon should ask you for a password.

Locking down ssh

Having ssh ask for a password could possibly give attackers a way into your machine, if they can guess that password. A better thing is to not use a password and to give your ssh public key to the Pi. The advantages is that only you, or others who give their key to the Pi, can log into the machine. You don’t need a password. This is secure because you keep your private key on your “client machine” (the laptop or desktop you are using to log into the Pi) and that is needed to ssh to the Pi. No one else can guess that private key (it’s big). The disadvantages are that you have to always use that client machine to log into the Pi. You can’t use a public machine (e.g. at the library) nor a friend’s machine. If your laptop or desktop breaks, you won’t be able to use another and you’ll have to log into your Pi physically from the console to regain access.

If you don’t already have a private/public key pair on your client machine, you can easily make one with the ssh-keygen command. Follow the instructions. You can assign a passphrase to the key, so that you have to enter that phrase whenever you use it to ssh. I don’t bother with this, but you might if others can use your client machine. This will leave you with two files, id_rsa is the private key. Don’t move it nor share it with anyone. id_rsa.pub is your pubic key. Copy this file to your Pi (use the scp command) and add it to the contents of ~/.ssh/authorized_keys on the Pi. If you don’t have that file, make it. If you already have it, make sure the keys in there are still valid (remove ones that you don’t use anymore). Then simply add the text for your public key to the bottom.

Now, on the Pi, lock down sshd so that it no longer accepts password trys. To do this, sudo vi /etc/ssh/sshd_config and change the line with PasswordAuthentication to say no. Then, restart sshd with sudo /etc/init.d/ssh restart . Now you are all set.

]]>https://rpihouse.wordpress.com/2012/12/06/outside-looking-in/feed/1lyonsquarkWatching the dog (the Pi watchdog process)https://rpihouse.wordpress.com/2012/12/06/watching-the-dog/
https://rpihouse.wordpress.com/2012/12/06/watching-the-dog/#respondThu, 06 Dec 2012 03:42:32 +0000http://rpihouse.wordpress.com/?p=10If the Pi is going to be running unattended for a period of time, it’s important to have it automatically “fix” itself if something goes wrong. The chip that runs the Pi has a “watchdog” that can reboot the Pi if it determines that the computer has hung (or if other conditions are met). There are several blogs that explain how to set this up, but none of them get it completely right. I’ve finally gotten it to work, including doing the “fork-bomb” panic test. The several sites that have information on the watchdog are,

You should now be protected. There is a “watchdog daemon” that sends a signal to /dev/watchdog every ten seconds. A reboot is triggered if this file does not receive the “heartbeat”, indicating that your Pi is hung.

There are some situations where the Pi will be unresponsive, but the heartbeat may still occur. Uncommenting the max-load-1 line means that if your one minute load average exceeds 24, then the Pi will reboot. A load average of 24 means that the Pi is abnormally busy and should never be reached in normal operation. Indeed, while running the Pi with XBMC showing a Youtube video, the one minute load average never broke 2.

You can test the watchdog with a “fork-bomb”. You need to turn off the swap space first and make sure nothing critical is going on. Turn off swap with swapoff -a. Then issue this strange looking command