Showing posts with label tellstick. Show all posts
Showing posts with label tellstick. Show all posts

December 2, 2016

Wireless Pulse Counter 3 (WPC3)

I have updated the firmware to support the Telldus products.
For Telldus products it is needed to convert the received data into Energy and Power consumption.
An example how this is done can be seen in the file wpc-calc.c here.

Another update is the 1-wire support. Now the WPC can communicate to the same 1-wire-devices as the WMS mk3.
  • DS18B20
  • DS18S20
  • DS1820
  • DS18B22
  • DS2450
  • MAX31850K
Of course is the DHT22 also supported.

The new Wireless Pulse Counter 3 (WPC3) is available now in the foogadgets store.

May 30, 2016

Soon: Wireless pulse counter (WPC2) to support Tellstick DUO/NET

I am currently working on adding support for Tellstick DUO/NET to the WPC2. The support will be implemented in the same way as the old WPC.
The 1-wire support will at the same time, be extended to be compatible with more devices.
Beta testing is ongoing.

February 5, 2016

New CO2-sensor support for the WMS mk3

I have implemented support for an additional carbon dioxide sensor that is much cheaper and easier to get hold of compared to the S8 sensor from SenseAir.

The new sensor (MH-Z19) can be found on eBay or Aliexpress from $26 including shipment.

Of course there are differences between the two that is reflected by the price.

I have setup two WMS mk3 side by side. One WMS with an S8 sensor and one with an MH-Z19 sensor. The result is logged to ThingSpeak

The MH-Z19 variant used have a range from 0-5000ppm. As the digital output on the MH-Z19 only can be 0-1000, every digital step represents 5ppm. This probably contributes to the jagginess in the graphs presented below.

First observation when comparing the two graphs is that the MH-Z19 sensor gives a much more jagged curve. Both graphs have the same shape which indicates that the response time is about the same for both. The MH-Z19 has however a slower response time.

The left half of the graphs below should be close to 400ppm as both sensors was placed in the opening of a window. Outside air can be used to calibrate a CO2 sensor since the open air CO2 concentration is constantly very close to 400ppm.

A feature that the MH-Z19 is lacking compared to the S8 is auto calibration (a.k.a. ABC - Automatic Baseline Calibration). The ABC continuously keeps the S8 sensor calibrated.

This picture shows the difference between the two. The timescale is 1 hour.
This second image shows that the MH-Z19 averages out to shape the same graph as the S8, but the readout is not very smooth. The graph spans about 1 hour to make the comparison more obvious.

Another image that shows the jagged graph from the MH-Z19 sensor.
In the graphs below I had added a +45ppm offset to the MH-Z19 sensor readings as I thought it was showing around 45ppm too much compared to the S8. After calibration I reconsidered and had to change the offset factor to -30ppm. The offset change can be seen at about 14:50. When zooming out the comparison between the two is more fair.


Summary

The price/performance ratio for the MH-Z19 is good, and I think it is worth its price and good enough to measure the air quality in an apartment or house. The S8 on the other hand seem to be very much more accurate and there is usually no problem to detect presence of one or several persons in my 97m2 apartment.

I will update the blog when the 0-2000ppm MH-Z19 sensor arrives. That variant is likely to give better results as the resolution of the output is 2ppm per step.

Note that the output of the MH-Z19 is always 0-1000 which is shown by the WMS as 0.0°C - 100.0°C
To convert this to a proper carbon dioxide ppm reading, the temperature need to be multiplied by 50.0 for the 0-5000ppm MH-Z19 variant, and by 20.0 for the 0-2000ppm variant.




May 3, 2015

How to make the WPC work in Domoticz


Updated 2016-12-04: Updated to reflect Mattias new lua-script.


Here are some short steps to get the WPC working in Domoticz.

1. Enable the X10 protocol.
In Domoticz: Click Setup and then Hardware. Click Set Mode for the RFXtrx433(E). Check the X10 checkbox if not already checked.
The WPC should after this, be shown as a RFXMeter
(In Domoticz you can fully ignore the other type of protocol the WPC transmits. i.e. Temperature/Humidity sensor with ID 4600)

2. Turn on and find the WPC in Domoticz.
In this step, the WPC does not need to be mounted to your electrical meter or Gas meter or whatever you like to count. It just need to be powered on and within range of the RFXtrx433(E)
Click Setup then Devices. Click the button All Devices and locate the RFXMeter sensor in the list. The WPC transmits a signal immediately at power on, and the once every 60 seconds, so it should be found in the list.

3. Add the RFXMeter to your list of Used sensors.
Click the green circle with white arrow pointing to the right, on the right most side of the page.
If it is a blue circle, it is already added to your list of Used sensors.

4. Name your RFXMeter sensor.
Click on the tab Utility in the top. Locate the RFXMeter, and click Edit and give it a name of your choice. This name will be used further down in this list. Also choose Type Energy in the dropdown list (if that is what you like to measure).

5. Add device that show Power consumption [W].
To be able to not only see Energy [Wh] but also see the Power usage [W], please download this excellent lua-script from one of my customers (credit to Mattias Hedström), https://github.com/mrhedstrom/domoticz/blob/master/scripts/lua/script_device_ActualEnergy.lua
To make it work, you need to follow step 5.1 to 5.3 below.

5.1 Create an Electric virtual sensor.
Click Setup and then Hardware. As Type, choose Dummy... Add a name and click Add.
From the newly created Dummy-device, click Create Virtual Sensors. In the drop-down list choose Electric...
Click Setup and then Devices. Click All devices. You should be able to find your newly created Electric virtual sensor. Make note of its idx for later use.

5.2 Modify the script to fit your local settings.
energyCounter: This should be the same string as the name you gave to the RFXMeter in step 4 above.
dummyEnergyMeter: This should be the same string as the name you gave to the Electric Virtual Sensor created in step 5.1
dummyEnergyMeterid: Use the idx integer of the Electric Virtual Sensor created in step 5.1 above.
Now all the software is in place and you should get reports once every minute from the WPC to Domoticz.

5.3 Place the updated script in the Domoticz subfolder <path-to-domoticz>/scripts/lua/

6. Mount your WPC in a secure and light tight fashion onto your Energy meter and enjoy your graphs in Domoticz.


Credit to Mattias Hedström and Patrik Nordelind for helping out making this list.

February 6, 2015

New version of the WMS Mk2 Manual

I have updated the manual with more information and more describing pictures.
The manual can be downloaded here. PDF version here.

August 13, 2014

New Firmware and Manual for the WMS Mk2

Just before the summer vacations I finalized the Wireless Multi-sensor Mk2 firmware that I have been working with for quite some time.

News,

  • CO2 sensor S8 from SenseAir is now supported. It can be connected to the Event Input after changing the input mode of the Event Input (c.f. Manual). You can get the CO2-sensor here.
  • MAX31850K support. This chip is a Thermocouple Type K to 1-wire chip. This makes it possible to make a Type K thermocouple wireless. It can output 409.6°C as the highest temperature. It is a limitation set by the protocol I use. Here you can find a MAX31850K-module, m.nu.
  • DS2450 support. This is a 4 channel AD converter. All 1-wire sensors based on this chip will be compatible with the WMS Mk2. This,  this, this, this and this is also compatible modules since they are based on the DS2450 chip.

Improvements,

  • Events are now sent as a LMST-606 device. An ON or OFF signal will be sent depending on if the input pin is pulled up or pulled down.
  • The Manual is out in a first revision.

All Wireless Multi-sensors Mk2 will be shipped with this new firmware from now on.

May 13, 2014

The Wireless Pulse Counter will take over from the old Wireless Energy Meter

EDIT (2014-09-21): I have added RFXMeter compatibility so that the WPC will show up as a RFXMeter and thus be natively supported in Domoticz. Available in WPC sold from this date. Here is an instruction for how you configure it in Domoticz.

EDIT (2014-09-15): Added information about support for the LED-pulse detector from m.nu.


The old Wireless Energy meter serves its purpose, but it has a few shortcomings.

Here is a new product that I call Wireless Pulse Counter (WPC). This is a better name compared to the old Wireless Energy Meter, since it is actually only counting pulses, not energy or liters.



Since it is only counting pulses it is also much more versatile.

  • You can combine the WPC with a reflex detector (TCRT5000) and measure water flow, gas consumption or electric energy consumption if it is of the rotating disk type.
  • You can count the amount of blinks from an Electric energy meter. Both LED and S0 output is supported.
This is how you connect the WPC to a S0 interface. The current through the S0 port need to be limited.
A resistor value of R=330Ω is OK.
The LED-pulse detector from m.nu is very very sensitive. The sensitivity can be reduced by adding a resistor R between S0- and GND on the WPC. A value between 820Ω and 4k7Ω seem to be reasonable values. Lower value => lower sensitivity.

From the counted pulses you can then calculate the consumed water/energy/gas/events etc.

The new WPC will fit perfectly in a plastic box from Hammond, with the dimensions 20x35x50mm. Note! I have not decided on a box with or without flanges as in the pdf.



The power feed is changed to a micro-USB instead of a mini-USB connector. In this way you will very likely already have a power source for it. You can just reuse an old Android-mobile charger to power it.

Most people do not have a soldering station at home. This version comes with screw terminals so that a  soldering station will never be needed.

It is professionally assembled with perfectly soldered components.

Further more, I have changed the protocol to a simpler variant. All credits to Stefan Strömberg at OpenNetHome for this suggestion.
With this new protocol you can drop several packages. Lots of packages. Still, even with only a few packages received, you can trust that they reflect the consumed energy. The solution is utilise the Humidity data field as counter data in the same way as with the temperature data field. In this way it is possible to have an always increasing counter.
It will wrap around, but the maximum counter value will be so big so that there will need to pass several hours of lost packages to mess up the energy logging.

Note that in the normal case you do not loose many packages, so the above text describes the extreme situation.

As soon as I have finished the verification of the hardware, I will make it available in the foogadgets store.

EDIT: It is now available in the web-store foogadgets.tictail.com.

March 9, 2014

Update: CO2 sensor support for the Wireless Multi-sensor

I am getting closer to a working version of the firmware that support the CO2-sensor S8 from SenseAir®.
You can get it from m.nu.

The sensor measures CO2 levels from 0 to 2000ppm and the Wireless Multi-sensor outputs this as 0.0°C - 100.0°C which corresponds to 0.0% - 100.0% of 2000ppm.

Here is a graph from the bedroom last night,
It averages around 50% during the night. This corresponds to around 1000ppm.
At first the sensor was placed outside, where the level is quite steady at 400ppm. The Wireless Multi-sensor outputs 20%.

We started the night with me and my two sons in the bedroom. The CO2 level increases until 3 o'clock, to a maximum of 56%. At 3 o'clock my eldest son leaves the bedroom and the CO2-level decreases to about 50%. After 6 o'clock me and my youngest son leaves the room and my wife enters and continue to sleep alone in the bedroom. The peak is probably me breathing too close to the sensor when checking its position.

The remaining task is to make this work together with DHT22 and the 1-wire-network. The Wireless multi-sensor is supposed to automatically detect if you have connected a CO2-sensor or if you have a PIR-sensor or other type of TTL logic type of sensor.

UPDATE: Here is another graph that shows the CO2-ppm level on the y-axis. The snapshot is taken after one night sleep with my wife and my eldest son in his bedroom.

Top notation is 1306ppm just before 7 o'clock in the morning.


February 22, 2014

Wireless Multi-sensor soon to support a CO2 sensor

I am working on a new firmware for the Wireless Multi-sensor that will add support for a CO2-sensor from SenseAir.
Most of the code is written and it is "only" the troubleshooting left. I hope I will manage to get it to work soon. However, I will not be able to code in about a week.

The sensor will be connected on the PIR-input and will be plug-and-play. The multi-sensor will be able to tell if a PIR-sensor or a CO2-sensor has been connected.
The CO2-sensor need 4.5V-5.25V and will draw 300mA peak and 30mA in avareage. This makes it not so suitable for being battery powered with this sensor.

The CO2-sensor is able to measure CO2 levels from 0ppm to 2000ppm. Due to the oscillator frequency the readings will be limited to even readings, 400, 402, 404, etc.

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