All posts by Stuart

Optismart Sensor Pinout

Optismart sensor pinout is as follows

pin 1 = pulse input, extremely high impedance. Pull low for the duration of the meter LED’s flash to register a pulse. Requires external pull-up resistor.

pin 2 = battery + output via internal 10k safety resistor

pin 3 = +ve pulse train direct out from MCU pin. Lights the indicator LED on the optical pick-up. This LED must have an external series resistor.

pin 4 = GND

Wireless Temperature Sensor using Ciseco RFu-328


Home automation typically starts with the measurement of temperature from many locations. Ideally this should be accomplished with a wireless sensor

The arrival of Ciseco’s RFu-328 Arduino compatible wireless module it should hopefully be possible to make a more intelligent sensor platform, the aim a battery lifetime of > 1 year for a  sample frequency of every minute.


  • > 1 year battery life from 2xAA battery (2000mAH)
  • Lightweight RF protocol
  • OTA (Over the air) Firmware upgrades
  • Low Cost base, Low power base station
  • Modern Enclosure Design
  • User definable sample frequency
  • Over the air encryption

Development Platform

Using an RFU Developer Board , RFu-328 , and Slice of Radio for Raspberry PI all of which make use of Ciseco’s SRF RF Modules it has been possible to begin to explore the possibilities of creating an extensible sensor platform using off the shelf component parts.

Here it is.

Left to Right: 2xAA Battery pack, Ciseco RFu-328 module mounted on RFu Developer Board, MCP9700A analog temperature sensor.

Code for the RFu can be developed using the standard Arduino IDE, with a library available from Ciseco for to allow interaction with the SRF radio module present on the larger RFu module.

The Test Scenario

The aim of achieving a battery life for the sensor of > 1 year is great, but waiting for 12 months to prove both the hardware and software isn’t desirable. So rather than sampling at a frequency of once a minute, the sample frequency is reduced to once every 2 seconds. This means that 1 day of runtime is development mode is equivalent to 30 days of runtime when sampling at one sample a minute.

We record the data sent from the sensor using an LLAP message, using a Raspberry Pi and Slice of radio. We’ve previously covered this in another article. This is then processed using Node-RED and uploaded to Xively to record and plot the results.

The Results

We sent data for battery voltage in mV measured using the ATMEGA328’s own supply voltage measurement function, and analog voltage from the MCP9700 to Xively every 2 seconds. Starting on the 1st December 2013.

Here is a screenshot of the xively feed, on Boxing Day (26th December 2013).

At this stage we’re only interested in the being able to run the sensor for more than 1 year on a single set of AA batteries, so the plot above is for battery voltage only. We’ll look at temperature sensing in a future article.

Working left to right on the graph above we’ll describe the date, and size of each voltage drop.

  • November 27th – 3019mV Previous version of testing firmware with 20 second sample
  • December 2nd  – 2956mV Initial drop after replacement firmware with 2 second sample
  • December 3rd   – 2948mV
  • December 6th   – 2940mV
  • December 8th   – 2918mV
  • December 16th – 2908mV
  • December 19th – 2903mV
  • December 25th – 2985mV
  • Current Reading (26th Dec) – 2985mV

So, using the results from December 2nd to December 26th, a period of 24 days, we’ve seen a drop of 29mV, or 0.03V.


After 24 days of running at 2 second sample frequency, we’ve seen the supply voltage to drop by a fraction of a volt. Clearly there’s still a lot of life left in these batteries. Whilst the RFu may be getting close to the voltage tolerance of a 16MHz crystal, the SRF module itself is rated down to 2V. Decreasing the sample rate to 60 seconds, will give ~2 years of operations. (24 days *60/2).

The Future

So the target battery life is clearly achievable, we’ll begin to focus our efforts on getting actual sensing of temperatures, design of a PCB, and production of documentation in the New year.

Want to find out more then why not get in touch.

You can follow the on-going progress of the sensor documented above by watching the following Xively feed

Here’s a picture of the Sensor in situ


Moving to Arduino 1.0

Arduino released Arduino1 RC1 on Sept 17th.

A summary of changes is included here

Some of these changes have caused Third Party libraries to break. We encountered just such a problem with the ethernet libraries used on nanode.

However thanks to great support by the libraries author @andrewdlindsay these issues have now been resolved, and the nanode works successfully with Arduino1 RC1.

In summary here are the changes

  • Wprogram.h replaced by Arduino.h
  • wiring.h replaced by Arduino.h
  • Wire.send becomes Wire.write

There’s probably a few more that will crop up along the way.

Here’s some example code from the etherShield libraries showing how to cope with the differences introduced by RC1.

#if (ARDUINO >= 100)


Useful links


etherShield Library





Battery Configurations

The image above shows different battery configurations for the Xbee Temperature sensor.

The sensor has been designed to allow battery configurations using, 1.2v, 1.5v, and 3.6v batteries allowing the use of rechargeable, alkaline, and thionyl-chloride-lithium batteries.

From left to right

  1. No batteries or jumpers present
  2. 2 x 1.5v Alkaline, Output 3v 2200mAh
  3. 3 x 1.2v LiPo, Output 3.6v 2200mAh
  4. 3 x 3.6v thionyl-chloride-lithium, Output 3.6v 6600mAh

With an onboard voltage convertor outputting a constant 3.3v from an input voltage of <1.2v – 4.5v it should be possible to get the maximum lifetime out of the batteries chosen to drive the wireless sensor.

Output voltage is set using 2×1 jumpers on the 4×3 pin matrix (the same jumpers as found on computer hard disk drives) as shown above. Because of the need to be able to insert the batteries in either orientation there are no battery polarity markings on the unit.