| [Top] | [Contents] | [Index] | [ ? ] |
This is the manual documenting DomoNet (version 0.1, last updated on 23rd Feb 2007).
DomoNet is an application for manage domotic devices resolving the cooperation problem caused by the different standards existing in this world. It also provides a mechanism to manage devices of any technology in the distance.
Copyright © 2006-2007 ISTI-CNR (Dario Russo)
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being "GNU General Public License", with no Front-Cover texts and with the Back-Cover text being "You have freedom to copy and modify this manual, like GNU software.".
A copy of the license is included in the section entitled "GNU Free Documentation License".
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Version 2, June 1991
Copyright © 1989, 1991 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
one line to give the program's name and a brief idea of what it does. Copyright (C) yyyy name of author This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA |
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. |
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. signature of Ty Coon, 1 April 1989 Ty Coon, President of Vice |
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.
| 1. Introduction | What domotic is and what domoNet tries to solve |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The present relation illustrates the results obtained during my collaboration with the Domotic Laboratory near the Institute of Science and Technologies of Information ISTI "Alessandro Faedo" of the CNR in Pisa, in the within of the project of research called HATS(1) (Home Automation Technologies and Standards). The project is born in order to develop an architecture based on new technologies, in order to create intelligent domestic atmospheres that concur integration and interoperability among the services offers.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The slang of the new technologies has gone enriching of terms as Home Automation, Building Automation, Smart Home and so on. They are all synonyms diverted by an other neologism, domotique, coined in France and composed by the fusion of the two domus and informatique terms. Such neologism, recovered in Italy with the domotica term, represents the application of the technologies of information and communication to the domestic world, in order to improve the comfort and the control.
In this unexplored panorama of development, the industry and the market has played, and they still play, a role of primary importance for the definitive take-off of the domotic technologies. On the one hand the deriving financings from the industry have proposed numerous middlewares, standard always more sophisticated; from the other the presence of too poorly interoperable standards, all promoted by business different coalitions. This has made the domotics an unexploded bomb.
The "boom" that the world of the research and that of the industry waits is what is not still happened: the real employment of the domotic technology is still hindered by the attempt of each industry to impose its standard on the others. The presence of a so vast number of domotic standards, by now broadly established, announces that hardly will be the definitive consecration of one of them and it is as much unlikely that all the coalitions gather about to realize an unique middleware that represents the standard de facto for the domotics.
My proposal is to realize a practicable solution that is able to guarantee the definitive affirmation of the domotics. My solution consists in the realization of a framework, based on the standard technology of the web service and on XML grammar, said domoML, that allows the integration and the interoperability of the offered services from the middleware currently introduced on the market. For obvious reasons, the proposed model represents only a part of the whole framework; in particular it will show as the prototype guarantees the interoperability among two the most important, and among diverge, domotic middlewares: Konnex(2) and UPnP(3).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domotics constitutes all the the technologies that are dealt of the automation of the buildings, and in the first place of the integration of the electronic devices, of the appliances, of the systems of communication and control, that they introduce. The purposes that the domotic applications establish are:
It's sure that the domotics proposes futuristic sceneries and of the positive impact that its employment would be able have on the quality of our life. For this reason, last years were been the theatre for the development of solutions, promoted above all from private firms, for extended all the benefits derivated from a new, and presumably flourishing market.
Paradoxically, the technologies and the different domotic standards, and poorly interoperable, are so numerous by representing an obstacle to the expansion of the market. From the point of view of the final consumer it's very complicated, and perhaps even little comprehensible, perceive the necessity to acquire domotic instead of traditional devices. In fact the potential beneficents that would divert from the acquisition of this products doesn't succeed to justify an economic greater effort: the introduction of "intelligence", understood as ability of calculation, in an any device, involve additional costs always more small. Besides, on account of the scarce interoperability among various standards, the consumer is forced to acquire only the conforming products to a particular system and it could happend in two conditions: the contemporary acquisition of all the present devices in the building, or a technical knowledge that allowed the knowledge of the standard used in order to acquire further conforming devices. Both the conditions are however of difficult realization because in the most of the cases, the domestic environment is a lot of dynamic: the topology and the removal of his elements change frequently and the devices come acquired in different moments.
Try to think, for example, to the appliances: it is at least rare that all that introduce in a residence are acquired contemporarily. To understand better this limitations are of help a classical example of the domotic applications: suppose to have a coffeepot that is able to alight through a radio alarm to a pre-established hour. If the radio alarm and the coffeepot "speak the same tongue" (have the same standard), every morning will be possible have the ready coffee just wakes. Yet, if for any motive, one of the two devices must be changed, will be necessary to replace it with an other in proportion as the same standard.
Is instead desirable allow to the consumer to choose the devices independently from the standard which belong: in this way the consumer don't has not to leastly know the technical detailed bills of the really system, but would be able exclusively draw all the beneficent possibles.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domotic middlewares can be divided in two great classes that differ substantially for the system of communication used:
To the side of a particular system of communication, is available a number always greater of standards that realise transmissions as IEEE 802.11b (Wi-penalties), Bluetooth, IEEE 1394 (Firewire), IrDA, ZigBee, etc.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The main objective proposed to reach is to study an architecture that allows to resolve the problem of the domotic cooperation among heterogenous devices from the technological point of view and to implement an application based on it. The used architecture must moreover allow to control the domitic devices in a remote mode, independently from their lease.
This becomes possible creating a level of abstraction that allows to describe the domotic devices from a behavioral and phisic point of view in order to have one homogenous vision of all devices independently from the below technologies.
The domoNet architecture is composed by a set of servers (web services) and clients (for the remote control). The remote control allows to interact with all the devices reachable from the domoNet network domoNet.
Figure 1.1: The domoNet architecture
In fig:ex1 it comes given a first look to the architecture domoNet. The architecture shown is composed from a client side ( domoNetClient + domoNetClientUI) that, connected to the part server (webService + techManagers) is in a position to carrying out request through TCP/IP in order to be executed by devices. The server part, executed the request, is in a position to send data or an inner code of succeeding or failure (based on the resolution or less of the operation) as response to the client.
For all the application is used the domoML language in order to obtain in the client side and in the logic server side, the perfect abstaction of standards except for each techManager where, inside them, is used the specific protocol sintax because they must control (as drivers) the devices.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| 2. DomoML | The XML language created and used inside the application |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
domoML is a language implemented throught an XML library based on the Xerces Library(4) to represent devices and interactions in a compact way abstracting them from their technology.
The domoML, used with this architecture, is "a middle language" from and to which translate devices and packets representation. All the logic part uses domoML and only the phisical iterations with device modules (in the techManager) the domoML is translated to the techLanguage of the technology used.
The domoML library is composed by two mainlines:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domoDevice language has the purpose to create a compact, effective, simple and complete way to represent devices abstracting them from the technology.
The domoDevice can be represented throught a wide and poorly deeped tree (the grammar provided high attributated tags and not many children). The tree can have maximum four levels:
All this fields are optional except for the id, URL and tech because they permit to identify and use the device.
domoML.domoDevice.DomoDevice.DataType if is exptected
a return value when the corresponding domoMessage will be executed. This
attribute must not be placed if no return value is provided.
Here, an example for a simple lamp:
<device description="energetic saving lamp" id="0" manufacturer="pholips" postionDescription="on the bedside table beside the bed" serialNumber="xxxxxxxxx" tech="KNX" type="lamp" url="http://www.thiswebservice.it/service"> <service description="Get the status" output="BOOLEAN" outputDescription="The value" name="GET_STATUS" prettyName="Get status" /> <service description="Set the status" name="SET_STATUS" prettyName="Set status"> <input description="The value" name="status" type="BOOLEAN"> <allowed value="TRUE" /> <allowed value="FALSE" /> </input> <linkedService id="3" service="setPower" url="http://www.otherwebservice.it/service"> <linkedInput from="status" to="power" /> </linkedService> </service> </device> |
Example 2.1: A domoDevice example for a lamp.
In ex:ex1 it is possible to see that the domoDevice described is a energetic saving lamp from the company "pholips" and that it is found on the bedside table beside the bed.
It's of the Konnex technology and is of the lamp category. The lamp is drived from the web service http://www.thiswebservice.it/service.
The services offert from the lamp are two: to take its running state as boolean format and to set its state through a input, always boolean, that it can assume FALSE or TRUE values.
When it comes invoked this last service, it comes called also another service of name setPower pertaining to the domoDevice managed from the web service http://www.otherwebservice.it/service with id 3.
The value of the input assigned to the first service (status) comes assigned also to the second (power).
If it comes invoked therefore the service setStatus of the domoDevice with url="http://www.thiswebservice.it/service" and with id="0" passing like value of input TRUE, it comes also invoked the service setPower of the domoDevice url=" http://www.otherwebservice.it/service", with id="3" and with value of input TRUE.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domoMessage has the role to create a mechanism simple, compact and effective in order to represent the interactions between the domoDevice apart the technologies. Also the domoMessage can be represented through a wide and little deep tree (it uses an highly attributated grammatical). The tree has maximum 2 levels:
An example of domoMessage in order to turn on one simple lamp is:
<message message="SET_STATUS" messageType="COMMAND" receiverId="1" receiverURL="http://www.otherwebservice.it/service" senderId="0" senderURL="http://www.thiswebservice.it/service"> <input name="status" type="BOOLEAN" value="TRUE" /> </message> |
Example 2.2: A domoMessage example for request a service.
In this example it's asked to execute the service SET_STATUS on the domoDevice with web service http://www.thiswebservice.it/service and id=1 with a boolean input type with value TRUE.
Executed the service, it is possible to receive the following message of confirmation:
<message message="TRUE" messageType="SUCCESS" receiverURL="http://www.thiswebservice.it/service" receiverId="0" senderId="1" senderURL="http://www.otherwebservice.it/service" /> |
Example 2.3: A response domoMessage example.
This message gives the confirmation to the sender that the previous message has been executed with succeeding and that the lamp is now on.
| 3. Server side | The server side of the application |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The server side of the application tries to resolve the cooperation from devices that belong to different technologies and executes commands becaming from another server or from the client.
Figure 3.1: The domoNetWS (server side) architecture: a general view.
Every web service, at startup time, setup the techManagers stored in
the techManagerList and get from them the list of device
currently installed.
The techManagerList take a reference of the class implementation of a
particular technology (viewed as driver or module).
There can be many techManager of different technologies.
Every device recognized by every techManager is converted using the
domoDevice formalism and stored inside the DomoDeviceList
where is indicized assigning it an unique domoAddress composed by the
URL of the web service that stores the domoDevice (at startup time
is empty because is not relevant here), and an id (an identifier, as a progressive
positive number, that permits to identify the domoDevice inside the
web service).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The request to execute a domoMessage can came from a client application (for the remote control of devices), from another web service (for the cooperation).
When a domoMessage arrives for being executed, first of all it comes characterized the domoDevice of the interested device throught the DomoDeviceId using the attributes receiverURL and receiverId of the message. From the domoDevice it comes characterized the type of belongings technology of the device and, with the techManagerList, characterized the tech mamanger of competence to which forward the message. The techManager translates the domoMessage in its corresponding techMessage and supplies to its execution.
Executed the message, the techManager supplies to construct a new one domoMessage of success (type = "SUCCESS") or failure (type = "FAILURE") with an eventual answer of the device.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To this level, the cooperation between devices pertaining to various technologies works like shown (fig:dnwsa1):
Figure 3.2: The domoNetWS (server side) architecture: the cooperation.
The techManager receives a techMessage from the own net and it characterizes, analyzing it, the domoDevice representative sender and the involved service.
The data come analyzed from the web service that verifies the existence of linkedService tag in the description of the invoked service.
If it finds at least a linkedService, it generates new domoMessages and it sends them to the web services interested otherwise does not complete some action.
Every web service can also import and manage the devices of others web service taking advantage of Internet and communicating directly with the interested domoNetWSs.
Inside of domoDeviceList the domoDevice are recognized through the attribute URL.
In this way it is possible to have the cooperation between devices pertaining to various web services (fig:dnwsa2).
Figure 3.3: The domoNetWS (server side) architecture: the cooperation from various web services.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A techManager is a module (or driver) of the web service that has the function to phisically interface it with the devices of a particular technology such as Konnex, UPnP, X10 and so on. A techManager implements calls, functions and all required to implement a specific technology of devices.
The main functions to which it must be in a position to fulfilling are:
In phase of initialization, the techManager must have the list of the devices available and initialize eventually data structures.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When the techManager receives a domoMessage to be executed, it must get the realAddress of the device of the receiver of the message and convert the data included in the domoMessage to a techMessage.
Figure 3.4: The techManager architecture: the execution of a domoMessage.
This means that the techManager must verifies if the domoMessage is of type
COMMAND, understeand the action to do interpreting the attribute
message. It must converts input tags (if any) considering the
datatype and value attributes. At this time, the message, (now
techMessage) can be sent through the transport way for that technology.
The execution of the techMessage can (not must) envolve others messages as
example a response to the orginal message with a value or ack.
If it's provided a response, it must be converted from a techMessage to a
domoMessage considering again the datatypes and the data. This information
are stored in a domoMessage of type SUCCESS or FAILURE.
If it is not provided a response, the techManager provides an empty
domoMessage. In any case, the response domoMessage can be of type
SUCCESS or FAILURE (it can depend from the state of the net,
from the throw of exception and so on).
To do that, so, a techManager must be composed by a domoMessage to
techMessage and vice versa translator. To translate addresses, it uses a
DoubleHash: a special HashMap that permits to use the
domoDeviceId or the realAddress as key to obtain the other.
For each domoDeviceId it's possible to associate more than one realAddress
(useful for example for the Konnex technology) but for each realAddress
it's possible to associate only one domoDeviceId.
| 4. Client side | The client side of the application |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The DomoNetClient executes the control of the devices in the distance regardless its technology.
It can connect to one or more web services at the same time, taking the list of the domoDevices through the method getDeviceList(), and sendes domoMessage commands through the method execute(dm).
For some service a return parameter is also displayed. All the domoDevices are stored in the domoDeviceList. The domoNetClient manages only the logical part of the side client.
For being able interact with it it is needed an interface as a web, textual or graphical application.
Figure 4.1: The domoNetClientUI (client side) architecture
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In fig:dncu1 two possible interactions between the logical part and the interface are shown for:
getDeviceList() on the domoNetClient.
The domoNetClient executes a remote call addressed towards the web service requested, creating a local copy of the domoDevice in the List DomoDeviceList indexable through the domoAddress. The domoNetClient and the domoNetClientUI share this structure in reading. Obtained the list, the domoNetClientUI supplies to show it to the user.
DomoMessage execute (DomoMessage domoMessage) on the domoNetClient. The domoNetClient executes a remote call addressed towards the web service involved and remains in attended of an answer.
Obtained the answer, the message is forwarded to the domoNetClientUI that supplies to show it to the user.
| 5. The development | The development of the application |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This chapter describes the detailed implementations of the architecture.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These are the techManagers implemented that they can be taken as example.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The KNXManager is the module that manages the Konnex(5) technology and it is based on the open source library called "
Calimero(6)."
The constructor of the module takes as parameters the URL and the port number of the service that is connected to the devices.
At startup time it perform a connection to the server and the initialization of the structures that take care of the conversion of datatypes, from domoML.DomoDevice.domoDevice.DataType to Major and Minor indetifier used in order to convert the tag input of the domoMessage as a fruibile value for the technology.
After the initializations the module loads the available devices parsing the XML file generated from the application "ETS 3(7)", a software to configure konnex networks.
The configuration file contains the descriptions and all the functionalities that the Konnex system can offer.
As example is shown a piece of configuration file for the service of a device (in italian, drivers are in italian language):
<row>
<colValue nr="1">0/0/1 Comando Uscita A</colValue>
<colValue nr="2">
0: Comando,tasto sinistro superiore-Commutazione
</colValue>
<colValue nr="3">
1.1.4 16196.. Pulsante 4 canali
</colValue>
<colValue nr="4">S</colValue>
<colValue nr="5">-</colValue>
<colValue nr="6">C</colValue>
<colValue nr="7">-</colValue>
<colValue nr="8">W</colValue>
<colValue nr="9">T</colValue>
<colValue nr="10">U</colValue>
<colValue nr="11">
16196.. Pulsante 4 canali
</colValue>
<colValue nr="12">
16196 On-Off-Dimmer-Tapparelle-Led
</colValue>
<colValue nr="13">1 bit</colValue>
<colValue nr="14">Basso</colValue>
<colValue nr="15">0/0/1</colValue>
</row>
|
Example 5.1: A piece of the Konnex XML "ETS 3" configuration file.
From this piece, and every tag row present in the file, it is possible to characterize:
colValue: the name of the service;
colValue (the begins part): the real address of the device;
colValue: if the readable field (set to R);
colValue: if the scrivibile field (set to W);
colValue: if the transmissible field (set to T);
colValue: the name of the device that offers the service;
colValue: the description of the service;
colValue: the address of group associated to the service.
The others colValue are not significant for the scope proposed from the KNXManager.
It's interessant only the transmissible and at least readable or writeable services.
A device comes described in all its services joining all the eleventh colValue with the same label.
This example produces the following domoDevice:
<device description="" id="" manufacturer="" postionDescription="" serialNumber="" tech="KNX" type="16196.. Pulsante 4 canali" url=""> <service description="Get the status" output="BOOLEAN" outputDescription="The value" prettyName="Get status" name="GET_STATUS" /> <service name="0/0/1" description="16196 On-Off-Dimmer-Tapparelle-Led" prettyName="16196 On-Off-Dimmer-Tapparelle-Led"> <input description="The value" name="value" type="BOOLEAN"> <allowed value="TRUE" /> <allowed value="FALSE" /> </input> </service> </device> |
Example 5.2: The domoDevice translated from the piece of the Konnex XML "ETS 3" configuration file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
All the messages that journey on the Konnex bus come captured from the KNXManager through the use of a listener in listen on the bus. It's interesting to analyze the bus for two scopes:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The UPnPManager is the module that manage the UPnP(8) technology and is based on the opensource library "Cyberlink(9)". At startup time, the UPnPManager inizialize the ManagerPoint: the listener, heart of the manager, that it allows to add, to remove, to test the hartbeat and to admin the packages of the devices. The ManagerPoint supplies to inizialize the data structures for the conversion from domoML.DomoDevice.domoDevice.DataType to the symbols used for this technology and vice versa.
When it comes added a device to the UPnP net, this is announced by the device giving its own description and the list services that it can offer. These informations are stored on various XML files that the library supplies to parse and give of the correspondent tree. To this point it becomes easy to obtain the information. An example of description of the device it is:
<device> <deviceType>urn:schemas-upnp-org:device:light:1 </deviceType> <friendlyName>CyberGarage Light Device</friendlyName> <manufacturer>CyberGarage</manufacturer> <manufacturerURL>http://www.cybergarage.org </manufacturerURL> <modelDescription>CyberUPnP Light Device </modelDescription> <modelName>Light</modelName> <modelNumber>1.0</modelNumber> <modelURL>http://www.cybergarage.org</modelURL> <serialNumber>1234567890</serialNumber> <UDN>uuid:cybergarageLightDevice</UDN> <UPC>123456789012</UPC> <iconList> ... </iconList> <serviceList> ... </serviceList> <presentationURL>http://www.cybergarage.org </presentationURL> </device> |
Example 5.3: The description of an UPnP device.
From this piece of code it is found:
friendlyName: the description of the device;
deviceType: the real address of the device;
modelName: the type of the device;
serialNumber: the serial number.
The one of the offered services (called actions) is:
<actionList>
<action>
<name>SetPower</name>
<argumentList>
<argument>
<name>Power</name>
<relatedStateVariable>
Power
</relatedStateVariable>
<direction>in</direction>
</argument>
<argument>
<name>Result</name>
<relatedStateVariable>
Result
</relatedStateVariable>
<direction>out</direction>
</argument>
</argumentList>
</action>
<action>
<name>GetPower</name>
<argumentList>
<argument>
<name>Power</name>
<relatedStateVariable>Power</relatedStateVariable>
<direction>out</direction>
</argument>
</argumentList>
</action>
</actionList>
<serviceStateTable>
<stateVariable sendEvents="yes">
<name>Power</name>
<dataType>boolean</dataType>
<allowedValueList>
<allowedValue>0</allowedValue>
<allowedValue>1</allowedValue>
</allowedValueList>
<allowedValueRange>
<maximum>123</maximum>
<minimum>19</minimum>
<step>1</step>
</allowedValueRange>
</stateVariable>
<stateVariable sendEvents="no">
<name>Result</name>
<dataType>boolean</dataType>
</stateVariable>
</serviceStateTable>
|
Example 5.4: The description of a service of an UPnP device.
From this piece of code it is deduced:
action-name: the name and the pretty name of the service;
argument-name: the name of the parameter of input;
relatedStateVariable: the key to find in the serviceStateTable in order to find the other information of parameter;
direction: if it is out it is a parameter of output therefore a value of return to the execution is waited for the service; if it is in it is a parameter of input;
datatype: the datatype of the parameter;
allowedValue: the values allowed for that parameter.
For every action a set of argument is previewed.
Every argument then has a datatype to be converted in domoML.DomoDevice.domoDevice.DataType. Of every argument it is necessary to verify the direction tag for knowing if the variable is used as parameter of input or output. The correspondent domoDevice is:
<device description="CyberGarage Light Device" id=""
manufacturer="" positionDescription=""
serialNumber="1234567890" tech="UPNP" type="Light">
<service description="" name="SetPower"
output="BOOLEAN" prettyName="SetPower">
<input description="" name="Power"
type="BOOLEAN">
<allowed value="0" />
<allowed value="1" />
</input>
</service>
<service description="" name="GetPower"
output="BOOLEAN" prettyName="GetPower" />
</device>
|
Example 5.5: The domoDevice translated from the piece of the description of a service in a UPnp device.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The UPnPManagerPoint implements also the functions of listener in attempt of messages that journey on the net.
When a new message journeys, it is calculated the subscription code of the service and the domoDeviceId of the sender device. With these information, passed to the web service, is possible to verify the linkedService presence associated to the invoked service.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In order to implement a new techManager module, it is necessary to extend the class domoNetWS.techManager.TechManager and to create a new instance of the new class in domoNetWS.DomoNetWS.managerList using like key the identifier of the technology (it must be contained in domoML.domoDevice.DomoDevice.DomoTech).
The new module it must implement the abstract methods that are:
public void addDevice (final domoDevice DomoDevice, String address): in order to add a device to the list of the domoDevice of the web service; it must call the methods doubleHash.add() and addDomoDevice() of the web service;
public DomoMessage execute (DomoMessage domoMessage) throws Exception: in order to execute a domoML.domoMessage.DomoMessage; it must be in a position to converting the domoMessage in techMessage and vice versa;
public void finalize(): actions to execute when it comes closed the web service.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The DomoNetClient allows to control in remote the devices dislocates in the domoNet network inside the web services.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This interface implements a graphical client to attack to DomoNetClient engine.
Figure 5.1: Snapshot of the domoNetClientUI (main window).
The client it is supplied with an XML file configuration from which it takes the information on the available web services. The addresses of the web service are shown up contextually to one short description. The bar of the address it can however be edited. Selected or editated the address of the web service, clicking on the Connect button the connection to the web service is executed materially. The web service answers giving a list of the domoDevice currently available (the devices of all supported technologies). The domoDevice come shown uniforms for web service with one tree structure (fig:sdncui1). Clicking on one of them comes opened one new window builded at run time parsng the description of the domoDevice. The window shows informations about the device and all services available.
Figure 5.2: Snapshot of the domoNetClientUI (services window).
For every service it comes shown the button labeled with the pretty name. To its right a textual field is present if, to the execution of the service, a return value is attended. To its left much input parameters as requested for that service exist. Next to every field, a description of the type of waited data is present. Correctly filling up the parameters of input demands and clicking on the button of the service, the client generates the correspondent domoMessage to send to the domoNetClient which supplies to address to the web service of competence. In fig:sdncui2 is shown a window of the services of a television:
SetPower: for setting the state of the television. It's needed a boolean parameter as input and attended a parameter of output like answer;
GetPower: it gives back the state of the television with a parameter of output.
Figure 5.3: Snapshot of the domoNetClientUI (services window).
In fig:sdncui3 the window of the services of one group of buttons at four channels with a service for each push-button. On it is possible to only invoke services that determine commutation of the push-buttons through a boolean value 0 or 1.
| 6. Conclusions | The conclusions |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The tests on the software executed to the Laboratory of Domotica near the Institute of Science and Technologies of Information ISTI "Alexander Faedo" of the CNR of Pisa, have demonstrated to the effectiveness and the generality of the engine of the software. The software has been in a position to importing all the devices subordinates to the test correctly like dimmer, interrupts, televisions, washing machines and light bulbs. The side client successfully interact correctly with the devices subordinates, showing all the services available, constructing one corrected interface for everyone of them. For the cooperation, the crucial point is the location of the message that passes on the way of communication of the technology in object, the acknowledgment of the sender device (in order to find the corrispective) and the correspondent domoDevice invoked service.
For that it regards the developed technologies, these information always have been characterized and elaborated correctly therefore has been always possible to verify the presence of demands for cooperation and eventually to satisfy them.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The model proposed is integrated perfectly with Internet as is a fondamental role of the protocols and the standard and open instruments of the net, like XML and the web service, play with its operations. Such instruments are used for the communications between the various architectural members and more just between domoNetClient and domoNetWS in order implementing the remote control and between various domoNetWSs for the interoperability. Moreover, being the prototype relased under the terms of licence GNU and leaning it as open source software, it can be published and be distributed on the net without some tie.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domotic, now is still hindered from the attempt of every industry to impose this standard on others. The presence of an immense number of domotic standards indicates that difficultly there will be definitive consacration of one of them. The realized software represents a practicable solution that can guarantee the definitive affirmation of the domotic in a definitive way, with an architecture simple and clean and can resolve the obstacle placed. But occour still much job. In the first instance it is necessary to continue the development of the software. This only implements the base functionalities apt to demonstrate the effectiveness of the architecture introduced but far from being able to take advantage of all offered potentialities. Of smaller importance it does not cover the development of others techManager so as to be able to widen the park of the supported technologies. The introduced software, moreover, represents only an example of application for the proposed architecture. Ulteriorly increasing the degree of generality of the architecture it is sure possible to find ulterior ambles of use where it is necessary one cooperation between various and incompatible devices and sensors.
| Appendices |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| Index | Complete index |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| Jump to: | A B C D F G H I L M N O P R S T U V X |
|---|
| Jump to: | A B C D F G H I L M N O P R S T U V X |
|---|
| Figures | The list of figures |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domoNet architecture
The domoNetWS (server side) architecture: a general view.
The domoNetWS (server side) architecture: the cooperation.
The domoNetWS (server side) architecture: the cooperation from various web services.
The techManager architecture: the execution of a domoMessage.
The domoNetClientUI (client side) architecture
Snapshot of the domoNetClientUI (main window).
Snapshot of the domoNetClientUI (services window).
Snapshot of the domoNetClientUI (services window).
| [Top] | [Contents] | [Index] | [ ? ] |
http://hats.isti.cnr.it
http://www.konnex.org
http://www.upnp.org
http://www.xerces.apache.org/xerches2-j
http://www.konnex.org
http://calimero.sourceforge.net
http://www.konnex.org/knx-tools/ets/intro/
http://www.upnp.org
http://sourceforge.net/projects/cgupnpjava
| [Top] | [Contents] | [Index] | [ ? ] |
| [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Dario R. on May, 24 2007 using texi2html 1.76.
The buttons in the navigation panels have the following meaning:
| Button | Name | Go to | From 1.2.3 go to |
|---|---|---|---|
| [ < ] | Back | previous section in reading order | 1.2.2 |
| [ > ] | Forward | next section in reading order | 1.2.4 |
| [ << ] | FastBack | beginning of this chapter or previous chapter | 1 |
| [ Up ] | Up | up section | 1.2 |
| [ >> ] | FastForward | next chapter | 2 |
| [Top] | Top | cover (top) of document | |
| [Contents] | Contents | table of contents | |
| [Index] | Index | index | |
| [ ? ] | About | about (help) |
where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:
This document was generated by Dario R. on May, 24 2007 using texi2html 1.76.
