Announcing project “Datazzle” – and connecting with CurrentCost

Standard

Today I have been working on the project I mentioned a few weeks back, to collect, store and graph data sent from my current cost unit. If you have been following this blog, you will know that I plan to make the service available to anyone, for free, so that they can do the same.

As I intend to release this service to the community in the coming months, I realised I couldn’t keep referring to the project as ‘the project’, so from here on in it has been lovingly code-named ‘Datazzle’ (say: dah-taz-all).

Ok, so what’s the deal? What is it? How will it work?

Datazzle will comprise initially of an XML web service (for receiving your sensor data)  and a companion web site, or web front-end, that will allow you to view all your sensor data from one place, graph it, and also let you define various options for sharing your data with others.

To get started, all one will have to do is sign-up for a free account, define at least one ‘environment’ (eg. “My House”) with one location inside it (eg. “Living Room”), and setup at least one sensor (eg. “Temperature sensor”). That’s it. It’s all point-and-click.

Then, you’ve got to get your hands dirty because it’s up to you to send compatible XML data to the API on a regular basis. To help you along the way, I will be releasing an open-source version of my test code (cleaned-up a little, of course!) that will initially connect to the current cost, take your API key, User Id and the environment configuration variables, and publish the data for you. This will basically convert the current cost XML data into XML that conforms to the “Datazzle Data Specification”, which is basically just a tweaked-version of the EEML standard.

You can use Datazzle to store data from ANY compliant device, not just the Current Cost…

Datazzle will be device-agnostic, meaning that you can use it to connect any physical or virtual sensor data (eg output from something like Second Life), and it will store it and allow you to navigate your data in a variety of different ways. From one Datazzle account, you will be able to setup multiple environments, and locations within those environments, to store data from as many sensors as you wish. You’ll get a ‘sensor dashboard’ to maintain all your sensors, from multiple locations.

Introducing the Datazzle Data Specification… feedback please 🙂

Although still only in the design phase, I have decided to base my XML format loosely around the EEML specification, already well established for sharing sensor data. The web service includes a web front-end that lets users setup and configure their devices and set a bunch of parameters (such as sensor types and locations) from the GUI, so the EEML that is sent to the server need only specify the corresponding ID values, instead of the actual string values every time. Take a look at the snippet to see what I mean:

<datazzle>
  <userId>123456</userId>
  <apiKey>00000000-0000-0000-0000-000000000000</apiKey>
   <eeml>
    <environment updated="2008-10-12T16:35:42" creator="" id="3456789">
      <location id="123" />
      <data sensorId="101"> <!-- Current temperature, in degrees celsius -->
       <value>28.7</value>
      </data>
      <data sensorId="102"> <!-- Current energy consumption, in watts -->
       <value>2692</value>
      </data>
    </environment>
  </eeml>
</datazzle>

You will note that there is less EEML here than in the specification and that some of the attributes have changed. I have also added “userId” and “apiKey” elements. A lof of the data included in the EEML specification has been ommitted from the EEML element you are required to send to the server, simply because you have already specified it once – when you were setting your sensor up online (i.e. the status of your feed, a description, a title, any links/copyright data etc, latitude and longitude, tags for each <data/> element and the units of measure).

Of course, when the service is available, there will be a nice UI to help you get up and running with the XML standard as quickly as possible (and a lot more documentation!). For now though, that’s all the info I have for you. If anyone has any thoughts or ideas, please feel free to comment – I’m open to adapting the specification to suit the needs of the community.

Here’s a quick preview of the tray app monitor that lets you see what data the current cost is sending to your computer, and the converted output being sent to Datazzle:

I will try to post more information and screenshots on the application and the service soon.

Thanks for reading!

Advertisements

3 thoughts on “Announcing project “Datazzle” – and connecting with CurrentCost

  1. Hi there,

    Thanks for your comment. In many respects I suppose Datazzle is going to be similar to Pachube, but my goal is to make it a bit more consumer-friendly with tighter social integration planned. As you might imagine, on the run up to Xmas things get a little busy, so I haven’t really had much time to devote to my pet project lately 😦 If you have a spare invite, I’d much appreciate that, thanks.

    I’d love to have been able to attend homecamp, but unfortunately I will be out of the country this weekend. I will add my name to the Wiki though to keep up to date.

    Thanks for taking the time to write.

  2. jt

    Hi Richard,
    Datazzle sounds a lot like Pachube (http://www.pachube.com/) which recently got an update to support html puts, ideal for CurrentCost date. I have mine hooked up on this feed -> http://www.pachube.com/feeds/333
    Let me know if you’d like to sign up- I’ve got a couple of invites left.

    Also, if you’re really quick, there’s one space left for homecamp next weekend (29th November), which seems to be mostly for current cost people to meet up. There’s even a free new meter on offer! http://homecamp.pbwiki.com/

Comments are closed.