Revisiting a Windows GUI for CurrentCost

tweaking the CurrentCost GUII spent a couple of evenings last month knocking together a quick example of a Windows GUI for the data you get from CurrentCost home electricity use monitors. And then promptly put it to one side and kinda forgot about it.

As a quick recap, I created a Windows app which grabbed the history data from the CurrentCost serial output, and drew a few bar graphs from it – to represent the hours, days, and months data. The app also persisted the history data in the user’s “Application Data” folder, so that older data is kept by the GUI even after it is lost by the CurrentCost meter itself.

I’m thinking about picking it up again, so spent a bit of time idea-storming what I could do with the code. These aren’t all my own ideas – they’re a random collection of ideas and notes taken from discussions with others. I’m posting them here for feedback – new ideas are welcome, as are comments on the usefulness of the stuff I’ve suggested.

Stuff to display

  • Display usage data in different units – e.g. electricity units, kWh, £, etc. – with ability to switch between them
  • Customizable date range – “show me usage for days between date X and date Y”
  • Show changes in resting rate over time. Large spikes in usage of more than a kW (e.g. from a kettle) make it harder to clearly see differences in resting rates. If we could ignore the impact of these short-lived spikes, it would make it easier to distinguish longer term changes. A mode where we lop off spikes is one option. A customizable Y scale might be another.
  • Text-based representation of trends as an alternative / addition to bar graphs – “you used 5% more during weekends than you did last month”

Interface improvements

  • Scrollable interface when there is more data than you have space for – rather than the current static approach of showing a fixed number of most recent data
  • Currently hard to distinguish between one day and the next – provide a way for the interface to:
    • highlight different days when showing more than 24 hours
    • highlight different months when showing more than 31 days
    • highlight different years when showing more than 12 months
  • Display progress bars when:
    • accessing serial port
    • reading persisted history data on startup

New features

  • Dynamically switch interface based on whether history data is included – if no history data included in the serial port data after a few retries then switch to a dashboard-y view without graphs. Might make the app more useful to people with v1 CurrentCost meters, which don’t include history data. (Although, if there isn’t any history data to collect, is there much benefit to showing live data on the GUI which the physical LCD display does anyway?)
  • Integrated MQTT client for posting history data to web server for sharing with others


  • Write the app in Java rather than .NET? The current app was written in .NET – the reasoning behind this was that the app was sort of aimed at less-technical users who would benefit from a single executable that they could just run without any setup or install. There are some problems with this. Firstly, and most obviously, it means Linux people can’t play with it. Secondly, I wrote it using .NET v3 because of the improved graphics libraries compared with .NET v2. However, this doesn’t seem to be as widely installed as I’d thought and I did get comments from people who struggled to install .NET 3.5, either because this was too complicated, or because of install restrictions on corporate or shared computers. I could:
    • Write a new version of the app in Java – this makes it available for Windows and Linux users, but potentially adds complexity to both setup and running the app. What is the simplest overhead for giving a non-technical user a Java app to run?
    • Write a new version of the app using .NET v2 libraries – writing my own versions of whatever graphics libraries I used from .NET 3.5. This still makes an assumption – is .NET v2 a reasonable assumption as a pre-req?
    • Write a new version of the app in C++ making no use of .NET – lots of re-inventing the wheel potential here. Probably more work than I really want to do on this app. But at least would probably work on any Windows machine, and without any setup or pre-req needs.
    • Provide a setup.exe installer that handles installing .NET 3.5 either by including and running a redistributable version of the .NET framework (simple for the user, but makes what is otherwise a simple app huge!), or by opening a web-page where .NET can be downloaded if it’s found not to be installed (simple for me, but still leaves the user with the task of installing .NET which may be too complex and/or forbidden on some machines).

Any other ideas?


5 Responses to “Revisiting a Windows GUI for CurrentCost”

  1. Graham White says:

    Twitter: dalelane “thinking about CurrentCost coding (link) is anyone else still playing with their CurrentCost meter?”

    Hi Dale, I’ve pretty much just started playing with my current cost. I’m looking into graphing at the moment (through PHP Image Graph) and will likely nick your idea of a daily bill of some description including a graph. See my blog posts at

  2. tamberg says:

    Hi Dale,

    isn’t it possible to call a .NET 3.5 DLL from a 2.0 (or to a lesser degree 1.1) DLL or EXE? As long as the DLL’s interface does not take advantage of new language features (e.g. generics in 2.0 DLLs) there should be no problem.

    When mixing libraries compiled under different .NET versions, I think the first loaded assembly determines which runtime version is used.

    However I’m not sure if it’s allowed to redistribute individual Microsoft .NET (3.5) DLLs.


    PS. Sorry I did not include references to support my “claims”. Can’t find any at the moment.

  3. dale says:

    @tamberg – Interesting point… the .NET DLLs are just DLLs, so – assuming no complex dependencies – it makes sense that they could be portable. Could be worth looking into

  4. John Sinclair - Energy Manager LB Sutton says:

    Hi Dale,

    I have Windows 2000 Professional SP4 and .NET 3.5 requires Windows XP or later. I therefore cannot run your .NET app. There is absolutely no chance of my OS being upgraded for the foreseeable future – I’ve asked.

    So I would welcome an alternative app, please.

  5. […] been talking about it for a while, but I finally got around to spending some time working on a CurrentCost […]