[go: up one dir, main page]

WO2012005617A1 - Commande de dispositif multiservice résidentiel pour système de communication à plusieurs protocoles et dispositifs intégrés, et son procédé de fonctionnement - Google Patents

Commande de dispositif multiservice résidentiel pour système de communication à plusieurs protocoles et dispositifs intégrés, et son procédé de fonctionnement Download PDF

Info

Publication number
WO2012005617A1
WO2012005617A1 PCT/PT2010/000029 PT2010000029W WO2012005617A1 WO 2012005617 A1 WO2012005617 A1 WO 2012005617A1 PT 2010000029 W PT2010000029 W PT 2010000029W WO 2012005617 A1 WO2012005617 A1 WO 2012005617A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
name
data
devices
routine
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/PT2010/000029
Other languages
English (en)
Inventor
Fernando Luís PINTO NEVES
António Manuel PACHECO E MURTA
Rui Fernando Oliveira De Almeida
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
QUIIQ Lda
Original Assignee
QUIIQ Lda
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by QUIIQ Lda filed Critical QUIIQ Lda
Priority to PCT/PT2010/000029 priority Critical patent/WO2012005617A1/fr
Publication of WO2012005617A1 publication Critical patent/WO2012005617A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H04L12/2827—Reporting to a device within the home network; wherein the reception of the information reported automatically triggers the execution of a home appliance functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/285—Generic home appliances, e.g. refrigerators

Definitions

  • the present invention pertains to the fields of telecommunications and electronic systems, namely in providing for highly integrated communications and services in the same device or system, namely at home or other residential settings.
  • triple-play service is a marketing term in which voice, video and data are all provided in a single access subscription.
  • the most common applications are telephony, community antenna television and high-speed Internet service.
  • the triple-play transmission medium is usually fiber optic, conventional cable or satellite and it focuses on a combined business model rather than solving any technical issues.
  • home users who subscribe to triple-play networks enjoy the fact that they have to pay only one bill each month and can deal with a single entity to resolve problems with their telephone, TV or Internet connections .
  • US 2007/0290882 relates to a novel centralized domotic system able to remote control and manage household appliances, apparatuses, installations, devices, machines, etc. existing in a dwelling-house. Another objective of the invention is at the same time to allow each manufacturer of the household appliances, apparatuses, etc. provided with specific software to update such software easily, continuously, remotely and automatically. They achieve such goals by providing a domotic system to carry out drive, control and centralized management which essentially consists of a remote logic drive, control and management unit installed in a dwelling- house .
  • this previous document bestows a way to manage the house content, providing the system integrator with a tool, that allows to interact with the physical system without being present but it does not provide a specific interface embraced with a dynamic description of both display and action properties of all the attached devices, which allows the final user to interact with that same physical system in a functional and consistent way.
  • Triple-play is mainly seen as a commodity with the intention to simplify the home users' life. For a considerable amount of years that the home commodity issue has been approached through several perspectives and often a new solution appears to improve the home life. Being the Triple-play concept an end-user home oriented package, how can we improve this same concept to unify all available elements in a house? The answer is quite simple; expand Triple-play to n-play.
  • Domotics also called Home Automation
  • Domotics designates an emerging practice of increased automation of household appliances and features in residential dwellings, particularly through electronic means that allow for things ⁇ impracticable, overly expensive or simply not possible in recent past decades.
  • the term may be used in contrast to the more mainstream "building automation”, which refers to industrial uses of similar technology, particularly the automatic or semi-automatic control of lighting, doors and windows, Heating, Ventilation and Air Conditioning, and security and surveillance systems .
  • the process of home automation works by making everything in the house automatically controlled using technology to control and do the jobs that one would normally do manually. As the amount of controllable fittings and domestic appliances in the home rises, the ability of these devices to interconnect and communicate with each other digitally becomes a useful and desirable feature.
  • the consolidation of control or monitoring signals from appliances, fittings or basic services is an aim of Home automation .
  • a home automation project foresees a wide range of control points including internet, telephone, television, home theater, apparatuses, etc. It will combine the advantages of informatics and electronics to obtain an integrated management over all control points making life easier, more comfortable and even enjoyable.
  • Home users can interact with all control points through an ample variety of gadgets such as mobile devices, computers, etc. These gadgets are provided with specific control access interfaces that ensure that the users "intensions" are transmitted to the system.
  • Interface in computer science refers to a set of named operations that can be invoked by clients.
  • Interface generally refers to an abstraction that an entity provides of itself to the outside. This separates the methods of external communication from internal operation, and allows it to be internally modified without affecting the way outside entities interact with it, as well as provide multiple abstractions of itself. It may also provide a means of translation between entities which do not speak the same language, such as between a human and a computer. Because interfaces are a form of indirection, some additional overhead is incurred versus direct communication.
  • the interface between a human and a computer is called a user interface.
  • the user interface In the industrial design field of human-machine interaction, the user interface is where interaction between humans and machines occurs. The goal of interaction between a human and a machine at the user interface is effective operation and control of the machine, and feedback from the machine which aids the operator in making operational decisions. Examples of this broad concept of user interfaces include the interactive aspects of computer operating systems, hand tools, heavy machinery operator controls and process controls.
  • the user interface includes hardware (physical) and software (logical) components.
  • User interfaces exist for various systems, and provide a means of both Input and Output. Input allows the user to manipulate a system and output allows the system to indicate the effects of the users' manipulation.
  • the goal of human-machine interaction engineering is to produce a user interface which makes it easy, efficient and enjoyable to operate a machine in the way which produces the desired result. This generally means that the operator needs to provide minimal input to achieve the desired output, and also that the machine minimizes undesired outputs to the human.
  • One of the main objectives of this invention is to fully overcome the limitations of interactions with the home environment.
  • This invention will abolish such boundaries based upon a plug and play environment, built on top of an open architecture, flexible enough to be easy and dynamically adapted to an n-play telecommunication offer.
  • people tend to set boundaries to which they consider acceptable and non-acceptable when someone bothers them at home. It is not by any means reasonable that a system integrator periodically schedules a routine inspection to update the installed system in the users' house. It is mandatory to develop a concept that allows such updates to be automatically performed with a minimal effort for both user and system integrator.
  • domotics One particular platform that supports the home environment is domotics .
  • One of the main goals of this interface is to abstract the hardware components in such a way that will allow them to be represented as standard and custom objects. Each component will keep their control options, but to the final user it will be as if they all belonged to the same sub system. Therefore there is no need for the user to adapt to the hardware because the hardware will be "adapted" to the user .
  • this invention assembles, in one hand, in its core both the gadgets usability and the intended standard approach.
  • the invention accommodates an adaptive system that will automatically accustom to the physical and logical changes made by the user or by the system integrator. This allows a clean and efficient connection between two specific worlds, the hardware and the software.
  • the present invention describes a consolidated residential device control and communication system comprising: a main server (50) ; a multi-protocol and multi-equipment layer (1A, IB); physical subsystems (40, 41, 42, 43, 44, 45); a common user interface (30B, 31B, 32B) , and is able to abstract divisions (10) and respective hierarchy, devices (12), routines (13) and respective actions (14) and trigger (15) conditions, environments (11) and respective hierarchy of actions ( 14 ) .
  • the multi-protocol and multi- equipment layer (1A, IB) comprises: an xml file (54) generator module (60) and parameter verifier module (20), said xml file (54) being able to describe address, display and action properties of a specific device (12); said parameter verifier module (20) being able to export a set of rules (200) to the data converter and distributor module (21); a data converter and distributor module (21) able to select the necessary code for runtime execution by main server (50) and also able to filter a set of rules (200) to the client specification module (22); a client specification module (22) able to convert the filtered xml content (201) into a xml format especially adapted to the devices (12); said xml file or files (54) also being able to describe routines for a routine module (23) , environments for an environment module (24), device rules for a server device module (25) , through the data converter and distributor module (21) which is also able to validate and filter the data (202
  • said main server (50) comprises: a communication module (51) for user interface (30B, 31B, 32B) and communication (30D, 31D, 32D) devices; communication module (52) for devices (40, 41, 42, 43, 44, 45); cache (53) of filtered (201) xml content (54) in a format especially adapted to the devices (12); execution capabilities for said multi-protocol and multi-equipment layer (IB) .
  • said virtual device representation module (25) comprises: a division filter comprising its name and its parent filters; a list of data types comprising its name, type and optionally user symbol, decimal digits, minimum and maximum values; device abstraction interface comprising its name, members and respective data types, and optionally respective descriptions; a list of device types, comprising its name and the respective device abstraction interface; a device list comprising the respective device identifier and type, and its members and the respective device abstraction interface, which in turn comprises properties and the respective data type.
  • said environment module (24) comprises an environment list, comprising for each environment its identifier, name and access, respective action device identifiers, members, values and delays, and respective executable environment identifiers and states.
  • said environment module (23) comprises a routine list, comprising for each routine its identifier, name and access, respective trigger device identifiers, members, values, operations, dates, time and days of the week, respective action device identifiers, members, values and delays, and respective executable environment identifiers and states.
  • said virtual device representation module (25) device list comprises device identifier, name, divisions where it is to be accessed, device type, group, actionable status, user visibility and respective members comprising names, addresses, output and input capabilities, and command strings.
  • the present invention also describes an operation method for a consolidated residential device control and communication system, comprising the steps of:
  • it further comprises the steps of: virtually representing said devices (12) by a virtual device representation module (25) ;
  • it further comprises the following steps for device (12) interaction: changing (70) device (12) state;
  • the client updating (30C, 31C, 32C) comprises the steps of:
  • the trigger validation comprises the steps of :
  • FIG. 1 is a schematic view of a software layer 1A present in the core of several software applications 30.A, 30. B, 30. C.
  • FIG. 2 is a schematic view of the software layer IB present in the core of the main server 50.
  • FIG. 3 is a schematic view of the system and its interrelations 1C.
  • FIG. 4 is a schematic view of the changes that occur when a component 40, 41, 42, 43, 44, 45, etc. is interacted with (cameras, alarms, video door phones, domotic protocols, intercoms, health monitoring, respectively) .
  • FIG. 5 is a schematic view of the changes that occur when a component 40, 41, 42, 43, 44, 45, etc. is added to the main server 50.
  • a division is something that divides or separates; a partition.
  • a division is something that divides the house logically over several partitions such as bedroom, kitchen, etc.
  • a division is exactly the same thing; it divides the concept of house/system in several fragments, providing a way of grouping all the other objects in a logical way.
  • a division can contain other divisions, so it can represent the existence of several nested levels in the house.
  • a division as a complete abstract member allows us to embody the entire house as a division.
  • the house "being a division" concept can be exemplified considering the first nested level of divisions to be the house floors and the second level the rooms (bedroom, kitchen, etc.) .
  • the concept of device integrates at least two different perspectives: the system integrator perspective, to which each device expose its concrete behavior and data types, and the final user perspective, to which each device expose its abstract behavior and general functionality.
  • a device basically consists of a name and one or more behaviors.
  • a light can have the name "bedroom ceiling light” and the associated behaviors are "Turn on” and "Turn off”.
  • the concept of behavior needs to be completely easy to figure to keep the interface as functional and standard as possible.
  • the concept of behavior needs to be more dynamic for the system integrator due to the vast amount of physical domotic components.
  • the concept of behavior is used to link these two worlds allowing an abstraction over the system network enabling the possibility to create a multi-protocol and multi-equipment layer. This layer interacts with various physical subsystems but it is presented to the final user as a standard interface removing the ambiguity of the entire physical system.
  • Divisions and devices are considered the basic structures of the invention and they are the platform that allows us to reach the next level of automation control which is commonly referred as ambient intelligence.
  • Ambient intelligence is an idea that aims to provide an easy way of living, while the actual technology stays in the background, integrated in a non-intrusive way. In order to better achieve the ambient intelligence vision, there is a need to integrate all technology in the house and to also go one step further in order to give the final user that special feel of comfort and quality of live.
  • environments are complex elements that can be easily and intuitively defined/created directly by the user to automate a set of tasks/chores and execute them with the simple and well known "push of a button". It is also important to fact that an environment must preferably be able to execute other environments to remove the need to replicate groups of actions allowing the user to more efficiently manipulate the house tasks.
  • a set of behaviors in the everyday life can also be triggered by specific conditions.
  • routine that acts (performs a group of "Actions") when certain conditions are met (when all "Triggers" are validated) .
  • a system routine is composed by two distinct sub elements named “Triggers” and “Actions”. These “Triggers” are logical expressions (propositions) which can be composed using the logical operators “AND”, “OR” and “NOT” over a certain and specific type of environment variables (i.e. day/hour, device state, temperature, email received, Mp3 player connected, etc.) . Routine "Actions” are the same as Environment “Actions”. They can execute an environment or a direct action over some behavior of a specific device.
  • divisions, devices, environments and routines are the four basic concepts needed to model a standard, easy-to-use and fully functional interface for any home environment equipped with domotics, security, video doorphone, HVAC, etc.
  • these four basic concepts are sufficient to model an entire ambient intelligence system and to provide to the final user an extended control over any home automated system/apparatuses existing in a dwelling-house.
  • FIG. 1 is a schematic view of a software layer 1A present in the core of several software applications 30.A, 30. B, 30. C.
  • the layer 1A has four specific base elements 10, 11, 12 and 13. These elements will be manipulated in each interface to provide the user a clear view of the available components of the house.
  • Element 10 can contain a variable number of the other elements (10, 11, 12 and 13) .
  • This element works as a container to filter information for the user. It represents a real division of the house or a generic space to band the elements for an easier access.
  • the several components such as 40, 41, 42, 43, 44, 45, etc. can be virtually represented in 12 to allow the interface 30. B, 31. B, 32. B to show them to the user in a functional way.
  • These virtual objects will provide a bridge from the interfaces to the main server 50 allowing several operations to take place with minimal effort for the user.
  • Some of the house components can receive specific orders on how to act and these actions are represented in 14.
  • 14 is a group of commands that can be applied to the house components 12 (represented by the connection 104) , to other specific virtual components 11 (represented by the connection 100) and to any other generic entity (like playing a music file) .
  • Environments 11 is a group of 14 (represented by 101) , these are defined by the user allowing him to interact with several components at the same time with minimal effort. Standard behaviors from our daily life can be represented in 11 which allow a more efficient reaction to a desired state on the house content .
  • a variety of actions can be executed when certain and specific conditions are met, these condition evaluators are called triggers 15 and they can be triggered by a specific device 12 (a set of 12 is represented by 105) , a day, an hour, etc. depending on the user needs.
  • a routine 13 that is basically a set of actions 14 (a set of 14 is represented by 103) and a set of triggers 15 (a set of 15 is represented by 102) .
  • a routine allows the user to automatically execute his chosen actions 14 without the need of him being present at the time.
  • FIG. 2 is a schematic view of the software layer IB present in the core of the main server 50.
  • an xml file 54 is generated in 60 and uploaded into 50 with a list of addresses, display properties and action properties for that component.
  • This file 54 is going to be verified in 20 in order to automatically validate the received data and generate sets of rules on how the component will be displayed to the user and also which actions will be available (turning it on/off, etc.) .
  • system routines 23 and system environments 24 can be uploaded to the main server 50.
  • the approved generated rules 200 will be sent to a data conversion and distributor object 21 which will dictate which is the necessary code to be executed in runtime.
  • This object 21 has the most critical role in the entire design since it will dictate what will be ran in the server 50 and what will be shown to the user in the interfaces 30. B, 31.B, 32. B. Since only the necessary code is executed in runtime there is no waist of the main server 50 resources allowing a more efficient control over the house components 40, 41, 42, 43, 44, 45, etc.
  • a client is a gadget 30.A, 31.A, 32.A, etc. (computer, touch pad, smart phone, respectively) that runs a specific software 30. C, 31. C, 32. C, etc. which connects to the main server 50 to provide an interaction with the house components 40, 41, 42, 43, 44, 45, etc.
  • the generated rules 200 will be filtered by 21 and the ones aimed for the clients 30.A, 31.A, 32.A (the client rules are represented by 201) will be converted in 22 to a specific formatted Xml object.
  • the Xml object generated in 22 as a unique standard format (described further down) that allows the interfaces 30.B, 31.B, 32.
  • Routines 13 and environments 11 are shown to the user in 30. B, 31.B, 32.B, etc. but they are executed and verified in the server 50, also some routines and environments are restricted and are only available to server 50. Both the restricted and unrestricted routines/environments are allocated in the same virtual space (23 and 24) and both are generated by 21 after a thorough examination. All routines that satisfy all validation criteria's 202 (such as; a component exists and a device 25 is correctly associated to it, etc) are sent to 23 for coordination and management. The information generated in 23 is shared to the user if needed otherwise all actions are silent. This also applies to 203 (environments that satisfy all validation criteria's) in 24. Routines 23 and Environments 24 are defined as 11 and 13.
  • Rules 200 regarding house components 40, 41, 42, 43, 44, 45, etc. are created assuming that the received information 54 is accurate accordingly to the components settings.
  • the valid components rules 204 are sent to 25 which will embody a virtual element to represent each component 40, 41, 42, 43, 44, 45, etc. Their state is always supervised and when any changes occur all clients' software 30. C, 31. C, 32. C, etc. are alerted of that fact.
  • a component 40, 41, 42, 43, 44, 45, etc. communicates by 52 with the main server 50 its data is sent to the devices control 26 area that sends the data 205 to the intended virtual representation 25 of that component.
  • the control area 26 works as a bridge, filtering unnecessary data to the virtual components 25.
  • FIG. 3 is a schematic view of the system and its interrelations 1C.
  • Every house component that is able to communicate with another entity can be connected to the main server 50 throw 52.
  • This connection can differ from component to component, it can be an infra-red port, Bluetooth access, WAN, LAN, SMS's, etc. From now on a connection let's call "COMS" a connection between a component 40, 41, 42, 43, 44, 45, etc. and the main server 50.
  • COMS is variable, if a new connection type is needed the proper hardware/software is added to 50 to allow this "COMS” to happen with the intended component. Also “COMS” isn't limited to one type of connection several can take place at the same time for an instance we can have a LAN and a Bluetooth connection at the same time.
  • gadgets described in 30.A, 31.A, 32.A are a small example of a wide variety of possible host for the client software. Desktops, laptops, Ipods, Ipads, Pocket pes, cellular phones and many others, all belong to this bundle of gadgets. More Eg. HP Touch smart, iphone, Asus Touch, notebooks, etc.
  • Every gadget will need to have means to receive/send information, allowing the main server 50 to communicate the status of the house components 40, 41, 42, 43, 44, 45, etc., from now on let's call this mean "COM 2 " (communication between gadgets and the main server 50) .
  • "COM 2 " 30. D, 31. D, 32. D, etc. can differ from gadget to gadget and it can be an infra-red port, Bluetooth access, WAN, LAN, SMS's, etc. but for a "COM 2" to established the same communication mean must preferably be present in the main server 50 (the communication access is referenced as 51) .
  • the main server 50 is adaptable when a new "COM 2 " is needed its added in 51.
  • the main server 50 is a custom made piece of hardware; the software IB needs to be able to run in the selected equipment and for that some minimal requirements are necessary.
  • a 32Mz processor, 16 Mb of RAM memory and 5Mb of free disc space are the minimal requirements for the server 50 to work properly and efficiently.
  • the main server was built using a Marvell/Intel ARM Xscale PXA300 embedded microcomputer that runs at 208MHz, 32Mb SDRAM memory and 8Mb NOR Flash disk.
  • Generic equipment 60 is needed for an easier access to the xml file 54.
  • This file will be transferred from 60 by a specific software that will replace the old file 54 with a new one, by replacing the file 54 an internal event will be triggered in IB (more specifically in 20) that will update the main server 50 data and content.
  • IB internal event
  • IB internal event
  • another Xml file is generated 53.
  • An event will be sent to 51 which in turn will be transmitted to every "COM 2" (30. D, 31. D, 32. D, etc.) and 1A will take the necessary actions to retrieve 53.
  • the file 53 needs to implement a specific structure that allows 1A schema to be established. This structures needs to be standard which will allow the clients software 30. C, 31. C, 32. C, etc. to interpret it and dynamic in order to accustom any component 40, 41, 42, 43, 44, 45, etc. added to the server.
  • the filter 10 allows an accommodation of 11, 12 and 13 in an orderly manner and therefore a node containing this filter information is needed; the following xml node exposes an example of such information.
  • PATH - A filter 10 can contain other filters 10, this attribute show the current filter parents;
  • the data received by 26 when new information is sent from the house components 40, 41, 42, 43, 44, 45, etc. isn't standard and the clients software 30. C, 31. C, 32. C, etc. is expecting information that can be translated to the user.
  • the "server devices" 25 are responsible to convert that data into a specific standard format which allows a more efficient communication between both parties.
  • xml nodes shows, as an example, the current data types and new types can be added when needed at any moment .
  • NAME A generic name to differ every data type, this value is only used internally;
  • House components 40, 41, 42, 43, 44, 45, etc. can differ from each but also can have similar functions. Grouping different components into a single one to allow the user to interact with them as if only one raises the need to define an abstract concept and therefore the interface conceit was implemented.
  • An interface is an abstract type that exposes specific members that can receive or send information.
  • Several devices 12 are bundled into one allowing a more efficient way to control the entire group and for that purpose each one of those devices 12 need to implement the same interface. New interfaces can be added at any moment, as an example, the following xml list shows the currently used ones .
  • Interface NAME A name to distinguish each interface; Interface DESC - An attribute to add extra information if needed;
  • Member NAME A name to identify the member inside an interface, also this field can be easily accessed by "Interface NAME” . "Member NAME";
  • the devices 12 are provided with a specific type which also assigns them a specific interface (previously described) .
  • This not only works as a more precise filter for the house components 40, 41, 42, 43, 44, 45, etc. but also enables an easier grouping of the devices 12.
  • a device type can be added at any moment and as seen below they can implement the same interface. The following list shows as an example the currently used devices types .
  • NAME A name to differentiate each device type
  • a “device” represents a house component 40, 41, 42, 43, 44, 45, etc. There are several prerequisites that are needed to allow an improved interaction with those components.
  • Each “member” of the “device” expands a property that receives and/or sends information to the main server 50. For an instance if the "member" name was "percentcontrol” (appears in the "interfaces” above) , this member would allow the user to see or set the percentage value for a component, in a blind, zero would be the state closed and one hundred would be the state completely open, also in a dimming lamp, zero would be the state off and on hundred the light would be completely on.
  • All “devices” must preferably belong to a specific device type ("devtype") and this means they will have a specific "interface”.
  • the members that an "interface” possesses will be bestowed to the “device” allowing it to be controlled in a specific group.
  • a device that is a group will be a virtual representation of several house components 40, 41, 42, 43, 44, 45, etc. and not an actual component itself.
  • the “device” can support more “members” besides the ones used by the interface allowing a more precise control when the user specifically intends to interact with that component .
  • Device DEVTYPE The type of the device that component belongs to. It needs to be one of the "devtypes" previously defined and this linkage needs to be assured by IB;
  • Device GROUP If this device belongs to a group, values used are true and false;
  • Device STATELESS If this device will show any information to the user in 30. B, 31. B, 32. B, etc., values used are true and false;
  • ADDRESS An address used to communicate in 26 with the specific component that this device 25 represents;
  • the file 54 injected in 50 also needs to comply with a specific structure when providing data for new environments 24, routines 23 and components 40, 41, 42, 43, 44, 45, etc.
  • Actions Delay TIMESPAN - Delineates a delay between actions, this field represents a time value which will need to be abide before the following action can be executed; Actions Environment ID - Identifies which environment will be executed;
  • Actions Environment STATE - Activates or deactivates the environment, usually it is only used to activate the environment but can also be used to set the environments devices to their previous states;
  • a routine is basically an environment that does not need a direct action overt it. Routines 23 can execute themselves whenever there triggers conditions are met, since routines 23 are self sufficient they validate themselves in the main server 50. Being extremely similar to environments only the triggers differ in their structure. Devices 25 states and dates are basic elements for a routine to execute and accordingly to that the next structure was generated, as an example :
  • Routine ID An identifier to distinguish each routine, this value will also be used in 23;
  • Routine NAME If a name needs to be shown to the user in 30.B, 31. B, 32. B, etc. this will be the value used;
  • Routine ACCESS Declares if the routine is accessible by the users or if it is only a system routine;
  • Triggers Device ID - Identifies which device will be checked for any changes in its members
  • Triggers Device OPERATION - Can have several options which will compare if the current device value is "Equal”, “Lesser Then”, “Lesser or Equal”, “Bigger Then”, “Bigger or Equal” and “Different" to the triggers value;
  • Actions Delay TIMESPAN - Delineates a delay between actions, this field represents a time value which will need to be abide before the following action can be executed; Actions Environment ID - Identifies which environment will be executed;
  • Actions Environment STATE - Activates or deactivates the environment, usually it is only used to activate the environment but can also be used to set the environments devices to their previous states;
  • the devices structure resembles with the one previously exposed by the xml file 53 since its important all the information about the house components 40, 41, 42, 43, 44, 45, etc.
  • Both structures basically mainly differ in their members because the first one (file 53) is designed for the interfaces 30. B, 31. B, 32. B, etc. to communicate with the main server 50 (which is already standardized) and this one is targeted to the house components 40, 41, 42, 43, 44, 45, etc (they differ from each other) .
  • Every member has an address to communicate with the component, also what defines if that data should preferably be sent, received or even both must preferably be specified in it. Since all components 40, 41, 42, 43, 44, 45, etc.
  • Device DEVTYPE The type of the device that component belongs to. It needs to be one of the "devtypes" previously defined and this linkage needs to be assured by IB;
  • Device GROUP If this device belongs to a group, values used are true and false;
  • Device STATELESS If this device will show any information to the user in 30.B, 31. B, 32. B, etc., values used are true and false;
  • ADDRESS An address used to communicate in 26 with the specific component that this device 25 represents;
  • FIG. 4 is a schematic view of the changes that occur when a component 40, 41, 42, 43, 44, 45, etc. is interacted with.
  • a component 40, 41, 42, 43, 44, 45, etc. state is changed, either by user interaction, programmed task, etc. (represented by 70) that data is provided to the main server 50 through 52 (all new data sent is represented by 701) which will deliver it to 26.
  • 26 After receiving any valid data, 26 sends it to 25 in order to determine if the data contains new relevant values to be stored. If the data does not contain any new information all activity will end here otherwise two steps will be taken; validation of the routine triggers and the update of all clients 30. C, 31. C, 32. C, etc.
  • Every active client will then request the latest data to the main server 50 (represented by 702) .
  • the received data will be verified again in 1A because communication breaks can occur due to several factors (e.g. LAN connections failed, etc.), after validated, if interface changes need to occur (in this case a device state changed), 30. B, 31. B, 32. B, etc. will update themselves as less intrusively as possible (all these steps are represented as 71) .
  • routine triggers are listed in 23 and after receiving the necessary data from 25 (represented by 703) a fast search will take place in order to find the triggers that use the device in question. If a trigger is satisfied with the data from the device 25 and all other triggers of the same routine 23 are also satisfied, the routine 23 will execute by sending its device related actions to 25
  • FIG. 5 is a schematic view of the changes that occur when a component 40, 41, 42, 43, 44, 45, etc. is added to the main server 50.
  • a simple light (only uses On and Off commands) will be added to the main server 50, as it can be seen the light is named “Table Light” and will be place in a division called “Living Room”.
  • To manage the new light 26 will have to connect to the address "192.168.1.100” and send either the value "1” or "0", also 26 will be expecting a value "1” or "0” if any communication is received from that component because as it can be seen the option "outputinput" exposes that this is a two way communication component (unmatched commands are ignored) .
  • the distributor object 21 will verify if any code needs to be loaded to execute in runtime and in case that another "Light On/Off" was already in the main server no changes will be made. Both 23 and 24 will be disregarded because no environments or routines where added or removed from 54.
  • the necessary rules will be sent to 22 for it to create the specific formatted xml 53 intended for the clients 30.A, 31.A, 32.A, etc.
  • a communication addressed to 30. C, 31. C, 32. C, etc. will be made to announce that new parameters where added and all the active clients 30.A, 31.A, 32.A, etc. (the active clients are represented by 81) will retrieve this new data to update their 1A (the communications made are represent by 800) .
  • the new added component will also be represented as a virtual device in 25 when the proper component rules 204 are sent.
  • the necessary data is assigned to 26 for it to make an initial validation of the communications between the main server 50 and the new added component 82 (the communications are represented by 801) .
  • All the communications 801 may fail if 82 is not currently available or properly installed. Such failures does not affect the system behavior because both the main server 50 and the components 40, 41, 42, 43, 44, 45, etc. may work independently. Allowing such a process raises the possibility to pre-configure the main server 50 before installing it in the users' house. This also promotes and ensures the so much intended non intrusion.

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne les domaines des télécommunications et des systèmes électroniques, c'est-à-dire en permettant des communications et des services très intégrés dans un dispositif ou système, par exemple au domicile ou dans d'autres environnements résidentiels. Ladite invention comporte un serveur principal, une couche à plusieurs protocoles et équipements, une interface utilisateur/sous-systèmes physiques, et extrait des divisions et une hiérarchie respective, des dispositifs, des programmes et des actions respectives et des conditions de déclenchement, des environnements et une hiérarchie d'actions respective. L'invention comporte un module générateur de fichier xml et un vérificateur de paramètre capable d'exporter un ensemble de règles, ledit fichier décrivant des propriétés d'adresse, d'affichage et d'action d'un dispositif particulier. Le module convertisseur et distributeur de données, à savoir à partir desdites règles, sélectionne le code nécessaire pour une exécution par le serveur principal et filtre un ensemble de règles pour le module de spécification de client. En d'autres termes, ce module convertit le contenu xml filtré en un format spécialement adapté à des dispositifs connectés au serveur principal.
PCT/PT2010/000029 2010-07-07 2010-07-07 Commande de dispositif multiservice résidentiel pour système de communication à plusieurs protocoles et dispositifs intégrés, et son procédé de fonctionnement Ceased WO2012005617A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/PT2010/000029 WO2012005617A1 (fr) 2010-07-07 2010-07-07 Commande de dispositif multiservice résidentiel pour système de communication à plusieurs protocoles et dispositifs intégrés, et son procédé de fonctionnement

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/PT2010/000029 WO2012005617A1 (fr) 2010-07-07 2010-07-07 Commande de dispositif multiservice résidentiel pour système de communication à plusieurs protocoles et dispositifs intégrés, et son procédé de fonctionnement

Publications (1)

Publication Number Publication Date
WO2012005617A1 true WO2012005617A1 (fr) 2012-01-12

Family

ID=43769290

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/PT2010/000029 Ceased WO2012005617A1 (fr) 2010-07-07 2010-07-07 Commande de dispositif multiservice résidentiel pour système de communication à plusieurs protocoles et dispositifs intégrés, et son procédé de fonctionnement

Country Status (1)

Country Link
WO (1) WO2012005617A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070061020A1 (en) * 2005-09-15 2007-03-15 Bovee Jeffrey K System for home automation
US20070241945A1 (en) * 2006-03-16 2007-10-18 Seale Moorer User control interface for convergence and automation system
US20070290882A1 (en) 2004-09-29 2007-12-20 Matrix S.R.L. Domotic System Provided With Centralized Controlling and Managing Hardware and Software for Remote Management of Domestic Appliances, Apparatuses, Installations, Devices and Machines Existing in a House
US20100052843A1 (en) * 2008-09-02 2010-03-04 Apple Inc. Systems and methods for saving and restoring scenes in a multimedia system
US20100138007A1 (en) * 2008-11-21 2010-06-03 Qwebl, Inc. Apparatus and method for integration and setup of home automation

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070290882A1 (en) 2004-09-29 2007-12-20 Matrix S.R.L. Domotic System Provided With Centralized Controlling and Managing Hardware and Software for Remote Management of Domestic Appliances, Apparatuses, Installations, Devices and Machines Existing in a House
US20070061020A1 (en) * 2005-09-15 2007-03-15 Bovee Jeffrey K System for home automation
US20070241945A1 (en) * 2006-03-16 2007-10-18 Seale Moorer User control interface for convergence and automation system
US20100052843A1 (en) * 2008-09-02 2010-03-04 Apple Inc. Systems and methods for saving and restoring scenes in a multimedia system
US20100138007A1 (en) * 2008-11-21 2010-06-03 Qwebl, Inc. Apparatus and method for integration and setup of home automation

Similar Documents

Publication Publication Date Title
Nakamura et al. Feature interactions in integrated services of networked home appliances
US10719200B2 (en) Architecture for remote control of IOT (internet of things) devices
US20140128994A1 (en) Logical sensor server for logical sensor platforms
CN105357245A (zh) 一种基于云服务及ZigBee技术的智能家居系统及其设计方法
Zimmermann et al. The universal control hub: An open platform for remote user interfaces in the digital home
Sommaruga et al. DomoML-env: an ontology for Human Home Interaction.
Kastner et al. Building Automation Systems Integration into the Internet of Things The IoT6 approach, its realization and validation
CN108234408A (zh) 一种物联网网关联动控制方法及物联网网关
CN109104473A (zh) 一种控制方法、控制装置、控制系统及网关
CN113168334A (zh) 数据处理方法、装置、电子设备及可读存储介质
Kim et al. Home appliance control framework based on smart TV set-top box
Sai et al. Smart home messenger notifications system using IoT
Eckl et al. Smart home challenges and approaches to solve them: A practical industrial perspective
KR101573594B1 (ko) 서비스 의도에 기반하여 동적 매쉬업 서비스를 제공하는 서비스 시스템 및 방법
CN115296949A (zh) 智能家电设备远程控制方法、装置和系统
Wang et al. An ontology-based actuator discovery and invocation framework in home care systems
Takatsuka et al. Design and implementation of rule-based framework for context-aware services with web services
WO2012005617A1 (fr) Commande de dispositif multiservice résidentiel pour système de communication à plusieurs protocoles et dispositifs intégrés, et son procédé de fonctionnement
Bansal IoT applications in smart homes
Kistler et al. An adaptive network architecture for home-and building environments
Preuveneers et al. Intelligent widgets for intuitive interaction and coordination in smart home environments
KR20070038532A (ko) 실제 가전기구의 동작을 소프트웨어 공학적으로 모델에서재생산하기 위한 방법, 장치 및 소프트웨어 모듈
Bjelica et al. A concept and implementation of the embeddable home controller
Bonino et al. Technology independent interoperation of domotic devices through rules
Di Ciccio et al. The homes of tomorrow: service composition and advanced user interfaces

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10745023

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 22/04/2013)

122 Ep: pct application non-entry in european phase

Ref document number: 10745023

Country of ref document: EP

Kind code of ref document: A1