CurrentCost – getting the history into Windows

The CurrentCost meter has been ignored of late as I’ve been a bit busy with other things. Tonight, I started playing with it again.

The plan
The more geeky amongst us have connected the CurrentCost to a server of some sort. By connecting it to something that’s always on, we can collect a history one reading at a time. But what about people without a server? How can they collect history?

As Rich highlighted in his post on the CurrentCost XML output, the CurrentCost meter maintains some running totals in flash memory, and these are included with updates for every reading from the device.

It maintains:

  • totals for each two-hour block for the last day
  • totals for each day for the last 31 days
  • totals for each month for the last 12 months
  • totals for each year for the last 4 years

This means that if you store and aggregate these history totals, you can connect the meter to a computer periodically and still get reasonable CurrentCost readings history.

  • connect at least once every 26 hours to maintain the two-hourly history
  • connect at least once every 31 days to maintain the daily history
  • connect at least once a year to maintain the monthly history
  • connect at least once every four years to maintain the yearly history

Okay, so the two-hourly history might be a bit much, but the others all seem reasonable, even for non-geeks!

So, the plan is to write a simple Windows application that a user could periodically link to a laptop or computer that will collect CurrentCost readings and aggregate them into history data. And ideally then display them in a pretty way

(Not my plan, incidentally, but rather one that I nicked from Andy. Still, if you’re gonna nick ideas, there are worse places to start… 🙂 )

This is what I’ve got so far…

the start of a CurrentCost GUI

Step 1 – Connecting CurrentCost to Windows
Like my Slug home server, my ThinkPad doesn’t have a COM port, so I’m using a USB to Serial adaptor cable. When I got it, it came with a CD with Windows drivers. Unfortunately, knowing that I’d be connecting it to a Linux server, I binned this. Whoops.

I found some Windows drivers on the Maplin website, which did sort of work. But they kept crashing. Windows Device Manager showed that the drivers were six or seven years old, so after a few blue-screens-of-death, I searched for a more up-to-date version. I found one on the Prolific website, and since updating to that, I’ve had no more BSODs. Yay. 🙂

Step 2 – Getting the data
Unlike the Linux app I’ve been running so far, this app wont be a long-running background task – all I need is to get a single update from the CurrentCost meter, because that will have the history data that we need.

As Rich outlined, the data from the CurrentCost meter comes down the serial port in XML form.

So I read a single line from the serial port and try and parse the XML. If I fail (if the update is incomplete, the XML cannot be recognised, or if there are any other problems), I discard it and read another line.

Step 3 – Recognising the data
Nothing too elegant here – for a first quick hack, I use an XmlReader to read through the line and get the values from it.

If anyone wants a copy, the class that does this is here.

The only slight tweak over just trying to turn XML into a series of text and number fields, is that I’ve added the ability to discard the timestamp in the XML and replace it with time taken from the computer where the code is running.

I’ve done this because the clock on my CurrentCost meter keeps losing time, so the computer timestamp is more likely to be accurate. But, as it’s the CurrentCost meter time that is used to maintain the running totals on the meter, this isn’t really going to help a great deal for this app. Ah well, I’ve added it anyway 🙂

Step 4 – Translating the data
As I said at the start, the CurrentCost data is relative – it gives the total readings for “three days ago” or “two months ago”. To store this as a historical reading, I then needed to translate this into an absolute timestamp.

For years, months, and days, this is easy. For example, a reading for four days ago (“d5”), is going to the total reading for 11th June.

The history for hours was a bit more confusing. You get thirteen (why thirteen?) readings for two hour blocks: h2, h4, h6, h8, h10, h12, h14, h16, h18, h20, h22, h24, h26.

I’m not sure what this means – what does “h2” mean? A total for midnight – 2am? A total for the last two hours (e.g. 7.40pm-9.40pm)? A total for the last two complete hours (e.g. 7pm-9pm)? A total since the last ‘even’ hour (e.g. 8pm – 9.40pm)? Dunno… I’ve written a script to capture the hours data for a day – I’ll take a look at what it collects by tomorrow and try and reverse-engineer it!

For now, my code doesn’t try to calculate hourly totals.

Update: I’ve since worked out the hourly totals, see comments below.

Step 5 – Persisting the data
I’m storing the readings in a collection by date. If there is already a reading for a particular timespan, it is overwritten with the new history reading. And I’m serializing the collection to XML files of my own.

I’m separating it out into separate files – one for yearly totals, one for monthly totals, etc. I mainly did this so that the serialization code doesn’t break when I finally figure out the two-hour blocks and change the collection.

Step 6 – Representing the data
I’ve never used Windows Presentation Foundation (WPF) before, but I’ve read about how it offers developers the chance to create more advanced interfaces than the Windows Forms libraries that I’m used to. It has better support for binding interface elements to data objects, richer support for pretty text, easier support for graphics… this seemed like a perfect opportunity to write my first WPF app.

As I twittered a little while ago, my first impressions on WPF is that it’s pretty cool, but I’ve still got a lot to learn – it’s quite different from Windows Forms.

Annoyingly, there don’t appear to be any graph controls already. I’ve made a stab at writing my own bar graph control – I basically draw a series of rectangles, and adjust the height based on the CurrentCost reading I’m representing.

CurrentCost bar graphingThe support for events is pretty neat – which I’ve played with by adding a line that changes the colour of the bar you have your mouse pointer over, and changes it back when you move away. Pointless, but pretty 🙂

I’ve not worked out a nice way of adding labels to the graph axes, which is a pain. For the moment, I’ve reused the event colour-changing code – when you hover over a bar in the graph, I display the height of the bar in a text box, to give the CurrentCost reading for that bar.

The problem is, as that event only knows of the bar as a graphical Rectangle object, I’ve only got the height from it. I can’t say what timespan the reading was from. Hmmm… annoying. Bit more practice with WPF needed, methinks! Still, for my ‘Hello World’ app and the result of an evening’s work, I’m pretty happy with it so far.

What’s next?
It’s not finished, but it’s a start… once I figure out the daily history data (Update: done!), and learn how to draw graphs in WPF properly, it should start getting more useful.

But if anyone wants to play with what I’ve got working so far, please feel free!

Tags: , ,

This entry was posted on Sunday, June 15th, 2008 at 9:33 pm and is filed under code. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

20 Responses to “CurrentCost – getting the history into Windows”

  1. Chris Dalby says:
    Monday 16th June 2008 at 7:44 pm

    Nice work Dale. I’m yet to have a play with my current cost like this. I’m still playing catch up and should have my slug online this week hopefully. Loving playing with this type of gear.

  2. dale says:
    Monday 16th June 2008 at 8:16 pm

    I’ve worked out how the hourly history data works – seems pretty straightforward. They are two-hour buckets giving the total since the last “even” hour?

    For example, consider the hourly history data you would get at 7.41pm

    h2 contains total for 18:00 to 20:00
    h4 contains total for 16:00 to 18:00
    h6 contains total for 14:00 to 16:00
    h8 contains total for 12:00 to 14:00
    h10 contains total for 10:00 to 12:00
    h12 contains total for 8:00 to 10:00
    h14 contains total for 6:00 to 8:00
    h16 contains total for 4:00 to 6:00
    h18 contains total for 2:00 to 4:00
    h20 contains total for 0:00 to 2:00
    h22 contains total for 22:00 (yesterday) to 0:00
    h24 contains total for 20:00 (yesterday) to 22:00 (yesterday)
    h26 contains total for 18:00 (yesterday) to 20:00 (yesterday)

    Looking at it like that, it makes sense to me now why there are 13 updates – it means you can get twenty-four hours worth of updates.

  3. dale lane » Blog Archive » Tweaking the CurrentCost app says:
    Tuesday 17th June 2008 at 12:15 am

    […] dale lane fan of all things mobile, father of small girls, IBM code monkey, youth charity trustee… « CurrentCost – getting the history into Windows […]

  4. Roo Reynolds says:
    Sunday 6th July 2008 at 8:40 am

    It’s worth knowing that the history data isn’t included in the output from the 2400 baud versions (which are sadly the ones being sold at the Eco Gadget Shop). 🙁

  5. Dave says:
    Tuesday 26th August 2008 at 3:30 pm

    Hi Dale

    I have run your windows software but can not get it to work. On one PC it says I need a newer .net framework as I only have version 1. On another I have version 2 and when I run your program nothing happens.

    Do I need version 3?

    Help

  6. dale says:
    Tuesday 26th August 2008 at 4:03 pm

    @Dave – yes – I wrote it with .NET 3.5. Although I think .NET 3 would probably be enough.

    FYI – As I’ve mentioned, I’m planning to rewrite this app anyway, probably using Python. This should make these pre-req issues much easier, as I can compile the whole thing into a single executable containing all the libraries needed.

  7. Dave says:
    Tuesday 26th August 2008 at 4:14 pm

    Hi Dale

    Yes that would be easier.

    BTW

    Have you seen this CellTrack at:

    http://www.afischer-online.de/sos/celltrack/

    Work very well.

    This is a good site to find out where cell sites are:

    http://www.sitefinder.ofcom.org.uk/

    Dave

  8. Dave says:
    Monday 8th September 2008 at 6:17 pm

    Hi Dale

    I?ve done this because the clock on my CurrentCost meter keeps losing time……….

    Here is the reply from Current Cost when I asked about the clock and Temp.

    “Some early version displays had a clock issue that (curiously) resolves itself -due the mechanical nature of the oscillator.

    The temperature readings were also unstable due to an overly sensitive component ? resulting in different readings dependant on direction and not ambient.”

    Hm I have a 2400 and a 9600 buad unit and the clock is bad on both. Southern Electric have agreed to send me a new unit as the 2400 one will not display the correct Cost per Day/Month at night. It stays on the Day rate.

  9. Dave says:
    Thursday 11th September 2008 at 12:03 pm

    Hi All

    Here is an update. Southern Electric have sent me a new unit. However, it has the same fault as the first one, it will not display the correct Cost per Day/Month at night. It stays on the Day rate.

    BUT, there is something more worrying. I now have two sensors connected to the same tail from the meter but there is a 25% difference between the two. As an example:
    the first sensor reads 3.03 Kw the second reads 2.74 Kw
    the first sensor reads 412 watts the second reads 302 watts

    I have moved the sensors apart and have even moved one to the other leg i.e one on the live and one on the neutral. Thinking they maybe upseting each other, I dissconected the first one but the second sensor still read low.

    Luckily, I have a set of tails that go to a seperate consumer unit. From this I can plug just one device in, say one 100W bulb and see which sensor is the closest. What a pain !!!

  10. Dave says:
    Thursday 11th September 2008 at 10:29 pm

    Hi

    Follow up to the above. It would appear that the sensor is most sensitive at the bottom of the clamp i.e the part futhest from the claw opening. So I now have the sensor that reads the highest hanging on the tail by the top of the clamp. The other one is attached so that the tail is up against the bottom of the claw.
    Now they are within 10% of each other. 604 watts and 579 watts.

    I still need to do the 100W light bulb test.

  11. Tim says:
    Wednesday 1st October 2008 at 6:43 pm

    Hi,

    I’ve just started playing with a Swalec branded CurrentCost from EcoGadgetShop (it’s a 9600 baud unit) and I found this page while searching for information on the data format.

    I’m a bit confused about the hourly format. If I understand you correctly, I should see the same data in th h4 slot at both 18:59 and 19:00, and that would be the figure for the consumption between 16:00 and 18:00?

    What I am seeing though, is that the data seems to “roll over” on each odd hour, so the h4 reading at 18:59 in my logged data was 1.1, while at 19:00 it was 0, and H6 becamame 1.1. Similarly, the day data rolls over at 23:00, which seems a bit odd. As far as I can tell there’s no provision for daylight savings time, so I’m not sure if I am doing something wrong. Any ideas?

    Thanks

  12. Dewang Dave says:
    Thursday 2nd October 2008 at 12:00 pm

    Hi,
    I am using a current-cost meter that sends the current energy every 6 seconds in watts and I am storing these values in the database i.e. currentEnergy = currentEnergy + liveEnergy and counter = counter + 1 so at the end of the day i m having the total sampled value and total no of sample with sampling rate as 1 sample in every 6 seconds and they are 10097246 Watts & 10976 samples. if i divide the total sampled energy with total no of samples i.e. 10097246/10976 = 919.94 Watts per sample. How do i calculate the kW-hr for that day??

  13. dale says:
    Thursday 2nd October 2008 at 12:30 pm

    @Tim – I rewrote my hour handling code after writing this post (and the comments above) because it looked wrong to me.

    I’ve copied a snippet from my current code, if it is any help to you, below. currentDateTime is the time the reading was collected, hoursago is the value from the XML element name (e.g. for h4, hoursago is 4)

    Update: Actually, this is not true. See below for explanation, but in short – hoursago should be 0 for <h2>, 2 for <h4>, 4 for <h6> etc.

    def GetOldHour(currentDateTime, hoursago):
    if currentDateTime.hour % 2 == 0:
        hoursago = hoursago + 1

    newhour = currentDateTime.hour - hoursago

    if newhour < -24:
        newhour += 48
    elif newhour < 0:
        newhour += 24

    return newHour

    I think this is right, but to be honest if you want the definitive answer, it might be worth contacting CurrentCost themselves?

  14. dale says:
    Thursday 2nd October 2008 at 12:35 pm

    @Dewang – have you read https://dalelane.co.uk/blog/?p=273 ?

  15. Tim says:
    Thursday 2nd October 2008 at 9:11 pm

    Thanks for the reply, Dale.

    “it might be worth contacting CurrentCost themselves”

    I tried that, they told me to come and ask you:-) (Their initial response to my question about the format was to do a Google search which is what brought me here)

    Fortunately today I have had a more helpful reply in which they confirm that the “roll-over” does indeed occur on each odd hour, so taking your earlier example of 7:41pm:

    h2 contains total for 19:00 to 21:00
    h4 contains total for 17:00 to 19:00
    h6 contains total for 15:00 to 17:00
    …
    h18 contains total for 03:00 to 05:00
    h20 contains total for 01:00 to 03:00
    h22 contains total for 23:00 (yesterday) to 01:00 (today)
    h24 contains total for 21:00 (yesterday) to 23:00 (yesterday)
    h26 contains total for 19:00 (yesterday) to 21:00 (yesterday)

    and as I mentioned, the day slots roll over at 23:00 (also confirmed by CurrentCost)

    Looking at your code snippet quickly, I think that you may be 2 hours (one slot) out?

  16. dale says:
    Thursday 2nd October 2008 at 9:43 pm

    @Tim – Thanks very much for the reply – nice to have this confirmed.

    You worried me there for a minute that my app must have stored months of hourly data with the wrong timestamps, but looking back at my code I was calling the function in a daft way that compensated for it! 🙂

    (I was calling it with 0 for h2, 2 for h4, 4 for h6, etc.)

    I’ll adjust the code to make it clearer, but it’s not gonna make any difference to the result so that’s nice to hear.

    The 11pm rollover thing was a surprise though!

  17. Tony Day says:
    Monday 8th June 2009 at 4:17 pm

    Hi Dale,
    Thanks for the app. After using it for about two weeks I am finding it very useful. Are there any plans to pull the temprature values from the meter too in future – may be useful as a reference.
    For info – the issue with the clock. I have the CC128 and the clock is very unreliable.
    Tony.

  18. dale says:
    Monday 8th June 2009 at 8:26 pm

    @Tony – I’m probably not going to do anything with the temperature. The app is focused on using information from the meter history, which doesn’t store temperature data.

    Techtoniq have a CurrentCost app which is more focused on capturing and displaying live data, including temperature. Perhaps that would be worth a try?

  19. kim says:
    Tuesday 3rd November 2009 at 6:35 pm

    I tried to download the app but get an error

    HTTP Error 404.2 – Not Found
    The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server.

    Have got xml data coming through using hyperterminal – now trying to graph the hourly/monthly etc history – using your app would seem to be perfect. Any help much appreciated.

  20. dale says:
    Tuesday 3rd November 2009 at 7:52 pm

    kim – Try http://code.google.com/p/currentcostgui/