Tag Archives: Home Automation

Hive Motion Sensor and OpenHab2

Recently I’ve started adding ZigBee based devices to my home automation solution – specifically I’ve added the Husbzb-1 stick to my setup. This has the benefit of combining both a Z-Wave and Zigbee controller in the same physical device, so I get to be agnostic as to the devices I add.

My next step was to try out a Hive Motion Sensor, for no other reason then there was one in the local store and a quick Google showed that it was Zigbee based.

This device is interesting in terms of form factor – suits what I was planning quite well, and the channels it provides;

  • Motion Intrusion (_intrusion) – Switch
  • Temperature (_temperature) – Number:Temperature
  • Tamper (_tamper) – Switch
  • Motion Presence (_motion) – Switch
  • Low Battery (_iaslowbattery) – Switch
  • Battery Voltage (_batteryvoltage) – Number
  • Illuminance (_illuminance) – Number

So I actually ended up with more then I expected since neither the illuminance nor the temperature are referenced in any documentation that I can find. I’ve no clue what the difference between Motion Intrusion and Motion Presence are though – both seem to trigger at the same time… will update when I learn more.

The other interesting thing is that on the very first trigger, the state is updated from NULL to ON for presence (_intrusion and _motion), but the sensor itself never seems to trigger a state change to OFF. In order to handle this, I’ve defined an item, subscribed to the _motion channel, and then a rule to reset it back to off after 5 mins.

var Timer vFrontDoor_holdDown  = null

rule "Reset Front Door trigger"
when
    Item FrontDoorMotion changed to ON
then
    if(vFrontDoor_holdDown === null || vFrontDoor_holdDown.hasTerminated){
        vFrontDoor_holdDown = createTimer(now.plusMinutes(5), [| 
            postUpdate(FrontDoorMotion, OFF)
            vFrontDoor_holdDown = null
        ])
    }
    else{
        vFrontDoor_holdDown.reschedule(now.plusMinutes(5)) 
    }
end

Hass.io and a custom relay

While I’m currently OpenHab based, I was looking into Hass.io as an option, but that does leave the challenge of getting my WiFi controlled relays to work correctly.

This turns out to be fairly simple in the end, by using the platform command-line option + CURL

switch:
   - platform: command_line
     switches:
        relay1:
          command_on: '/usr/bin/curl -X GET http://<ip address>/relay/on'
          command_off: '/usr/bin/curl -X GET http://<ip address>/relay/off'
          command_state: '/usr/bin/curl -X GET http://<ip address>/relay/state'
          value_template: '{{ value == "ON" }}'
          friendly_name: My Relay

Wifi Controlled Relay and OpenHab

Items used:

  • LOLIN D1 mini V3.1.0 (ESP8266)
  • LOLIN Relay Shield V2.0.0
// Load Wi-Fi library
#include <ESP8266WiFi.h>

// Replace with your network credentials
const char* ssid     = "mySSID";
const char* password = "VerySecret";

// Set web server port number to 80
WiFiServer server(80);

// Variable to store the HTTP request
String header;

// Auxiliary variables to store the current output state
String relayState = "OFF";
// we will have the relay on 5
const int relay = 5;


void setup() {
  Serial.begin(115200);
  // Initialize the output variables as outputs
  pinMode(relay, OUTPUT);
  // set the relay off by default
  digitalWrite(relay, LOW);
  pinMode(LED_BUILTIN, OUTPUT);     // Initialize the LED_BUILTIN pin as an output
  // we match the LED state to the relay state
  digitalWrite(LED_BUILTIN, HIGH);  // High is off, low is on

  // Connect to Wi-Fi network with SSID and password
  Serial.print("Connecting to ");
  Serial.println(ssid);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  // Print local IP address and start web server
  Serial.println("");
  Serial.println("WiFi connected.");
  Serial.println("IP address: ");
  Serial.println(WiFi.localIP());
  server.begin();
}
void loop(){
  WiFiClient client = server.available();   // Listen for incoming clients

  if (client) {                             // If a new client connects,
    Serial.println("New Client.");          // print a message out in the serial port
    String currentLine = "";                // make a String to hold incoming data from the client
    while (client.connected()) {            // loop while the client's connected
      if (client.available()) {             // if there's bytes to read from the client,
        char c = client.read();             // read a byte, then
        Serial.write(c);                    // print it out the serial monitor
        header += c;
        if (c == '\n') {                    // if the byte is a newline character
          // if the current line is blank, you got two newline characters in a row.
          // that's the end of the client HTTP request, so send a response:
          if (currentLine.length() == 0) {
            // HTTP headers always start with a response code (e.g. HTTP/1.1 200 OK)
            // and a content-type so the client knows what's coming, then a blank line:
            client.println("HTTP/1.1 200 OK");
            client.println("Content-type:text/plain");
            client.println("Connection: close");


            // turns the GPIOs on and off
            if (header.indexOf("GET /relay/on") >= 0) {
              Serial.println("Relay on");
              relayState = "ON";
              digitalWrite(LED_BUILTIN, LOW);  // High is off, low is on
              digitalWrite(relay, HIGH);
            } else if (header.indexOf("GET /relay/off") >= 0) {
              Serial.println("Relay off");
              relayState = "OFF";
              digitalWrite(relay, LOW);
              digitalWrite(LED_BUILTIN, HIGH);  // High is off, low is on
            }
            else if (header.indexOf("GET /relay/status") >= 0) {
              Serial.print("Sending status: ");
              Serial.println(relayState);
              
              client.println();
              client.print(relayState);
              client.println();
              
            }
            client.println();
            break;
          } else { // if you got a newline, then clear currentLine
            currentLine = "";
          }
        } else if (c != '\r') {  // if you got anything else but a carriage return character,
          currentLine += c;      // add it to the end of the currentLine
        }
      }
    }
    // Clear the header variable
    header = "";
    // Close the connection
    delay(1);
    client.stop();
    Serial.println("Client disconnected.");
    Serial.println("");
  }
}        
  

Now for the OpenHab side

Here, I’m making use of the HTTP binding (and the REGEX mapping), and we basically have 3 calls we need to handle

  • On
  • Off
  • Status

And so our items definition is simple to handle those 3 cases:

Switch MyRelay "MyRelay" <switch> ( gSwitches, gRelay ) { http=">[ON:GET:http://<IP Address>/relay/on] >[OFF:GET:http://<IP Address>/relay/off] <[http://<IP Address>/relay/status:10000:REGEX((.*))]"}

And that is basically it – I can now control the on/off of my relays, and check on the current status.

Conclusion / Finishing Thoughts

Some obvious points to consider are:

  • Lack of security – anything that can reach the IPs of the relays can manipulate their state
  • Lack of rate limiting – a follow up from the 1st point is that we don’t do any cooldowns or rate limiting to prevent accident or maliciousness from repeatedly toggling the relays, potentially damaging the relay and worse, the appliance
  • Updating the relays – requires them to be disconnected and connected via USB to a PC/programmer

Preparing for some Home Automation – Heating

Today I decided to start planning for the install of some home automation kit, specifically related to heating, but while planning on that I decided to take a closer look at a problem I’ve been having for some time – the thermostat hasn’t been doing very much.

This is a standard dial thermostat – and as you would expect, the numbers on the dial are a little off (~6°C) compared to the actual temperature. This isn’t the actual issue, since once you find the comfortable point, it doesn’t really matter what the reading on the dial is.

The issue I was having was that, regardless of the thermostat position, the radiators were always on (except in the rooms with thermostatic valves) – I had managed before the summer by running with the timer on the boiler, and reducing the boiler temperature.

This has the side effect of (1) the boiler operating less efficiently, and (2) I can’t use it for heating the hot water as the temperature isn’t high enough.

After some digging, I got to this simple diagram of the basic setup:

As you can see, the thermostat doesn’t directly influence the boiler at all – instead it controls the actuator, which in turn allows hot water to flow, or not, through the radiator loop.

Taking a multimeter to the two wires in the Thermostat, I could see that it was in fact switching – 240V between the two when turned off vs 0V between the two terminals when it was on.

So with the thermostat basically functional, I then moved on to the Actuator (SZ2301) – this is a basic 2 port actuator. When there is current applied it opens, and when the current is stopped a spring pushes it back closed – generally speaking these things either work or they don’t.

But… on closer inspection, I found that someone had set the manual lever to flushing – basically forcing the valve open at all times. I moved it back to the “normal” position, and bingo – the thermostat could now control the flow of hot water through the radiators.


Next Steps

Now that that little niggle is sorted, I’m looking for a HA type solution to allow me to manage it all a bit better.

I’m also starting to use OpenHab for some of my other devices, so integration into that setup is essential.

TBC…

Update on the Belkin WeMo Switch

As I noted previously I was less then pleased with the WeMo. Basically I had to put in a few hacks to allow me to manage it via RPi and the excellent ouimeaux tool rather then the provided app and/or IFTTT.

It seemed that anything ‘cloudy’ wasn’t working at all. Possibly because my home router was in turn sitting behind a CG-NAT solution, possibly not…

Thankfully the latest set of firmware updates (now running WeMo_WW_2.00.8643.PVT-OWRT-SNS) seems to have sorted all of those issues. Android app works as expected (can turn it on and off) from both the local network and remotely, as can IFTTT, so I’m definitely happier with the product now then when I bought it.

Internet of Things – Potential Architectures & Drawbacks

The Internet-of-Things or IoT (terrible name since everyone knows that IoT stands for Inter-operability Testing) seems to be quite the buzzword around lately – replacing the previous version which of course was Machine-to-Machine [M2M]. Nest and other home telemetry/automation tools seem to be quite the cliche-du-jour for the digirati.

Consider what Nest actually does – local (in house) temperature compared with external (nearest location/airport) temperature and a few interesting algorithms to handle temperature differentials, learn preferences, awareness of presence and away type scenarios. Of course  given that it seems to automatically download updates, I’m sure it’s logging and submitting lots of information ‘to improve the product’

Likewise, we have hubs finally coming onstream to try and manage all the possible combinations of hardware and software for home sensors and everything else (or so they promise).

Think home sensors/lightbulbs/whatever – currently we have a plethora of specs to choose from for household comms and telemetry: X10, Zigbee, Z-Wave, Lightwave RF. Telldus, etc. Currently each manufacturer has their own choice of spec, controller software, etc.

Fortunately the Open Source/Open Hardware groups are are already experimenting with options to handle this – a good example is the Home Automation Hub (HAH) project which sets out to turn an Orange Livebox router into a home automation server, with an extra bit of hardware that – like the TellStick – allows it to control a range of gadgetry, and even keep an eye on energy consumption too. Likewise the dovado routers I’ve raved about before have the beginnings of some interesting Home Automation features with integration with Telldus sticks and the use of GPS to determine sunrise and sunset times for the location.

Open Source Open Hardware Hub

Home Hub - Internet of ThingsKey features as I see them are:

  • Compact
  • Reliable
  • Minimum Downtime
  • Low power
  • Open

Publish & Subscribe

So, assuming that we can get all these sensors talking to our hub, and that data recording (and potentially taking local actions based on that – heating, lighting, etc.) what do we do with it.

The hobbiest answer is to put it up on a website for your own entertainment. The more interesting options are open to the hub provider, and I see a few possible approaches here:

  1. Act as a relationship broker: making partnerships with different consumers of the telemetry e.g. allow the hub to submit information of the users choice to projects of their interest e.g. SmartCities, utility providers, etc.
  2. Act as a centralised clearing house: store all users data, sell it in bulk (users are the product) and plan to be bought at some point by Google/IBM/whoever
  3. Act as a centralised broker – grouping your users according to, for example, energy usage patterns and negotiating (optional) bulk deals from utility providers. For example, contacting the Power company and saying here is aggregate usage data for 30k ‘night owls’ – can we get a special deal, since they are offsetting the base load cost, but not adding to peak loads.

 

Providers/Website subscribing to the date