Wi-Fi Infrared Control Gateway for Hotel Automation

Arduino · Android · Wi-Fi · Infrared · Legacy Device Integration · Smart Building Control

A network-connected infrared control gateway developed around 2012–2013 to integrate heterogeneous hotel equipment into a centralized mobile-control workflow. The system captured and consolidated infrared command sets from legacy remote controls, stored them as a device-independent command library, and reproduced those signals through Arduino-based IR transmitters controlled over the hotel Wi-Fi network or through internet connectivity.

1. Project Overview

This project was developed for a hotel automation scenario in which existing equipment needed to be controlled centrally without replacing the original appliances.

The hotel contained many devices that were operated only through infrared remote controls.

Examples included:

air-conditioning units,
equipment in the lobby,
devices across other hotel areas,
and other IR-controlled systems from different manufacturers.

The objective was ambitious for its time:

turn existing infrared-only equipment into network-controllable devices without modifying the equipment itself.

The system introduced a compatibility layer between:

Legacy Infrared Equipment
          ↓
IR Command Library
          ↓
Arduino-Based IR Gateway
          ↑
        Wi-Fi
          ↑
Android Mobile Application

The prototype was installed and tested at Darvishi Hotel together with the user's instructor.

2. Historical Period

Approximate development period:

Iranian year 1391–1392 / approximately 2012–2013

This places the project in an early period of practical IoT / smart-building experimentation, before Wi-Fi-connected consumer automation devices became common.

At the time, many hotel appliances offered:

no network interface,
no API,
no centralized protocol,
and no standardized smart-building integration.

Infrared was the only practical control interface.

The project therefore solved the problem by creating an external network-to-IR bridge.

3. Core Problem

The hotel had numerous independent infrared-controlled devices.

Each device typically depended on its own remote control.

That created several limitations:

Device A → Remote A
Device B → Remote B
Device C → Remote C
...

There was no unified control layer.

The project replaced this fragmented interaction model with:

Mobile Application
        ↓
Hotel Wi-Fi / Internet
        ↓
Central IR Gateway
        ↓
Selected IR Command
        ↓
Target Equipment

This allowed legacy appliances to participate in a digital control environment without internal hardware modification.

4. Engineering Concept

The central engineering idea was simple but powerful:

If an appliance already understands infrared commands, reproduce exactly the signal it expects rather than replacing or modifying the appliance.

This transformed the infrared protocol into an integration boundary.

The gateway did not need to understand the internal electronics of every device.

It only needed to know:

Which IR command corresponds to which device action?

Examples:

Device: Air Conditioner A
Action: Power On
→ IR Command X

Device: Air Conditioner A
Action: Temperature Up
→ IR Command Y

Device: Lobby Device B
Action: Power Off
→ IR Command Z

Once captured, those commands could be sent programmatically.

5. Reverse-Engineering the Infrared Commands

One of the most distinctive parts of the project was the method used to recover command data from existing remote controls.

The workflow used:

Sony RMT-V656A learning remote control
HTC One smartphone with infrared capability
Android debugging connection to a computer

The Sony learning remote was used as an intermediate capture device.

The workflow was approximately:

Original Remote
      ↓
Teach Command to Sony RMT-V656A
      ↓
Replay Learned Signal Toward HTC One
      ↓
HTC One Captures / Exposes IR Data
      ↓
Android Debugging Connection
      ↓
Inspect Command Representation
      ↓
Record Command
      ↓
Add to Consolidated IR Library

This process was repeated for commands from different devices.

6. Why the Sony Learning Remote Was Useful

Different remotes and appliances could use different infrared encoding schemes.

Rather than building a unique hardware decoder for every original remote, the Sony RMT-V656A learning remote acted as an intermediary.

Conceptually:

Remote From Device A ─┐
Remote From Device B ─┼→ Sony Learning Remote
Remote From Device C ─┘
                             ↓
                    Repeatable IR Source
                             ↓
                         HTC One

This created a practical workflow for consolidating command sets.

It also reduced dependency on the physical characteristics of each original remote.

7. HTC One as an Analysis Tool

The HTC One was used because of its infrared capabilities.

The phone was connected to a development machine in debugging mode while the learned signals were reproduced toward it.

The resulting low-level command representation could then be inspected.

The historical description refers to this output as the assembly-level code / low-level IR command representation exposed during debugging.

For portfolio purposes, the safest wording is:

The HTC One was used as an infrared analysis endpoint while connected to a development computer in debug mode, allowing captured IR command data to be inspected and documented.

The exact internal Android/HTC representation should not be described more specifically unless surviving source or documentation is recovered.

8. Building the Unified Command Library

The captured command data from many remote controls was consolidated into a single logical command library.

The purpose of the library was to answer:

Device + Action
      ↓
Which infrared signal must be transmitted?

Conceptually:

IR Library
│
├── Air Conditioner 1
│   ├── Power On
│   ├── Power Off
│   ├── Temperature Up
│   ├── Temperature Down
│   └── ...
│
├── Air Conditioner 2
│   ├── Power On
│   ├── Power Off
│   └── ...
│
├── Lobby Equipment
│   └── ...
│
└── Other IR Devices
    └── ...

The architecture was not limited to one brand.

9. Brand Independence

A key property of the design was:

the gateway was not restricted to a specific equipment manufacturer.

If a device could be controlled through infrared and its commands could be captured, the signal could be added to the library.

That made the integration approach largely device-agnostic at the network layer.

The system architecture therefore separated:

Network Control

from:

Device-Specific Infrared Commands

This is an important architectural decision.

10. Arduino-Based IR Gateway

The physical gateway was built around Arduino.

Its role was to receive a network-triggered command and reproduce the corresponding infrared signal.

At a high level:

Incoming Network Command
          ↓
Select Device / Action
          ↓
Lookup IR Command
          ↓
Arduino Processing
          ↓
IR Emitter
          ↓
Legacy Appliance

The Arduino acted as the bridge between digital network commands and physical infrared control.

11. Wi-Fi Integration

The gateway was connected to the hotel Wi-Fi network.

The Android mobile application could send commands:

from inside the hotel network,
or remotely through internet connectivity where network access permitted.

The overall path was:

Android Phone
      ↓
Wi-Fi / Network / Internet
      ↓
Hotel Network
      ↓
IR Gateway
      ↓
Infrared Transmission
      ↓
Target Device

This transformed local infrared control into network-addressable control.

12. Android Application

A dedicated Android application was developed for controlling the system.

The application was built during the older Android development era using:

Eclipse
the Android development tooling available at the time

The development environment was significantly less mature and streamlined than modern Android Studio workflows.

The application acted as the user-facing control layer.

Its responsibility was conceptually:

User Selects Device
        ↓
User Selects Action
        ↓
Application Sends Network Command
        ↓
Gateway Executes Corresponding IR Signal

13. Original Architecture

The complete historical architecture can be represented as:

┌─────────────────────────────┐
│      Android Application    │
│         (Eclipse)           │
└──────────────┬──────────────┘
               │
               │ Wi-Fi / Network / Internet
               ↓
┌─────────────────────────────┐
│      Hotel Network Layer    │
└──────────────┬──────────────┘
               │
               ↓
┌─────────────────────────────┐
│   Arduino IR Control Box    │
│                             │
│  Command Lookup / Mapping   │
└──────────────┬──────────────┘
               │
               │ Infrared
               ↓
┌─────────────────────────────┐
│ Existing Hotel Equipment    │
│                             │
│ AC · Lobby Devices · ...    │
└─────────────────────────────┘

Separate from runtime operation, the command-acquisition workflow was:

Original Device Remote
        ↓
Sony RMT-V656A
        ↓
HTC One IR Analysis
        ↓
Debug / Command Extraction
        ↓
Unified Command Library

14. Two Distinct Subsystems

The project can be understood as two separate engineering pipelines.

A. Command Acquisition

Legacy Remote
    ↓
Learning Remote
    ↓
IR Capture / Analysis
    ↓
Command Dataset

B. Runtime Control

Android App
    ↓
Network
    ↓
Arduino Gateway
    ↓
IR Transmission
    ↓
Appliance

This separation is architecturally important.

The difficult reverse-engineering work was performed during onboarding of a device.

Normal runtime operation then became simple and deterministic.

15. Device Onboarding Model

Adding a new device followed a repeatable process:

New IR-Controlled Device
        ↓
Obtain Original Remote
        ↓
Capture Relevant Commands
        ↓
Associate Commands With Actions
        ↓
Add to Command Library
        ↓
Deploy to Gateway
        ↓
Control From Mobile App

This effectively created a reusable onboarding process for legacy equipment.

16. Horizontal Scalability of the Physical Gateway

Only one gateway unit needed to be engineered initially.

The design concept allowed additional units to be placed elsewhere in the hotel as required.

In other words:

the architecture was repeatable rather than tied to a single physical location.

Conceptually:

Hotel Network
│
├── IR Gateway — Lobby
│
├── IR Gateway — Floor 1
│
├── IR Gateway — Floor 2
│
├── IR Gateway — Restaurant
│
└── IR Gateway — Other Areas

The exact number of deployed units should not be claimed unless verified.

The important point is that the design could be replicated.

17. Infrared Coverage Model

Infrared is line-of-sight / area-sensitive.

Therefore, a single emitter cannot necessarily control an entire building.

The project handled this architecturally by treating the controller box as a repeatable module.

Additional IR gateways could be installed wherever physical coverage was required.

This separated:

Logical Control System

from:

Physical IR Coverage

That is a sensible distributed-control design.

18. Hotel-Wide Automation Vision

The prototype was not conceived as a single-TV remote replacement.

The broader vision was to digitize control across the hotel.

The project targeted equipment in:

the lobby,
multiple hotel areas,
air-conditioning systems,
and other infrared-controlled devices.

The intended direction was:

one digital control environment for heterogeneous legacy equipment.

This gives the project much stronger architectural relevance than a consumer universal-remote application.

19. Deployment

The system was not purely theoretical.

It was installed and tested at Darvishi Hotel together with the user's instructor.

This makes the project:

Prototype
   +
Real Environment Deployment

rather than only a laboratory experiment.

The public portfolio should avoid claiming full hotel-wide production rollout unless additional evidence confirms it.

A defensible statement is:

A working prototype was installed and tested in a real hotel environment.

20. My Role

The project involved direct hands-on work across several layers.

Confirmed responsibilities include:

researching the infrared-control problem,
selecting and using the Sony learning remote,
using the HTC One as part of the IR-analysis workflow,
extracting and cataloging command representations,
building the consolidated command library,
developing the Arduino-based IR transmitter/controller,
integrating Wi-Fi/network control,
building the Android control application,
and participating in the real hotel installation with the instructor.

This is a genuinely cross-disciplinary project.

21. Engineering Domains Combined

The project combined:

Mobile Development
        +
Networking
        +
Embedded Systems
        +
Infrared Protocol Handling
        +
Hardware Integration
        +
Legacy-System Integration
        +
Smart-Building Automation

That combination makes it particularly useful in a portfolio focused on architecture and integration.

22. Legacy Integration

The strongest architectural interpretation of the project is legacy integration.

The hotel already owned equipment.

Replacing all of it with network-native hardware would have been expensive and unnecessary.

Instead, the project preserved the existing devices and inserted an integration layer around them.

This is the same architectural principle used in many enterprise modernization projects:

Do Not Replace Working Legacy System
            ↓
Introduce Adapter / Gateway
            ↓
Expose Modern Interface

In this project:

Legacy Interface = Infrared
Modern Interface = Wi-Fi / Mobile
Adapter = Arduino IR Gateway

23. Adapter Pattern in Physical Systems

From a software-architecture perspective, the gateway behaved conceptually like an Adapter.

The appliances understood:

Infrared Protocol

The mobile application understood:

Network Commands

The gateway translated between them.

Mobile / Network
      ↓
Adapter Gateway
      ↓
Infrared Device Interface

This is a useful example of an architectural pattern implemented across hardware and software boundaries.

24. Protocol Abstraction

The mobile application did not need to know the waveform or encoding details of each infrared command.

It only needed a logical action.

For example:

ac_lobby_01.power_on

The gateway could map that logical command to a device-specific IR transmission.

This is a clean separation of concerns:

User Intent
     ↓
Logical Command
     ↓
Device Mapping
     ↓
Physical Signal

25. Why the Project Was Technically Interesting

The project had several non-trivial engineering challenges:

heterogeneous infrared protocols,
lack of standard APIs on legacy appliances,
extracting reusable command data,
translating commands into Arduino-transmittable form,
network communication,
Android application development,
physical IR coverage,
and deployment in a real building.

The solution connected all of these into one system.

26. Working With Incomplete Standards

Infrared consumer electronics historically contain a wide variety of command formats.

The project did not require every device to expose a documented integration API.

Instead, compatibility was established empirically through command learning and replay.

That is an example of pragmatic interoperability engineering.

27. Reverse Engineering vs. Replacement

A conventional approach could have been:

Replace Existing Equipment
        ↓
Buy Network-Compatible Devices

The project instead used:

Understand Existing Control Interface
        ↓
Reproduce It
        ↓
Add Network Control

This significantly changes the nature of the solution.

It becomes a retrofit architecture.

28. Retrofit Architecture

The project is best categorized as a retrofit smart-building solution.

Retrofit systems are valuable because they allow modern control capabilities to be added without requiring replacement of all physical infrastructure.

The project therefore anticipated concepts that later became common in:

smart-home IR hubs,
IoT gateways,
building automation adapters,
and universal device-control systems.

29. Technology Stack

Confirmed technologies / devices:

Arduino
Android
Eclipse
Wi-Fi
Infrared
HTC One
Sony RMT-V656A
Hotel LAN / Network
Internet Connectivity

Additional hardware details should not be invented unless recovered from old documentation or photographs.

30. Evidence Boundary

Safe claims:

developed around 2012–2013,
Arduino-based gateway,
Android application developed with Eclipse,
Wi-Fi / hotel network control,
internet-accessible control path where network access allowed,
infrared command consolidation,
Sony RMT-V656A learning remote used in the acquisition process,
HTC One used for IR analysis,
support was not intentionally limited to a single brand,
intended for broad hotel equipment integration,
prototype installed/tested at Darvishi Hotel with the instructor.

Do not claim without evidence:

exact number of hotel devices,
exact number of installed gateway boxes,
exact network protocol such as HTTP/TCP/UDP,
exact Arduino model,
exact IR carrier implementation,
full production rollout across the entire hotel,
commercial deployment scale,
specific encryption/authentication architecture,
exact custom PCB design.

31. Source-Code Availability

The original source code is no longer available.

However, several critical hardware components and implementation steps are still remembered precisely:

Sony RMT-V656A
HTC One
Arduino
Android / Eclipse
hotel Wi-Fi integration
infrared command acquisition workflow
real hotel installation

For portfolio purposes, this should be labeled as a historically reconstructed project.

32. Portfolio Classification

Recommended categories:

IoT / Embedded
Smart Building
System Integration
Mobile
Legacy Modernization
Hardware / Software Integration

Recommended CV relevance:

Tier B — Strong Portfolio Evidence

For roles involving:

IoT,
integration,
solution architecture,
embedded systems,
building automation,
or heterogeneous-system modernization,

the project can become a strong interview example.

33. Why It Is Relevant to Architecture Roles

The project demonstrates architectural thinking across system boundaries.

The problem was not solved inside one application.

It required coordinating:

Mobile UX
+
Network
+
Embedded Controller
+
IR Protocol
+
Legacy Appliances
+
Physical Deployment

That is exactly the type of cross-boundary reasoning expected in solution architecture.

34. Career Evidence

The project supports evidence of:

Solution Architecture
End-to-End Ownership
System Integration
Legacy Modernization
IoT / Embedded Systems
Mobile Engineering
Networking
Hardware / Software Integration
Smart Building Automation
Reverse Engineering
Product Prototyping

35. Website Hero

Wi-Fi Infrared Control Gateway for Hotel Automation

Arduino · Android · Wi-Fi · Infrared · Smart Building · Legacy Integration

Designed and deployed a network-connected infrared gateway that converted heterogeneous hotel equipment into mobile-controllable devices. IR commands from existing remotes were captured, consolidated into a reusable command library, and reproduced through Arduino-based transmitters controlled over the hotel Wi-Fi network.

36. Website Project Card

Hotel Wi-Fi Infrared Gateway

Arduino · Android · Wi-Fi · IR · Legacy Device Integration

Built a retrofit hotel-control gateway that translated mobile network commands into infrared signals for heterogeneous legacy appliances without modifying the original equipment.

37. Short Website Card

Hotel IR Control Gateway

A Wi-Fi-to-infrared control system that brought legacy hotel appliances onto a centralized Android control layer using Arduino-based IR gateways.

38. One-Line Description

Built an Arduino-based Wi-Fi-to-IR gateway that integrated heterogeneous legacy hotel equipment into a centralized Android control workflow.

39. CV Entry

Wi-Fi Infrared Gateway for Hotel Automation — Arduino / Android / IoT

Developed a retrofit smart-building prototype that enabled legacy IR-controlled hotel equipment to be controlled from an Android application over the hotel network. Reverse-engineered and consolidated device command sets using a Sony RMT-V656A learning remote and HTC One IR analysis workflow, then reproduced the commands through Arduino-based network-connected IR gateways. Installed and tested the system in a real hotel environment.

40. Short CV Entry

Built and field-tested an Arduino/Android Wi-Fi-to-IR gateway that integrated heterogeneous legacy hotel equipment into a centralized mobile-control system.

41. Interview Story

Situation

A hotel wanted centralized digital control over equipment that had no network interface and could only be operated through individual infrared remote controls.

Task

Create a system that could control heterogeneous existing devices without replacing or internally modifying them.

Action

I created a command-acquisition workflow using a Sony RMT-V656A learning remote and an HTC One connected in debug mode to inspect infrared command representations. I consolidated the commands into a reusable library, built an Arduino-based IR gateway connected to the hotel Wi-Fi network, and developed an Android application in Eclipse that sent logical control commands over the network.

Result

The prototype successfully bridged mobile/network control to existing IR-only hotel equipment and was installed and tested in a real hotel environment with my instructor.

42. Technical Interview Version

“The hotel had a lot of equipment that was perfectly functional but had no network interface—only infrared remotes. Instead of replacing the devices, I treated infrared as the legacy API. I used a Sony learning remote to capture commands from different remotes, replayed those toward an HTC One while the phone was connected in debug mode, extracted the low-level command representation, and built a consolidated device/action library. An Arduino-based box then reproduced the correct IR signal when it received a command over the hotel Wi-Fi network. I also wrote the Android controller in Eclipse. The interesting part was that the mobile side did not need to understand device-specific IR formats; it sent logical actions, and the gateway mapped them to physical signals. We installed and tested the prototype at Darvishi Hotel.”

43. Architecture Interview Angle

This project is especially useful for explaining the principle:

Modernize through an adapter rather than replacing a functioning legacy system.

The same reasoning applies to enterprise software:

Legacy System
      ↓
Adapter / Integration Layer
      ↓
Modern Interface

In the hotel project:

IR Appliance
      ↓
Arduino Gateway
      ↓
Wi-Fi / Android

This makes the project relevant even when interviewing for non-IoT architecture roles.

44. Security Perspective

Because the project dates from approximately 2012–2013, it should not be retroactively presented as having modern IoT security architecture.

A production-grade modern implementation would require explicit consideration of:

authenticated device access,
encrypted transport,
network segmentation,
authorization,
device identity,
secure firmware update,
audit logs,
and remote-access controls.

The historical prototype should remain documented as it actually existed.

45. Modern V2 Architecture

A modern rebuild could preserve the original architectural idea while replacing the implementation stack.

Example:

Mobile / Web Application
          ↓
Authenticated API
          ↓
IoT Control Service
          ↓
MQTT / Secure Messaging
          ↓
ESP32 / Edge Gateway
          ↓
IR Transmitter
          ↓
Legacy Appliance

Supporting services could include:

Device Registry
IR Command Database
RBAC
Audit Log
Monitoring
OTA Updates

46. Modern Device Model

A modern system could represent devices as data rather than hard-coded application logic.

For example:

Device
├── id
├── location
├── type
├── manufacturer
├── model
└── commands[]

and:

Command
├── name
├── protocol
├── carrier_frequency
├── raw_data
└── metadata

This would make the integration platform configurable.

47. Modern Hotel Model

The physical hierarchy could become:

Hotel
│
├── Lobby
│   ├── Gateway 01
│   ├── AC 01
│   └── TV 01
│
├── Restaurant
│   ├── Gateway 02
│   └── ...
│
├── Floor 1
│   ├── Room 101
│   ├── Room 102
│   └── ...
│
└── Floor N

This would allow control by:

device,
room,
floor,
zone,
or equipment type.

48. Modern Rules Engine

A V2 could move beyond direct remote-control replacement.

Example:

If Lobby Temperature > Threshold
        ↓
Set Air Conditioners to Defined Mode

or:

Hotel Closes Public Area
        ↓
Execute Scene
        ↓
Turn Off Selected IR Devices

This would turn the gateway into part of a real building-automation platform.

49. Modern Observability

A production system would also benefit from:

gateway heartbeat,
online/offline status,
command delivery logs,
device health,
network status,
firmware version,
command history.

One important limitation would remain:

Traditional one-way infrared often cannot confirm that the target appliance actually executed the command.

That limitation would need to be modeled explicitly.

50. Modern Reliability Considerations

A V2 could address:

command retries,
duplicate protection,
gateway availability,
local buffering,
offline operation,
remote configuration,
device provisioning,
and monitoring.

These features would make the system suitable for larger deployments.

51. Why This Project Is Distinctive

The project is distinctive because it combined several different technical disciplines at an early stage:

Android development,
embedded control,
Wi-Fi networking,
infrared reverse engineering,
hardware experimentation,
and real-world deployment.

It also demonstrates a recurring engineering pattern:

preserve valuable legacy assets while adding a modern integration layer around them.

That principle remains highly relevant today.

52. Portfolio Evidence Summary

This project demonstrates:

Physical Device
      +
Embedded Controller
      +
Network
      +
Mobile Application
      +
Legacy Protocol
      +
Real Environment

Few small personal projects span that many system boundaries.

53. Suggested Tags

Arduino
Android
Eclipse
Wi-Fi
Infrared
IoT
Embedded Systems
Smart Building
Hotel Automation
Legacy Integration
Reverse Engineering
Mobile Development
Hardware Integration
Network Control
Retrofit Automation
HTC One
Sony RMT-V656A

54. Suggested Website Metadata

Page Title

Wi-Fi Infrared Control Gateway — Hotel Automation with Arduino & Android

Meta Description

An Arduino and Android retrofit hotel-automation system that captured and reproduced infrared remote-control commands, allowing heterogeneous legacy equipment to be controlled over Wi-Fi without modifying the original appliances.

Suggested Slug

/hotel-ir-control-gateway

Alternative:

/projects/wifi-ir-hotel-automation

55. Evidence Boundary Summary

Confirmed

Approx. 2012–2013
Hotel automation use case
Arduino-based control box
Android controller
Eclipse development
Hotel Wi-Fi/network
Internet-accessible path
Sony RMT-V656A learning remote
HTC One IR analysis workflow
multi-brand intent
reusable IR command collection
real hotel installation/testing with instructor
Darvishi Hotel context

Not Yet Verified

exact Arduino board model
exact networking protocol
exact command encoding format
exact number of devices
exact number of gateways deployed
exact IR emitter circuit
full hotel-wide production rollout

56. Final Portfolio Statement

Developed an early retrofit smart-building system for hotel automation that connected legacy infrared-controlled equipment to a centralized Android control layer. I created an IR-command acquisition workflow using a Sony RMT-V656A learning remote and HTC One, consolidated commands from heterogeneous devices into a reusable library, built an Arduino-based network-connected IR gateway, and developed the Android control application in Eclipse. The resulting prototype was installed and tested at Darvishi Hotel, demonstrating how existing appliances could be digitally integrated without replacing their internal hardware.

57. One-Line Summary

Built and field-tested an Arduino/Android Wi-Fi-to-IR gateway that transformed legacy hotel appliances into network-controllable devices.

58. Ultra-Short Portfolio Label

Hotel Wi-Fi IR Gateway — Arduino · Android · Smart Building · Legacy Integration

Tags: Hardware Integration IoT Networking