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.

The new Wireless Multi sensor Mk3 is available in the store!

You can read about it here and download the manual for details here.

Enjoy!

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,

• CO₂ 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 CO₂-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.

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.

• You can also connect the LED-pulse detector from m.nu.

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.

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.

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.

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