Smart HUB

Objective and Design Philosophy

The Smart Hub is the central computing device that manages and coordinates all smart home operations. It is built around the ODroid H4, a full-featured x86 desktop-class machine running Debian 13 (“trixie”). At its core, the hub runs the Home Assistant program, a customizable and open-source smart home integration platform. 

The system is configured to stay on the stable release branch of Debian with automatic updates enabled, reducing the risk of major failures from system changes while still receiving security patches. By using Home Assistant, the Smart Hub provides interoperability between commercial and custom devices, enabling the Remote Support Station (RSS), Smart Mobile Device (SMD), and other components to interact seamlessly. Its open-source ecosystem ensures future scalability and easy adaptation to new technologies.

Core Components

The Smart Hub ecosystem consists of several tightly integrated hardware and software components:

  • ODroid H4: Hosts all core smart home software and provides local compute resources
  • Debian 13 (“trixie”): Operating system running on the hub
  • Home Assistant: Central smart home integration and automation platform
  • IEEE 802.11g Wi-Fi Network: Local-only network hosted via hostapd
  • Mosquitto MQTT Broker: Manages messaging between smart devices
  • HTTP Server & REST API: Facilitates command/control from the SMD
  • Log Storage System: Retains 30 days of historical device data

Implementation Strategy:

Upon startup, the Smart Hub initializes a Wi-Fi network through hostapd, establishing an isolated 802.11g access point with restricted routing policies. All smart devices, except the Smart Speaker and Roku Relay, connect through this network using the MQTT protocol.

Each device publishes or subscribes to specific MQTT topics managed by the Mosquitto server hosted on the hub. MQTT was selected due to its lightweight, reliable messaging capabilities and its compatibility with Home Assistant’s auto-configuration APIs. This enables smart devices to register themselves upon connection, significantly reducing manual setup.

In addition to MQTT communication, the hub runs an HTTP server that exposes a REST API used by the Smart Mobile Device to trigger device actions such as turning on lights or initiating video calls. Commands are received as HTTP POST requests and interpreted by Home Assistant to activate the appropriate devices.

Performance:

Smart Hub has shown strong performance across all expected functionalities. MQTT communication is reliable and has low-latency, enabling responsive interaction between devices. The REST API receives and processes commands from the Smart Mobile Device without noticeable delay.

 

Smart Mobile Device (SMD)

Objective and Design Philosophy

The Smart Mobile Device (SMD) was designed to give users an easy way to control everything in the smart home from a user-friendly and intuitive graphical user interface. It’s a custom Android application housed on an Android device, such as a Google Pixel Tablet. The app was built using MIT App Inventor, a web-based development platform that uses block-based coding and is useful for rapid prototyping and proof-of-concept design. The app lets users navigate through various menu options using either the touchscreen or SALE-R inputs. The kick buttons connect to the app over Bluetooth Low Energy (BLE), allowing the resident to move through the interface without using their hands. Once a command is selected (such as turning on a light or opening a window shade), the app sends that command to the Smart Hub using a web request. The app emphasizes accessibility, ease of navigation, and reliable wireless communication with both input and output devices in the smart home environment.

System Architecture and Core Components 

The system is built around the following hardware and software elements:

  • Android Tablet: Runs the SMD app and displays the interface
  • MIT App Inventor: Used to build the app using block-based programming
  • Bluetooth Low Energy (BLE): Handles wireless input connection from peripherals
  • REST API over HTTP: Used by the app to send commands to the Smart Hub

Implementation Strategy

After startup, the SMD runs an initialization function that sets up the interface and establishes a Bluetooth Low Energy (BLE) connection to the kick buttons by connecting to the correct GATT service and characteristic using predefined UUIDs. Once connected, the resident can begin interacting with the system using either the touchscreen or directional kick button inputs.

The app interface is implemented through various different menu states, with each state tied to a specific device (or the main menu for device selection). These states are managed using nested if-else logic that determines what the current menu is and how inputs should be interpreted. Each menu corresponds to a specific device or function that can map directly to kick button inputs, with the exception of the Smart Speaker and the Smart TV, as both devices have multiple inputs and require their own menus (and, in the instance of the Smart TV, submenus). As the resident moves through the interface, inputs update the current state, controlling what actions are available and what screen is displayed.

Once an action (such as toggling a light, adjusting volume, or requesting assistance) is made, the app sends a REST API call via an HTTP request to the Smart Hub to carry out the selected command. The Smart Hub works with Home Assistant to interpret the request and activate the appropriate functionality in the target device.

To ensure smooth interaction, kick button inputs received over BLE are debounced through custom logic built into the app, while touchscreen inputs are automatically debounced by MIT App Inventor.

Engineering Challenges and Solutions

  • BLE connections required significant development time. The app was originally planned in Android Studio using Java and XML, but poor documentation and deprecated functions made progress difficult. Development was shifted to MIT App Inventor, but even then, importing the correct BLE extension, selecting the right version, and properly configuring BLE notifications made the initial setup frustrating. Ultimately, we achieved full functionality and established a stable connection between the kick buttons and the SMD.
  • As the number of supported devices increased, maintaining a clear and functional user interaction model became challenging. A nested if-else structure was used to manage control states across menus and submenus, and this logic had to be revised frequently as new devices were added and usability improvements were made. Submenus were especially difficult to implement, particularly when they required refactoring already-established logic.
  • Directional input from kick buttons sometimes triggered repeated signals. A logic-based debouncing system was added to filter out rapid or duplicate BLE inputs and ensure stable navigation.

Performance

The SMD demonstrated reliable performance during normal operation. BLE inputs were recognized with a negligible delay and consistency, and touchscreen responses were immediate. Users were able to navigate menus and trigger smart home commands with ease.

At the time of writing, the Smart Security Door Camera has not been fully integrated into the SMD. While the camera successfully streams video to the Smart Hub and can be viewed through the Home Assistant interface, the video feed is not yet accessible within the SMD app. Retrieving the stream requires a GET web request, whereas the app currently uses POST requests to send commands. Since implementing GET requests follows a similar structure, we are reasonably confident this feature will be functional by the time of the demo.

Remote Support Station

Objective and Design Philosophy

The Remote Support Station (RSS) is a specialized website that allows caregivers or family members to communicate with senior and/or disabled residents of the smart home and support them without compromising their privacy. The RSS provides remote support staff access to information from certain smart home devices: the Smart Pillbox, the Smart Door, the Smart Light, and the Smart Mobile Device (SMD).

System Architecture and Core Components

Home Assistant: Home Assistant is an open-source home automation platform designed to run on devices like a Raspberry Pi or a local server. It comes with customization for dashboards, users, and automations.

Implementation Strategy

The system is built around the Home Assistant software. The Remote Support station uses a custom dashboard and non-admin user account to handle access limitations. It also uses a custom input boolean to see when the resident requires help. It uses a helper input boolean to turn medication reminders on/off. To set the medication reminder time, we installed the datetime integration and set up an automation that triggered at the set time. When the set time arrives, the automation checks if medication reminders are on. If medication reminders are on, the speaker plays a reminder and the Smart Pill Box dispenses pills.

Engineering Challenges and Solutions

  • The original design involved the ability to send calls to/from the RSS and a custom app on the SMD. Due to issues with programming the SMD app, we did not have enough time to implement calls.
  • The original design planned to use the Home Assistant Authentication system to implement limited permissions for the RSS user. However, permissions are not yet enabled on Home Assistant. This means that the RSS user is only limited by the configuration file for their dashboard.
  • The original design had the RSS user creating automations in order to set reminders for the Smart Pill Box. In order to allow the RSS user to access Home Assistant automations, they had to be an admin user. This caused issues with implementing limited permissions. We resolved this by adding the datetime integration to allow the RSSuser to schedule reminders without directly accessing automations.

Performance

The Remote Support Station is able to see the logs and control the devices that it should have access to. The call functionality to and from the SMD has not been programmed yet, and is currently represented by audio feedback from the Smart Speaker.

 

Home Assistant Website

Objective and Design Philosophy

The Home Assistant Website is a specialized website that allows residents to control their homes.

System Architecture and Core Components

Home Assistant: Home Assistant is an open-source home automation platform designed to run on devices like a Raspberry Pi or a local server.

Implementation Strategy

Add additional dashboards and automations using the Home Assistant GUI.

Engineering Challenges and Solutions

  • Ensuring configurations stay in place.

Performance

The Home Assistant Website is able to see the logs and control the devices that it should have access to. It is able to request help and alert the RSS staff.