Economy Size Geek - Who Goes There? Adventures in Amateur Security
The situation: I share an office with my brother. This office is in a suite of other offices that we share with another company. Sometimes I work from home; sometimes I go in. I haven't been in the office for the past few weeks because of a motorcycle accident (from which I hope to be fully recovered by the time you read this—fingers crossed). That got me thinking, I have no idea if anyone has been in my office during the time I've been out. It would be great if I had some sort of basic security system that could tell me if people entered my office and, if possible, show me a picture of who they were.
The first thing I did when I moved in was upgrade the lock to my office. This actually was more about laziness than security. I got a keypad lock so I still could get in even if I forgot my keys (or needed someone else to get something if I wasn't there). When I went shopping, there were a lot of locks from which to choose. The one that really caught my eye was the Schlage Wireless Keypad lock. This was a keypad lock, but it also included Z-Wave support. Schlage had an add-on version and a starter kit. The starter kit included a wireless hub and a lamp controller. It didn't seem like a terrible deal until I realized the included hub required a monthly service fee to use it, which turned me off.
I figured there had to be a way to control it from Linux. If I could do that, I could meet my first goal—alert me when someone enters. I've used X10 for a long time, and it always was pretty easy to script from Linux. I assumed Z-Wave would be the same, but it turns out, Z-Wave communication is a lot more complicated (I guess I shouldn't be surprised, as it is much more advanced than X10).
Under Linux, there are two paths to follow to Z-Wave access. The first is the LinuxMCE (www.linuxmce.com). This project is a combination of media management, home automation, phone and security system, all built on top of Kubuntu. In order to access Z-Wave from it, you need a Z-Wave hardware dongle. Several supported dongles are listed on the Web site. I was especially interested in this path, because of rhouse from Fernand Galiana (github.com/derailed/rhouse). rhouse lets you script LinuxMCE from Ruby. It seemed like a solution right up my alley.
The second path for Z-Wave is the Vera from Mi Casa Verde (www.micasaverde.com). I first learned about this product in the May 2009 issue of LJ (www.linuxjournal.com/article/10302). As I already mentioned, I've used (struggled with) X10, and the Vera seemed like a solution that would be more reliable and more accessible to my other family members.
Choosing a path always is hard. The LinuxMCE path was tempting because it used the least amount of hardware and the most amount of software (which favors my skills). But, I ended up choosing the Vera, because of deployment issues. I don't run Kubuntu, so I either would have to set up another box in my office or run a virtual machine on my workstation (and handle passing through the USB Z-Wave dongle). The Vera box uses little energy and, thus, does not generate much heat—something that is always a consideration here in south Texas. I decided to start with the Vera and figured I always could fall back on the LinuxMCE.
I turned on and set up the Vera. A handy guide on the Wiki (wiki.micasaverde.com/index.php/Schlage_Lock) walked me through the process of pairing the lock. The first step was upgrading my firmware. My Vera was running 1.0.434, but 1.0.602 was required for the lock, and the current version was 1.0.939. I went to the latest version, figuring I might get other improvements as a bonus.
If you have ever worked with X10, the pairing process for Z-Wave is a breath of fresh air. Instead of messing with small toggles, you simply pull the dongle out and press a button to put it in pairing mode. Then, you activate the Z-Wave device. Next, you put the dongle back into the Vera and start configuring your new device. This would all be true if you were talking to a normal Z-Wave device, like a lamp. It turns out, they take lock management a lot more seriously. As a result, the pairing process is much more involved. And, it's a little more complicated, because the Schlage does not emit a very strong signal (a result of it trying to conserve battery power and being encased inside the lock mechanism). That didn't prove to be too much of a problem, because I had a network and power port not very far from the door.
I did the secure pairing dance, which mostly meant starting the pairing process and then running to the door to punch in a programming code. After two attempts, I got a green light from the lock. I was able to see the lock on the Vera device screen. Things always should go this smoothly. I started adding and removing code. I clicked on lock and unlock. Nothing seemed to happen. It turns out that although the lock and Vera were talking, they still were exchanging encryption information—meaning that all my messing around was being queued up until it was done. After about ten minutes, the lock and Vera were fully in sync.
Here is where I realized the LinuxMCE path is not as clear as I thought. I did some research, and I was not able to find anyone who reported pairing with a lock under LinuxMCE successfully. I would have been really frustrated to have gotten Kubuntu, LinuxMCE and rhouse installed only to find out the lock was unsupported.
Once the job queue was cleared, I was able to add myself as a user to Vera. My profile on the Vera has an e-mail and cell-phone number so I can get SMS alerts. Vera supports the concept of “scenes”. A scene allows you to tie together an event, a notification and one or more changes to Z-Wave devices. I created a scene called Door Opened, which was tied to the event that is generated when the lock reports being opened. I also told the scene to notify me via both e-mail and SMS.
Once this was set up, I was notified when the door opened. This was completely independent of entering a pin on the keypad, which meant that when I left the door unlocked, going in and out of the room generated alerts. The SMS can take some time, so by the time I realized how many alerts I had generated, I was getting a lot of them.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server