4 Apr 2011

Getting the data from a CurrentCost meter on-line has required either an always-on PC or something like the Arduino/Ethernet Shield set-up I’ve been using. That was the case until CurrentCost released their Bridge device.

CurrentCost Bridge

This little box plugs into the data port of the meter on one side and into your network on the other. It then sends the energy readings over HTTP, so you can then view it on your own dashboard.

My CurrentCost Dashboard

Under the covers, the Bridge is essentially an Arduino and Ethernet shield relaid onto a single PCB by the good folk at the sadly-no-more TinkerLondon. This makes it relatively easy to reprogram for your own nefarious needs – or in my case, getting it to publish the data over MQTT.

John Crouchley has written about some of the specifics of the board and how it can be reprogrammed with the standard Arduino development environment using a custom USB cable. Not wanting to bother with making a custom cable, I stuck to using my USBtinyISP to flash the board directly. Herewith an outline for how to do that (on Linux at least):

  1. Plug the ISP into the 6-pin header on the bridge board. If you have the ISP set to power the board make sure you haven’t got the bridge’s own power supply plugged in.
  2. Make sure you’ve followed the instructions at the bottom of the page here about udev to ensure you have the appropriate permissions to access the programmer.
  3. From the Arduino IDE, burn the bootloader. To do this, first ensure Tools->Board->Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328 is selected. Then do Tools->Burn Bootloader->w/ USBtinyISP. Of course, if you’re using a different ISP, select the one for you. This takes a little while to complete, but it is worth the wait.
  4. Once you have a sketch you want to upload, select Sketch->Verify/Compile. This generates the hex file we need in a temporary directory with a name like /tmp/build3473620529065332403.tmp. The hex file itself will have the same name as your sketch, but with a .cpp.hex file extension.
  5. Use avrdude to upload the file and you are done.
    $ cd /tmp/build3473620529065332403.tmp/
    $ ls *.cpp.hex
    MyBridgeCode.cpp.hex
    $ avrdude -pm328p -cusbtiny -D \
          -Uflash:w:MyBridgeCode.cpp.hex
    ...
    

As for a sketch to use, the basic one I wrote over two years ago needs some considerable updating. It uses absolute positioning in the XML feed to find the data it wants. This makes it fragile to any timing issues in the serial feed; something the CurrentCost can occasionally suffer from. Nor does the sketch handle the multiple sensors and channels that the newer hardware supports.

On top of that, there are some differences specific to the Bridge that need to be accounted for. The serial connection from the CurrentCost is connected to digital pins 0 and 1 which means we can use the built-in Serial object to access it rather than use the SoftwareSerial library.

As John mentions in his post, the Ethernet chip’s reset pin is connected to a digital pin on the Arduino – so something like the following can be used to to cleanly enable it:

pinMode(7,OUTPUT);
digitalWrite(7,LOW);
delay(250);
digitalWrite(7,HIGH);
pinMode(7,INPUT);
delay(500);

With all that in mind, I’ve put a new sketch on Github that does all of this and more. It uses the UUID of the bridge (stored in EEPROM) to generate both the client ID to connect with and the topic to publish to. This lets the same sketch run on multiple bridges without having to recompile with instance-specific settings. Some of the other features of the sketch are:

  • generates a new 16-byte UUID if it doesn’t find one in EEPROM
  • uses the last 6-bytes of the UUID as the MAC address
  • uses DHCP to obtain a local IP address
  • uses DNS to look-up the server address if SERVER_HOST_NAME is defined – otherwise expects SERVER_IP_ADDRESS to define the address to use.
  • reconnects to the MQTT server if the connection is lost
  • publishes readings to the topic structure “cc/[uuid]/[sensor]/[channel]
  • if PUBLISH_CONNECTION_STATE is defined, connection status is maintained on the topic “cc/[uuid]/s“. A retained message is published with the value ‘1’ when the bridge connects. A Will message is set so that if the bridge loses its connection, a retained message will be published to this topic with the value ‘0’.
  • if PUBLISH_TEMPERATURE is defined, temperature is published to the topic “cc/[uuid]/t“. It is published as a retained message and will only republish a temperature when it is 0.5 different to the last one sent

The sketch was developed using arduino-0022, the latest version of my PubSubClient library and the DHCP/DNS libraries from Adrian – links to these are in the sketch. Once the next version of Arduino is released, I will refresh the sketch to use that – as the DHCP/DNS libraries ought to be part of the standard distribution by then.

Power Graph

  1. Aideen • April 11, 2011

    This is fabulous information thanks. I’m trying to find a cost effective way to monitor energy use and temperature in multiple serviced apartments (very short term lets). My boss is nervous about Linux computers turning up in cupboards 🙂 I feel sure that the CC Bridge (or similar), MQTT and probably Pachube are the way to go.

  2. pingback from Staying Connected « knollearyMay 25, 2011

  3. andybmac • July 4, 2011

    Hi – do you know if/have had issues with different versions of the cc128 firmware and the bridge? I’ve flashed my bridge and cant get anything from the hardware serial, I’ve proved the bridge is alive by writing dummy values via ethernet to a webserver. I also tried the same sketch on a standard arduino tied to pin 0 using ‘Serial’ but no values were seen. When i modified the sketch to use newsoftserial and another pin (5) values showed thru (both cases I had serial/newsoftserial set to 57600). thanks

  4. nickJuly 5, 2011

    Hi Andy, I do know the older models of CC sometimes get their timing a bit off on the serial line; but not usually to the extent of getting no data at all. When you say you get no values, do you mean you get no XML at all, or just that the sketch fails to find the reading within the (potentially garbled) XML? If the former, then you could try varying the 57600 speed to find a better fit for your meter. If the latter, then you could modify the XML parsing to make it more tolerant.

    It is worth adding that the very latest meters appear to have much more stable timing on the serial line.

  5. andybmac • July 6, 2011

    Hi Nick
    Nothing was coming thru at all – I setup another arduino to act as a dummy CC connected from it’s TX (pin 1) to another arduino running the same code as the bridge and it did pick up data on pin 0. And to cut a long story short, a friend tried the same code on his bridge and CC and it worked fine so I have either a duff bridge or a floating serial speed on my cc128 (which works fine on newsoftserial)
    So a hardware problem in the end – thanks for the reply

    Andy

  6. andbmac • August 7, 2011

    Hi Nick,
    Just an update – I have mine working fine, with a little routine to ‘find’ a stable baud rate. I’ve been experimenting with the watchdog – I can get it to work fine on a vanilla arduino (after modifying the bootloader) but the cc bridge just doesn’t seem to want to know, every time the watchdog kicks in the bootloader spirals out of control (a known problem of course if you dont have the modification in). Have you tried experimenting with the watchdog/bootloader on the cc bridge?

    andy

  7. pingback from Moving energy readings from MySQL to redis « knollearyAugust 30, 2012

  8. leave a comment

    You must be logged in to post a comment.