Actual home automation: building the helpful dumb house

Robots aren't anywhere close to being able to automate the annoying aspects of our lives.

I've gotten another Raspberry Pi, and the first one is working well with Oscar - other projects like TheThingSystem and Ninjablocks have falled by the wayside a little.

The only things I've got that I can feasibly automate include an automated cat feeder; or maybe an outdoor vertical garden.
Neither is really solving a proper life problem - not the same way that watering timers do.

After thinking about it for a while, the issue isn't making the full leap to automation. A modern flushing toilet is an incredible piece of automation - gone is the requirement to deal with waste daily, and when linked to a modern sewage system; the benefits to health, labour and much more are a very good trade-off.
All of this is reduced to a simple mechanical button and a charge from your council.

Building collaborative agents that can reason about the best rules to apply in the best situations is a very hard problem. Simple triggers like "motion detected in room X" firing "switch on light" need contexts and bounds: there's no point switching on a light if it is daylight; or put better; the ambient light provides a suitable visibility.
Dealing with multiple actors at once and building models of their "comfort" is way, way beyond what we can do - the sensors we have and means to deal with their input are far far to limited.

Maybe this isn't such a bad thing. Many people have recently ridiculed light switch apps on phones - a simple mechanical trigger coupled with a human solves the room lighting problem in a residential house really well.

So by that token, what can we do with more limited sensors, automated schedules and basic rules that can be reduced to a user hitting a button; or not?
I think the answer goes back to Oscar and TODO list systems like Trello - higher level decision making is almost always going to require a person; and the decision making should be for difficult or relevant tasks.
Trello and others solve the communication amongst a group of humans problem really well - it ends up being a really rough service bus.

What can we do to take advantage of that?

Observation 1: The federal government is really stuffing up the South Australian economy, with doubt around renewable energy projects, car manufacturing support ending, defence projects being on-again, off-again.

Observation 2: A lot of skilled labour is looking for new opportunities, through things like Airtasker or Gumtree. Many of these folks aren't 100% tech saavy, but are tech saavy enough. They aren't going to earn a living, but they are going to be able to take small opportunities. Provided that doesn't inflict an opportunity cost on them (being unable to find full time work because they are too busy chasing small scale work).

Observation 3: Service provider hubs are cropping up like wildflowers. The next evolutionary steps for a lot of them are going to be APIs - be it internal APIs for mobile apps or public APIs. Uber has forced all of the taxi companies in South Australia to compete with apps - they aren't pretty, but they are an evolutionary step.
In the Philippines, the taxi based culture is very prevalent - aggregators have sprung up with a few major 'platforms' allocating work across companies.

Google Now is the best implementation so far of 'Helpful Agent' that I've seen, recognizing when there is travel happening and prompting with directions, food, etc.

We can surely take the google now approach to sensing when something is happening; and prompting a user for decisions. The candidates should be recurring.

To that end I think my next project is going to be "Raspberry Pi that polls users for feedback constantly".
The idea for anyone who has flown through Singapore's Changi airport is pretty familiar - How would you rate the cleanliness of this room? Poor, OK, Great? on a touch screen.
Combine that with an agent that offers to post a job to Airtasker for a one-off clean, and you are really onto something.
Apps like http://www.moodpanda.com/ exist, as do a lot of fitness apps (Google health, Up, etc); even for your dog (Whistle; which I have found to be very effective) - people have done a lot of data collection in the past.
Automating that and focusing on the problem areas in your home is going to create a much smarter sensor. You don't need to build an entire AI to understand a model of the real world if you optimize the questions correctly.

This will not get us smart houses, but potentially helpful dumb houses. I think that's a pretty worthy goal.

A quick map of my current home automation

Here's a quick diagram I'm working on to depict my house's current state.

The dotted lines are projects that are in progress or not quite working as expected - for example, my Rootooth didn't do what I needed, my EnviR power meter is now installed (but not the second one for solar) but needs a bigger 433mhz aerial on the ninjablocks; and Huginn isn't yet deployed to an instance.

I can't quite tell who will win out of Zapier, IFTTT and Huginn yet - my money is on open source, though there's a long way to go.

Surprisingly, bluetooth is rarely in the mix - the roomba, and perhaps bluetooth for presence sensing would be about it.
UPnP is there for the airconditioner and XBMC, which boils down to HTTP. Ninjablocks is very HTTP oriented at the moment; but soon MQTT will take over a big chunk of its messaging.

ZWave, I have a stick but no devices - the cost was too high.

Introduction to Huginn & Owntracks (or how to make your own Google latitude and IFTTT)

Huginn is an open source IFTTT or Zapier clone written in RubyOnRails. Right now it's in the early phases, but it is easy to imagine this beginning to approach feature parity with those closed platforms.

What I really like about it is how easy it is to get up and running - a development copy is just a git clone and bundle away from functional.

To deploy it on a server, they've even provided Chef recipes.

Right now the architecture leaves a little bit to be desired - everything is based off of ActiveRecord and caters for many, many concerns - from publication, receiving events, generated UI from class metadata, configuration, and the actual setup of the various code to act on your behalf, all in the same model. If you put that aside; the surrounding framework is fantastic - it provides all of the robustness of a decent queuing or job management system, while being generic enough to execute any agents you choose.


The thing that is missing from my Ninjablocks or TheThingSystem is deep integration with a variety of webservices. Zapier or IFTTT doesn't integrate for example, but can do many useful things - how neat would it be to turn on lighting when I leave a foursquare place I've checked into?


The thing that is missing from either of the web platforms is really knowing much about my house and home automation setup. I don't really want a generic house or to control specific Wemo powerpoints from a web system, I want something to knows and discovers things within my local network - things behind the firewall.

TheThingSystem excels at this, and Ninjablocks speaking to a variety of 433mhz actuators (provided you have a big enough aerial) to switch on lamps = a cheap, decent way to get things done around your house.

To fix that, I've added in MQTT publish/subscribe support to Huginn.

Now any Huginn agent can publish their results to a broker, and vice versa.

How can you do the same?

Get a MQTT Broker

You have two main options here, hosted or self hosted. I recommend CloudMQTT's free plan - 10 connections will go a long way, and it's literally a few clicks to spawn a new instance.

Once you are hooked, you can look at the plans available or cook you own.


You'll need to take note of the URL, credentials and more.

Install Huginn

Pretty easy to do. Experienced ruby folks may want to use rbenv or rvm as suitable. Assumes ubuntu or debian:

Assuming https://github.com/cantino/huginn/pull/368 is merged:

git clone git://github.com/cantino/huginn.git
apt-get install ruby1.9.3 ruby1.9.1-dev rubygems mysql-server
cd huginn
gem install rake bundle
bundle
bundle exec rake db:create
bundle exec rake db:migrate
bundle exec rake db:seed
bundle exec foreman start

There's plenty more guidance here, but if the above has worked you can now visit http://127.0.0.1:3000/

Install Owntracks

Straight forward enough, simply visit http://owntracks.org/ and follow the links to the apt-store.

Configuration - Owntracks

Fire up the app, and under preferences, enable Advanced connection details. You probably want to tick 'start on boot' as well.

Next, configure the broker settings:

Don't forget to pick a snazzy name for your device, as it'll be your proxy on the map.

Hit connect, and everything should be all good.

Next, you'll want to define a waypoint (geofence). Particularly useful as you can choose when the event should fire - entering, leaving, or both.

That's it!

Configuration - Huginn

You'll want to do this last, as it'll make a whole lot of things start to happen.

1. Add a new Agent
2. Select MQTTAgent
3. Populate the MQTT url from the details before.
   It's like a http url
   
   mqtt://user:pass@server:port/
   
4. Choose what you are going to subscribe to. For now, I recommend adding a topic of:
   /#
   which boils down to "Give me everything!"

The big test

Now that you've done all of the configuration, in Owntracks, use the icon to force share your location if it hasn't run already.

In a few moments (or you can force it to run), your MQTT Agent in Huginn will execute and give you a nice nested JSON event to play with:

There's plenty more you can do, now set up trigger agents to invoke other tasks; or deploy this as a service via chef.

What's MQTT and how can you use it?

MQTT is a machine to machine protocol that runs over the top of HTTP. Think SOAP or REST, but designed to be a lot smaller.

Unfortunately, the documentation on the main site is very much about the protocol, not what you can do with it.

The key difference between SOAP or REST and MQTT is the idea of a broker is built in from the start. Instead of point to point connections, everyone just publishes and reads from centralised locations.

While you can do that with SOAP or REST, it's not common - and there are very few public instances of RabbitMQ or similar just sitting around to play with.

Not so with MQTT.


Here's some examples:

• Publish Jenkins broken build results to a broker and turn up the local airconditioning a few degrees to help people really feel the heat
• Use Owntracks to identify waypoints (Home, Work, X, Y, Z) and publish when you get near a geofence.
• Hey Huginn, see that Owntracks notification? Check me in on foursquare [well, I have to write this bit] when I'm at the pub waypoint.
• Hey TheThingSystem: turn off the local aircon when I leave the home geofence according to Owntracks.
• Hey NinjaBlocks turn off the powerpoints you control [again, has to be written, but it's not far off] when the amount of Owntracks presence sensors at waypoint home drops to 0.

Pretty neat stuff. You can tell why IBM think it's the bee's knees - they want to integrate a whole bunch of industrial or medical stuff into this and sell Websphere MQ.

This all seems pretty exciting, as does IFTTT or Zapier, but you quickly realise there's either limits (because it's not designed for programmers) or you need some serious neckbeard to get things working.

Over the next few posts, I'll be documented specific HOWTOs and some of the pull requests or contributions I'm making to remove some of that pain.

Project idea: Barcode scanner to shopping list

I've had this idea for a while in various forms, and I'm not alone. Until recently not all of the pieces of the puzzle were going to work together though.


The first attempt, google tasks API to product search/lookup. I got it working, but it was too hard and the results too limited - amazon, and google product searches were all that were supported.

Most recently I wanted to set up my raspberry pi, opencv, and have a shot at webcam based image recognition, but got bogged down in opencv installation.

Oscar solves the problem more simply. The python code is on github. I've just ordered a barcode scanner from ebay, with stand, $25 AUD.

More importantly, for Australia, the major supermarkets have finally gotten into online ordering - I already use this.

Here's examples of searching for products by barcodes.

Coles: Barcode 9300650008861
Woolworths: Barcode 9300650008861

It's not quite to the point I can call an API on their site(s) and add it to a cart, but it's likely I can update the trello list items to link to the woolworths/coles pages - one click to buy per product.

That's pretty close to automatic.

Looking a bit deeper, woolworths appears to support basic POST for authenticated users:

As does Coles, once you strip away the ajax behaviour

I think it would be reasonable, if you could ensure you were authenticated, to end up with a 'one click add to cart' behaviour.

Various home automation todos

LED strip lights are surprisingly cheap and at the level of DIY - ebay suggests around $12-13 for 5m.

I have a few projects in mind.

The first is LED skirting boards, coupled with a motion sensor and dimmer. This video manages to make a simple, good idea look terrible through the use of lighting best left for strip clubs.

Here's the motion sensor:

If I could combine the two, plus a tiny bit of logic to only enable them at certain times, walking through my house at midnight means no more fumbling for a light switch.

I'm fairly confident it'll be useful, as I already did a similar experiment with cheap stick on LEDs - the battery maintenance was the downfall of that idea.


The second one is a natural extension of the first - I spent around $30 on a terrible sunrise alarm clock, which didn't work and was impossible to program.

If I've got LED skirting boards, why not LED strips for the edges of a bed? Ideally, the situation ends up somewhat like this.

To get the sunrise clock effect, I'd consider a ZWave RGB LED controller. Throw in the thing system, and for the mornings you'd get a warming wakeup.


There's a few other neat suggestions, like LEDs being used for feedback in the house (too close to the garage wall? Red! Stop!)



Other ideas I've had:
ZWave controlled blinds seem useful. I'd seen them before, but it wasn't summer then.
It'd be neat if these roof vents were controllable - you don't want it running in winter.

The Thing System and Planning Alerts

• The Thing System is close to supporting my air conditioner
• Planning Alerts has fixed scrapers for a few more councils
• There is no third thing yet, and I'm all out of weekend :S

Samsung air conditioners - direct interaction

A few days ago, a Brisbane based chap named Shannon dusted off my blog posts from last year, and pointed out that directly interacting the a samsung A/C only required a bit of SSL.

We seem to have slightly different models, but the underlying principles are all roughly the same. Given my web based authentication method stopped working, and given the Australian Copyright Council says this, with regard to reverse engineering:

Making interoperable products
Software may be reproduced or adapted in order to get information necessary to enable an
interoperable product to be made. The relevant provision also allows the person making the interoperable product to reproduce or adapt the original software in the interoperable product, but only to the extent necessary to enable interoperability either with that or any other software.

I'm happy to publish the direct method now via bitbucket.


Speaking with Shannon a bit, he's likely to write a full perl or other language version as well; and had some strong ideas around home automation - I've suggested integrating into the thing system.

Internet of Things: two visions

I do like the idea of ubiquitous computing - it's what you get when you follow Moore's law and adopt IPv6's address space: a whole lot of cheap components that are aware of each other.

We've certainly achieved the cheap: due to the increasing demands of the smartphone market, a GPS chip, decent processor, memory and more are certainly ubiquitous.
It's easy enough you can buy a Raspberry Pi with a few clicks, and have the power of a decent server available to you.
Right now, I've got my Pi running burning-down - I do need to extract a few key stats from the data, given we are in a bushfire season too.

What we lack is robust means for all of these cheap different components to talk to each other. The fact I had to frown at my air-conditioner so much to get it to speak to me is alarming, what's more alarming is the Korean Electrical Engineer understanding of the web is terrible - the reason my 'smart' Air-conditioner takes so long to connect to my phone stems entirely from the fact the designers simply spam the local spectrum with "hello, are you there" requests.
Having read the basics of the specs, I doubt I would have taken the same approach. That said, the future won't be built by folks like myself, it's more likely to emerge from a Chinese manufacturing plant. Western businesses believe they are cutting costs, but the real effect (and in my opinion, a good one to some degree) is training the next generation of localized startups, developers and more.
This is widely acknowledged: it's common for Indian app developers to observe an idea working in one market, produce a clone and localize it; to obtain the first mover advantage.

My issue with this scenario is not derivatives or some kind of 'theft' of ideas; but the production of silos.

I can't explain to you how much it frustrates me that I can't simply buy a Nest Smoke Alarm here in Australia; because of shipping costs; plugs and voltage.
I can't explain to you how much it frustrates me that I can make my phone, laptop and air conditioner talk; but only behind certain limited network conditions and with enough manual coddling to make the effort invalid.

There's two efforts, tackling different parts of the problem that I'm aware of. The first is http://thethingsystem.com/

Clearly, someone here knows enough buzz words to appeal to developers; but ultimately I have my doubts about the utility of it.
For example; I accepted the initial overall concept enough to be half way through purchasing a second Pi to run it (clearly marketing works for them) before I dug into the 'supported hardware' section.
95% of the devices listed aren't in my market, available for me, or of use to me.

On the other end of the spectrum, I'm reading about the architectural problems that 'The Thing System' and others will likely face:
http://iot-datamodels.blogspot.com.au/2013/10/a-modular-open-source-platform-for-web.html

This acts as a hell of a reality check to me; as the language here and assumptions made are so far removed from the current computing ecosystem that they border on unobtainable.

Where does the middle ground lie? With devices that talk through limited protocols and proxies; or a approaching a lingua franca of computing spanning multiple devices, domains and more?