[Top] [Contents] [Index] [ ? ]

DomoNet Architecture

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”.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

GNU GENERAL PUBLIC LICENSE

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] [ ? ]

Preamble

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.

  1. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The “Program”, below, refers to any such program or work, and a “work based on the Program” means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term “modification”.) Each licensee is addressed as “you”.

    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.

  2. You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

    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.

  3. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
    1. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
    2. You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
    3. If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

    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.

  4. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
    1. Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
    2. Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
    3. Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

    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.

  5. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
  6. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
  7. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
  8. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

    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.

  9. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
  10. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

    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.

  11. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
  12. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
  13. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

Appendix: How to Apply These Terms to Your New Programs

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1. Introduction

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] [ ? ]

1.1 The problem

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] [ ? ]

1.2 The domotics

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] [ ? ]

1.2.1 Domotic middlewares

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] [ ? ]

1.3 The solution: DomoNet

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).

images/domoNetArchitecture

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] [ ? ]

1.4 Dictionary


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.5 How to install, compile and launch the application

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).


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2. DomoML


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.1 What domoML is and what it does

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] [ ? ]

2.1.1 domoDevice

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:

  1. device: opens the domoDevice description and gives general informations about the device as follow:

    All this fields are optional except for the id, URL and tech attributes because they permit to identify and use the device.

  2. service: describes a service offered of the domoDevice. This information is used to create a domoMessage and to converting it to a techMessage. For each domoDevice there can be more than one service tags. Tags for this are:
  3. two possible ones tag for this level:
  4. two possible tags for this level:

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] [ ? ]

2.1.2 domoMessage

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:

  1. message: it opens the tag that it describes the domoMessage and it contains the following attributes:
  2. input: if message type is COMMAND, it represents a value to be sent as input of the service to call. Otherwise, if message type is UPDATE, it represents a new value of the state of a device. This tag is optional and every tag message can have more input tag. The attributes for this tag are:

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3. Server side


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1 DomoNetWS

images/domoNetWSArchitecture2

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] [ ? ]

3.1.1 The execution of a domoMessage for the DomoNetWS

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] [ ? ]

3.2 techManager

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.

images/techManagerArchitecture1

Figure 3.2: The techManager architecture: the execution of a domoMessage.

techManager main functionalities are:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2.1 Executing a domoMessage

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] [ ? ]

3.3 The cooperation between different techManagers

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.

images/domoNetWSArchitecture1

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.

images/domoNetWSArchitecture3

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4. Client side

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.

images/domoNetClientUIArchitecture

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5. The development

This chapter describes the detailed implementations of the architecture.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.1 TechManagers

These are the techManagers implemented that they can be taken as example.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.1.1 KNXManager

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 XMLETS 3” configuration file.

From this piece, and every tag row present in the file, it is possible to characterize:

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] [ ? ]

5.1.1.1 Capturing the techMessage from the Konnex bus

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] [ ? ]

5.1.2 UPnPManager

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:

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:

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] [ ? ]

5.1.2.1 Capturing the techMessage from the UPnP net

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] [ ? ]

5.1.3 Implementing a new one tech manager

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:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.2 The domoNetClient

The DomoNetClient allows to control in remote the devices dislocates in the domoNet network inside the web services.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.2.1 A possible domoNetClientUI

This interface implements a graphical client to attack to DomoNetClient engine.

images/domoNetClientSnapshot1

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.

images/domoNetClientSnapshot2

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:

images/domoNetClientSnapshot3

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6. Conclusions


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.1 Realizations experience and appraisals.

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] [ ? ]

6.2 Integration with Internet

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] [ ? ]

6.3 Future directions of research

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

Index

Jump to:   A   B   C   D   F   G   H   I   K   L   M   N   O   P   R   S   T   U   V   X   Z  
Index Entry Section

A
allowed2.1.1 domoDevice

B
Building Automation1.1 The problem

C
Calimero5.1.1 KNXManager
COMMAND2.1.2 domoMessage

D
description2.1.1 domoDevice
description2.1.1 domoDevice
description2.1.1 domoDevice
device1.4 Dictionary
device2.1.1 domoDevice
domoAddress1.4 Dictionary
domoDevice1.4 Dictionary
domoDevice2.1.1 domoDevice
domoDevice2.1.1 domoDevice
domoDeviceId2.1.1 domoDevice
domoDeviceId2.1.1 domoDevice
domoMessage1.4 Dictionary
domoMessage2.1.2 domoMessage
domoML1.1 The problem
domoML1.4 Dictionary
domoML2.1 What domoML is and what it does
domoML2.1 What domoML is and what it does
domoNet1.4 Dictionary
domoNet architecture1.3 The solution: DomoNet
domoNet Client1.3 The solution: DomoNet
domoNet Client User Interface1.3 The solution: DomoNet
domotica1.1 The problem
domotique1.1 The problem
domotique1.1 The problem
domotique1.1 The problem
domus1.1 The problem

F
FAILURE2.1.2 domoMessage
from2.1.1 domoDevice

G
GNU General Public LicenseDomoNet Architecture

H
hasValue2.1.1 domoDevice
HATS1. Introduction
Home Automation1.1 The problem

I
id2.1.1 domoDevice
id2.1.1 domoDevice
ifInput2.1.1 domoDevice
informatique1.1 The problem
input2.1.1 domoDevice
input2.1.2 domoMessage

K
KNX1.3 The solution: DomoNet

L
linkedInput2.1.1 domoDevice
linkedService2.1.1 domoDevice

M
manufacturer2.1.1 domoDevice
message2.1.2 domoMessage
message2.1.2 domoMessage
messageType2.1.2 domoMessage

N
name2.1.1 domoDevice
name2.1.1 domoDevice
name2.1.2 domoMessage

O
output2.1.1 domoDevice
outputDescription2.1.1 domoDevice

P
positionDescription2.1.1 domoDevice
prettyName2.1.1 domoDevice

R
real address1.4 Dictionary
receiverId2.1.2 domoMessage
receiverURL2.1.2 domoMessage

S
senderId2.1.2 domoMessage
senderURL2.1.2 domoMessage
serialNumber2.1.1 domoDevice
service1.4 Dictionary
service2.1.1 domoDevice
service2.1.1 domoDevice
service2.1.1 domoDevice
service2.1.1 domoDevice
service2.1.1 domoDevice
service2.1.1 domoDevice
Smart Home1.1 The problem
SUCCESS2.1.2 domoMessage

T
tech2.1.1 domoDevice
techLanguage1.4 Dictionary
TechLanguage1.4 Dictionary
techLanguage2.1 What domoML is and what it does
techLanguages2.1 What domoML is and what it does
techManager1.4 Dictionary
techManager1.4 Dictionary
techManagers2.1 What domoML is and what it does
to2.1.1 domoDevice
type2.1.1 domoDevice
type2.1.1 domoDevice
type2.1.2 domoMessage

U
UPDATE2.1.2 domoMessage
UPnP1.3 The solution: DomoNet
URL2.1.1 domoDevice
URL2.1.1 domoDevice

V
value2.1.1 domoDevice
value2.1.1 domoDevice
value2.1.2 domoMessage

X
X101.3 The solution: DomoNet
XML1.4 Dictionary
XML2.1 What domoML is and what it does

Z
ZigBee1.3 The solution: DomoNet

Jump to:   A   B   C   D   F   G   H   I   K   L   M   N   O   P   R   S   T   U   V   X   Z  

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

Figures

Figure 1.1

The domoNet architecture

Figure 3.1

The domoNetWS (server side) architecture: a general view.

Figure 3.2

The techManager architecture: the execution of a domoMessage.

Figure 3.3

The cooperation between two techManager for the domotic interoperability

Figure 3.4

Two distinct instances of DomoNetWS that interact.

Figure 4.1

The domoNetClientUI (client side) architecture

Figure 5.1

Snapshot of the domoNetClientUI (main window).

Figure 5.2

Snapshot of the domoNetClientUI (services window).

Figure 5.3

Snapshot of the domoNetClientUI (services window).


[Top] [Contents] [Index] [ ? ]

Footnotes

(1)

http://hats.isti.cnr.it

(2)

http://www.konnex.org

(3)

http://calimero.sourceforge.net

(4)

http://www.konnex.org/knx-tools/ets/intro/

(5)

http://www.upnp.org

(6)

http://sourceforge.net/projects/cgupnpjava


[Top] [Contents] [Index] [ ? ]

Table of Contents


[Top] [Contents] [Index] [ ? ]

About This Document

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.