Posted on
by

Home.API The modern world is full of cool gizmos, but our houses are pretty primitive by comparison.

Still, more and more houses are getting water and electricity smart meters of one sort or another. Various new home automation, like the Belkin Wemo, are hitting the market, and that is not to mention all the home brew efforts that various hackers are putting together themselves.

As you can see from other posts on this blog, I’ve been having a bit of fun playing around my Current Cost smart electricity meter, as well as playing around with the Raspberry Pi and PiFace, which has got me thinking about building a number of appliances around the place to solve a number of real world problems around the house – monitoring and controlling a number of things (I’ll post some more on this later).

So, problem is, all these devices have their own ways of talking to them, reading data and controlling them, and I thought it’d be cool if we had a common and easily extensible API, which you could talk to using standard web technologies. Having such a platform would enable people to start wiring things together in unexpected ways, using a variety of different devices, the more apis get added the more possibilities you have!

Introducing Home.API

Hacked together as an itch-scratching weekend project, Home.API is my first stab at solving the problem. It is a PHP 5.3+ web app that runs on a web server and is designed to be easily extensible through simple plugins and human readable configuration files.

Out of the box it includes a couple of demo plugins, and a simple dashboard, although the real power comes from its extensible JSON API which can be accessed by simple web calls.

Key features

  • Simple plugin format and configuration files.
  • Wire up the API in a branch structure which suits, use each plugin multiple times.
  • Simple but powerful development dashboard.
  • Currently a JSON API, but trivial to extend to other output formats using a powerful template system.

Format of an endpoint definition file

You API is defined using one or more configuration files in the /def directory. The configuration file contains a number of entries, separated by blank lines, each one defines the endpoint, class to use, and any initialisation parameters.

E.g.

/bedroom/light
    class \x10\DimmerLight
    minvalue 0
    maxvalue 50
    deviceIP 192.168.0.45

/hallway/light
    class \x10\DimmerLight
    minvalue 0
    maxvalue 100
    deviceIP 192.168.0.46

Making a call

Making an API call is simply a matter of making a call to a URL http://my.home.api/api/your/endpoint/function.format?param1=xxxx¶m2=yyyy, where function.format is the exposed method of the plugin class, and format is the template to use (e.g. json).

Each of these endpoints can act independently, and in our example you might be able to execute commands like:

http://home.local/api/bedroom/light/currentLevel.json

or

http://home.local/api/bedroom/light/setting.json?level=20

or

http://home.local/api/hallway/light/off.json

Have a play, and let me know what you think!

» Visit the project on Github…

Posted on
by

experiment 2 - traffic lights In the last experiment I wired up LEDs to each one of the PiFace’s outputs and cycled through them. In this one, I decided to try a slightly more “real world” application, and build a set of traffic lights.

Since I live in the UK, these are the UK three light traffic lights (red/amber/green) and follow the UK light sequence – RED, RED/AMBER, GREEN, GREEN, AMBER, RED.

The Circuit

The circuit here is very similar to the one used for the previous experiment, but will only use six of the available eight control outputs. Each light contains a set of three LEDs connected to one of the pins of the PiFace’s output interface, one red, one amber and one green.

See the attached diagram.

The Software

The code for this experiment is where the extra complexity resides, since we must drive each light in the correct sequence and obeying certain rules:

  • The lights must transition in the correct, UK, sequence, i.e. RED, RED/AMBER, GREEN, and then GREEN, AMBER, RED.
  • For traffic safety, the green light must transition to red before the red light transitions to green.

To avoid repeating myself, I created a simple class to drive the lights.

Each class is initialised with the pin number of each light, and an initial status. The Toggle method will transition the light; RED, RED/AMBER, GREEN if status is RED, and GREEN, AMBER, RED if status is GREEN.

The main loop of the program waits for a period of time, then toggles the lights, starting with the green one.

Here we have it in action…


Posted on
by

It was recently revealed that the NSA and FBI have been using the US Patriot act to conduct blanket, unwarranted, surveillance of US citizens (and anyone who happens to talk to a US citizen), and of course comes as no surprise. The fact that major companies, Google, Verizon, Apple, to name but a few, were complicit in this, is very disappointing.

In the UK, the security services already track your phone calls, RIPA makes it a criminal offence to refuse to decrypt data (or what they believe is encrypted data) on the government’s request, and with plans to re-introduce universal internet surveillance (shamelessly capitalising on the tragic murder in south London of a young man, re-branded as “Terrorism”), we are taking the lead in creating the “Cradle to Grave” Surveillance State.

History shows that the greatest threat to an individual’s liberty comes from the state itself, rather than some foreign actor. My good friend Ben Werdmuller recently coined a new “Second Amendment”, which I thoroughly agree with:

Privacy being necessary to the sanctity of a free state, the right of the people to own and encrypt data shall not be infringed.

Of course, it is easier said than done. You can’t trust cloud based services to protect you; Apple, Google, Twitter, Facebook, your phone company and ISP are all complicit.

Wider use of encryption would be a start, but that’s hard to do in isolation. Email encryption is a microcosm of the problem; I’ve had a public key available for over a decade, but the grand total of encrypted emails I’ve received can be counted on the fingers of one hand. This is not because encryption or key management is necessarily complicated, it’s just that there is no motivation for me to use it if nobody else is as well.

It is useless in isolation.

Newer technologies fare better, without the need to carry too much legacy baggage, they can afford to switch on encryption from the get-go. Many, especially IM clients, have another advantage in that they are synchronous, and so could do content negotiation ahead of time. So, perhaps a mail client/webmail client with Webfinger support, and wider adoption of that?

Might help.

However, I think the biggest issue is that society at large tolerates the state doing this sort of thing. Perhaps “We the people” should start presenting a more unified opposition.