433Mhz Sensors

Orange tree
We have a number of plants in our conservatory (5.5m × 4m) that we want to look after with this project. These are not particularly valuable but they they have sentimental value and because it can get quite warm in the conservatory in the summer, they can dry out very quickly. The first is this mini orange tree.

The main aim of this project is to connect these plants up with wireless sensors so that we can monitor their health and condition. The initial focus is on soil moisture level and local temperature but we have many other sensors in our smart conservatory already.

Orange tree
The second plant we want to look after is an Arabica coffee tree. Who knew you could grow coffee in the UK? ;-)

A future project will implement a multi-channel irrigation system for the plants in our conservatory, so that we can deliver a personalised watering scheme to each individual plant. This will be controlled by our Home Control System (HCS), which will have 'whole house context'.

The third plant we want to look after is a 1.5m tall lemon tree.


433MHz Receiver & Transmitter

We bought a matched 433Mhz receiver and transmitter on eBay for just £3.29.

MX-05 Receiver

The MX-05 device uses just 3 pins to the Arduino: GND, +3.3V and a connection to an analogue input (A0). It can work with 5V but all of what we have read suggests it works better using the 3.3V supply. It is connected to an analogue pin because a varying output voltage is used to represent both low and high signals, i.e. it does not have a binary output.

MX-FS-03V Transmitter

We are not using our MX-FS-03V module as part of this project but will be using it later for control of the ceiling fan (and its integrated light) in our smart conservatory.

Arduino UNO

Arduino UNO
The receiver is mounted on a modified prototyping board (cut out around the RJ45 socket) as these are really cheap to buy on eBay. This then sits on an Ethernet shield, which is mounted on the Arduino UNO.

We have developed a lot of software on these devices (we have at least 8 in our home now) and much of it is reusable for this project.

Range & Aerials

We don't need a huge range for this project but long range is good. Without an additional aerial (i.e. just using the coils on the receiver board) the range is less than 50cm. When we added a 17.2cm aerial to the board, the range increased to about 2.5m.

Contrary to what we had read, when we used a longer aerial, the range increased to over 4m. We eventually settled on this coil loaded aerial design.

This compact design provides a range of more than 5m.


I will add much more detail on the software and publish my Arduino code later. For now, all I want to say about the software is that it sits in a loop waiting for a transmission to be spotted and then it captures the signal as a sequence of low-high duration pairs in the form [3,7] or [11,4], etc. It also detects and marks up the start and end of individual transmissions.

In 'debug' mode our software provides a raw view of what it sees, displayed in blocks of 8 transitions, for example:

[4,7] [4,7] [4,7] [4,7] [4,7] [4,7] [4,7] [11,7]
[4,0] [11,8] [3,8] [11,7] [4,7] [11,7] [4,7] [11,8]
[11,7] [11,7] [11,8] [11,7] [4,7] [11,7] [4,7] [11,8]
[11,7] [4,7] [4,7] [4,7] [4,7] [4,7] [11,8] [3,8]
[3,8] [3,8] [3,8] [3,8] [3,8] [3,8] [3,8] [3,8]
[10,8] [11,7] [4,7] [11,8] [3,8] [3,7] [4,108]

Notice how the timing isn't exact and completely repeatable. [11,7] and [11,8] are basically the same signal. So are [4,7] and [3,8]. Our software has to handle these slight variations and we do this by specifying an acceptable range for the first and second duration.

The durations used by each type of sensor also vary they often use different pulse lengths and patterns. Our 433MHz door bell produces pulse lengths that are often captured a 0 or 1 in length. This is pushing the boundaries of what can be done with an Arduino UNO running at 16MHz. It would be better to use a faster processor and code combination, in order to measure these durations with higher accuracy. Having said that, it does work :-)

The Arduino UNO also has a limited amount of memory. Whilst debugging we set aside quite a lot of space to capture and store transmissions but we saw some issues when it got close to using most of the memory available. We reduced the storage used for the transmissions once we had got things working.

Our software currently handles four different types of sensors and maps these to zeros and ones. This allows us to visualise the data and try and interpret what it means. Some more unusual pulse patterns are mapped to letters though as you will see later.

Any low/high pairs that have long durations are assumed to be end of transmission markers and are mapped to the letter 'E'.

The sensors typically transmit (approximately) every 45 seconds but, each transmission contains several repeat transmissions of the sensor data. Our Arduino code (like all our slave processors) enforces rate limiting on the updates sent to our Home Control System (HCS). There is little point in sending the soil moisture levels this regularly, so updates are limited to a minimum of 59 minutes and only if the value has changed. We are still optimising the temperature reporting but since we only send changes and they only report integer values, we envisage sending all changes. The sensor will naturally limit these to every ~45 seconds (repeats transmissions aside) but we still enforce a minimum update period of 43 seconds for now.

Door Bell

433Mhz wireless door bell button
I just happened to have a 433MHz wireless door bell to hand and thought this would make a good test device, primarily because the push button means I can create a transmission on demand. This photo shows both the front and the circuit inside. A wide range of addresses are possible using the DIP switches.

Our starting point was tutorial, to ensure that we could receive 433Mhz transmission before we started trying to decode them.

We then wrote some rough code to capture the signals and convert them into strings of characters. This is what we saw initially with the DIP switches set such that just no. 6 was down.:


The repeated pattern changed in a completely predictable way when we started changing the address settings.

With DIP switches: 1-6 UP we get:

With DIP switches: 6 DOWN:

With DIP switches: 5 & 6 DOWN:

With 4,5 & 6 DOWN:

With 3,4,5 & 6 DOWN:

With 2 to 6 DOWN:

With 1 to 6 DOWN:

So we have a predictable signal and can vary the address as required.

Plant Sensor

This plant sensor caught our eye whilst browsing eBay. Each one cost £8 delivered and uses 433Mhz to transmit the soil moisture level and the local temperature to a display device. We actually bought them as additional sensors and didn't initially buy the display module. The display module will work with up to three of these sensors, which is all we want to connect (wirelessly) in our conservatory. We have other plans for many more wired sensors though. This could be considered a limitation in some cases but not for us. As you can see later, this is a limitation enforced by the hardware addressing mechanism used.

We then turned our attention back to this. It is designed for outdoor use and the specification says:

The XH300 sensor detects soil volumetric water content (VWC) through sensing the dielectric constant of the media using capacitance domain technology. The sensor is built on PCB, it is reliable in almost any soil. The system has a self learning process built to eliminate the influences of different soil or media. Also on the remote sensor, it measures outdoor temperature, which is received and displayed on by the receiver for easy reading purpose. Since the temperature sensor is located inside the moisture sensor housing, when exposing to direct sun light, the outdoor temperature reading will be a few degrees higher comparing to normal air temperature.


  1. Remote temperature range: -40C to +65C
  2. Temperature accuracy: +/-1.0C
  3. 2 x AAA alkaline batteries
  4. Transmission frequency: 433.92MHz
  5. Transmission range: up to 100 meters (300 feet) in free open air
  6. 1 years battery life for both outdoor and remote sensor (alkaline battery used)
  7. RoHS Compliance

Moisture & Temperature Sensor

When we plugged in the moisture and temperature sensor, we saw a regular 47-bit signal appearing that looked something like this:

[4,7] [4,7] [4,7] [4,7] [4,7] [4,7] [4,7] [11,7]
[4,0] [11,8] [3,8] [11,7] [4,7] [11,7] [4,7] [11,8]
[11,7] [11,7] [11,8] [11,7] [4,7] [11,7] [4,7] [11,8]
[11,7] [4,7] [4,7] [4,7] [4,7] [4,7] [11,8] [3,8]
[3,8] [3,8] [3,8] [3,8] [3,8] [3,8] [3,8] [3,8]
[10,8] [11,7] [4,7] [11,8] [3,8] [3,7] [4,108]

Our Arduino software maps these sequences of high and low values to binary. We took anything between 3,7 and 4,8 to be a '1' and anything between 11,7 and 11,8 to be a 'zero', though we can add a bit more flexibility in the timing to better handle noise. A sequence of transmissions look like this:

11111111 01010101 00000101 00111111 1111111 11001100
11111111 01010101 00000101 00111110 1111111 11001011
11111111 01010101 00000101 00111110 1111111 11001011
11111111 01010101 00000101 00111101 1111111 11001011
11111111 01010101 00000101 00111101 1111111 11001011
11111111 01010101 00000101 00111101 1111111 11001011
11111111 01010101 00000101 01000011 1111111 11001110
11111111 01010101 00000101 01000010 1111111 11001101

To try and make sense of the data coming from the sensor, so that we could reverse engineer it, we stuck it in the freezer for 15 minutes to make it really cold. We then captured all the data as it slowly warmed back up to room temperature. We have split the data into bytes above but notice that the 5th column is only 7 bits long.

The first byte is fixed and is always a sequences of eight 1's.

Sensor Address

Soil sensor address setting
The sensor has a tiny jumper to set its address. This can go in one of three positions. The above digit sequences were done with it in position 1.

When we changed the jumper to position 2, we spotted an obvious change in the last 2 digits of the second byte:

11111111 010101 10 0000010 10011110 01111111 11001011

When we changed the address to 3, we saw another change

1111111 1010101 11 0000010 10011110 11111111 11001100

Just to confirm it we changed it back to 1 and it reverted back as expected:

11111111 010101 01 0000010100111110111111111001011

So we can use up to three of these sensors in our conservatory and assign each with a unique address.

Soil Moisture

To see which bits were used for soil moisture level, we covered the probe in wet tissue. We immediate saw the 3rd byte change from 00000101 to 01100011. This was almost too convenient as these map to 5% and 99% respectively :-) 99% is also the highest reading the display module can show on its display screen.


The temperature was the hardest part to decode but we now getting repeatable and accurate results. We think there are still some details yet to be resolved though. To try and understand the encoding used we put the sensor in our freezer and monitored the readings collected as we let it rise back up to room temperature. We could see a clear pattern of binary increments in the 4th byte and each change seemed to be representing a temperature rise of 1°C.

The specification for the device says that the remote sensors can record temperatures from -40°C to 65°C. If this was done with 1°C accuracy then this represents a series of 105 readings, which could be represented by 8 bits (maximum of 256 readings).

There is also another rising pattern in the 6th byte but it seems to change at half the rate and only involve the last 4 bits. This could be some parity checking or something else.

11111111 01010101 00000101 00111111 1111111 11001100
11111111 01010101 00000101 00111110 1111111 11001011
11111111 01010101 00000101 00111110 1111111 11001011
11111111 01010101 00000101 00111101 1111111 11001011
11111111 01010101 00000101 00111101 1111111 11001011
11111111 01010101 00000101 00111101 1111111 11001011
11111111 01010101 00000101 01000011 1111111 11001110
11111111 01010101 00000101 01000010 1111111 11001101

Display Module

display module box
We eventually bought the display module (it comes with another sensor) to see if we could better correlate the transmissions to the readings presented on the display. This confirmed that we had decoded the data incorrectly but we were quite close. The temperature from these devices is not meant to be amazingly accurate.

This display module and sensor was branded 'Imagintronix' and the device is called an 'IM300'. Our other 'additional' sensors were labelled as 'XH300'.

display module receiving data
The display module has an indicator to show when it is getting valid transmissions from a sensor. Although it says it can display the values from 3 sensors/channels, we have yet to get it to display the 3rd channel, even though we are picking up the transmissions and decoding them.

display module receiving temperature data
The display module presents the integer temperature values on screen. The display module has its own temperature sensor and clock built in too.

display module receiving data
The display module presents the soil moisture level as a percentage value between 5% and 99%.

Battery Level

As far as we can tell there is no battery level reporting done and there doesn't appear to be any way to show this on the display module.

Ceiling Fan Remote

Mercator remote control
We have a Mercator 3-speed ceiling fan with integral 100W halogen tube lamp in our conservatory. This is manually controlled using a 433MHz remote control unit. It has buttons for 'Hi', 'Med', 'Low', 'Off' and 'Light'.

We don't really use the light as it uses so much power and is not compatible with a lower power LED equivalent. We also fitted multiple 12V LED ceiling lights to the roof rafters when the conservatory was built.

Oregon Scientific TX-01

We already have an Oregon Scientific wireless temperature monitor in our conservatory, with a wireless TX-01 temperature sensor outside. The encoding for this is more complex and but well documented. We will be covering this in detail soon.

HCS Integration

Integration into our Home Control System (HCS) is really easy because we use technology abstraction and the Arduino used here is just another slave device, with all the benefits and inherited monitoring that this brings.

The Arduino is simply sending events to our Home Control System (HCS) which provides all the intelligence and collective 'whole house context'. All of the decision making in our smart home is done by our HCS as only it has all the information and context to make the right decisions.

We simply add the new sensors and devices to our JSON configuration files and because they are using existing object types, they inherit all of the characteristics of these object types. This means they adopt all associated capabilities such as alerts, notifications, voice announcements, etc. For each individual plant we have set minimum and maximum temperatures for alerts and also the soil moisture levels. This basically means we get notified (typically via SMS) when the each plant needs watering.

Learning & Insight

Soil Moisture

This project has already provided some useful insight. The dry soil on the surface of our plant pots had led us to believe that our plants were drying out very quickly and thus required very regular watering (typically every 2 days). These soil moisture sensors reach deeper into the soil (more than 6cm) and have shown that lower down the soil is still quite moist and remains so for several weeks. This new insight is going to prevent over watering and significantly reduce the effort involved in maintaining our conservatory plants.

The soil moisture levels change really slowly. We have rate limited updates to a minimum of 59 minutes. We also force an update every 359 minutes. The display module indicates a dry plant at a soil moisture level of 60% and this is the value we use to generate notifications.

One interesting thing we noticed is that the soil moisture sensors are sensitive to the ambient temperature. This graphs shows one day (with sunshine) in our conservatory. The temperatures are pretty extreme because they are in direct sunlight for some of the day. The soil moisture level clearly rises with temperature despite the overall trend being downwards.


The temperatures captured are also significantly higher than those captured from sensors mounted on the house wall due to the conservatory being north facing and some of the plants being in full sun from about 1pm onwards. One days with both cloud and incident sunshine the plant temperatures fluctuate relatively quickly and temperature updates arrive every 2 to 5 minutes. Because this temperature data isn't particularly valuable to us, we have rate limited the updates to every 17 minutes.


Because we now have a reliable mechanism to collect plant data, our Home Control System (HCS) can now be left to look after them and let us know when action is required.

With the plant sensors now fully operational in our conservatory, we can see just how warm our conservatory gets on sunny days. Despite having an automated ceiling vent (which makes a huge difference), it gets toos warm. Our attention has now moved to the ceiling fan and intelligent control of it. Mixing the air in the conservatory will ensure a much more even temperature gradient from floor to ceiling and more consistent overall temperatures (much lower on hot days).

We don't generally recommend the unlicensed 433MHz spectrum for smart home automation. It's not a very reliable technology and is not using two way communications, to acknowledge commands have been received. It is fine for non-critical services though, where the odd missing reading will not really matter.

Transmission & Control

Because our Arduino is continuously listening for transmissions, we don't want to burden it with also listening for commands from our Home Control System (HCS) and then actioning them as well. The Arduino UNO doesn't have the ability to run multiple threads or services at once. For the 433MHz control and transmission we will use another networked Arduino UNO and this will covered as a separate project.

Conservatory Irrigation

The objective of this project is to collect the sensor data required to keep our conservatory plants alive. We are going to follow this project with a conservatory irrigation project, to enable intelligent irrigation and a watering scheme that is customised to each plant.

Further Reading


This is a widget showing what was recently tweeted by our smart home and this now includes our plant sensors:

Share ...
We are on ...
Facebook Twitter
YouTube Flickr Follow us on Pinterest