Tutorial expert 2:
Access Remote Devices
Content of the tutorial:
Dear user, in this tutorial we will discover how to build a project that allows you to switch on or off remote devices located in different places using your mobile. Actually there are no new concepts now, only a collection of things already seen in previous tutorials. What we are going to describe more in details is how the data are exchanged among your mobile and the controlled devices and viceversa.
The knowledge of what we are going to talk about in this tutorial is not really important for the realization of the project, because every issue is automatically solved by the Devise Home tool. However, for completeness of description, or just to satisfy the user curiosity, we will provide fundamental information about.
As you can see in the following picture there are six devices (three relays and three temperature sensors) connected to three different controller boards. All those controllers communicate each other through radio connections, so there are also three radio devices. Furthermore one of these controller (let's call it the Master) is connected to internet and is the one that directly communicates with your mobile through the Web Server service.
Just to understand how this project works, let's talk a bit about the addressing mechanisms. The addressing is done by using a 16 bit address field in the radio message that can address up to 254 controller boards (the number 255 is a broadcast address) and up to 254 devices for each board. However these numbers are only theoretical limits. The real limitation of addressable device number comes from the available hardware resources of the controller boards (number of pins on the board, available memory etc).
As said before, there is nothing up to the user to do to setup the addressing, as it is computed by Devise Home itself. The only parameter that is on charge of the user is the location property of the controller boards. The location is the effective place where the device is located in your home. For instance you can have some devices in your kitchen, others in your badroom, others in your garden and so on.
The purpose of the location field is to group web controls together in pages on your mobile web browser, having a page for each location, and it is just to organize better all the web controllers when for instance they do not fit all together in only one web page.
Let's spend now a few words to analyse the full path of data, i.e. how the user action on its mobile touchscreen is trasformed in data communication sent up to the target device.
When user executes a command on its browser (set operation), an internet message is sent to the Devise Home cloud and then is received by the Master Controller Board of your home system (i.e. the one connected to internet). The Master Controller Board receives a data message containing the info related to the user action on its mobile browser: generally the id of the target device and the value to set. Of course the Master controller knows where all the target devices belonging to the project are connected. These devices could be either directly connected to the Master itself or to another controller board that is connected to the master through a radio chennel (or more generally through a communication channel).
Let's guess that the destination device is connected to another board controller. In this case a radio message, containing the info received from internet, is sent by the Master to the destiation controller. After that the Master controller waits a few time for an answer containing the result of the operation. In this way, either the success or the failure of the operation can be communicated back to the web.
A similar process is performed when the user wants to know the value of temperature provided by the thermo sensors (get operation). In case of thermo sensor directly connected to the Master Controller board, the value is read everytime an update is executed by the user on its browser. The user can require an update of the values represented on its browser in three ways.
The operation of retreiving values from devices that are connected to other controller boards is made on polling base. This means that periodically (i.e. every about 30 sec) the Master asks to the other controllers to provide an update of all the values read from the connected devices and, after the answer has been received, it keeps in memery all these values. When the user performs an update action, the Master immediately sends the values kept in memory instead of requiring again these values to the other board controller. In this way the whole process of updating values is more efficient and the waiting time of the update operation is very low.
Status lights are lights (or leds) that show the status of the devices belonging to your home system. They are useful, for instance, to have an immediate view of the status of the system itself. At project design level, it is possible to enable the status light for a device, simply by setting the pin number in the Status Light property of the device itself, in the property panel of the design page. Of course is up to the user to connect a led to that pin during the hardware implementation of the project.
In our example there are two kind of status lights:
By collecting a set of status lights in one main panel, it is possible to know immediately the situation of all the devices around your home, without going round and round through all the rooms.
One of the main features of Devise Home is related to the Security.
Devise Home, as any other remote control systems, uses communications mechanisms to carry informations from the user to the target device and vice versa. As we have already seen above, the data transmission starts from the user device (mobile or other browser application), travels through the internet infrastructure, is received by the Master Controller, if needed is replicated over a radio channel, is received by the final target device and, after that, a feedback returns to the user going back across the same path.
The problem is that all these communication channels are shared: everyone can send or receive data on internet and everyone can transmit or receive data on air. That means that everyone can receive our data, look inside, modify them and send to our system again to violate in someway our home discretion.
Devise Home takes a huge care to keep the vulnerability risk of the home system as low as possible. For this reasons some Secure Protocols are implemented inside Devise Home communication systems. These Secure Protocols are the SSL and the TOTP, both of them based on asymmetric key algorhytms.
The SSL is the standard web Security Protocol that has the main purpose to encrypt data to make them unreadable. The TOTP (Time based One Time Password), that is a standard algorythm as well, uses a password that is valid only one time, or for a very small lapse of time (normally 30 sec). In this way, even if someone captures a piece of communication belonging to our home system, he cannot use that data to break our system by retrasmitting the same message as it is or modified, because the security code inside the message expires after a while and the message is no more valid and it is immediately discarded by the receiver.
Just to understand the level of protection of this protocol, we can note that the same protocol is used by the bank communication systems in their money transactions!
What does it mean for the user?
From the project design point of view nothing!