So that the data being collected by the Livebox can be graphed, shared or used to trigger other real world events we use pachube - which people in the know pronounce 'pach-bay', but sound much cooler as 'pa-chu-be'. Note that pachube are now rebranded as Cosm.

The xap-pachube daemon has been designed to feed any xAP event that appears on the bus to pachube. This means the Livebox hardware plus any other xAP compliant software/device that you may have running elsewhere on your network.

This daemon is configurable via the webserver interface

Once you have a PACHUBE account you will get a unique KEY. This must entered into the interface so that trust is formed between the Livebox and the service. You will then need to create a FEED ID. Here is my data collected on Pachube: http://www.pachube.com/feeds/1892

The Max and Min values are used by pachube to perform graph scaling along with the Unit field to annotate the datastream.

The pachube parameters

• source - dbzoo.livebox.Controller:1wire.1
• class - xAPBSC.event
• section - input.state
• key - text

This will match the inbound message and extract the value 21.0 Which is a degree Celsius reading of the 1st 1-Wire DS18b20 device on the bus.

xAP-header
{
v=12
hop=1
uid=FF00DB80
class=xAPBSC.event
source=dbzoo.livebox.Controller:1wire.1
}
input.state
{
state=on
text=21.0
displaytext=Inside 21.0
}

xap-pachube can also handle a ON/OFF value and this will be automatically convert to a 1/0 so the numeric value can be logged, this is handy for relays, rf, and other boolean input/output devices.

The pachube parameters

• source - dbzoo.livebox.Controller:relay.1
• class - xAPBSC.event
• section - output.state
• key - state

xAP-header
{
v=12
hop=1
uid=FF00DB60
class=xAPBSC.event
source=dbzoo.livebox.Controller:relay.1
}
output.state
{
state=on
}

The PACHUBE daemon feeds data to the pachube service on a regular basis.

Its internal cache of data to push to PACHUBE can be updated by xAP messages being targeted at this service.

Messages sent to it are not immediately forwarded to the PACHUBE service. They wait until the next update cycle.

A Pachube update message looks like this:

xap-header
{
v=12
hop=1
uid=FFAADA01
class=pachube.update
target=dbzoo.livebox.pachube
source=dbzoo.acme.test:1
}
datastream
{
id=3
tag=Outside Temperature
value=10.4
}

In the message above * The id= key matches that of the ID field in the datastream for the default Feed ID. * The tag=key updates the tag value of the datastream identified by the ID key/field * The value updates the value of the datastream identified by the ID key/field

The configuration page on the HAH Pachube tab is unaffected

Note that the UID and source in the message above must either both have subaddresses or neither have sub addresses

With all this data being aggregated we can now graph it

As this data resides on an external server we can ask it to produce a graph for us too. It can take up to 5 minutes before you have enough history data logged to allow the graphs on the HAH to display.

<img src="http://www.pachube.com/feeds/1892/datastreams/0/history.png?w=320&h=200&t=HAH%20Temperature&b=true&g=true&r=3"/>