Check out the latest version of Home.API from the Github repository, and then attach the plugin to an endpoint by adding a definition to a .conf file in your def directory. E.g.
# Current cost envir
/power/smartmeter
class \power\smartmeters\CurrentCostEnviR
This will install the plugin using the default parameters, but you can override these by specifying them in your definition. Available parameters are:
port, which defaults to '/dev/ttyUSB0'
baud, the baud rate to connect to, defaulting to 57600
timeout, defaulting to 10 seconds.
Your Current cost meter should be connected to the same machine as your Home.API install, and the web server user granted access to the comm port the device is connected to.
Exposed API
Once you have enabled the Current Cost plugin, you should see a new entry appear on your Home.API dashboard which gives a quick summary of the information retrieved from the device. It also makes available a number of functions which you can query at your endpoint (http://home.api/api/path/to/endpoint/), and these are:
time.json: Retrieve the time from the device.
temp.json: Retrieve the temperature from the device.
power.json: Retrieve the power in watts from the device.
latest.json: Retrieve all of the above at once, and return them as an array.
Visit the endpoint in your browser and see it working!
So, the other week I made a simple security device for my house, using a Raspberry Pi, that will (when I have a moment to wire it up), give a read out before I leave the house telling me if I have any windows or doors open.
Since I’ve been coding this Home API thing, the next obvious step is to wire the it up to the API so other things could make use of the data.
The first step was to modify the code running on the Raspberry Pi to transmit the status of each switch to a central server as a JSON POST request whenever something changed. On the server, I wrote a plugin which accepted this payload and stored for display, using the newly coded CouchDB support. This means that Home.API doesn’t have to poll the device, which would be more complicated and less efficient.
Sending data Home.API
Here is the client code, complete with Home.API integration:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The important lines of code are between lines 68 and 78. These lines check whether an update needs to be sent (we check for a state change in one of the lines we’re monitoring, and raise a flag if it is different from the last pass), and then package up an array of results as a JSON object and fire it over to Home.API using HTTP.
In our plugin
On the server, our class endpoint is loaded, and our decode method called. For efficiency we store this in a NoSQL database, which our display function getAll() just echos the contents off.
public function update() {
$result = json_decode(\home_api\core\Input::getPOST());
if ($result === NULL)
throw new \home_api\plugins\PluginException(i18n::w ('raspberrypidistw:exception:no_json_data'));
// Decode status
$this->status = array();
foreach ($result as $key => $value)
$this->status[$key] = $value;
// See if there is an existing status
$latest = $couch->retrieve($uuid);
Log::debug("Retrieved: " . print_r($latest, true));
if (!$latest)
$latest = new stdClass();
$latest->status = $this->status;
// Store revision
Log::debug("Updating UUID:$uuid with " . json_encode($latest));
return $couch->store($uuid, $latest);
}