January 8, 2014

Wireless Energy Meter

Hi again,

In our croft (summer house) I can turn on and off a couple of radiators just by sending an SMS. This is very convenient in the autumn to spring time. If we plan to visit the torp i just send an SMS some hours before our ETA, and that is all it takes to have a warm comfortable summer house to arrive to.

But I also wanted a way to measure the energy consumption in some way. From the electric meter in the barn to the torp where the logging computer is located, it is about 40 meter. And I really did not want to dig down a cable from there into the torp. Wireless would be so much more convenient.

Since I already had the Wireless Multi-sensor I figured I could reuse parts of the code and use the same PIC12F675 micro controller. I could not use the same multi-sensor since it was too crowded among the input/output pins. I had to start all over with a new device.

The electrical meter have a LED that blink 1000 times/kWh, but there are also electrical meters that blink 10,000 times/kWh. My Wireless Electrical Meter is however not dependent on the amount of blinks per kWh since the calculations is done in scripts on the receiving side (received by a tellstick or rfxtrx433) and are thus adapted there to the right blink frequency. Examples will follow later in this post.

This is the kind of Electric meter I have in our croft.

This is a close-up of the blinking LED:s. It is only the lower LED in this case that is interesting. That is the consumed energy that I pay for.


It is however important to know that this Wireless Energy Meter is only sending the detected amount of blinks as a temperature. It does not do any calculations or generate any timestamps locally on the device itself.

The Wireless Energy Meter phototransistor (looks like a LED) need to be mounted face-to-face to the blinking LED on the electrical meter. Care should be taken so that as little light as possible is exposed to the phototransistor, as this can generate false detections.

Once mounted and powered, it will start to send the data approximately once every minute.

Viking temperature/humidity sensor

The Wireless Energy Meter is seen by the Tellstick DUO or Rfxtrx433 as two separate Viking temperature+humidity sensors. Both sending data synchronous once every 60 seconds (approximately).

The primary Viking sensor is sending the last minutes number of detected blinks from the energy meters LED. The secondary Viking sensor is sending the penultimate minutes number of detected blinks.

The temperature that is sent is the amount of detected blinks divided by 10. So for example if the Wireless Energy Meter have detected 342 blinks it will send this as a temperature of 34.2°C.


Here is the PCB. The size of this PCB is 50x50mm.

This is the side that should face the Electric meter. The PT1 is the phototransistor that detects the blinks.

This is the back. The size is compared to 1 Swedish Krona. The PCB is 25x25mm but the TX433 transmitter builds 13mm on the side.

The humidity field I use as a data package number that increases from 0 to 99 and then wraps around. The humidity data can thus be used on the receiving side to detect if there have been any lost packages. If one detect a lost package on the receiving side one can recover the lost data by using the secondary sensors data since this is the penultimate data. For this reason, once every minute I send the penultimate data first, followed by the most recent data. In this way I will be sure to already have the penultimate data available when the most recent data is received. It is first when I get the most recent data I can detect if I need to recover.

Since this device is only sending raw counter data, it will be compatible with many home automation applications such as Beyond Measure, Switch King, Automagically, tellmon.net or any other solution used.

This flexibility come with a drawback. It is very much up to the user of this device to implement the code on the receiving side, to get a complete solution. I will in this blogpost share some of the algorithms and scripts that I have used.

Logging

The most interesting part of the energy reading activity is the logging. Then you can actually see the history of the energy consumption and correlate that to the inside and outside temperatures. You can also possibly detect any energy hogging device by looking at the periodicity of a peak power usage.

For this Wireless Energy Meter I first tried RRD (rrdtool). The RRD is the round robin database that is very good to use when you need to limit the size of the database. One of the drawbacks is that you need to specify at the time of creation, with what periodicity you will log your data. My sensor is sending new data once every 60 seconds ... approximately. I use the internal oscillator to clock the sleeping time of the PIC. The internal oscillator is not very accurate. The accuracy should however be within 60s +-2s. This will of course affect the accuracy of the energy calculations. The clock is also dependent on the surrounding temperature.

A better way to log the data is to use a SQL-database. Then you can save the timestamp of the data at the time of arrival, and then do calculations based on the counted pulses and time passed since last the previous package was received.

The following algorithm can be used to detect lost packages and also log to a database. See it as pseudo code,

// Callback function (If it looks similar to Telldus it is because it is based on an example from them)
void sensorEvent( int sensorId, const char *value, char *temp) {
  if ( sensorId == 69 ) { //Store the secondary virtual sensor value
    f_temp[sensorId] = atof( temp );
    i_seqno[sensorId] = atoi( value );
    return;

  } else if ( sensorId == 68 ) { //Store the Primary virtual sensor value
    f_temp[sensorId] = atof( temp );
    i_seqno[sensorId] = atoi( value );
    i_diff[sensorId] = i_seqno[sensorId] - i_prev[sensorId];
    switch ( i_diff[sensorId] ) {
      case 1:
      case -99: // All OK
                // Log f_temp in a MySql-db or send it to Xively for example.
      case 2:
      case -98: // One transmission lost. Check if we can recover.
        if ( (i_seqno[sensorId]-i_seqno[sensorId+1]) == 1 ||
             (i_seqno[sensorId]-i_seqno[sensorId+1]) == -99 ) {
                // It seem like we can recover. Log the f_temp[sensorId+1] and the f_temp[sensorId] value.
        } else {
                // If we are here, we have lost one transmission and can not recover. Anyway, we log the current value f_temp[sensorId] and do a best guess of what the lost value was. We could use an average number or the same as current value f_temp[sensorId]. This would likely be less wrong than leaving it empty.
        }
        break;
      default : // If we are here we have lost more than one complete transmission. If this occur frequently you have to look over your setup.
    }
    i_prev[sensorId] = i_seqno[sensorId];
  }
  return;
}



The formulas for total consumed Energy (Wh) and the current Power consumption (W), goes something like this,
TotalEnergi = Start_value + SUM(temp*10)/1000
The Start_value is optional and can be used when starting the measurements. You get it from the display on the electric meter. If you add this you will hopefully get the same numbers in the graphs as on the electric meter. The Start_value should be given in kWh. TotalEnergy is kWh.
SUM() is the sum of all incoming "temperatures". In C++ it would be written sumkWh += temp*10/1000;
Result in kWh.

Pmom = temp*10/1000*60* 60/(Time_now - Time_previous)
temp is the incoming data from the Wireless Energy Meter.
60/(Time_now - Time_previous) is a compensation factor that need to be added to compensate for the low precision oscillator in the PIC. The oscillator frequency depends on temperature and voltage. It is wise not to skip this compensation factor.
Result in kW


It can also be used in Domoticz. See this thread over at temperatur.nu.
Also check in Automagically and Tellmon.net that have native support for my Wireless Energy meter.
Further more, there is also a plugin for Beyond Measure, see this thread.





If you like it, you can also buy the Wireless Energy meter here, http://foogadgets.tictail.com

January 6, 2014

Getting closer ...

Last evening I made som updates of the assembly code for the Wireless Energy meter.
The code will not be open source, but you will anyway be able to change configuration parameters without recompiling any code.

I am using the EEPROM area to store configurable parameters that are interesting to change, such as time in between transmissions, amount of retransmissions for each sensor, and the sensor-ID.

What you will need in order to change any of the EEPROM data is a Pickit 2/3 or similar.


January 3, 2014

New version of the Wireless Multi-sensor PCB

Here is my latest version of the Wireless Multi-sensor PCB (Version 1.1).

Last night I assembled 12 units. I only had time to test two units very quickly, but all is sound so far. The only missing part is the PIC12F675. I have been waiting since 12th November :(. It will arrive any day now :)

As can be seen in the picture below, there are three inputs. One for the DHT22, one for the 1-wire bus and one event sensor input. The event sensor-input have the same pin-configuration as the PIR-sensor HC-SR501.
I have also added a power supply input (marked BAT) to the right of the DHT22 input where you have the possibility to add your own power supply.

The changelog for version 1.1,
  *A pull-down resistor can be soldered in the spot marked R4. It will not needed if the input is not used since there will be a jumper grounding the data input pin.
  *The 2.1mm DC-jack has been exchanged to a mini USB type B connector. I have also added the possibility to add your own power supply.
  *The hardware bug has been corrected.

November 29, 2013

Wireless Multi-sensor

A.k.a. esic-clone and fineoffset-clone.

How hard can it be to build a wireless temperature sensor? I had to find out.

I figured I needed a microcontroller that could read a sensor and bitbang the data to a 433MHz OOK radio module. My choice fell on the PIC12F675. Not too many pins and not too many registers/parameters/options to keep in the head. And one more thing. I wanted to write in assembler.

The temperature sensor that I set up as a project to copy was one that had the brand ESIC that was sold by Clas Ohlson in Sweden. The protocol seemed not too complex and it was easy to implement since the receiver that I have (Tellstick DUO) is written mainly in open source. I could easily have a look at what the Tellstick DUO expected to receive from an ESIC temperature/humidity sensor.
The the rest of this blog post is a description of how you can build your own temperature sensor that is compatible with Tellstick DUO/NET from Telldus and RFXtrx433 from RFXCom. I call it a Wireless Multi-sensor. It will be more clear why "Multi-" in a moment. Note: esic_clone/fineoffset_clone was the first name and it will be seen trough out the text.

The Wireless Multi-sensor mimic an ESIC/Viking temperature sensor but with better range, and best of all, it can mimic up to at least 11 ESIC-sensors with only one Wireless Multi-sensor device.

ESIC temperature/humidity sensor
Viking temperature/humidity sensor

It supports the following sensors,
  • DS18B20, DS18S20, DS18B22, DS1820 from Dallas Semiconductor. A network of 10 has been tested OK, and more will probably work as well. Parasite mode is not supported. The sensor variant MAX31820 is likely to work as well since they should be compatible to DS18B20, but they have not been verified yet. Please let me know if they work so I can update this blog post.
  • DHT22 Temperature and Humidity sensor (a.k.a. RHT03 and AM2302)
  • HC-SR501 PIR-sensor to detect movement. It will send data whenever pin 4 goes from L to H. Actually this can be any sensor that have a 0V-5V TTL logic output.
The data is sent over the air with a 433.92MHz OOK/ASK transmitter using the Mandolyn (or Fineoffset) protocol. The transmission is done once every minute but can be adjusted by changing the SAMPLE_DELAY parameter in the source code.

The Wireless Multi-sensor will appear as if it was one or several single ESIC/Viking temperature sensors. All depending on how many sensors that has been added to the Wireless Multi-sensor device.

Here are some examples of the different configurations (esic_clone = Wireless Multi-sensor):


The details

More about the electrical schema and the program.

Hardware

Bill of materials

- PIC12F675
- DS18X20 Dallas Temperature sensor(s) (Optional)
- DHT22 (a.k.a. RHT03 and AM2302) Temperature/Humidity sensor (Optional)
- HC-SR501 PIR sensor Google "DYP-ME003/Specification.pdf" (Optional)
- TX433 OOK/ASK transmitter module (i.e. FS1000A)
- R1  1k
- R2,R3  4k7
- LED
- 100nF decoupling capacitor


Power supply

Maximum voltage is limited by the PIC to 5.5V and minimum voltage is 3V.
However, if a HC-SR501 PIR sensor is used the minimum voltage is 4.5V.
I recommend 3 AA(A) batteries, unregulated or 4 NiMH AA(A).

Software

This has been my first PIC microprocessor project, so I am not very familiar with PIC-assembler. The code could probably be optimised and for sure much better structured.

Mandolyn protocol

There are several interpretations of the Mandolyn protocol on the internet. This is my interpretation of the protocol which I believe is the correct one ;)
  • 4-bit Preamble
  • 4-bit House Code (Either 6 byte 1-wire id XOR:ed or OSCCAL or PIR_SENSOR_ID)
  • 2-bit Channel Code (Either 6 byte 1-wire id XOR:ed or OSCCAL or PIR_SENSOR_ID)
  • 2-bit Unknown (Always b'11')
  • 1-bit Battery status (Here always b'0')
  • 7-bit Humidity (Represents battery status and/or Humidity depending on sensor)
  • 12-bit Temperature from 1-wire sensors and/or DHT22
  • 2-bit Packet sequence number (0-2)
  • 2-bit Checksum (1st bit XOR all ODD bits, 2nd bit XOR all EVEN bits)

House Code (HC) and Channel Code (CC)

In the Mandolyn protocol the House code and Channel code is used to tell one sensor from another.
I generate the HC and CC differently depending on the sensor.
  • 1-wire sensor: HC and CC for each individual 1-wire sensor is generated from every individual sensors unique serial ID.
  • DHC22: HC and CC for the DHC22 is generated from the OSCCAL register value, but could be hardcoded to another value if needed.
  • Event sensor: HC and CC for the event sensor will be set by the PIR_SENSOR_ID parameter. Default value is HC=15 CC=4.

Note that the way the HC and CC for all sensors above is generated, implies that the HC and CC survive a battery change.

Humidity bits

The ESIC-sensor is sending the Humidity value as a 7-bit integer.
In my Multi-sensor I have used the 7-bit humidity field to send the current battery status level when sending data from the 1-wire sensors. The value you get is dependent on Vdd. Anything from 3V to 5.5V should be OK to feed the circuit with. Lower numbers mean higher voltage. The voltage drop over the LED is used as a reference. In my case the voltage drop over the LED is 1.77V. This gives the following equation,

Vdd=Vdiod/Humidity/2*256

where Vdiod is the voltage drop over the diode and Humidity is the read value from the Tellstick.

Data packets sent from the DHT22 readings will contain the actual humidity.

In the case when activity is detected by the event sensor (i.e. PIR-sensor) the humidity field is
filled with data that should be different from the previously triggered event. The purpose with this is to make the sensor compatible with Beyond Measure, a very flexible, module based automation application.

Battery status bit

I have not used the battery status indicator flag in any way since it is ignored by Telldus.

System defines

The system define SAMPLE_DELAY tell how many 2.6 second periods that should pass
until next sample-transmit round. This is 23 in the asm-code which corresponds to a transmission
approximately once every minute.

The system define PACKET_RESENDS specifies how many packets in every burst that should
be sent. Default is 3, just like the original ESIC-sensor.



There are also three forums where I have presented this project where you might find more information.
Svenska Elektronikforumet (Swedish)
Telldus Forum (English)
Temperatur.nu Forum (Swedish)

There are two variants of the implementation. Both have the same features but uses different protocols.
  • esic_clone mimic ESIC sensors.
  • fineoffset_clone mimic Viking sensors.
The source code and already compiled hex-file can be found here.

If you need to re-compile the code you will need MPLab X IDE that is free to download from here,
http://www.microchip.com/pagehandler/en-us/family/mplabx/#downloads


You can also buy a kit or the complete product from here.

There you will also find a Wireless Energy Meter compatible with Tellstick DUO/NET and RFXtrx433 that I will post as soon as it is verified.


/Niclas

Fail: badly designed PCB for the Wireless Multi-sensor

I sell the boards that was badly designed.

The LED is connected to Vdd through R1 which makes it light up as soon as you power the wireless sensor. It is supposed to only blink when sending data.

This can be corrected by cutting and bridging  as in the picture below.


After this has been done the board is 100% OK.