An Ultra-Low Power Sticky Note Using E-Paper Display for the Internet of Things

Abstract

There are over 300 million smart homes worldwide and 60.4 million smart homes in the US, using devices like smart thermostats, smart plugs, smart door locks, etc. Yet in this age of smart and connected devices, we still use paper-based sticky notes on doors to display messages such as “Busy, do not disturb”, “In a Zoom meeting”, etc. In this project, a novel IoT-connected digital sticky note system was developed where the user can wirelessly send messages from a smartphone to a sticky note display. The sticky note displays can be hung on the doors of offices, hotels, homes, etc. The display could be updated with the user’s message sent from anywhere in the world. The key design challenge was to develop the display unit to consume as little power as possible to increase battery life. A prototype of the proposed system was developed comprising ultra-low-power sticky note display units consuming only 404 µA average current and having a battery life of more than six months, with a Wi-Fi-connected hub unit, an MQTT server, and a smartphone app for composing the message.

1. Introduction

When we are not available to meet, we hang messages such as “Do not disturb”, “In a meeting”, etc., on the outside of our doors. These messages are sometimes manually written on paper or sticky notes. This approach lacks a sense of aesthetics and goes against a greener environment. The goal and objective of this project was to develop an electronic sticky note system where the user could send messages from a smartphone to sticky note display units from any place in the world. The sticky note displays could be attached to the doors of offices, hotels, restaurants, homes, classrooms, etc. The overall operation of the proposed system is shown in Figure 1. The needs and significance of the proposed system are mentioned below:

• Our life is unpredictable. For instance, a professor may have an office hour at 10 a.m. but may not arrive at the office at that time due to a flat tire, traffic jam, or other emergency. Using the proposed IoT-connected sticky note system, the professor can send a message from the road to the door display unit such as “In a traffic jam, I will be in at 10:15 a.m.”. Thus, the students who physically come to meet the professor are informed of the updated time.
• Businesses such as restaurants, shops, medical offices, etc., hang neon signs on doors or windows to display “Open”, “Closed”, etc. After manufacturing, the designs of these signs cannot be changed. Using the proposed system, the user could display any message, such as “Opening at 8 a.m.”, “Closing at 6 p.m.”, “Closed for the weather”, etc., from any place in the world and customize the message using various styles depending on holidays and emergencies. Motivational quotes and special items for sale related to an occasion could be displayed easily using the smartphone. This will attract customers and may increase profit.
• In hotels, the tradition is to hang a tag on the door indicating if the room service can be performed. Using the proposed system, the customer could send customized messages to the door display with service instructions. Thus, room service could be done more efficiently without verbal instructions.
• There are commercially available Internet-connected digital noticeboards used for applications such as sports matches and advertising. However, these devices are not designed for low-power operations that can run on batteries for a long time or smart home environments. In contrast, the proposed sticky note display is a compact, ultra-low-power device that could be easily placed anywhere in a smart home and could run for more than six months on battery power—without requiring cumbersome wiring for the power supply.

The proposed system, as shown in Figure 1, is composed of ultra-low power sticky note display devices, a Wi-Fi-connected hub unit, and a smartphone app. The smartphone app has a settings menu to add hub and display devices and configure the hub’s Wi-Fi SSIDs and password using Bluetooth Low Energy (BLE). The app has a textbox for composing messages and a button for sending a message to the target sticky note display device. The message background color is white or black, and the font size can be selected from the app. Message Queuing Telemetry Transport (MQTT) [1] transmission protocol, designed for Internet of Things (IoT) applications, is used to send data to the hub unit—where the smartphone app is the publisher client, and the hub unit is the subscriber client. As soon as the smartphone app publishes the message, the MQTT broker sends the message to the subscriber hub through the Internet. The hub then broadcasts the message wirelessly using the Long Range (LoRa) transceiver [2]. The LoRa transceiver of the sticky note display device receives the message and then displays it if the message is targeted at that device. One hub unit could be placed anywhere in a building and connect wirelessly to several sticky note displays. The hub unit is plugged directly into the wall AC power outlet.

The key contributions of this paper are as follows: (a) an IoT-connected sticky note display system is proposed, consisting of e-paper-based sticky note displays, a hub unit, an MQTT server, and a smartphone application; (b) a custom low-power communication protocol is implemented—extending the battery life of the display devices to over six months. The proposed system has been developed and successfully tested.

2. Related Works

There are several works available in the literature on Internet-connected digital noticeboards. The work in [3] uses a Raspberry Pi 2 Model B (Raspberry Pi Ltd., Cambridge, UK) a NodeMCU, and a P10 LED display to show messages sent from a smartphone app. The smartphone app transmits messages to the App Cloud, which the Raspberry Pi connects to and then forwards to the LED display via NodeMCU. However, the display resolution is limited to only 32 × 16 pixels. The current consumption of the Raspberry Pi exceeds 240 mA when using Wi-Fi [4], the NodeMCU consumes approximately 70 mA [5], and the display can draw up to 3000 mA (15 watts) [6], resulting in a total current consumption of more than 3310 mA. With a 2000 mAh capacity battery, the device can only run for 36 min.

The paper in [7] focuses on the development of a wireless noticeboard system capable of displaying messages sent directly from a user’s phone. The system hardware utilizes an Arduino Mega 2560 MCU, incorporating both Bluetooth and Wi-Fi for data transmission, with the ESP8266 Wi-Fi module and the HC-05 Bluetooth module. Messages can be transmitted via a Bluetooth-enabled application for Bluetooth communication or the Telegram app for Wi-Fi-based transmission. The messages are displayed on the receiver end using a MAX7219 LED dot matrix display, which consists of four serially connected 8 × 8 dot matrices, resulting in a resolution of 32 × 8 pixels. No low-power design is implemented in this work. Assuming the average current consumption as 70 mA for the Arduino Mega 2560 MCU [8], 70 mA for the ESP8266 Wi-Fi module [9], 20 mA for the HC-05 Bluetooth module [10], and 320 mA for the LED dot matrix [7], the total power consumption of the hardware is approximately 480 mA. Thus, it can only run for 4 h using a 2000 mAh battery.

The study in [11] discusses the development of a smart Wi-Fi bulletin board. A mobile app designed using the Kodular platform allows users to send messages to the Firebase cloud. The display system, utilizing an ESP32 microcontroller, connects to Wi-Fi, periodically checks for new messages from the Firebase cloud, and displays them on a 64 × 8 LED dot matrix. When connected to Wi-Fi, the ESP32 can consume over 200 mA of current [12]. With the LED dot matrix consuming approximately 320 mA [7], the total power consumption of the hardware is estimated to be around 520 mA with a battery life of 3.8 h when run by a 2000 mAh battery.

The authors in [13] developed a wireless noticeboard capable of displaying messages sent from a user’s mobile application via the Global System for Mobile Communications (GSM) network. The system integrates an Arduino UNO with a GSM modem and an LED dot matrix display. The GSM modem’s peak current can reach up to 2A during data transmission. However, assuming an average current of 100 mA for the GSM modem in data mode [14], 50 mA for the Arduino UNO [15], and 320 mA for the LED dot matrix [7], the total power consumption of the hardware is estimated to be approximately 470 mA—having a battery life of 4.2 h.

Compared with these works, our proposed system includes a 400 × 300 high-resolution e-paper display capable of retaining messages even in the absence of power, distinguishing it from existing solutions. It incorporates Wi-Fi provisioning and device management features, allowing users to add, edit, and remove hubs and displays via a smartphone application. To optimize energy efficiency, a custom low-power communication protocol is implemented between the hub and the display device, along with battery level monitoring and a charge indicator. The system’s minimal power consumption extends battery life beyond six months, and it ensures long-term usability without frequent maintenance. Its compact form factor and prolonged battery life make it well-suited for deployment as a digital sticky note device, which can be easily affixed to various surfaces such as doors and shelves, eliminating the need for wired power connections or frequent recharging.

3. Materials and Methods

The key design challenge was to make the sticky note displays consume as little power as possible. The display device is powered by a rechargeable battery instead of a DC power adaptor because powering using wire on the door might look messy and cumbersome. To increase battery life and reduce the recharging frequency, a custom low-power LoRa transmission protocol was developed and implemented when transmitting data from the hub to the display unit. The different components of the system—the ultra-low power sticky note display device, the hub, the MQTT broker server, and the smartphone app—are briefly described below.

3.1. Ultra-Low Power Sticky Note Display Device

The hardware and firmware of the device are described below.

3.1.1. Hardware

The block diagram of the hardware unit of the sticky note display device is shown in Figure 2.

The LoRa32u4 II development board [16], integrating an ATmega32u4 microcontroller (Microchip Technology, Tempe, AZ, USA) [17] and an HPD13 915MHz LoRa transceiver module [18], serves as the core processing and wireless communication unit within the display device. The ATmega32u4 is a low-power, 8-bit AVR^® RISC-based microcontroller that provides 32 kB of self-programming flash memory, 2.5 kB of SRAM, 12 analog-to-digital converter (ADC) channels, general-purpose input/output (GPIO) ports, and support for communication protocols such as SPI and I2C, among other peripherals. Its six sleep modes make it particularly suited for applications requiring ultra-low power consumption to maximize battery longevity.

The LoRa transceiver is connected to the microcontroller via SPI and offers a transmit power of up to +20 dBm, a receiving sensitivity as low as −139 dBm, and a maximum data rate of 300 kbps. For wireless communication, a 915 MHz frequency external antenna with a 2 dBi gain is attached to the board. In urban environments—where increased signal attenuation is caused by obstacles such as walls, structures, and interference from other devices—the maximum communication range of the LoRa link is approximately 200 m [19].

Additionally, the board includes an ultra-low quiescent current (IQ) low-dropout (LDO) voltage regulator capable of converting a 3.7-volt battery input to a stable 3.3-volt output with a peak current of 500 mA. To facilitate battery monitoring, a voltage divider circuit consisting of two 100 kΩ resistors in series is implemented, with its midpoint connected to an analog-to-digital converter (ADC) pin of the microcontroller. The voltage divider’s power is controlled via a GPIO pin of the microcontroller through a transistor switch, allowing the circuit to be deactivated to conserve energy. A 3.7 V Li-Po rechargeable battery [20] with a capacity of 2000 mAh is connected to the battery terminal of the development board. The development board incorporates a compact, single-cell, fully integrated charge management controller [21] optimized for Li-Ion and Li-Polymer batteries. It is powered from the USB port of the development board and an external USB charger can be used for recharging the battery. An LED is interfaced with a GPIO pin for monitoring the charging state, which turns on when the battery is charging and turns off when the battery is charged. The display device includes a heartbeat LED for indicating active program execution and a push-button switch—termed the Prog button—which enables reprogramming of the microcontroller after USB functionality has been disabled to save power.

The LoRa32u4 II development board is interfaced with a 400 × 300 resolution, 4.2-inch e-paper display module [22] using the SPI communication protocol and some additional GPIO pins. An e-paper display, also known as an electronic ink (E-Ink) display, works by using tiny microcapsules or particles suspended in a liquid within a thin film. These microcapsules contain positively and negatively charged pigments that move when an electric field is applied. By selectively applying voltage to different areas of the screen, the display can create high-contrast images that remain visible without continuous power. Unlike traditional LCDs, e-paper only consumes energy when updating content, making it highly power-efficient. This display retains the last displayed content for extended periods—several months to years—even when power is removed. To avoid continuous current consumption, the supply voltage of the module is generated from a GPIO pin of the microcontroller which will only be made high when the screen refreshes. The power consumption of the e-paper display during refresh is 26.4 mW [22]. With a supply voltage of 3.3 V, the current required for the e-paper during refresh is 8 mA. The GPIO pin of the ATmega32u4 can safely supply more than 8 mA current [17,23], making it possible to use a GPIO pin as the power supply without the need for additional control circuitry. The display supports black-and-white colors and is readable from a wide viewing angle. These characteristics make it particularly well-suited for applications where energy efficiency, long-term visibility, and a natural, paper-like reading experience are priorities.

3.1.2. Firmware

The flowchart of the sticky note display device firmware is shown in Figure 3, and the different functions are described below.

Initialize: At first, it initializes the GPIO pins where the heartbeat LED pin and e-paper display power control pin are configured as outputs, and their values are set to low to reduce power consumption. The Prog pin is configured as a falling edge interrupt. To reduce power consumption, the voltage divider for battery monitoring, the ADC, and the USB hardware of the microcontroller are disabled. As USB is disabled to reduce power consumption, the MCU cannot be reprogrammed using the USB port for debugging. To address this, a button referred to as the Prog button is used as an interrupt source. When the button is pressed, an interrupt service routine (ISR) is triggered, executing code to re-enable the USB hardware, allowing the device to be reprogrammed via USB. The LoRa transceiver is initialized to work at a 915 MHz band. It then shows its unique display unit ID on the e-paper display so that the user can read the ID and use it to configure the display in the smartphone app.

Low-power sleep mode: After initialization, the MCU and the LoRa transceiver go to low-power sleep mode and wake up after an 8 s interval. The MCU consumes the lowest power in this power-down state, and it is implemented using the low-power library [24], which shuts down power from the ADCs, timers, and brown-out detector (BOD).

Check battery: When the MCU wakes up after 8 s, it blinks the heartbeat LED for 30 ms and checks the battery. The battery monitoring function periodically checks the voltage at intervals controlled by a counter, which increments with each loop iteration. Once the counter reaches a predefined limit of 60 × 60 ÷ 8 = 450, representing approximately 1 h based on the system’s sleep duration of 8 s, the function activates the voltage divider circuit and the ADC to measure the battery voltage. The ADC is configured to use the internal 1.1 v reference so that the ADC measurement is not affected when the battery voltage goes down. We experimented to find the minimum required voltage for operation by varying the supply voltage from a DC power supply. We found that the microcontroller and the e-paper display can work having a minimum voltage of 2.8 volts, and its corresponding ADC value is defined as the safe threshold. If the ADC value is below the defined safe threshold, a message prompting the user to recharge the battery is displayed on the e-paper screen, and the charging circuit is activated while the system waits for the battery to charge. While the battery is charging, the battery voltage is monitored using ADC, and the charging LED is turned on as long as the battery is charging. If the battery voltage is adequate, the charging and monitoring circuits are turned off to conserve power, and the counter is reset, deferring the next check for another cycle.

Custom LoRa protocol for low power consumption: When the user sends a message from a smartphone, the hub unit receives it and then sends the data to the sticky note display unit through the LoRa transceiver. To send and receive LoRa messages, the microcontroller uses the BSFrance LoRa library for AVR boards [25]. To receive the message in the display unit instantly, the LoRa transceiver in the display unit must always be in the receive mode. The receive mode, however, consumes a significant amount of current: approximately 15 mA. To reduce power consumption in the display unit, a custom communication protocol is implemented that lowers power consumption by compromising data latency. The protocol involves handshaking between the hub unit and the display unit, as shown in Figure 4. In the flowchart in Figure 4, the hub unit steps are executed after the user message arrives in the hub unit, and the display unit steps are executed every after 8 s of sleep, as shown in the custom protocol diamond box in Figure 3.

In the protocol, the hub first continuously broadcasts a short knock frame, and after receiving a correct acknowledgment from the display unit, the hub then sends the data frame. The frames are shown in Figure 5, where m = message length, n = data frame length = m + 2, nh = Higher byte of n, and nl = Lower byte of n. The knock frame consists of 4 bytes: knock frame header = 1, target display unit ID, lower byte of data frame length, and higher byte of data frame length. The number of bytes in the data frame depends on the size of the message. The data frame bytes are data frame header = 2, isBackgroundWhite using 1 bit and font size using 7 bits, and the message characters bytes.

After every 8 s of sleep mode, the LoRa transceiver in the display unit is set to receive mode for a time window of 80 ms. Opening an 80 ms receive window instead of continuously being in receive mode reduces a significant amount of power consumption of the LoRa transceiver by compromising a maximum of 8 s of data latency. When the display unit receives the knock frame in the receive time window, it parses the bytes and checks whether the frame header is a knock frame = 1 and whether the target display unit ID matches its ID. If it is a knock frame and the knock is targeted for this particular display device, it then sends an acknowledgment byte—which is its display unit ID—to the hub unit. It then goes to receive mode for a threshold time of 10 s until it receives the data frame from the hub unit. The length of the data frame was sent a priori in the knock frame, and it allocates memory dynamically to store the data frame. After receiving the data frame, it parses the data and verifies the header to be the data frame = 2. It then calls the function to show the message on the e-paper display with background color, font size, and the message string as function parameters.

Update e-paper display: To display the message on the e-paper, the function first makes the e-paper display power control GPIO pin high and then initializes the display [26]. Then it calculates the total number of rows in the message, TRM, by counting the new line characters. It then allocates memory in the microcontroller to store one row of text. The memory buffer is dynamically allocated for one row at a time based on font height, minimizing RAM usage on the ATmega32u4 microcontroller. In the e-paper display, each pixel is represented by 1 bit; thus 1 byte can store 8 pixels. The buffer memory required to store one row of text is DISPLAY_WIDTH × FONT_HEIGHT ÷ 8 bytes, where DISPLAY_WIDTH is 400 and FONT_HEIGHT could be 8, 12, 16, 20, or 24. The total number of rows on the e-paper display is calculated as $TR=\left|{\displaystyle \frac{\mathrm{D}\mathrm{I}\mathrm{S}\mathrm{P}\mathrm{L}\mathrm{A}\mathrm{Y}\_\mathrm{H}\mathrm{E}\mathrm{I}\mathrm{G}\mathrm{H}\mathrm{T}}{\mathrm{F}\mathrm{O}\mathrm{N}\mathrm{T}\_\mathrm{H}\mathrm{E}\mathrm{I}\mathrm{G}\mathrm{H}\mathrm{T}}}\right|$, where DISPLAY_HEIGHT is 300. The e-paper display rendering process iterates through each displayable TR number of lines, filling the buffer with the specified background color at the start of each iteration. For each TRM number of lines containing text, a single line of the message is extracted and drawn onto the buffer using the specified font size and color. The buffer content is then transferred to the e-paper display, with partial refreshes used for intermediate lines and a full refresh performed on the final line [26]. After processing each line, the vertical coordinate of the buffer location is incremented by adding the FONT_HEIGHT to position the next line appropriately. This approach ensures efficient memory usage by handling one line at a time, making it suitable for microcontrollers with limited RAM. Finally, the e-paper display power control GPIO pin is set to low to turn off the display power consumption. The program then goes for the low-power sleep mode for 8 s, as shown in Figure 3, and the cycle repeats.

3.2. The Hub

The hub receives the message from the smartphone using the Internet and then broadcasts the message to the nearby sticky note display devices using LoRa. One hub can be used for several sticky note display devices, and it can be attached directly to the AC wall outlet. The hardware and firmware of the hub are described below.

3.2.1. Hardware

The block diagram of the hub hardware unit is shown in Figure 6. The ESP32-S3-Zero [27] microcontroller is used as the main processing unit, which includes Xtensa^® 32-bit LX7 dual-core processor running at 240 MHz speed, 2.4 GHz Wi-Fi (802.11 b/g/n), Bluetooth^® 5 (LE), built-in 512 KB of SRAM and 384 KB ROM, onboard 4 MB Flash memory and 2 MB PSRAM, UART, GPIO, and ceramic antenna, etc. A heartbeat LED, to visually indicate the normal operation of this microcontroller, is interfaced with a GPIO pin. This microcontroller’s BLE is used for Wi-Fi provisioning, and its Wi-Fi is used to receive the user’s message from the Internet.

To broadcast the message to the nearby sticky note display devices using LoRa, it is interfaced with another microcontroller—the LoRa32u4 II development board [16] having an HPD13 915 MHz LoRa transceiver module [18]—using UART. The Tx pin of ESP32-S3-Zero is connected with the Rx pin of the LoRa32u4 II microcontroller to transmit the message using Serial protocol from one microcontroller to the other. A GPIO pin, referred to as busy, is connected between the microcontrollers so that the ESP32-S3-Zero knows when the LoRa32u4 II microcontroller is busy in LoRa transmission. An LED, referred to as Busy, is also interfaced with the LoRa32u4 II microcontroller for visual indication of LoRa transmission. For the power supply, a 100–240v AC to 5v DC converter module [28] is used. It can provide a maximum of 600 mA current and 3-watt power. A casing with a wall-outlet AC plug [29] is used to hold the electronics.

3.2.2. Hub Firmware in ESP32-S3-Zero Microcontroller

The flowchart of the hub firmware implemented in the ESP32-S3-Zero microcontroller is shown in Figure 7. The different functions of the flow charts are described below.

Initialize: It initializes the GPIO pin for the LED, allocates 1 kB in the flash memory to use as EEPROM, and initializes BLE [30]. The firmware then initializes the MQTT client with the broker’s IP address, port, username, and password and configures settings such as the keep-alive interval, clean session, and network timeout [31]. The UART is then initialized to enable serial communication between the ESP32-S3-Zero and LoRa32u4 II microcontrollers.

Provision Wi-Fi: The Wi-Fi provisioning process uses BLE to transfer the required Wi-Fi credentials from a smartphone app to the ESP32-S3-Zero microcontroller. The process begins when the hub detects that it is not connected to the Wi-Fi, either during the initial boot or if a disconnection occurs. Upon boot, the device reads the stored Wi-Fi credentials—SSID and password—from the EEPROM. If these credentials fail to establish a connection after multiple retries, the device enters BLE advertising mode, allowing a smartphone app to discover and connect to it. BLE advertising broadcasts the device’s unique name (i.e., SDD_HUB) and service UUID. During advertising, the heartbeat LED blinks at a 1 Hz frequency, visually indicating that the device is actively seeking Wi-Fi credentials from a BLE. Once a BLE connection is established, the device halts advertising, maintains a steady LED, and waits for commands from the smartphone app to handle provisioning. Upon receiving a connection request command, the firmware extracts the SSID and password from the BLE payload using a delimiter-based parsing method. The extracted credentials are used to initiate a connection to the requested Wi-Fi network using the WPA2-PSK protocol [32]. If the connection is successful, a success response containing the connected SSID and the microcontroller’s Wi-Fi MAC address is sent back to the smartphone via BLE, and the credentials are stored in EEPROM for persistent usage. If the Wi-Fi connection fails after multiple retries, a failure response is sent to notify the smartphone app, prompting the user to provide updated credentials. After successful Wi-Fi provisioning, the LED is turned off, signaling that the device is connected to the Internet.

Connect to MQTT broker: The MQTT connection process begins once the device successfully connects to Wi-Fi. The firmware attempts to connect to the MQTT broker, retrying a specified number of times with delays between attempts. In the event of repeated failures, the device restarts to recover connectivity. Upon successfully connecting to the broker, the device subscribes to a topic SDD_HUB/<DeviceID>, where DeviceID is the unique MAC address of the microcontroller’s Wi-Fi. This allows the device to receive messages directed to its unique topic from other devices or applications.

Loop: In the main execution loop, the hub continuously checks its connection to the MQTT broker and Wi-Fi, re-establishing them if necessary. The heartbeat LED blinks periodically—approximately every 8 s—during normal operation to signal activity and readiness. When an MQTT message is received, a callback function reads the incoming payload and stores it in a first-in-first-out (FIFO) circular buffer, ensuring data are queued for subsequent processing. The payload contains the target display ID, background color (0 for black and 1 for white), font size, and the message string. Each piece of data in the payload is separated by the delimiter, ASCII 30, which is a non-printable character. The loop monitors the hardware pin—referred to as Busy—to determine if the connected microcontroller is ready to receive data. If the FIFO contains data and the Busy pin is not asserted, the oldest item in the FIFO is retrieved and transmitted to the other microcontroller over the hardware serial interface. A non-printable delimiter, ASCII 29, is appended to the data to facilitate parsing by the receiving microcontroller.

3.2.3. Hub Firmware in LoRa32u4 II Microcontroller

The flowchart of the hub firmware implemented in the LoRa32u4 II microcontroller is shown in Figure 8. The different functions of the flow charts are described below.

Initialize: It begins by setting the busy pin and the busy LED as output and high, ensuring that the system can manage hardware synchronization and indicate its status visually. The serial port is initialized for hardware communication, enabling serial communication between the microcontrollers. The LoRa module is configured to communicate at 915 MHz. A callback function is registered to handle incoming LoRa messages. Once all initializations are complete, the busy pin and LED are set to low, signaling that the system is ready to receive data from the ESP32-S3-Zero microcontroller.

Loop: The loop function continuously monitors the hardware serial port for incoming data from the ESP32-S3-Zero microcontroller. When serial data are available, it reads the string up to the ASCII 29 delimiter. If the received string is in the correct format, it is transmitted via LoRa to the target sticky note display unit. This involves calling the function responsible for the low-power LoRa transmission protocol.

Transmitting by custom low-power LoRa transmission protocol: The function first sets the busy pin and the busy LED as high to indicate its busy status. Then, it prepares the knock frame and the data frame by parsing the input string and follows the two-step protocol— knocking and data transmission—as shown in Figure 4 and discussed in Section 3.1.2 in Custom LoRa protocol for low power consumption. In the knocking stage of the protocol, it repetitively sends the knock frame using the LoRa transceiver in a loop for a threshold time of 30 s until it receives an acknowledgment from the display device. In the loop, the LoRa sends the knock frame in transmit mode and then waits for 35 ms in the receive mode alternately [25]. The 30 s timeout will give at least three chances to receive the knock frame after each 8 s sleep mode of the display device. The timeout will also cause the hub unit to come out of a hang situation if the display device does not respond due to a low battery or if it is out of range. If the acknowledgment arrives in the 35 ms window, an ISR is called. In the ISR, if the acknowledgment byte matches the requested display ID of the knock frame, it then sets an acknowledgment receive flag to true and exits the loop. Then it waits for 100 ms so the display device gets time to stabilize in the receive mode. Then in the transmission stage of the protocol, the hub unit goes to transmit mode and sends the data frame to the display unit. The transmission uses dynamically allocated memory to handle varying message sizes, ensuring efficient utilization of the microcontroller’s limited resources. After transmission, the LoRa module is placed in sleep mode to conserve power, and the busy indicator pin and LED are set to low to signal the completion of the process.

3.3. MQTT Broker Server

A secure MQTT transmission protocol [1], specifically designed for Internet of Things (IoT) applications, is used to transfer data from the smartphone app to the hub unit over the Internet. This protocol employs a lightweight publish/subscribe messaging model, wherein the transmitting client publishes messages to a specific topic on the broker server, and the server forwards these messages to subscribed receiving clients.

For this project, Mosquitto [33] is implemented as the MQTT broker on a Windows computer. To enhance security, username and password authentication are configured, ensuring access is restricted to authorized users. Password management is facilitated using the Mosquitto password utility [34], which stores passwords in a hashed format for improved security. Hashing algorithms, such as SHA512, SHA256, and PBKDF2, ensure that stored passwords cannot be easily reversed, even if the password file is compromised, as these algorithms are designed to be computationally irreversible.

The host computer requires a fixed address and port to enable public access to the MQTT broker server. Since the private IP of the host computer is dynamically assigned by the router’s DHCP server and may change, it is configured as a static IP. Port forwarding is set up on the router [35] to redirect incoming Internet traffic to the MQTT broker server, and the listener port is opened in the Windows Firewall [36]. Additionally, a dynamic domain name system (DDNS) service, No-IP [37], is used to assign a user-friendly name to the router’s public IP. Although the public IP, provided by the ISP, changes infrequently, Dynamic DNS Update Client software [38] is installed on the host computer to monitor for changes and automatically update the DNS at No-IP to ensure consistent access to the MQTT broker.

3.4. Smartphone App

The smartphone app was developed for the Android platform. The app is used to configure the hub and the display units and send messages to the target display device. The different functions of the app are described below:

3.4.1. Configuring Hub

The app contains a hub settings menu from which the list of hubs can be viewed and hubs can be added, edited, and deleted. To add a hub, the app first scans available 2.4 GHz Wi-Fi networks [39] and populates them in a dropdown combo box. The user then enters the hub nickname, selects the Wi-Fi SSID from the combo box to which the hub should connect, provides the Wi-Fi password, and presses a button. The app then searches for BLE devices [40] that are advertising nearby and establishes a BLE connection with the hub device having the name SDD_HUB. Once a BLE connection is established, it then sends a Wi-Fi connection request command—containing Wi-Fi credentials—to the hub by writing on BLE characteristics. The hub attempts to connect to the specified network, and upon success, the app receives the hub’s MAC address and stores it in a local file along with the hub name. The MAC serves as the unique hub ID. Using GUI, an existing hub name can be edited while retaining its ID. The hub can be deleted using GUI, and deleting a hub removes its entry from the stored list. The app dynamically saves and updates the displayed list of hubs after each add, edit, or delete action.

3.4.2. Configuring the Sticky Note Display

The app contains a display settings menu from which the list of displays can be viewed and added, edited, and deleted. To add a display, the user provides a nickname for the display, enters the display unit ID that is shown on the e-paper after the display device is booted, and then assigns the display unit a hub by selecting it from a combo box populated with the list of all hubs. For editing, users can modify the display name or reassign it to a different hub by choosing from the available hub options. Deleting a display removes its entry from the stored list, similar to hub management, and updates the display list dynamically to reflect the changes.

3.4.3. Composing and Sending Messages

The app facilitates message composition and delivery to displays through the MQTT protocol. Users begin by selecting a target display from a dropdown menu populated with the list of displays. Once a display is selected, the app determines its associated hub using stored mappings and constructs the MQTT topic in the format SDD_HUB/<HubID>, where <HubID> corresponds to the unique identifier of the hub connected to the selected display. Users then configure additional message parameters, such as font size and background color, and then write message text.

When the send button is pressed, the app makes the MQTT message content that includes the display ID, background color, font size, and text, with each data point separated by a non-printable delimiter of ASCII 30. Using the stored MQTT credentials, the app makes a secure connection to the broker and publishes the message to the SDD_HUB/<HubID> topic [41]. Upon successful transmission, confirmation is displayed to the user while any connectivity issues are reported.

4. Results

4.1. Prototype Development and Testing

A prototype of the proposed sticky note display system consisting of three sticky note displays, two hubs, a server running the MQTT broker, and a smartphone app was developed and tested successfully. Photographs of the sticky note display and hub hardware, where the circuit components are soldered onto PCB prototype boards, are shown in Figure 9 and Figure 10, respectively.

The three sticky note displays and the two hub nodes were placed in different locations of an approximately 2000 square foot, three-storied house. The MQTT broker server, as described in Section 3.3, was running on an Internet-connected laptop computer. Using the smartphone app, hub and display units were successfully added as described in Section 3.4.1 and Section 3.4.2, respectively. Then, smartphone messages were sent from the house, using different fonts and background colors, to different target displays, as described in Section 3.4.3. Also, messages were sent far away from the hub unit—for instance, 11 km away—where the smartphone was using cellular Internet. In all of the tests, the messages were successfully sent and displayed on the target sticky note displays with the expected text formatting. Some screenshots of the smartphone app and messages shown on the displays are shown in Figure 11 and Figure 12, respectively.

The latency (i.e., the time it took from clicking the send button on the smartphone app to appear the message on the e-paper display) was measured using a stopwatch. The average latency of 15 tests was 13.92 s. This latency is mainly caused by the maximum 8 s delay of the custom low-power protocol and the 5 s refresh time of the e-paper display [22].

4.2. Current Consumption of the Sticky Note Display

The current consumption of the sticky note display device was measured using the Keysight N6705C DC Power Analyzer [42], equipped with the N6781A Source/Measure Unit (SMU) module [43]. The SMU module was configured as a 3.7 V battery emulator, serving as the power supply for the device.

In idle mode, the sticky note display device operates in a low-power sleep state for approximately 8 s, and then the LoRa transceiver enters receive mode for about 80 ms, as described in Section 3.1.2. This cycle then repeats. To determine the device’s average current consumption in idle mode, current data were logged for 30 s at a 1 ms sampling rate. Figure 13a presents a screenshot of the logged data. During sleep mode, the device consumes approximately 0.11–0.12 mA. When the receive window opens, the current peaks at around 24 mA. Measurement cursors, m1 and m2, were placed to capture two complete 8 s cycles, including the peak currents. The average current over this period was found to be 0.40 mA.

When a message arrives, the display device receives it and updates the e-paper screen, as described in Section 3.1.2. To measure the average current consumption during message reception, current data were logged for 1 min while a message was sent to the device from a smartphone during the logging period. The current consumption during message reception is shown between the markers in Figure 13b. Marker m1 indicates the moment the message is received, while marker m2 marks when the MCU returns to sleep mode after displaying the message on the e-paper. The average current consumption during this 12 s period is approximately 11 mA. It is important to note that messages are expected to arrive only a few times per day, and for the majority of the time, the device’s average current consumption will remain at 0.40 mA.

Let us assume the display device receives three messages a day. In one day, which has 24 × 60 × 60 = 86,400 s, the average current is 0.40 mA for 86,400 − 3 × 12 = 86,364 s, and the average current is 11 mA for the remaining 3 × 12 = 36 s. Thus, the average current consumption for one day is (0.4 × 86,364 + 11 × 36) ÷ 86,400 = 0.4044 mA. Thus, a 2000 mAh battery can power the device for 2000 ÷ 0.4044 = 4945.6 h, which is more than six months. The battery will need to be recharged only twice a year.

In

Table 1. Performance comparison without and with the proposed low-power protocol.

Performance	Without Low-Power Protocol	With Low-Power Protocol
Avg. current consumption (mA)	15	0.4044
Battery life (days)	6	206

, the performance of the display device is compared without and with the proposed custom low-power protocol, as discussed in Section 3.1.2 and Figure 4. If the custom protocol was not used, then the device will need to be in LoRa receive mode all the time which would consume 15 mA current. Opening an 80 ms receive window after an 8 s sleep, instead of continuously being in receive mode, reduces around 97.30% current consumption by compromising a maximum of 8 s of delay from the hub to the display unit. Using the proposed protocol, battery life is increased by 37 times.

4.3. Comparison with Other Works

Table 2. Comparison with other works.

	Kurian et al. [3]	Jha et al. [7]	Gundavarapu et al. [11]	Surendiran et al. [13]	Proposed
Processing MCUs	Raspberry Pi 2 and NodeMCU	Arduino Mega 2560	ESP32	ATmega328	ESP32-S3-Zero and LoRa32u4 II
Wireless connectivity	Wi-Fi	Wi-Fi and Bluetooth	Wi-Fi	GSM	Wi-Fi and LoRa
Internet access	App cloud	Telegram app	Firebase cloud	-	MQTT
Display hardware	P10 LED display	MAX7219 LED dot matrix	LED dot matrix	LED dot matrix	e-paper
Display retains image after power off	No	No	No	No	Yes
Display resolution	32 × 16	32 × 8	64 × 8	32 × 16	400 × 300
Wi-Fi provisioning using smartphone	No	No	No	No	Yes, using BLE
Device management using smartphone	No	No	No	No	Yes
Low-power firmware design	No	No	No	No	Yes
Battery level check	No	No	No	No	Yes
Current consumption (mA)	3310	480	520	470	0.4044
Battery life (hours) 1	0.6	4	3.8	4.2	4945.6

¹ when running using a 2000 mAh battery.

presents a comparison of the proposed work with other related works. Compared to the others, the proposed system has the highest display resolution on an e-paper screen, with the ability to retain messages even when power is removed. It includes Wi-Fi provisioning and device management functionalities—such as adding, editing, and deleting hubs and displays—via smartphone. Additionally, it implements a custom low-power protocol for communication between the hub and display device, as well as battery level monitoring with a charge indicator. The system’s ultra-low current consumption enables a battery life of over six months. Its compact size and extended battery life make it ideal for use as a digital sticky note device, which can be conveniently attached to surfaces like doors, shelves, and more without the hassle of cumbersome power supply wires or frequent recharging.

5. Discussion

One drawback of e-paper displays is their inherently slow refresh rate. Unlike traditional LCD or LED displays, e-paper technology relies on the physical movement of particles to form an image, a process that takes considerable time to complete. For instance, the e-paper display [22] used in this project takes 5 s to refresh. The refresh time depends on the color and resolution of the display model. This limitation makes the e-paper displays more suitable for static or low-frequency update use cases, such as digital signage, eBooks, or battery-powered IoT devices, rather than scenarios requiring high refresh rates. Using an e-paper display for a sticky note application is suitable due to its low power consumption, and the high refresh rate is not a critical requirement in this context.

The library for the e-paper display [26] includes Courier New font in sizes 8, 12, 16, 20, and 24. It is possible to make custom fonts of different sizes using a Python version 3 program. Creating custom fonts for embedded systems involves several key steps. First, a fixed-width font file—such as Liberation Mono, DejaVu Sans Mono, Lucida Console—is selected along with the desired font size. Each character is rendered onto a blank image canvas. The pixel data are then extracted from the image to form a glyph representation, where each pixel’s color determines the character in the glyph (i.e., white as “.” and black as “#”). The glyph is processed row-by-row to generate a hexadecimal table where “.” is bit 0 and “#” is bit 1, with each byte representing eight pixels. This table is structured as an array that can be stored in the flash memory of a microcontroller. However, larger font sizes, such as 48, 60, or 72, require significantly more flash memory to store the font data in the MCU. For instance, storing the characters from ASCII 32 to ASCII 126, having a font size of H×W = 60 × 40 pixels, will take around 28 kB of flash memory. Additionally, more RAM is needed during runtime to buffer the glyph data, which are transferred to the e-paper display’s RAM for rendering. This can be a limiting factor for the ATmega32u4 MCU having constrained memory resources. To accommodate future requirements for a larger and broader selection of fonts, we plan to use MCUs with higher flash and RAM capacities.

After initialization, the MCU and LoRa transceiver enter low-power sleep mode and wake up at 8 s intervals. This length interval determines a trade-off between message latency and power consumption. Lower intervals will improve latency but will increase power consumption. The ATmega32u4 microcontroller utilizes the Watchdog Timer (WDT) as a wake-up source during sleep modes, offering a selectable timeout period ranging from 16 ms to 8 s 17]. The low-power library [24] thus supports a maximum of 8 s of sleep. Beyond 8 s, there is no built-in hardware timer in the ATmega32u4 that can trigger a wake-up without an external interrupt. For this reason, the 8 s duration was selected as a design choice that balances latency and power.

In the custom protocol, two frames—a knock frame and a data frame—are sent sequentially instead of transmitting a single data frame. The knock frame, shown in Figure 5, is a small, fixed 4-byte frame consisting of a knock frame header set to 1, the target display unit ID, the lower byte of the data frame length, and the higher byte of the data frame length. To receive the knock frame, the sticky note display unit opens a fixed 80 ms RX time window every 8 s and checks the incoming LoRa packet’s data size. The 80 ms window is enough to read the 4 bytes. It only processes the packet if its length is exactly 4 bytes. Once the knock frame is received within the fixed RX window, the device extracts the data frame length from the last two bytes of the knock frame. This allows the MCU to determine the expected data frame size and read the exact number of bytes from the LoRa packet. The number of bytes in the data frame depends on the user-composed message size, and its length is unknown unless a knock frame is sent beforehand. If the data frame is sent without a knock frame, the LoRa RX window would need to be significantly longer than 80 ms to accommodate the reading of the maximum possible characters, resulting in higher power consumption.

Internet and LoRa network conditions can impact the proposed system’s performance. The message coming from the smartphone to the hub is transmitted using MQTT. Depending on different network conditions, the MQTT broker may take from 10 ms to 100 ms to send the notification [44]. The hub is powered by an AC wall outlet, and the Internet condition does not have any effect on the sticky note display’s battery life. The sticky note display device opens an 80 ms RX window every 8 s to read the knock frame, and its power consumption mainly depends on this repeated event. The hub repeatedly broadcasts the knock frame for a 30-s threshold time. If the sticky note display device can’t read the frame in one RX window due to interference, it will try to read it again after 8 s. In 30 s, the sticky note display devices will open at least 3 RX windows in 8 s intervals to read the knock frame. If the device cannot read the knock frame within the 3 RX windows, the message will be missed and will not be displayed. The sticky note display device will continue to open the RX windows every 8 s. Thus, a bad LoRa network would cause the device to miss the message, but it would not have any impact on power consumption.

The sticky note display device may read trash data when it opens an RX window to read the knock frame or the data frame due to interference from other wireless devices operating in the same unlicensed ISM bands. However, it only processes the knock frame if its length is exactly 4 bytes and sends acknowledgment when its ID matches the knock frame’s target device ID. In the same way, it only processes the data frame if its length matches the data frame length mentioned in the knock frame. Thus, trash data, having random lengths and incorrect formatting, will be ignored by the device. To further improve reliability, one or more signature bytes can be added to the knock frame and data frame so that the device will only process frames if the signature bytes match. We plan to investigate these situations and their solutions in the future.

Interference from household and office devices, such as microwaves and vacuum cleaners, can disrupt wireless communication in smart home and IoT environments. While physical-layer jamming is a common challenge, various mitigation strategies can improve system resilience. Techniques such as adaptive frequency hopping, spread spectrum methods, and dynamic channel selection help reduce the impact of interference. Additionally, physical-layer jammer detection methods [45], which analyze received signal strength anomalies or packet delivery rates, can identify jamming events. Once detected, countermeasures such as automatic retransmission, increasing transmission power, or switching to an alternative frequency can maintain connectivity. Advanced solutions, including machine learning-based jamming detection and multi-radio redundancy, could further improve system reliability in complex environments.

One alternative architecture could be to use Wi-Fi-enabled microcontrollers, such as ESP32, directly in the sticky note display unit. This would remove the requirements of the hub unit and LoRa communication. However, Wi-Fi consumes around 90 mA in listening mode [46], whereas LoRa requires only 15 mA, making Wi-Fi significantly less power-efficient. Experiments were conducted with an ESP32 microcontroller in [47], where the device will switch between active and sleep state periodically to save power. It shows that it creates around 100 mA and 300 mA current spikes and an average current consumption of 18.33 mA. In contrast, only 0.404 mA average current consumption was achieved when using LoRa and the custom protocol. If multiple microcontrollers continuously disconnect and reconnect and repeatedly request IP addresses from the router’s DHCP server every few seconds, it can lead to network issues. We plan to explore this architecture in the future.

Along with a smartphone app, it is also possible to make a desktop/laptop app that connects to the MQTT broker and publishes messages targeting a sticky note display. We plan to make this app in the future.

Offices regularly change or recharge batteries for devices such as wall clocks, wireless keyboards, smart locks, and remote controls, making occasional battery charging and replacements a standard maintenance task. For large offices with hundreds of staff members, centralizing battery maintenance with a scheduled replacement cycle can make the process manageable. We plan to explore energy harvesting from indoor light to further minimize maintenance efforts.

The use of MQTT, which relies on Transmission Control Protocol (TCP), is a suitable choice for the smart sticky note display system, as it ensures reliable and secure message delivery. According to the work of [48], Transport Layer Security with Transmission Control Protocol (TLS/TCP) outperforms Quick User Datagram Protocol Internet Connections with User Datagram Protocol (QUIC/UDP) when handling Man-in-the-Middle (MitM) attacks, making it a more secure option. However, in terms of efficiency in achieving short delays and low packet loss rates with limited central processing unit (CPU) and memory resources, QUIC/UDP performs better under Denial of Service (DoS) attacks. We plan to explore MQTT, which relies on QUIC/UDP, in the future.

6. Conclusions

In this paper, an IoT-connected sticky note display system is proposed comprising sticky note displays, a hub unit, an MQTT server, and a smartphone app. A custom low-power protocol was implemented, enabling a battery life of more than six months for the display devices. The proposed system was developed and tested successfully. We plan to develop a desktop/laptop application for sending messages, adding more font options and sizes, energy harvesting from indoor lights, and enhancing system security by implementing TLS certificates.