Remote Administration of an Automated House
through Web and SMS

Ian Esguerra, Juphel Guerra, Ronald Idjao, Adrian Serohijos, Melisande Tupa

Tristan H Calasanz and Carlos M Oppus

Abstract--The Automated House provides a controlled and automated home system which consists of five modules—Access and Security, Interconnection, Status and Monitor, Environment Control, and Remote Administration. The Automated House-Remote Administration (AHRA) module interacts with the rest of the system through exchange of status and log files that are exchanged via serial ports. The AHRA automatically replies to requests by remotely located administrator to send the contents of status and log files through SMS. The AHRA prompts the administrator when the automated house encounters emergency interrupts. The software for this mobile interface is coded in Visual C++ and Visual Basic. The administrator can likewise extract information regarding the status of the house through a web and send command to the central automated control by updating the command file on-line. Still images (captured with an interfaced webcam) and command files are regularly uploaded to the site for updates.

Keywords--Visual C++, Visual Basic, GSM Interface

I. Introduction

Numerous processes could be automated enhancing convenience in our daily lives. At home, the increased manageability and control brought about by automation would increase convenience to peoples’ lives. However, controllability should not be confined to the house’s immediate premises. The Automated House: Remote Administration (AHRA) conceptualized an automated house that can controlled through different media immediately available to a remote administrator.

Two of the most common means of communication and data exchange now are the internet and the GSM. These two media which are readily accessible and available may be utilized to increase the controllability.

II. Statement of the Problem

The administrator of an automated system wants to maintain some controllability and access to the system if he or she is away from it. This increases the functionality of the automated house.

A. Objectives of the Study

The main objective of this study is to provide information update and system control to a remote system (automated house) administrator through internet and GSM. Specifically, the group had the following objectives:

• Develop a software that interfaces a mobile phone to a PC and sends and receives command to and from the administrator, and interconnects the AHRA to the rest of the automated house.

• Develop a web site that would display automated house settings and accepts commands

• Develop a software that interfaces a webcam to a PC, regularly captures images of house interior and regularly transfer files from the website to the local PC.

B. Scope and Limitations

The ActiveX Control used was taken from the Internet as a shareware product. There are several advantages offered by this ActiveX control however since the product is a free software, there are also several limitations. For example, the ActiveX controls will at random replace a received message with an advertisement. This causes an erroneous response from the system as it is fooled to think that it has received an invalid message.

The SMS module allows commands that will set or get the status of the AI house. Among the allowed command format, the SMS module allows the remote user to set the status of the file at a single command or to get the overall status of the AI house using only a single command. The module also tracks down emergency situations in the AI house and automatically informs the user through SMS messages of any known emergency.

The initiation of ftp processes is done using wraparound functions of the Wininet dll. Doing the internet session details in at the socks level is not a concern.

The website was created in combinations of Php, Perl and Html codes. The security feature of the website is not elaborate, but is sufficient to thwart the attempts of curious surfers.

III. Methodology

Figure 1. Diagram of AHRA components.

The different components of the AHRA are shown in figure 1. In the prototyping, a local PC receives status file from the automated house Status-Monitor containing current values of automated house parameters. The local PC can also send the Status-Monitor a command file containing the new values to which the remote administrator wants the house settings changed. The group develops software that provides the local computer an access to the internet and the GSM network.

Control through GSM Network

A mobile phone was connected to the communication port of the local pc of the remote administration module. This mobile phone serves as the interface of the remote administrator to the controls of the automated house. To interface the mobile phone to the personal computer, SMS Oxygen ActiveX Controls (together with a Visual C++ program developed by the members of the group) was used. An ActiveX is a COM (Component Object Module) file that can be attached to a Visual C++ Program. The SMS Oxygen ActiveX controls served as the means for interfacing the pc to the mobile phone. The particular ActiveX Control used was taken from the Internet as a shareware product.

SMS Oxygen ActiveX provides functions that allow the PC access into the memory modules of the mobile phone. It also allowed the PC to trigger functions inherent to the mobile phone unit. However, the main feature used in the ActiveX control was an event-triggered mechanism for allowing the PC to detect received SMS messages that may contain command from the remote user. Upon receiving these commands, the PC, is programmed to respond accordingly.

The commands sent by the remote user must correspond to the established format. The GUI program for the PC-mobile phone interface was programmed to send reports to the user upon receiving the commands. These responses may be a mere confirmation that the command sent was received and acted upon or it may send error messages if the user sent an unrecognizable command.

Control through Web, Webcam Interface

We developed an interactive website that regularly displays updated information and images of the automated house. Also, through the site, the remote administrator can input new values to which house settings will change. E.g., home temperature can be changed by inputting values through the web.

The website structure is fairly simple: it is divided into a public area in which the surveillance function is implemented and a private area where only registered users (i.e. the members of the house) can change the house settings through the internet.

For the surveillance function, the website has an automated house status page that is updated every minute. This status page shows the settings that the monitoring module has obtained and is uploaded to the site by means of an independent program of the remote administration module. And since the status page is located in the public area of the site, curious surfers can also view these settings. However, to protect the automated house the public is limited to this feature together with brief information about the project.

The private area of the site, aptly called resident's lounge, is where the control function is present. This area is protected by means of a password protected log in. In the resident's lounge the members of the house has the ability to change the settings of the house. Any changes are saved and are downloaded to the remote administration module for processing and implementation. Also, an added surveillance function is present only in the resident's lounge. This surveillance is by means of a web camera in the room. Settings change and the room view are also update every minute.

To make the information update of the automated to the remote administrator more comprehensive, a web cam is interfaced into the local PC. The webcam captures still images (and movie streams) and stores them in the harddisk. The camera is controlled using an SDK provided by manufacturer (Logitech).

The still images and the command file are uploaded into the web site for display and convenient perusal of the remote administrator. We use file transfer protocol (FTP) in uploading and downloading files to and from the server hosting our site. The software developed for the file transfer uses Wininet, a dll provided by Microsoft. After instantiating an internet session, the we used FtpGetFile to download the new command settings to the local PC and FtpPutFile to upload the status and image of the house. The session is closed immediately after.

This sequence of capturing images and performing internet sessions is repeated over an interval of 25 seconds.

Interconnect to the Other Modules

The Remote Administration Module communicates to the whole Automated House system by sending command files and receiving house status files from the Status-Monitor Module through the serial port. The GSM and web interface performs remote administration of the automated house through these text files. Once the connection with the Status-Monitor Module is established, the house status file is constantly updated. Sending requests for new house settings requires rewriting the command file through SMS or the web. The functions handling the interconnection of the Remote Administration Module with the Status-Monitor Module is contained in the same Visual C++ code where the GSM interface is implemented.

IV. Software Set-up and Implementation

SMS hardware configuration

The hardware configuration of the SMS remote system is simple enough. A mobile phone is connected to one of the serial ports of the PC. However, since the AI project aims to implement a fully operational intelligent house, there has to be an agreement on the use of the ports. The serial port of the control PC of the remote administration module will be used both for interfacing the module’s PC to the monitoring module and for interfacing the PC to the mobile phone. Thus it must be agreed upon that the mobile phone used to interface the user with the PC will be connected through the communication port 1 (COM 1). It is inherent in the program that the chosen communication used for PC-mobile phone interface will be the COM1 port. With the mobile phone attached to the COM1 port, the rest of the mobile phone PC interaction is already implemented through software configurations.

SMS software implementation

The compiler used for developing a GUI (Graphic User Interface) was Visual C++. However most of the jobs involving interfacing the PC and the mobile phone were implemented through the use of ActiveX controls. Before any of the interfacing functions of the ActiveX could be used, the PC must first be initialized to find the mobile phone at COM Port 1 and to decide the medium of communication between the PC and mobile phone. As mentioned in the SMS hardware configuration, the mobile phone will be connected through the PC’s COM port 1. This is done by using the ActiveX function SetComNumber and SetConnectionMode. For the connection mode, the DAUP9 connection was chosen since the cable needed for this mode of connection is readily available. After setting up the connection between the mobile phone and the PC, actual connection must be established through the Connect function (another ActiveX Control command). The connect command will be executed upon the initiative of the user by clicking the connect button on the program’s application window. The connection of the PC and mobile phone was chosen to be a manual task that needs to be done before actual implementation of the program’s functions to allow the user the option to disable the "automatic responses" of the program

With the mobile phone properly connected to the PC, the intended function of the program can now be enabled. The "automatic response" of the SMS module revolves around the triggered event: SMSMessageReceived. When this event is triggered the computer automatically performs a specific function. Example upon receiving an SMS message, the PC will automatically read the message and determine whether the message is a valid command or not. If the message is a valid command, then the computer will execute the command upon decoding it.

Upon receiving the SMS message, the message will be read from the phone by the PC through the ReadSMSMessage function (again provided by the Oxygen ActiveX Control). The message will then go through a decode function that will be called to determine if the command is valid and if it is valid, the decode function determines the corresponding response of the program. Basically, there are only two commands: set(s) and get(g). The set command allows the user to set the status of the AI house. An example of this would be setting the intensity of the lights. The set command follows the following format:

s <parameter id> <value>

e.g., s l 0, s a 16 0 1 0

On the other hand, the get command allows the user to get the status of the AI house. It follows the following format:

g <parameter id>

e.g., g l

Upon determining what the command is, the program will begin executing the command. If the command is to set the status of the AI house, then the program will write to a particular text file the necessary status information as requested by the user.

This text file will be sent to the monitoring module so that the monitoring module could inform the Automated House: Interconnect Module of the request of the remote user. Then the program will give a report of a successful or failed execution to the remote user through SMS messages. If on the other hand, the remote user asks for an update on the status of the house through the get command, then the program will read the contents of file sent by the monitoring module (as requested by the interconnect module) to the remote administration module. This file contains the updated values of the status of the AI house. These values will be sent to the user as a SMS message.

If the command is invalid then a message will be sent to the remote user informing him/her of the error that occurred. Sending of SMS Message is done through the ActiveX Control function SendSMSMessage.

Figure 2. Front panel for the interconnect and SMS interface.

Web-based Control Implementation

The flowchart of the developed software is shown in figure (). The program was coded in Visual Basic. In interfacing with the webcam, we used the Logitech QuickCam SDK [Logitech SDK]. The application communicates with the video portal component of the SDK. Video portal gives PictureToFile function to capture a frame and save it to a 24-bit RGB, bitmap format.

Figure 3. Flowchart for FTP process and webcam interface.

In performing the ftp process, we used Wininet dll provided by Microsoft. After instantiating an internet session, the update settings are downloaded form the site using FtpGetFile function, the status and image of the house are uploaded using FtpPutFile. These sequence of steps are repeated over an interval of 30 seconds.

Figure 4. Front Panel for ftp upload.

Interconnect with the Other Modules

The Remote Administration Module communicates with the Monitoring Module through text files sent via the serial port. There are three text files vital to the Remote Administration Module. Commands to change the environment settings of the house (e.g., lights, temperature, volume of the radio, etc.) are found in command.txt. The latest update of the overall house status is contained in the file status.txt. The last file webcommand.txt serves allows the Web Sub-Module to communicate with the SMS Sub-Module. The SMS Sub-Module and the functions that facilitate the Remote Administration PC’s interconnection to the Monitoring Module lie in a single source code written in Visual C++ 6.0. A web browser passes commands to the SMS Sub-Module code through webcommand.txt.

Once a connection with the Monitoring PC is established, the Remote Administration Module will continuously update the house status file. The status of the house is also stored in a set of global variables for an easier access of other functions within the module. At the same time, the SMS and/or Web Sub-modules may be ready to request for a change in the house status by preparing the command file. To send the command file, the SMS Sub-module has to enable an internal flag in the source code. On the other hand, the Web Sub-Module has to specify its intent to send the command file in webcommand.txt. Prior to the actual sending of the file, the syntax of the command file is checked. If the command file contains valid parameters for the environment settings of the house, then it is sent to the Monitoring PC through the serial port.

Figure 5. Interconnect and GSM Interface

Serial port communication between the Remote Administration and the Monitoring Modules is done through a Null Modem Connection.

Figure 6. Null Modem Connection

A null modem connection connects two computers in only three wires. Any data transmitted by the first computer must be received by the second computer, and vice versa, thus TD is connected to RD. The signal grounds (SG) of the two computers must also be connected so that both computers have common grounds. The key concept in a null modem connection is to have a computer think that it is connected to a modem rather than another computer. Thus, the Data Terminal Ready is looped back to the Data Set Ready and Carrier Detect. When the DTR is active, the computer will think that a virtual modem is connected to it and that this virtual modem it is connected to another modem. It is assumed that both computers have the same communication speed, so the RTS signal is looped to the CTS pin. A high Request to Send signal indicates that the computer wishes to send data and since this is looped to CTS, the computer gets the reply that it is ok to send then proceeds on sending bits to the other computer.

V. Conclusion and Recommendation

The group provided a remote access and control to the administrator through internet and SMS. A mobile phone was interfaced to a PC. The PC in turn was connected to the controls of the house. The cell phone received the messages sent by the remote user and a program using ActiveX Controls was used to decode the message and implement the corresponding responses.

From a web site, the administrator could view house settings and change them. This was done by transferring files between the local PC and the site through ftp.

The implementation of the interfaces could be improved by implementing the functions at a lower level, giving the programmers better control of the process. More creative techniques may be implemented to reduce the delay caused by ftp process.

VI. REFERENCES:

www.beyondlogic.org

Logitech, Logitech QuickCam SDK 1.0: MS Visual

Basic Programmer’s Guide, www.logitech.com