Thursday, March 28, 2013

Arduino Alarm, Test 28 MAR 2013 - SUCCESS

Here is one more post on our way to a cheap security system.

Well, it has been a great day.  Working through the last kinks of the bad board design, I finally got all of the pins connected, and the board is now using DHCP.  That means all I need to do is specify the MAC address.  The DHCP server will set the address I choose it to have, or it will return a random one if I don't choose.

To have it respond as a server (e.g. if you are monitoring it), you will probably need to set a static one so that the IP address doesn't bounce around on you.  Otherwise, you probably won't care.  I needed it to respond as a server, because I needed to be able to query the state of stuff, and also to fire off switches.  If you have been following along, in a previous post, we added some relays so that our Arduino can switch things on and off (that was a fun experience - creating a new PCB that you just solder some parts to - and all because I wanted to be able to open a garage door).

That means that I had to add some new logic (handling inbound connections so something outside of the Arduino could interact with the switch) and matching configuration options to handle switches.  Seeing as how I can't implement only one type of switch, I implemented logic for two kinds in my mind, a momentary switch (where the switch is engaged and later disengaged), and a toggle switch (e.g. a light-switch type that remains in the state it's put into until it is switched again).  In the updated code, I added new configuration options and processing, e.g. :
With the new PCB, the two relays are on pins 22 and 23.  The configuration definition is PIN,DEFAULT_STATE,TIME_TO_DELAY_IN_MILISECONDS.  Pin 22 will ultimately be tied up to the garage door opener as a switch.  However, in this test, I simply connected it up to the volt meter (put into continuity testing mode that makes an audible beep when the two probes are connected together), and had no beep with it defaulted to LOW.  Fired off the :
    hostname:~ username$ telnet 3612
    Connected to arduino.
    Escape character is '^]'.
    switch garagedooropener
    Connection closed by foreign host.
    hostname:~ username$
... and viola... an audible beep for one second!  I instantly felt the need to proceed.

The next step was to connect them.  I quickly ran the wire (can use the same wire for the weather station and analog stuff in the future, but I'll leave that for a future project).  I used some quick connectors with heat shrink to get a good shield from the elements (I know, I know, this is all indoors, but my natural instinct is to protect it all), soldered them inline, and instantly had a fully functional switch for the garage door.  After I generate the portals, I will create a video showing the functionality of the system, and some of the components.  In the mean time, here is the current status of the project :
  • Event handling from switches [check] (the doors, etc) is complete and operational, including off-site notifications [check].
  • Motion events are triggered [check] (and video is captured as it happens [check], with clear and high resolution video [check]).
  • The Arduino device is stable [check] and hasn't had a failure aside from me tinkering with it.  It's almost perfect for me (I still want to add environmental sensors to it for monitoring wind, humidity, barometric pressure and temperature).
  • Logging is complete [check] (including off-site logging [check]).
Because the alarmserver package was created for plug-ins, it means the system could potentially connect to a PBX, or a Jabber client, to send messages.  However, I'd prefer a few things here, so here is our list of things to do :
  • The portal/interface
  • Rebuild the alarmserver software to allow for "chaining" of events or notifications.
The reasoning for rebuilding the alarmserver is that one night, as I was trying to initially add the relays to trigger the garage door, I broke some wires.  The same event is also what triggered me looking into doing a PCB for this.  I explored a few different options for that one (which is why that next post took me so long to put up), but ultimately found one that worked for me.

What I want to accomplish is to create "chains".  I'd like two events to combine into another additional event.  For example, if the motion in the front yard is triggered because the neighbors dog is running all over, I don't want to be notified.  However, if the drive way motion is triggered, notify me.  If the front lawn is triggered and the side of the house is also triggered, notify me.

And then I'd like the chains to apply to notifications.  I'd like it to first try to send me an instant message first (no need to get an SMS if you're logged in to a chat server), and if I'm not online, then try and send me an SMS.  That way, the data plan usage is kept to a minimum, I get notified (and potentially get more detailed information in IM vs the short 160 character SMS limitation), and everybody is happy.

At this point, all that I was looking for initially has been accomplished, and in the process this has become quite the little project.  I have definitely experienced and learned about the Arduino (and the Raspberry Pi - something I may write about later).  I'll shoot for a video once the interface is complete and the event server has been rebuilt.  But, until then, it's alive!

No comments:

Post a Comment