dale lane

I 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

Implementation

• 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?

Tags: currentcost

This entry was posted on Monday, July 28th, 2008 at 3:15 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.