Showing posts with label iOT. Show all posts
Showing posts with label iOT. Show all posts

Wednesday, 11 October 2017

X10 Home Security DIY - Rules Engine

X10 Home Security DIY - Rules Engine

Adding a json-based rules engine to our Home Automation DIY means we can make any action happen when any IoT device event triggers it.  This is a practical and flexible alternative to a commercial solution, or to using the (too many!) apps for each of our IoT devices.

This means we can turn on a light when the front door opens, or send a text message when the alarm triggers: the possible combinations are almost infinite (which is why it is better to do this with rules than with a big 'if' statement).

I am quite pleased with this addition to our home security DIY - we now have our house reacting to us (through our presence), instead of us having to explicitly control it by pressing buttons or running apps.  By controlling our IoT devices using rules, the house seems quite artificially intelligent...

Here's how we do it:

1. Each IoT device has its own html section (a module), its own JavaScript file to control the actions and display elements, and its own Perl CGI file to control access to the device API.  The Perl CGI resides on the server (a linux host; for us it is a Raspberry Pi running Raspbian and Apache); the JavaScript is run on the client.

To facilitate rapid communication of each IoT device state, a json file is used.  For example, the json file for our security module (Security.json) looks like this:

{"X10security":"off"}

That is, it is a simple json-format list of key:value pairs, stored in a file.  Any time the Perl file executes a command, it updates the json file (and returns it to the JavaScript client so that the web interface is updated).

2. The rules engine, coded in Perl, reads the current state of all of the IoT modules from the json files, and stores it in a Perl hash (associative array).  The rules themselves are also in a json file, and are structured as follows:
  • a rule name, e.g. "name":"Rule1"
  • a set of trigger events, e.g. "front_door_opened", any of which will cause the rule to be evaluated
  • a set of conditions, all of which must be true in order for the rule to fire
  • a set of actions which are performed if the rule is fired
Conditions are tested against the list of module states from the json files, whose values are all stored in the hash (associative array) to make the lookup easy.  A json-format rule looks like this:

{ "name": "Rule3a Motion sensed", 
      "triggers": [ "motion_sensor_activated" ],
      "conditions": [ { "module": "security", "name": "X10security", "value": "off" },
        { "module": "devices", "name": "wemo", "value": "off" } ],
      "actions": [ { "module": "devices", "name": "wemo", "value": "blink" } ]
},
 
The above rule basically reads "If the motion sensor triggers, and security is off, and the wemo device is also off, then set the wemo device to blink.

The actual rule-to-state comparison is:

First, we check that the trigger event matches at least one of the rule triggers:

     foreach my $ruletrigger (@$ruletriggers) {
       if ($trigger eq $ruletrigger) { $triggerresult = true; }
    }

Then, we check that all of the conditions are true:

  if ($triggerresult eq true) {
    my $overallconditionresult = true;
    foreach my $rulecondition (@$ruleconditions) {
      # look up the value/state of the condition name
      my $stateactual = $state{$rulecondition->{'module'}}{$rulecondition->{'name'}} ;
      my $conditionresult = eval ('$stateactual ' . eq . ' $conditionactual');
      if (!$conditionresult) {
        $overallconditionresult = false;
      }      
   }
}

Finally, if all of the conditions are met, we perform all of the actions (which will involve calling the Perl functions for each of the listed modules to execute the action, just like calling them from the Javascript files).

if ($overallconditionresult) {
 foreach my $action (@$ruleactions) {
         my $ret = `/usr/bin/perl $action->{'module'} -d "$action->{'name'}=$action->{'value'}" `;
 }

Now, by coding up a (remarkably short) set of rules, we can automate all kinds of things across our devices.  We can send all manner of notifications if the door opens, or we can turn lights, tv's, plugs, etc on or off.  We have implemented a presence detection algorithm in just two rules, and from there we automatically turn the security system on when we leave, and off when we come home.  By adding a 'heartbeat' using cron, we can make things happen at specific times.

In a future update, I'll post the complete code for the rules engine (just 300 lines!).

Friday, 9 December 2016

Home Security DIY - Updated Control Panel

Here is the updated Control Panel:

You will note the separate on/off buttons have been replaced with single sliders with active colours (blue background when "on", grey when "off").  This is much more like the kinds of settings screens you typically see on mobile devices.  they are easy to code also: just one line per control in the HTML and mostly one-line calls in Javascript.

I also played around with some of the tiling layout generators, but couldn't find anything that really kept the flexibility across phone/tablet/computer, and was lightweight enough not to take a hit on the performance.

The other differences are all in the Javascript code: I converted all the server calls to jQuery ($.get and $.getJSON).  On the server side, all the CGI scripts are in perl or python, depending on the service they are calling - which can be in perl (file I/O), python (lifxlan-master and Honeywell thermostat using therm.py), bash shell (for mochad and curl to web services like IFTTT, openweathermap/Dark Sky).

The big advantage of DIY is seen here - in total there are about 500 lines of code and they run lightning-fast.  It is clean and simple, has a common look-and-feel across all platforms , and when someone opens the front door, I get notifications on 7 different platforms (X10 devices, linphone, SSH, Google mail, IFTTT Maker, lifx, and notify-my-android).



Sunday, 6 November 2016

X10 Home Security DIY - Control


So we want a system that we can control from all devices - computers, tablets, and smartphones (iOS and Android).  Generally, this would imply developing apps for each platform, but there is one application that works on all these devices - an internet browser.

This means that if we develop the functionality to work on a server, and develop a set of mobile-friendly pages, then we can develop the control mechanism once, but access it from all devices using the browser - this is definitely the way to go for a DIY project.

From previous development efforts, I've found that the Abyss web server from Aprelium is a very flexible and easy-to-install server.  With a bit of HTML, Javascript, and CSS development knowledge it is remarkable how easy it is to develop websites.

The other key piece is the same mochad daemon that we use to catch X10 RF commands.  This function came with a set of scripts that have the ability to send out X10 powerline commands, so we can use it to control X10 devices by calling the commands directly from HTML buttons.

Control Flowchart



any LAN client --> LAN
--> Abyss web server on localhost:8080 -->
--> index.html Control Panel --> X10 powerline commands -->
--> mochad daemon running on port 1099 --> netcat TCP
--> X10 CM15A controller --> household wiring -->
--> X10 devices

At the same time, we can use the lifxlan-master scripts to send commands to LIFX bulbs on the LAN, and even send commands to IFTTT Maker channel to control other devices (like the Thermostat fan).  We'll integrate an ARM/DISARM function into the control panel (and add a numeric keypad for an access code) in a later post.

Here is the control panel.


Here's the html file that implements the control panel

A few comments on the code:

The file uses a simple table with buttons to perform the control functions.  A little bit of fancy styling is used to make the table and the buttons rounded, and perform some simple effects (like changing the cursor when it is over the buttons, and some simple animations to give the feedback that a button is clicked).  Each of the buttons then calls a perl script (x10cmd.pl) with parameters indicating the command to be performed. The perl script then calls the system function for the button - e.g. lifxlan-master for the LIFX bulb, or the x10cmd shell script for the x10 commands, and so on. 

The styling also makes the control panel usable from mobile devices (I tried to use very common-denominator styling so that it will work even from very old Android and iPhone phones).  This has the added advantage of raising the WAF (Wife Approval Factor), as it will work from her fancy new mobile phone as well.

The perl scipt x10cmd.pl gives simple feedback that the command was executed in a basic html page.  I plan to migrate all of this code, and the Abyss web server, to a standalone Linux PC so that it does not load down my desktop (although from what I have seen so far, it is hardly noticeable).

Sunday, 30 October 2016

X10 Home Security DIY - Notification


So, I've got some old X10 Pro stuff in a box, and I see what commercial products like iSmartAlarm can do, so here's the goal:

A do-it-yourself Home Security System not unlike iSmartAlarm:

  • A central hub
  • Window and door sensors
  • A motion sensor
  • Notifications
  • Arm and disarm functions on phones and tablets
  • A central control panel

My Proposal:


  • Use my desktop linux PC as the central hub, with the ActiveHomePro CM15A controller to receive RF events and to send out X10 powerline commands
  • Use my old X10 window and door sensors
  • Use the mochad linux TCP gateway to connect to the CM15A.  Mochad is a daemon that runs on a linux platform waiting for RF commands to be received and for powerline commands to be transmitted using the CM15A.
  • Use a bash script (bashX10.sh) to listen for events on the mochad port and to send various notifications, e.g.
  • Using linphonec for linux, Android and iPhone hosts to receive messages
  • Using curl to send to the IFTTT Maker channel, which can trigger all kinds of other things, like an events log in Google Drive, SMS messages to cell phones, and so on
  • Using lifxlan-master to send commands directly to LIFX bulbs over the LAN (rather than going through IFTTT, which is slower and requires internet access)
  • Using nc (netconnect) to initiate commands back to the cm15a - like the chime, and light and appliance modules

Notifications

The flowchart for notifications is as follows:




We send out notifications to:
- Android & iOS phones and linux desktops on my LAN (using linphone and notify-my-android)
- the IFTTT Maker channel (to Google Drive and to anywhere on the cloud)
- LIFX bulbs over my LAN using lifxlan-master
- X10 devices using x10cmd to send pl commands back through the CM15A

For now, the IFTTT link is used to keep a log of the notification events in Google Drive (see IFTTT to show how to link the IFTTT Maker channel to Google Drive in a simple recipe), and to notify my cell phone via SMS if I am not home.

The "at home" status is determined by pinging my cell phone on the LAN using nmap and awk from the bashX10.sh script.

References

[1] Lifxlan-master
[2] mochad
[3] linphone
[4] IFTTT

Alternatives:  

I could have used Home Assistant but they don't support the X10 RF sensors; someone has just started supporting mochad, but it is early days yet.  I could also have purchased an iSmartAlarm system, but where's the fun in that?  The incremental cost for this system is $0 - the hardware was sitting around doing nothing, and my time is (almost) free - and as you can see, I am leveraging the expert development efforts of many other fine developers who make their code freely available on the net.

Notifications: 

There are so many options for notifying to other devices, and chat on linphone is not exactly fit for this purpose (it is really a VOIP application, and the interface is quite finicky when used without a SIP account).

I've tried using SSH as well , but it only works on devices that are on the LAN and have SSH (available on Android, linux, and iOS, but not on a Chromebook without enabling Developer mode).

Pushover is a commercial choice, and the cost is quite reasonable - it can support notifications on phones, tablets, linux and windows computers, and chromebooks - it might be worth a try.

Pushbullet is another choice - free, but seems somehow to have lost its way, and it is not supported on my old Android cell.

I am presently using notify-my-android to push notifications to our Android phones when we are not home.  it is free for low volumes, and it is quite reliable.