Activation of Home Automation System via Mobile Technology

Transcription

1 Activation of Home Automation System via Mobile Technology M J Van Der Werff 1 W L Xu 2 X Gui 3 1 Institute of Technology and Engineering College of Sciences, Massey University Palmerston North, New Zealand. vanderwerff@clear.net.nz 2 Institute of Technology and Engineering College of Sciences, Massey University Palmerston North, New Zealand. W.L.Xu@massey.ac.nz 3 Institute of Information Science and Technology College of Sciences, Massey University Palmerston North, New Zealand. X.Gui@massey.ac.nz Abstract: The rapidly advancing mobile communication technology and the decrease in costs make it possible to incorporate mobile technology into home automation systems. Based on an SMS/GPRS (Short Message Service/General Packet Radio Service) mobile cell module and a microcontroller, a home automation server can be established, allowing a user to control and monitor any variables related to the home by using any java capable cell phone. This paper presents the development of AT modem driver, text based command processing software, and power failure resilient output for an Atmel micro-controller to facilitate in sending and receiving data via the cell module, together with the design of java application to enable the cell phone to send commands and receive alerts through the cell module. While the proposed design was implemented using SMS (commonly known as text messages), the possibility of using GPRS (Internet based protocol) as the main communication protocol has also been explored. Keywords Home Automation, SMS, GPRS, GSM, Remote Mobile Control. 1. INTRODUCTION As a student at Massey University a project is required as part of the final year work. The project chosen in this case was the activation of Home Automation via mobile technology. This was selected because of our keen interest in incorporating mobile technology with Home Automation, which we believe is the next important step to realize the Home Automation dream. This paper covers the range of the development of this project including: the concept of the system, the technology involved in implementation, and the prototype product developed. 2. INVESTIGATION When starting this project there were many aspects to consider. We started with the specifications needed to develop a cost-effective method for controlling and activating home appliances remotely. Among these specifications were that this system would need to work in most places where a house may exist, also there would have to be two-way communication to ensure that the messages had been received. The system would also have to be affordable and easy to use as this would be marketed to the general public.

2 2.1 Cellular Modem The first part of this project was investigating the existing technology. It was found after researching that there were systems that allowed users to call up their home and turn on appliances using any phone. Although that system is simple and works for some applications, it has its disadvantages including the following: (a) there is a high usage cost if the user is not local to the house, e.g., toll calls; (b) it is slow to operate as the user has to call the number, enter a password, and listen to each option before selecting the option needed; (c) the house needs to have a phone line, i.e., it would not work at places such as holiday homes which may not have a phone line. The next option investigated was the use of mobile cellular technology. This has many advantages such as low usage costs for data communications as compared to phone calls, and portability within the coverage area of the cellular system. To implement cellular communication into a house server a cellular modem is needed. There is a wide range of cellular modems from PCMCIA cards to USB and serial external modems, but after investigation it was found that the Sony-Ericsson GT48 cellular modem [see appendix] was a good modem to use. This modem was chosen for a number of reasons including: it is a serial external modem, it uses standard AT commands [see appendix], it has GPRS capabilities, it has a hardware TCP/IP stack, and it was donated for use for the duration of this project by Vodafone. Figure 1. Sony-Ericsson GT48 Cellular Modem with aerial After considering all factors it was found the best option to encapsulate all the specifications needed, was to use a cellular based system. To implement this system the Sony-Ericsson GT48 cellular modem was chosen and used in conjunction with an Atmel micro controller. It was setup as the home server. Since the cellular modem was being used it makes sense to use a cellular phone as the main interface to the house server as this takes full advantage of all the roaming and communication capability of this system, enabling it to be controlled anywhere in the world. So the system communicates to and from the house server using a SMS capable cellular phone via text based messages sending a username, password, and the command specified. 2.2 House Server Interface Although it was decided to use SMS as the primary communicating protocol, sending SMS commands via a messaging interface on a cellular phone is a cumbersome way of controlling home appliances. A more intuitive way would be to use a graphical user interface such as a web form or a small application. This is made possible with today s new cellular phones which have large colour screens and are capable of running custom applications downloaded from a web server. 2.3 Phone Programming Language The next part of the research was into the subject of suitable programming language for this project. The first problem was to research what languages are available, and what language should be used to allow this application to be portable across most cellular phones. The first language that we found was.net compact framework [1] for Smart phones. Smart phones at this time are still a small part of the world cellular phone market and partly because they are still expensive. Smart phones programming language would have been perfect for what we needed as its language is a cut down version of.net for windows and therefore it allows the use of any.net language. This also has the advantage of including the library for TCP/IP and UDP communication, and thus this phone could also receive messages over the Internet to open ports, allowing the house server to send messages easily and inexpensively to the cellular phone via GPRS using TCP/IP. Although these types of phones may have been perfect for the programming side of things, the cellular phones were too expensive for the project and also because of this they would have been too expensive for the consumer to buy for this application. But if this project was started in a few more years time we do not think this would be as much a problem as the cellular technology is increasing at phenomenal rates. The next language that we came across was Java Micro-edition [see appendix]; this is a cut down edition of Java that can be run on cellular phones. This is the leading programming language at this time for most brands of cellular phones including some of the main firms such as Motorola, Nokia, and Siemens. Applications can be developed with Sun s Java 2 Mobile Edition [2], which is a

3 development environment freely available intended for developing java applications for cellular phones. This language allows: (a) sending and receiving of data via SMS, (b) opening TCP/IP or UDP connections and sending data via these protocols to a receiving server on the Internet, (c) easy design applications using forms, and much more. The most important factors relating to our choice of this language was its highly portable nature as most new cellular phones have the ability to run this language with slightly different implementations in what they support and also the ease of creating client/server applications. There can be problems with slightly different implementations between cellular phones running the J2ME [3] language. For example, UDP push (a way of sending messages directly to the cellular phone), which is a recommended but optional implementation of J2ME MIDP 2.0 [3] standard which, has not been implemented by many cellular phone manufactures that support this standard. Differing implementations could lead to problems with compatibility with differing cellular phones but this can be avoided by using the certified and not optional libraries. Despite some small problems with some libraries not being fully supported, J2ME is highly portable so that any person with a new phone and our Home Server could use this software to control their home. Designing of java applications is also reasonably easy using Sun s [2] studio which is designed for developing java applications and includes a emulator which one can test his java applications on different virtual cellular phones before testing on real phones. These are some of the reasons that J2ME was chosen for this project. 2.4 Cellular Phone choice After J2ME has been decided to be the language that will be used to write the cellular application, the next step is to decide on a cellular phone to test this on. Although there were many cellular phones on the market at the time this project was started, the Motorola V525 [see Figure 2] was one of the only reasonable priced phones on the market with J2ME that implemented MIDP 2.0 (Mobile Information Device Profile) [see appendix]. A lot more research went into choosing this phone but this is beyond the scope of this paper. Figure 2. Motorola V525 Cellular Phone 3. THE PROTOCOLS This section describes the protocols and concepts used for the implemented SMS (Simple Messaging System) house control and for the proposed but not implemented GPRS (General Packet Radio Service) house control. 3.1 SMS The Protocol SMS allows you to send short messages to almost any SMS enabled mobile phone in the world. SMS is commonly referred to as text messaging, and is becoming increasingly popular, as it is an inexpensive way of communicating small amounts of information. The small fixed cost of communicating via SMS to almost any cellular phone in the world as well as the popularity of SMS makes SMS an excellent way to control home automation. SMS was the home automation control protocol chosen to send text based messages to the home automation system, mostly because of the small cost and the limited time that was available to investigate GPRS. GPRS has many advantages over the SMS system but also many complexities to overcome. 3.2 GPRS Control GPRS is a protocol, which has emerged to allow cellular phones on the GSM network to access the Internet. This is opening up a whole world of opportunities for cellular phones as they can now communicate data to anywhere for relatively small cost. Using GPRS as the main communication protocol for the house server rather than SMS would improve the system as it would become more accessible to other devices and protocols via the internet and also it would allow more affordable data transfer with in the cellular system. Another use of GPRS for this application could be implementing a web server on the microcontroller so the house could be accessed by any other devices over the internet, although security would have to be made extra strict. A major problem after investigating the use of GPRS on the house server was that the Cellular Modem has to activate its PDP (Packet Data Protocol) context before it is assigned an IP address. Explained simply the cellular modem does not get assigned an IP address until it submits a request to connect to an outside server and so it is given an IP address on the fly. This means that since no IP address is assigned the modem can not be called up using GPRS. Opening a connection to an outside server on the web and directing all data towards the cellular modem from this server could circumvent this problem. This server could then act

4 as a router sending out or receiving any information to the cellular modem. This may defeat the purpose of using a micro-controller as the house server for a single user but were this to become a commercial product, users could pay a small fee for use of such a server. and a high current voltage driver for driving external devices via a TRIAC or other driving devices. 4. HOUSE SERVER SYSTEM DESIGN This section gives an outline of the house server that was designed including both a description of the hardware designed and the software. 4.1 Harware Design The first part of the house server design was the choosing of a suitable micro-controller. The requirements for the micro-controller are; a RS232 port, a fair amount of output Digital I/O, and a reasonable speed. Also a reasonable amount of EEPROM was needed to allow for the software to process text commands, to provide Flash program data memory for storage of device status, and username and passwords related to login, so that data is not lost in the case of power outages. The micro-controller we chose was the Atmel AVR Mega 169, which was chosen for the above reasons as well as the excellent open source compiler, environment and libraries that are available for development with AVR s. The main environment/compiler that we used was winavr (see Appendix). These are a set of tools for AVR s including a C/C++ compiler and environment window. The AVR Mega 169 can also be purchased as a development board code-named Butterfly (see Figure 3). This has inbuilt components such as a LCD screen, Piezoelectric speaker, thermometer, and RS232 voltage converter. Figure 3. Atmel butterfly with AVR Mega 169 micro-processor To increase the speed of development of this project a Butterfly was used as the incorporated with a circuit board created in Altium s Protel DXP (see Figure 4). This circuit board contains (see Figure 5): DB9 for RS232 communication and programming, HD15 plug for communications with cellular modem, LED indication of simple output, Figure 4. Circuit diagram for House Server Figure 5. House Server main Board 4.2 Software Design The software programming for the house server is one of the most important parts of this project. It handles the communication to and from the cellular modem, the communication to the attached devices, the processing of the SMS messages performing of username and password lookups in the database and if authenticated the processing of the commands specified, and also sending of responses to commands/errors or alerts identified with a priority to send. The first stage of the software is to setup all factors the relating to the system. The first of these is to setup the device to their last state before power was lost, which is performed by saving any changes in device state on the micro-controllers on board data flash when ever any change to the data state is made, and so the system is made resilient to short term power failure. The cellular modem also needs to be setup to send and receive SMS messages, this is done by sending the AT commands specified to perform this task according to the GT48 AT datasheet [see appendix], then forwarding to the cellular modem via the RS232 port and waiting for the cellular modems acknowledging reply.

5 The second stage to the micro-controllers software is the processing of the SMS header messages sent to the device. The device first must wait for the text +CMT: to be sent via the RS232 from the cellular modem at which time it parses the message (see Figure 6) following the command taking from it information including; the cellular number the message was sent from, the date and time sent, and text message length. The text message length is then used to capture the text message in is entirety as no end characters are given. +CMT:" ",,"04/08/27,08:36:34+48", 145,4,0,0," ",145,14 u=mjv p=password1 Dev=(1:0,2:1) Figure 6. Cellular Modem text message as sent via the GT48 cellular modem It is then necessary to process the username and password contained in the text message. This is implemented parsing the username and password into variables. The username variable is then compared to the username variables in the database and when found; the password associated with the username in the database is compared with the sent password to verify that it is correct. If the username or password is incorrect an error message is sent back to the cellular phone that sent the message. When both the username and password have been found to be correct the command is then compared to the database of commands to check that it is a valid command, and if found to be a valid command the command is either processed or other wise an error message is returned. For this system to be able to control devices there need to be a standard of commands to be sent to perform the corresponding commands. One of these commands is devset(device_no:on/off,other_dev) this command turns the device number specified on or off depending on the command. Also another command devget=? gets all the current setting the device is set at. This is a very simplistic set of commands to that would work for a small set of devices but needs further development to control a large numbers of devices in a variety of different ways. 5. PHONE SOFTWARE DESIGN To design the application needed to control home automation remotely firstly it was started by looking at the example code included in Sun s studio. This was helpful in determining the format to design code for J2ME. I also found it helpful referring to the Motorola Design Guide [4] for J2ME, which gave code to send SMS via J2ME. To set out the application forms can be used, these are similar to web forms but as it is a small screen you have less control of the layout. Once you have created a form you attach child parts to in such as in this application text field of type any for username and text field of type password for the password field. This creates two text fields on the form one of type any, which means any characters and one of type password that hides all but the current character being typed in. Also command types can be added to the form; these are placed at the bottom of the screen and are commands such as Exit and Send. When the corresponding button is pressed the function related with that button is run for example the Send button would send the SMS message or the Exit button would destroy all objects and quit. The application that was developed (see Figure 7) contains a phone number, username, and password as Text fields. It also contains a set of tick box s to select the state the devices should be changed to. All this data is put into a text string and sent via SMS to the number specified when the Send button is pressed. Figure 7. A simulated version of the cellular phone application developed This is a simplistic application that maybe satisfactory to demonstrate a prototype, but further development is needed to enable all the functions and to enable security with password encryption and other such protection to make this a safe and user friendly application. Further development must also go into receiving the SMS sent to the cellular phone application from the house server. This could be achieved using SMS push, which defines a port number for the cellular phone application and when the cellular phone receives a SMS with the applications port number attached the cellular phone runs the application sending through the SMS to the application instead of to the normal mail application. 6. CONCLUSIONS This project has demonstrated the possibility of using cellular technologies such as SMS and GPRS to control home automation and with further

6 development could lead to a breakthrough in the way we interact with our homes. 7. APPENDIX There were many websites that assisted in the development of the House Server and programming of the Cellular phone some of these are included below: Technical Data for the Sony-Ericsson GT48: For further information on this device Sony- Ericsson must be contacted, as most websites are very unhelpful and most data on this device including the AT commands are confidential. Technical Data reference for the Motorola V525: Information on J2ME standards: Technical Data reference for Atmel microcontroller: ACKNOWLEDGMENTS Thanks to Vodafone and Vodafone s Steve Sumner for excellent advice and providing the cell modem, cell phone and sim card s free of charge for the duration of the project. Thanks to Ken Mercer form Massey University for all round circuit related advice. 9. REFERENCES [1] Microsoft, Frequently Asked Questions for.net Compact Framework development. 2004, 2004 Microsoft Corporation. [2] Sun ONE Studio 5, Mobile Edition. 2003, Sun Microsystems Inc. [3] Sun Microsystems and Motorola, I., Mobile Information Device Profile Specification ("Specification"). November 15, [4] Motorola, I., Technical Manual V300, V400, V500, and V600 Handset Series J2ME Developer Guide. 2002, Motorola.