[Top] | [Contents] | [Index] | [ ? ] |
This is the manual documenting DomoNet (version 0.1) @c,
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 Dario Russo, Vittorio Miori
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”.
* Copying:: The GNU General Public License says how you can copy and share DomoNet |
---|
[ < ] | [ > ] | [ << ] | [ 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 document presents the results obtained during my collaboration with the Domotic Laboratory at the Institute of Science and Technologies of Information ISTI “Alessandro Faedo” of the CNR in Pisa. This project is located within the “Home Automation Technologies and Standards” ( HATS(1)) research area. The project purpose is to develop an architecture based on new technologies to create intelligent domestic atmospheres that concur at the integration and interoperability of the offered services.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The slang of new technologies has gone enriching of new terms as Home Automation, Building Automation, Smart Home. They are all synonyms diverted by the domotique neologism. The domotique neologism was coined in France and it is composed by the fusion of two terms: domus and informatique. The domotique neologism is recovered in Italy with the domotica term and represents the technology applications of the information and communication in the domestic world, to improve the comfort and the control.
Domotics parnorama is still in 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. Different industry coalitions have promoted numerous middlewares and standards always more sophisticated and always too poorly interoperable each others This has made the domotics an unexploded bomb. The world of research and industry are waiting for the that “boom“ that 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 announces that hardly will be the definitive consecration of one of them. 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.
Pervasive Computing and Ambient Intelligence (AmI) visions are still far from being achieved, especially with regard to Domotics and home applications. According to the vision of Ambient Intelligence (AmI), the most advanced technologies are those that disappear: at maturity, computer technology should become invisible. All the objects surrounding us must possess sufficient computing capacity to interact with users, the surroundings and each other. The entire physical environment in which users are immersed should thus be a hidden computer system equipped with the appropriate software in order to exhibit intelligent behaviour. Even though many implementations have started to appear in several contexts, few applications have been made available for the home environment and the general public.
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 web service, and on an XML grammar called domoML. The goal proposed by the framework is the integration and to act a sort of interoperability among services offered by the main middlewares currently available.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domotics constitutes all the technologies that are dedicated at the integration of electronic devices, appliances, systems of communication and control placed inside a domestic environment. The purposes that the domotic applications establish are:
It’s sure that the domotics proposes futuristic and positive impact sceneries on the quality of our life. Unfortunately there are numerous technologies and different domotic standards that are poorly interoperable among them. This incompatibility represents 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 buy domotic technologies 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 happen in two conditions: the contemporary acquisition of all the devices, or a technical knowledge that allow the user to knowledge the previously used standard in order to acquire further conforming devices. Both the conditions are however of difficult realization because in the most of the cases. In particular, as regard the first condition It must be considered that the domestic environment is very dynamic: the home elements change frequently and the devices come acquired in different moments. It is in fact rare that all that devices in a residence are acquired contemporary. To understand the interoperability issue, let’s suppose to have a coffee pot that is able to turn on itself through a radio alarm to a pre-established hour. If the radio alarm and the coffee pot "speak the same tongue" (have the same standard), every morning it will be possible have a ready coffee just wake. If one of the two devices must be changed, it will be necessary to replace appliance with an other of the same standard. It is instead desirable to allow the consumer to choose the devices independently from the standard which they belong: in this way the final user doesn’t have to know the technical detailed knowledge of the installed system inside his home. His only attention should be to exclusively take advantage of all the possible benefits offered by the devices.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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] | [ ? ] |
One of the main objective of the work is to study and to implement an architecture to face the issue of the cooperation among heterogeneous devices from the technological point of view. This is possible creating a level of abstraction that allows to characterize the domotic devices from a behavioural and physical point of view. The abstraction layer aims to furnish a homogeneous description of all devices independently from the belonging technologies.
The domoNet architecture is composed by a server part that implements the management of domotic devices like the abstraction layer and the cooperation feature, and by one or more clients able to send requests to the server in order to activate domotic actuators and to query domotic sensors receiving a response from them. Client functioning can range from a simple remote control to a more sophisticated tool able to take decisions by evaluating contextual and environmental parameters to implement intelligent and specialized services (e.g. related to Ambient Intelligence, e-health, energy saving).
Figure 1.1: The domoNet architecture
In fig:ex1the client is composed by two elements: the domoNet Client that implements the business logic and the methods for interactions with the sever part and the domoNet Client User Interface that implements the user interface like a Web or desktop application, an app for the smartphone and so on. The server part is composed by the communication interfaces and business logic (webService) and by one or more techManager. techManagers are special gateway able to interface domotic technologies (such as KNX, UPnP, X10 ZigBee and so on) and to integrate them in the middleware.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
REQUIREMENTS:
* apache-tomcat (http://tomcat.apache.org);
* axis (http://ws.apache.org/axis);
* xerces (http://xerces.apache.org/xerces2-j);
* calimero (http://calimero.sourceforge.net);
* cyberLink for Java (http//sourceforge.net/projects/cgupnpjava)
INSTALLATION:
* If not already installed, install "axis" inside the "apache-tomcat" copying the directory "webapps/axis" of the "axis" distribution inside the "webapps" directory of the "apache-tomcat" installation.
* Change the directory path lines (from 6 to 12) in the "build.xml" file.
* Copy the jars of the "exerces" archive into "apache-tomcat" webapps/axis/WEB-INF/lib directory.
* Add in "apache-tomcat" webapps/axis/WEB-INF/server-config.wsdd the following lines in the services section:
<service name="DomoNetWS" provider="java:RPC">
<parameter name="className" value="domoNetWS.DomoNetWS" />
<parameter name="scope" value="application" />
</service>
If you don’t have this file, you can copy a basic configuration file at the this file.
* Copy "calimero" jars into "apache-tomcat" webapps/axis/WEB-INF/lib directory.
—————————–> server-config.wsdd <—————————-
<?xml version="1.0" encoding="UTF-8"?>
<deployment name="defaultClientConfig"
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
xmlns:handler="http://xml.apache.org/axis/wsdd/providers/handler">
<globalConfiguration>
<parameter name="disablePrettyXML" value="true"/>
<parameter name="dotNetSoapEncFix" value="true"/>
<parameter name="enableNamespacePrefixOptimization" value="false"/>
<requestFlow>
<handler type="java:org.apache.axis.handlers.JWSHandler">
<parameter name="scope" value="session"/>
</handler>
<handler type="java:org.apache.axis.handlers.JWSHandler">
<parameter name="scope" value="request"/>
<parameter name="extension" value=".jwr"/>
</handler>
<!– uncomment this if you want the SOAP monitor –>
<!–
<handler type="java:org.apache.axis.handlers.SOAPMonitorHandler"/>
–>
</requestFlow>
<!– uncomment this if you want the SOAP monitor –>
<!–
<responseFlow>
<handler type="java:org.apache.axis.handlers.SOAPMonitorHandler"/>
</responseFlow>
–>
</globalConfiguration>
<handler type="java:org.apache.axis.handlers.http.URLMapper"
name="URLMapper"/>
<handler type="java:org.apache.axis.transport.local.LocalResponder"
name="LocalResponder"/>
<handler type="java:org.apache.axis.handlers.SimpleAuthenticationHandler"
name="Authenticate"/>
<service name="AdminService" provider="java:MSG">
<namespace>http://xml.apache.org/axis/wsdd/</namespace>
<parameter name="allowedMethods" value="AdminService"/>
<parameter name="enableRemoteAdmin" value="false"/>
<parameter name="className" value="org.apache.axis.utils.Admin"/>
</service>
<service name="Version" provider="java:RPC">
<parameter name="allowedMethods" value="getVersion"/>
<parameter name="className" value="org.apache.axis.Version"/>
</service>
<service name="DomoNetWS" provider="java:RPC">
<parameter name="className" value="domoNetWS.DomoNetWS" />
<parameter name="scope" value="application" /> </service>
<transport name="http">
<parameter name="qs:list" value="org.apache.axis.transport.http.QSListHandler"/>
<parameter name="qs:method" value="org.apache.axis.transport.http.QSMethodHandler"/>
<parameter name="qs:wsdl" value="org.apache.axis.transport.http.QSWSDLHandler"/>
<requestFlow>
<handler type="URLMapper"/>
<handler type="java:org.apache.axis.handlers.http.HTTPAuthHandler"/>
</requestFlow>
</transport>
<transport name="local">
<responseFlow>
<handler type="LocalResponder"/>
</responseFlow>
</transport>
</deployment>
————————–> end server-config.wsdd <————————–
To compile the domoNet project, have javadoc and docs, type inside the domoNet directory, the command "ant".
To run a sample under linux, type: ant demo or launch "launch.sh" script., modifying paths (lines from 2 to 8).
2. DomoML | The XML language created and used inside the application |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
domoML is a subset of the XML language and it used as lingua franca abstracting the underlying technologies of devices in a way to level out them. In this way devices, functions and interactions inside the domoNet middleware are represented using an unique representation. It’s the standardized language by and towards which translate techLanguages for the proper functioning of the middleware. Infact, all the logical parts of the middeware use domoML and only the physical iterations between real devices and techManagers are in the techLanguage. domoML is composed by two sub-languages:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domoDevice sub-language has the purpose to create a compact, effective, simple and complete way to represent devices abstracting them from the underlining domotic technology.
domoDevice can be represented through a wide and poorly deeper tree. The tree can have maximum four levels:
All this fields are optional except for the id, URL and tech attributes because they permit to identify and use the device.
An example of a DomoDevice for a 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 is described a domoDevice lamp produced by “pholips” and that it is located bedside table beside the bed. It’s of the KNX technology and is of type lamp. The lamp is managed by the web service http://www.thiswebservice.it/service. The lamp offers two services: to get and set its state using a boolean value. The boolean value can be TRUE or FALSE. When is invoked the service to set status, it is also called the service named setPower of the domoDevice managed from the web service http://www.otherwebservice.it/service with id 3. The value used as input for the described service (status) is also used as input value for the service to call (power). This means that if it it is invoked the service setStatus of the domoDevice with url http://www.thiswebservice.it/service" and with id 0 using as input the value TRUE, it is also called the service setPower of the domoDevice with url http://www.otherwebservice.it/service, and with id 3 using as input the same value.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domoMessage sub-language has the role to create a simple, compact and effective mechanism to represent the interactions between the domoDevice without take care about underlining technologies. domoMessage is also represented through a wide and little deep tree with 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.
This example shows how to execute the service SET_STATUS on the domoDevice with web service http://www.thiswebservice.it/service and id 1. The service has an input of type boolean with value TRUE. After the execution of the called service, if no errors was found, the middleware creates a message of type SUCCESS:
<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.
3. Server side | The server side of the application |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Figure 3.1: The domoNetWS (server side) architecture: a general view.
At startup time, the server (fig:dnwsa2) sets up the techManagers that are in the techManagerList data structure and it requests them a list of domoDevices that are currently avaiable on them. In fact, each techManager works as gateway for a specific domotic technology. techManager and has the duty to manage and interact physically with the domotic technology and with its own devices. When a techManager recognizes a device of its competence, it creates the corresponding domoDevice.
In this way, the device is described in terms of functionalities and characteristics and notified in DomoML formalism to DomoNetWS. DomoNetWS then includes the domoDevice description in the DomoDeviceList structure assigning to it a domoAddress.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The request to execute a domoMessage can be originated by a DomoNet client (fig:ex1) or by another instance of DomoNetWS placed somewhere on Internet (fig:dnwsa3). A client application or another instance of DomoNetWS can request to execute a domoMessage to the server. When the request of execution of a domoMessage arrives to the DomoNetWS (fig:dnwsa2), the server identifies the domoDevice involved in the operation. The identification of a domoDevice is realized throught its DomoDeviceId that is obtained combining the receiverURL and receiverId attributes of the domoMessage. Using the domoDevice description, the server finds the techManager that manage the corresponding device of the domoDevice using the attribute named tech. The domoMessage is then tranfered to the found techManager to be translated in techMessage to provide to its execution. Once the domoMessage is executed, the techManager prepares a new domoMessage of type failure or success, in the outcome of the transaction.
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] | [ ? ] |
A techManager is a gateway used to physically interface the system side of the middleware with a specific domotic technology such as KNX, UPnP, X10, ZigBee, etc. To do that, the techManager interfaces directly the specific wired or wireless domotic bus of the technology to integrate, to capture and to send data packets to domotic devices.
Figure 3.2: The techManager architecture: the execution of a domoMessage.
techManager main functionalities are:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When a techManager receives a domoMessage to be executed (fig:tma1), it must find the real address of the device and the domoDevice that are involved in the communication. To do that, the techManager exploits the field receiverId of the received domoMessage twice: once as input parameter for the address translator functionality defined in the techManager in order to find the real address and of the device, and the other used as domoDeviceId to get the corresponding domoDevice. For each domoDeviceId it’s possible to associate more than one real address (that is useful for some domotic technology such as KNX) but for each real address it’s possible to associate only one domoDeviceId.
The message field of the received domoMessage contains the
name of the service of the domoDevice to invoke.
Moreover, in the domoMessage are eventually described input and output
parameters with the corresponding datatypes.
According with the characteristics of the domotic system managed by the
techManager, all these information contained in the
domoMessage are translated into a techMessage and sent to
the device through the domotic bus.
If the techMessage sent to the device requires a response from it,
the reply will be captued from the domotic bus and translated to
domoMessage.
The domoMessagecontaining the response will be forwarded to who
requested the information.
In any case, a domoMessage of type SUCCESS
or FAILURE
is emitted
by techManager to inform about the outcome of the operation.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To reach the interoperability objective, the middleware exploits the cooperation between techManager (fig:dnwsa1). Each techManager is able on the one hand to "speach" the domotic technology language that it manages and the other the domoML formalism. Being techManagers able to translate from one language to the other language, to act cooperation it is sufficient to exploit the common domoML facilities.
Figure 3.3: The cooperation between two techManager for the domotic interoperability
To reach the interoperability objective, the middleware exploits the cooperation between techManagers. Involved techManagers can belong to the same (fig:dnwsa2) or to different DomoNetWS (fig:dnwsa3). Infact, every DomoNetWS can import devices belonging to different DomoNetWSs. Imported devices are recognized using the url field of their domoDevice descriptions that identifies their belonging DomoNetWS. Each techManager is able on the one hand to “speach” the domotic tech language and the other the DomoML formalism. Being techManagers able to translate from one language to the other language, to act cooperation it is sufficient to exploit DomoML facilities.
Figure 3.4: Two distinct instances of DomoNetWS that interact.
In fig:dnwsa2 and fig:dnwsa3, a techManager receives from the DomoNetWS a request to execute a domoMessage. Analyzing the domoMessage, the techManager is able to find the correct device and service that are related with the request. With the acquired information, techManager is able to translate the domoMessage in techMessage andand to send it in the domotic bus for its execution. After the execution of the techMessage and after the eventually response by the involved device, the techManager sends the result to DomoNetWS that verifies the existence of the linkedService tag in the description of the invoked service in the domoMessage. If DomoNetWS finds at least a linkedService tag, it generates and sends new domoMessages to the corresponding techManagers for their execution.
4. Client side | The client side of the application |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The client side is composed by two elements: the domoNetClient and the domoNetClientUI. Followint the MVC (Model View Controller) paradigm, domoNetClient implements the Model and Controller part whereas domoNetClientUI implements the View part. The domoNetClient is an application to interact with one or more DomoNetWSs. It implements the necessary functions to manage and to get data to implement services to control devices.
Figure 4.1: The domoNetClientUI (client side) architecture
domoNetClient (fig:dncu1) can get the list of
domoDevices that are available in the DomoNetWSs
getDeviceList
function.
DomoDevices are stored in the DomoDeviceList
structure.
DomoNetClient is able to create and to send domoMessage
commands exploiting the descriptions provided in domoDevices.
To do that, DomoNetClient the execute
function.
When the output
field of the domoMessage is not empty,
DomoNetClient waits for a response form the DomoNetWS after
having submitted the request.
If needed, DomoNetClient is able to receive notifications about the
change of the state of sensors and actuators that occur in the
DomoNetWS.
DomoNetClinetUI, instead, can be a web or desktop application,
or an app for smartphone or tablet.
Its function is to offer to users an interface to interact easily with the
DomoNetClient application.
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(2) technology and it is based on the open source library called “
Calimero(3).”
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(4)”, 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(5) technology and is based on the opensource library “Cyberlink(6)”. 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.
Index | Complete index |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Jump to: | A B C D F G H I K L M N O P R S T U V X Z |
---|
Jump to: | A B C D F G H I K L M N O P R S T U V X Z |
---|
Figures | The list of figures |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The domoNet architecture
The domoNetWS (server side) architecture: a general view.
The techManager architecture: the execution of a domoMessage.
The cooperation between two techManager for the domotic interoperability
Two distinct instances of DomoNetWS that interact.
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://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 Russo on July 19, 2016 using texi2html 1.82.
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 Russo on July 19, 2016 using texi2html 1.82.