Friday 10 October 2014

(Ab)using CurrentCost dev boards - code

This is something that I've been meaning to do for a while. I put together a "framework" to deal with the common tasks with the CurrentCost digital development boards, such as transmitting and pairing. I've also provided an example of handling a DHT22 temperature and humidity sensor.

If you want to program the devices, you'll probably want to see (Ab)using currentcost dev boards part 3 for the pinout. You'll also need a PIC programmer, such as the PICKit2. Both the framework and DHT22 (HygroTherm) have hex files, so you don't have to compile the code.

If you do want to compile the code, it was written using MPLABX and compiled with XC8 in free mode.

Framework

https://github.com/GrahamM/CCDigitalDevBoard
This contains a basic 'framework' for building your own CurrentCost compatible data device from a CurrentCost Digital Development Board. It does NOT transmit electricity consumption (watts) values - you would need to modify the code for that, as the packet structure is somewhat different.

In its unmodified form, the code will transmit a value of 1 if CH1 sensor pins are shorted, and a value of 0 if they are not. After pairing, this information will turn up in the XML output from the EnviR.

The function getValue() is where the impulse value is set, and this should be the bit of code you want to modify. The impulse value is set as four bytes, making up a 32bit counter. This is called approximately every 26 seconds.

This framework includes pairing code, which is initiated if you hold down the red button for approx 5 seconds. The LED will flash gently on and off when pairing is occurring. This will take approximately 12 seconds, so make sure you have your EnviR ready for pairing before you push it!

HygroTherm example

This contains a basic DHT22 example, that'll transmit temperature and humidity data in a 'water meter' type packet. You will need to move the pulldown resistor on the digital dev board, and put a suitable pullup resistor in it's place.

Roughly every 80 seconds, the device will poll the sensor and transmit the result in the form of a water meter counter packet. In order to pair with a Current Cost base unit, choose a channel on the base unit, and put it in  pairing mode. Next hold down the button on the digital dev board until the LED starts flashing, which is about 5 or 6 seconds. The digital dev board unit  will stay in pairing mode for approximately 12 seconds.

Battery life should be pretty good. I have one sensor that has been running for about a year on the same set of AA batteries. However, be aware that the DHT22 really wants more voltage in order to operate well, Once the battery voltage gets down to about 2.8V or so, the DHT22 has issues operating normally. I'd recommend you power it from 3x AA batteries, to give a terminal voltage of about 4.5v. The DHT22 and digital dev boards will be fine, as they are safe to operate up to about 5.5v

6 comments:

  1. Hi Graham. Thanks for posting your work - I've enjoyed playing with my Dev boards.

    I would like to bypass the Currentcost envir and transmit the data from the dev board direct to my RF based OpenEnergy Monitor (EmonCMS). They have a product (EmonTH) which is very simplar to what you have acheived (but a bit expensive compared to the CC Dev boards).

    That system uses the same RF hardware, but is not PIC based. They use tx/rx protocols defined by JeeLabs (JeeLib library http://jeelabs.net/projects/cafe/wiki).

    Do you think it is a simple matter of reformatting the transmit packets from your code to that which JeeLib uses? I'm guessing each Group/node would need to be hard coded into each hex file to support multiple sensors in the house. Or do you think I'm over simplifying things?

    This approach would make a much more comprehensive logging and visualisation features possible using EmonCMS

    ReplyDelete
  2. Hi Mike,

    Glad you've been able to have some fun with the dev boards. I'm aware of the EmonTH board, although I've not used them as they're somewhat expensive. I actually ended up parsing the XML output from my Envi and posting that into various nodes on EmonCMS.

    I've also experimented with the opposite - configuring an RFM12b (as used in JeeNode) board to receive data from the dev boards. I've had a modicum of success, but have hit a few problems.

    In terms of RF hardware, the dev boards and EmonTH use different modules. The EmonTH uses a transceiver (RFM12b), whereas the dev boards use a transmitter (RFM02). However, that's not the end of the world, as it should be possible to match the settings between the two. This will mean changing the transmitter set up in my code in order to match that of JeeLabs. Remember that the dev boards cannot receive, only transmit.

    In terms of group and node information - this can be stored in the EEPROM of the PIC. It's possible to write the EEPROM information when you flash the device, or you could implement a software serial RX routine to allow it to be sent over a TTL serial link. There's two pins on the ICSP port that are free for use.

    ReplyDelete
  3. Thanks for the quick reply Graham...

    So you think my logic is "do-able"?

    I also have some scripts for parsing the Envir XML, and creating feeds to EmonCMS - but it gets confused every now and then, and needs restarting.

    So would like a "cleaner", more open and low-cost sensing widget, as it would be super cool to receive the data reliably, and send to my Pi based MQTT server, or alternatively receive via EMonHub (into EmonCMS) and then to the MQTT server via the Event module.

    You see, I've recently discovered OpenHAB (in an attempt to evaporate even more of my limited space time!). From MQTT I can take actions as well as log the data/visualise/analyze with OpenHAB's open hub integration.

    Make sense?

    Mike

    ReplyDelete
  4. Yes, it's entirely possible. The first step will be figuring out the settings that JeeLabs use, in terms of things such as centre frequency, deviation, bitrate and protocol. Then those settings can be translated into RFM02 register settings.

    The RFM02 doesn't have any intelligence when transmitting - it just transmits the bits you pass to it. That means things like group and node are just another part of the stream.

    ReplyDelete
  5. Hi Graham. Could you provide some code examples for decoding the datapacket? I'm converting the first byte for checksum, next 2 bytes for temp (.1 resolution) and last byte for Humidity - but the numbers don't look right. Also, how do you determine a negative temp?

    Thanks

    Mike

    ReplyDelete
    Replies
    1. In reverse order...
      Negative temperature has the high bit set.

      In terms of code, excuse the messy perl! The following snippet is what I use to build a string for emoncms:

      if ($line =~ m! *([\-\d.]+)(\d+).**(\d+)!) {
      $sensor=$2;
      my $data = $3;
      $output=($data & 0xFF000000)>>24;
      $output.=",0,";
      $output.=($data & 0xFF00)>>8;
      $output.=",";
      $output.=($data & 0xFF0000)>>16;
      $output.=",";
      $output.=($data &0xFF);
      $output.=",0";
      }

      There's a bunch of extra zeros in there, as EmonCMS expects values to be 16bit integers. The code that's running on the sensors replaces the checksum with the battery voltage.

      Delete