Completed2018Final Project

Sockets & Sensors

Multi-protocol IoT system for environmental monitoring and remote appliance control

PythoniOS (Swift)FirebaseArduinoRaspberry PiXBee/ZigBee433MHz RFC/C++

Overview

This was my final project for the Higher Diploma in Computer Science at NCI. As a building services engineer, I was drawn to monitoring internal environmental conditions and controlling systems remotely. This project tackled both problems in the context of my home.

The system had three main objectives: wirelessly monitor environmental conditions (temperature and humidity) and record them over time, facilitate remote control of electrical wall sockets, and provide a user interface to view monitored data and control the sockets from anywhere with internet access. At the time of submission, the system had been operating continuously for approximately one month without issue.

Note: This video has no audio as it was used during a live presentation where I described the system in person.

System Architecture

The system consists of five main components working together: a Firebase backend for data storage, a Raspberry Pi base station for coordination, an Arduino-based wireless sensor node, RF-controlled wall sockets, and an iOS application for user interaction.

System architecture with five integrated components communicating via WiFi, ZigBee, and 433MHz RF

Base Station

The base station was built around a Raspberry Pi 3 Model B, serving as the central hub connecting all system components. It ran a Python application in an infinite loop, handling three key responsibilities: listening for data from the wireless sensor node via XBee, uploading sensor readings to Firebase, and transmitting 433MHz RF signals to control the wall sockets based on commands from the iOS app.

The XBee module was configured as the coordinator in the ZigBee network, connected via a USB explorer dongle. The 433MHz transmitter and receiver modules had antennas soldered on for improved range, allowing socket control throughout the house.

The base station hardware: Raspberry Pi with XBee coordinator and 433MHz RF modules
Base station wiring diagram for the 433MHz RF modules

Wireless Sensor Node

The sensor node was built around an Arduino Uno with a DHT11 temperature and humidity sensor. An XBee module configured as an end device handled wireless communication with the base station using the ZigBee protocol at 2.4GHz. The Arduino sketch read sensor values at configurable intervals and transmitted them via the XBee network.

Three status LEDs provided visual feedback without needing a serial connection: green indicated successful transmission, red indicated errors, and blue showed power/activity status. This made troubleshooting straightforward when the node was deployed away from a computer.

The wireless sensor node: Arduino with XBee, DHT11 sensor, and status LEDs
Sensor node wiring diagram showing DHT11 and LED connections

RF Wall Sockets

Five radio-frequency controlled wall sockets were deployed throughout the house, providing remote control of lamps, computers, and other appliances. These were inexpensive off-the-shelf sockets that came with proprietary remote controls operating at 433MHz.

The RF wall sockets and their original remote controls
Socket deployment across the house

RF Code Reverse Engineering

The RF wall sockets came with proprietary remote controls, and the codes weren't documented. To control them programmatically, I needed to discover the codes each socket responded to.

I connected a 433MHz receiver to the Raspberry Pi and ran an RF sniffer utility to capture the signals when pressing buttons on the original remote. Each button press produced a unique numeric code that I could then replicate using the 433MHz transmitter.

Capturing RF codes from the remote control using the RFSniffer utility

By systematically pressing each button on the remote and recording the captured codes, I built up a complete table of on/off codes for all five sockets. The base station could then transmit these exact codes to control the sockets programmatically.

The discovered RF codes for each socket

This approach meant I could use inexpensive off-the-shelf RF sockets rather than expensive smart plugs, whilst still achieving full integration with the home automation system.

Multi-Protocol Integration

One of the most interesting aspects of this project was integrating three distinct wireless communication protocols into a cohesive system:

  • ZigBee (IEEE 802.15.4): Used for communication between the Arduino sensor node and the Raspberry Pi base station via XBee modules operating at 2.4GHz. This provided reliable, low-power wireless sensor data transmission.
  • 433MHz RF: Used to control the radio-controlled mains sockets. The base station sends on/off commands to five individual sockets, each with unique codes.
  • WiFi/HTTPS: The iOS app communicates with the Firebase backend using secure cloud APIs, enabling real-time data synchronisation without direct connection to the home network.

Cloud Infrastructure

Firebase Realtime Database stored all sensor data and socket states in a JSON structure with three root nodes.

Firebase database structure with three root nodes

The sensors node stored time-series data with epoch timestamps as keys. Each reading contained temperature, humidity, and a human-readable timestamp for easy debugging.

Sensors node: time-series data keyed by epoch timestamp

The sensorMeta node contained metadata for each sensor, including which data keys it provided, their units, a display name for the UI, and the sensor's location.

SensorMeta node: metadata for UI display and data interpretation

The sockets node tracked each socket's display name, number, and status (1=on, 0=off). It also stored the RPi last check time so the iOS app could detect when the base station went offline.

Sockets node: configuration and status for each controlled socket

Firebase Authentication with Google Sign-In ensured only authorised users could access the system. Automatic daily backups with manual JSON export capability provided data recovery options.

iOS Application

The iOS app provided the user interface for the entire system with a tab-based design. The Sockets tab displayed each socket with a toggle switch for on/off control, showing the RPi last sync time so users knew the base station was online. Socket names were user-configurable via tap-to-edit. When the base station went offline, the UI disabled controls to prevent confusion.

Sockets tab: control view, name editing, and offline state

The Sensors tab showed temperature and humidity data with interactive charts using the SwiftChart library. Users could select from available sensors, navigate day by day through historical data, and toggle between humidity and temperature readings. Tapping on the chart revealed specific values at any point in time.

Sensors tab: sensor selection, temperature graph, and humidity reading

Results

The project achieved all three objectives and demonstrated reliable operation over an extended period:

  • Continuous operation: One month of uninterrupted data gathering and socket control without errors
  • Real-time synchronisation: Changes in the iOS app reflected on the physical sockets within seconds
  • Data accuracy: Temperature readings tracked environmental changes accurately (21°C to 25°C range), humidity from 40% to 73%
  • Scalability: The architecture supported easy expansion with additional ZigBee sensors and RF sockets

Reflections

This project was my first experience building a complete IoT system from hardware to mobile app. The most valuable learning was understanding how different communication protocols can be integrated into a unified system, each chosen for its specific strengths: ZigBee for low-power sensor networks, RF for simple appliance control, and cloud APIs for mobile accessibility.

The RF code sniffing approach was particularly satisfying as it demonstrated practical problem-solving when documentation isn't available. Rather than being limited to expensive "smart" devices, I could integrate any RF-controlled appliance into the system.

Building the full stack (hardware, firmware, Python backend, iOS app, and cloud infrastructure) gave me an appreciation for how all these layers need to work together. It was a useful exercise in thinking about system boundaries and interfaces between components.