Unit 5: Bluetooth with NodeMCU

I. Orientation — Communication in a Smart IoT Device

A smart IoT device combines sensing, processing, communication, and actuation. In this unit, a NodeMCU development board exchanges commands or data through Bluetooth and communicates with local peripherals through I2C or SPI. The term NodeMCU commonly refers to an ESP8266-based board, which has Wi-Fi but no native Bluetooth; therefore, Bluetooth applications usually add a module such as the HC-05 or HC-06. ESP32-based NodeMCU-style boards may provide integrated Bluetooth.

• Core architecture: A complete system follows the path input → communication interface → NodeMCU → output.
  • Input may be a phone command, sensor reading, or voice converted into text.
  • Output may be an LED, relay, motor, buzzer, or LCD message.
• Bluetooth role: Bluetooth provides short-range wireless data exchange, commonly using a serial-style connection between a phone and an HC-05 module.
• Peripheral-bus role: I2C and SPI connect the controller to displays, sensors, memories, converters, and other integrated circuits.
• Logic levels: ESP8266 and ESP32 GPIO pins use 3.3 V logic; applying a 5 V signal directly to an input can damage the controller.
• Serial conventions: UART communication uses separate transmit and receive lines, with crossed connections: TX → RX and RX ← TX.
• Common software environment: Programs are generally written in the Arduino IDE using functions such as pinMode(), digitalWrite(), Serial.begin(), and Wire.begin().
• Protocol distinction:
  • Bluetooth is a wireless communication technology.
  • UART is often the wired link between NodeMCU and an external Bluetooth module.
  • I2C and SPI are short-distance wired protocols used mainly between chips on the same device.

II. Bluetooth Data Communication — Wireless Serial Control

A. data transfer through Bluetooth interface

Data transfer through a Bluetooth interface allows a phone, computer, or another controller to send and receive bytes wirelessly while the NodeMCU treats the Bluetooth module as a serial device.

• Typical hardware: The HC-05 supports Bluetooth Classic Serial Port Profile operation and exposes VCC, GND, TXD, RXD, STATE, and EN/KEY pins.
  • VCC powers the breakout board according to its rated input.
  • TXD sends data from the HC-05 to the NodeMCU.
  • RXD accepts data transmitted by the NodeMCU.
• Connection principle: Transmit and receive pins must be crossed.
  • HC-05 TXD → NodeMCU RX
  • NodeMCU TX → HC-05 RXD
  • GND → GND
  • A suitable divider or level shifter should protect the HC-05 RX input when required by the module.
• Transmission sequence: A Bluetooth terminal application converts entered characters into bytes, sends them over the radio link, and the HC-05 reproduces those bytes on its UART output.
• UART configuration: Both devices must use the same baud rate, often 9600 bit/s in normal HC-05 data mode. A typical frame contains one start bit, eight data bits, no parity, and one stop bit: 8-N-1.
• Command design: Simple systems may assign one byte to each operation.
  • Character '1' turns an LED on.
  • Character '0' turns it off.
  • A newline-terminated command such as "FAN_ON\n" is clearer for larger applications.
• Example program: The following ESP8266 sketch reads commands through a software UART and controls the built-in LED, which is commonly active-low.

#include <SoftwareSerial.h>

SoftwareSerial bluetooth(D5, D6); // RX, TX

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, HIGH);
  bluetooth.begin(9600);
}

void loop() {
  if (bluetooth.available()) {
    char command = bluetooth.read();

    if (command == '1')
      digitalWrite(LED_BUILTIN, LOW);
    else if (command == '0')
      digitalWrite(LED_BUILTIN, HIGH);
  }
}

• Bidirectional data: NodeMCU can acknowledge a command with bluetooth.println("LED ON"); or transmit sensor measurements such as TEMP:27.4.
• Reliability considerations: Programs should validate commands, define message boundaries, avoid long blocking delays, and limit buffer growth when malformed data arrives.
• Limitations: Bluetooth range, interference, pairing security, module compatibility, and UART pin conflicts must be considered. HC-05 modules generally do not provide Bluetooth Low Energy.

III. Voice-Based Control — Speech Converted into Bluetooth Commands

A. voice controlled Bluetooth device

A voice controlled Bluetooth device uses speech as the user input, but speech recognition normally occurs on the smartphone rather than inside the HC-05 module or NodeMCU.

• Processing chain: The complete control path is speech → phone recognition service → text/command → Bluetooth → NodeMCU → actuator.
• Functional roles:
  • The phone captures audio and recognizes a phrase such as “light on.”
  • The application maps that phrase to a compact command such as 'A'.
  • The HC-05 transfers 'A' through UART.
  • The NodeMCU activates the corresponding GPIO output.
• Command mapping: Distinct, deterministic commands reduce ambiguity.
  • "light on" maps to '1'.
  • "light off" maps to '0'.
  • "fan on" and "fan off" may map to 'F' and 'f'.
• Actuator interface: A GPIO pin must not directly power a mains appliance, motor, or high-current lamp. The design requires a transistor, MOSFET, motor driver, or optically isolated relay module with a correctly rated power supply.
• Program logic: The receiver compares the completed command with accepted values.

if (bluetooth.available()) {
  String command = bluetooth.readStringUntil('\n');
  command.trim();

  if (command == "LIGHT ON")
    digitalWrite(relayPin, HIGH);
  else if (command == "LIGHT OFF")
    digitalWrite(relayPin, LOW);
}

• Safety behavior: The controller should reject unknown phrases, initialize outputs to a safe state, and avoid changing an actuator until a complete valid command has arrived.
• Recognition limitations: Background noise, accent handling, network-dependent speech services, similar command phrases, and microphone quality affect recognition before Bluetooth transmission occurs.
• Security limitation: Pairing codes on basic HC-05 systems provide limited protection. Safety-critical or remotely exposed equipment requires stronger authentication and application-level authorization.

IV. Character Display Interface — LCD Using an I2C Backpack

A. liquid crystal display with I2C

A liquid crystal display with I2C combines a parallel character LCD, commonly based on the HD44780 controller, with an I/O expander such as the PCF8574 to reduce the required GPIO connections.

• Pin reduction: A direct LCD interface may require at least six control/data GPIO pins, whereas the I2C backpack usually requires only SDA and SCL, in addition to power and ground.
• Display organization: A 16 × 2 LCD contains 16 character positions on each of two rows; each position displays a character generated from the controller’s character memory.
• Typical ESP8266 wiring:
  • SDA → D2, commonly GPIO4.
  • SCL → D1, commonly GPIO5.
  • GND → GND.
  • Power must match the backpack, display, and logic-level requirements.
• I2C address: PCF8574 backpacks often use addresses such as 0x27 or 0x3F, but the actual address depends on the expander variant and address-jumper configuration.
• Software initialization: The library must be configured with the correct address and display dimensions.

#include <Wire.h>
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x27, 16, 2);

void setup() {
  Wire.begin(D2, D1);
  lcd.init();
  lcd.backlight();
  lcd.setCursor(0, 0);
  lcd.print("Bluetooth Ready");
}

void loop() {}

• Cursor coordinates: lcd.setCursor(column, row) uses zero-based positions; therefore, lcd.setCursor(3, 1) selects the fourth column of the second row.
• Practical faults: A blank display may result from an incorrect address, wrong wiring, missing common ground, unsuitable supply voltage, or an improperly adjusted contrast potentiometer.
• Display management: Updating only changed characters reduces flicker; repeatedly calling lcd.clear() inside a fast loop can make the display visibly unstable.

V. SPI Communication — High-Speed Synchronous Peripheral Bus

A. protocol of SPI

The protocol of SPI transfers data synchronously between one controller and one or more peripherals using a clock, separate transmit paths, and a device-select signal.

• Signal lines:
  • SCLK carries the controller-generated serial clock.
  • MOSI carries controller-to-peripheral data.
  • MISO carries peripheral-to-controller data.
  • CS or SS selects a particular peripheral, commonly using an active-low signal.
• Full-duplex operation: One bit can move in each direction on every clock pulse because MOSI and MISO are separate.
• Transaction sequence: The controller drives CS low, generates clock pulses while shifting data, and then returns CS high to end the transaction.
• Clock modes: SPI defines four combinations of clock polarity and phase: modes 0, 1, 2, and 3. The controller and peripheral must use the same mode.
• Transfer time example: Ignoring overhead, transferring 16 bits at 8 MHz requires:

t = N / f = 16 / 8,000,000 = 2 microseconds

• t is transfer time in seconds.
• N is the number of transferred bits.
• f is the SPI clock frequency in hertz.
  • Advantages: SPI supports high clock rates, simple framing through chip select, low protocol overhead, and simultaneous transmission and reception.
  • Limitations: It requires more wires than I2C, normally needs one chip-select line per peripheral, and has no universal addressing or acknowledgement mechanism.
  • Applications: Common SPI peripherals include SD cards, TFT displays, flash memory, radio transceivers, and high-speed analog-to-digital converters.

VI. I2C Communication — Addressed Two-Wire Peripheral Bus

A. protocol of I2C

The protocol of I2C transfers addressed data over two shared, open-drain lines: serial data (SDA) and serial clock (SCL).

• Electrical structure: SDA and SCL require pull-up resistors because connected devices normally pull the lines low or release them; they do not actively drive the lines high.
• Bus states:
  • A START condition occurs when SDA changes from high to low while SCL is high.
  • A STOP condition occurs when SDA changes from low to high while SCL is high.
• Address phase: The controller sends a device address followed by a read/write bit. Seven-bit addressing is most common; 0x27, for example, may identify an LCD backpack.
• Acknowledgement: After each eight-bit byte, the receiver uses a ninth clock pulse to send ACK by pulling SDA low. Leaving SDA high indicates NACK.
• Write transaction: A typical write follows START → address + write → ACK → register/data → ACK → STOP.
• Read transaction: A register read commonly writes the register address, issues a repeated START, sends the address with the read bit, receives data, and ends with NACK and STOP.
• Speed classes: Common operating rates include Standard-mode at 100 kbit/s and Fast-mode at 400 kbit/s; all devices and the electrical bus must support the selected rate.
• Address collision: Two peripherals with the same fixed address cannot normally share one bus unless address pins, an I2C multiplexer, or separate buses are used.
• Compared with SPI:
  1. I2C: Uses two shared signal wires, built-in addressing, and acknowledgement, making it efficient for several moderate-speed peripherals.
  2. SPI: Uses more signal wires and chip-select lines but generally provides higher throughput and full-duplex transfer.
• Limitations: Bus capacitance, pull-up resistance, cable length, voltage compatibility, and a device holding SDA low can prevent reliable communication. I2C is intended primarily for short connections within a device or circuit board.