Abstract:
A method and system for remote multi-tenant facility management are presented. The invention comprises a client-side user interface communicatively coupled to a system management unit. The system management unit includes multiple standalone management components that monitor and execute system inspection, rules processing, data logging, and other asynchronous processing. The system includes interfaces for users to create automations that serve as a proxy for controlling remote devices connected to the system. The system management unit includes multiple system processes running autonomously. The system management unit is further communicatively coupled to one or more remote devices through one or more Device Access Providers in the multi-tenant facility for monitoring and/or control of the remote devices.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    Field of the Invention 
         [0002]    Embodiments of the invention relates to the field of automation. More specifically, the invention relates to method and systems for remote multi-tenant facility management. 
         [0003]    Description of the Related Art 
         [0004]    Multi-tenant facilities such as office buildings and apartment complexes include controllable devices in tenant units and in common areas. Controllable devices include locks, switches, sensors, speakers, thermostats, etc. Some of these devices are controlled via hubs made by third party companies such as Icontrol, Mios, and Smart Things. Some devices are standalone devices with their own built-in hubs (or API) such as Nest Thermostats, Honeywell Wi-Fi thermostats, and Lockitron Bolt. 
         [0005]    Devices such as Nest thermostats and Honeywell Wi-Fi thermostats communicate through their API. In the near future, it is expected that there would be other devices where the API lives on the actual device eliminating the need for an API layer controlled by a third Party. 
         [0006]    For example, August lock has a lock that can be controlled out of the box via Bluetooth. However, there is a secondary hub device that provides Wi-Fi access to the August lock device. The problem is that when power goes out in such a system, access to the device through Wi-Fi is lost, though it is still accessible via Bluetooth. 
         [0007]    However, as these devices and their proprietary APIs proliferate in a multi-tenant facility, there is a need for central and remote management and automation of control of these devices to improve quality of life. 
       BRIEF SUMMARY OF THE INVENTION 
       [0008]    One or more embodiments of the invention are directed to a method and systems for remote multi-tenant facility management. Systems and methods of the present invention facilitate automation and control of devices within a network in a multi-tenant facility with one or more tenant units in the multi-tenant facility having one or more remote devices. For instance an embodiment may comprise gateways/hubs placed within a rental residence to facilitate communication with automated devices present within the network. The system is configured to be hub and device agnostic because typical multi-tenant facilities, in embodiments of the present invention, are made up of one or more third party gateways placed within one or more tenant units to facilitate communication with automated devices present within the network. 
         [0009]    In one or more embodiments of the present invention, each of the remote devices, e.g. switches, locks, thermostats, smoke detectors, moisture detectors, carbon monoxide detectors, speakers, etc. may communicate with other systems of the present invention via Device Access Providers (DAPs). Communication may be via Wi-Fi, Bluetooth, or any other suitable wireless communication system. 
         [0010]    In one or more embodiments, each Device Access Provider (DAP) acts as a Hub/Gateway allowing communication with and control of one or more remote devices in a property. Each multi-tenant facility may comprise multiple Device Access Providers that are managed by systems and methods of the present invention, with one or more remote devices managed by each DAP. 
         [0011]    In one or more embodiments, a remote device and a DAP may be an integrated unit. For instance, where the Application Program Interface (API) lives on the device, the device may be operated as a DAP. 
         [0012]    One or more embodiments of the present invention further comprise a system management unit. The system management unit comprises standalone management components that monitor and execute system inspection, rules processing, data logging, and other asynchronous processing. The system includes interfaces for users to create automations (executed by system processes) that serve as a proxy for controlling devices; these automations can be shared with other users in the system and external to the system. The system management unit may comprise multiple system processes running autonomously. 
         [0013]    In one or more embodiments, the system management may communicate with the DAPs through one or more wireless protocols, e.g. Bluetooth, Wi-Fi, 3G, LTE, etc. The system management unit controls the actions of a device and monitors the state of the device through the DAP connected to the device. 
         [0014]    In one or more embodiment of the present invention, the systems and methods further comprises a client-side user interface. The client-side user interface may comprise a mobile application on a mobile client, e.g. an iOS or Android device such as smartphones, tablets, smartwatches, etc. using a Mobile App. The client-side user interface may also comprise a web client on any smart device or computer system. 
         [0015]    One or more embodiments of the invention may be configured for different classes of users. For instance, the system may include a Resident User; Property Owner/Manager User; and System Operator. 
         [0016]    A Resident User may be classified as one or more residents within a tenant unit. Each Resident User may have access to devices within their tenant unit using a web client or a mobile application, e.g. iOS or Android applications. Each tenant unit can have multiple resident users with unique logins and their own automation sets. 
         [0017]    A Property Owner/Manager may be classified as management of the multi-tenant unit. A Property Owner/Manager may access all aggregated devices for their communities using a web-based management platform or a mobile management application, e.g. iOS or Android. Each property can have multiple managers and owners with unique logins and distinct automation sets. 
         [0018]    A System Administrator is a user with access to manage all devices, units, communities and system data using a web-based application. 
         [0019]    In one or more embodiments, the system management unit includes a rules engine that matches patterns in device event states to create automations. These states can be coupled with other external conditions, e.g. weather, to create a desired outcome. For instance, the result may be matched to a desired or defined action by acting on system controlled resources, e.g. devices, or by creating notifications. Rules can be defined by residents, property owner /managers and system administrators. 
         [0020]    For example, a resident user may define a rule wherein the system obtains information about the user through the mobile app, e.g. his/her location, traffic/congestion on their route home and environmental conditions. Using these and other information, the system may know when he/she leaves work and how long it will take to get home. Thus, the rule may comprise an action of turning the temperature up/down at the right time to get the tenant unit to the preferred temperature by the time the renter/owner gets home. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0021]    The above and other aspects, features and advantages of the invention will be more apparent from the following more particular description thereof, presented in conjunction with the following drawings wherein: 
           [0022]      FIG. 1  is an architectural representation of the logical interconnection of components, hardware and software, for management of a multi-tenant facility in accordance with one or more embodiments of the present invention. 
           [0023]      FIG. 2  is an architectural representation of the system management unit showing a breakdown of the Autonomous Processing Unit and the logical connections for of a multi-tenant facility in accordance with one or more embodiments of the present invention. 
           [0024]      FIG. 3  illustrates a general-purpose computer and peripherals that when programmed as described herein may operate as a specially programmed computer capable of implementing one or more methods, apparatus and/or systems of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0025]    The present invention comprising methods and systems for remote multi-tenant facility management will now be described. In the following exemplary description numerous specific details are set forth in order to provide a more thorough understanding of embodiments of the invention. It will be apparent, however, to an artisan of ordinary skill that the present invention may be practiced without incorporating all aspects of the specific details described herein. Furthermore, although steps or processes are set forth in an exemplary order to provide an understanding of one or more systems and methods, the exemplary order is not meant to be limiting. One of ordinary skill in the art would recognize that the steps or processes may be performed in a different order, and that one or more steps or processes may be performed simultaneously or in multiple process flows without departing from the spirit or the scope of the invention. In other instances, specific features, quantities, or measurements well known to those of ordinary skill in the art have not been described in detail so as not to obscure the invention. Readers should note that although examples of the invention are set forth herein, the claims, and the full scope of any equivalents, are what define the metes and bounds of the invention. 
         [0026]    For a better understanding of the disclosed embodiment, its operating advantages, and the specified object attained by its uses, reference should be made to the accompanying drawings and descriptive matter in which there are illustrated exemplary disclosed embodiments. The disclosed embodiments are not intended to be limited to the specific forms set forth herein. It is understood that various omissions and substitutions of equivalents are contemplated as circumstances may suggest or render expedient, but these are intended to cover the application or implementation. 
         [0027]    The term “first”, “second” and the like, herein do not denote any order, quantity or importance, but rather are used to distinguish one element from another, and the terms “a” and “an” herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item. 
         [0028]    One or more embodiments of the present invention will now be described with references to  FIGS. 1-3 . 
         [0029]    Systems and methods of the present invention facilitate automation and control of devices within a network in a multi-tenant facility.  FIG. 1  is an architectural representation of the logical interconnection of components, hardware and software, for management of a multi-tenant facility in accordance with one or more embodiments of the present invention. 
         [0030]    As illustrated, one or more embodiment of the system  100  of the present invention comprises a client-side user interface, e.g. Mobile Client  102  and Web Client  104 . The Mobile Client  102  may comprise one or more mobile applications, e.g. management App  102 M and Resident App  102 R. The mobile client  102  may be an iOS device, an Android device, or any smart device such as smartphones, tablets, smartwatches, etc. capable of communicating wirelessly through a computer network. 
         [0031]    In one or more embodiments, the client-side user interface may also comprise a web client  104  on any smart device or computer system. Web client  104  may comprise one or more mobile applications, e.g. Management App  104 M and Resident App  104 R. 
         [0032]    In one or more embodiments of the invention, the client-side interface may be configured for different classes of users. For instance, the system may include a Resident User; Property Owner/Manager User; and System Operator. 
         [0033]    A Resident User may be classified as one or more residents within a tenant unit. Each Resident User may have access to devices within their tenant unit using a web client or a mobile application, e.g. iOS or Android applications. Each tenant unit can have multiple resident users with unique logins and their own automation sets. 
         [0034]    A Property Owner/Manager may be classified as management of the multi-tenant unit. A Property Owner/Manager may access all aggregated devices for their communities using a web-based management platform or a mobile management application, e.g. iOS or Android. Each property can have multiple managers and owners with unique logins and distinct automation sets. 
         [0035]    A System Operator is a user with access to manage all devices, units, communities and system data using a web-based application. 
         [0036]    Resident Application 
         [0037]    One or more embodiments of the present invention comprise Resident App  102 R on a mobile client  102 ; Resident App  104 R on Web Client  104 ; and Resident App  206  in the System Management Unit  200 . In one or more embodiments, Resident App  104 R in Web Client  104  is a web interface to Resident App  206 . 
         [0038]    In one or more embodiments, Resident App  102 R communicates by passing messages to a client application listener, e.g. Resident App Listener  208 . The messages may be exchanged with the Resident App Listener  208  using a standard data interchange language, e.g. JSON (Java Script Object Notation) implemented as RESTful web services using Java 2 Platform, Enterprise Edition (J2EE) technologies. 
         [0039]    In one or more embodiments, Resident App Listener  208  converts the messages to and from the Resident App  102 R to match the message format in Resident App  206  web application, which may be implemented using various client side markup languages, e.g. HTML, CSS, etc., and various JavaScript frameworks. 
         [0040]    Resident App Listener  208  is the set of web services that allow communications between system management unit functionality and mobile applications, e.g. Resident App  102 R. In one or more embodiments, Resident App Listener  208  may be configured to receive inbound commands from third party systems interfacing with the system of the present invention, e.g. application services provided by Yardi and RealPage. 
         [0041]    In one or more embodiments, Resident App user interface, e.g.  102 R or  104 R, provides the user the capability to inspect the device state. For example, the User Interface allows a resident to examine the state of all devices under their control. They can drill down to an individual device level allowing the user to see multiple properties of the device. Thus, for example, a user is driving to work and can&#39;t remember if they locked the door to their unit. The user can pull over and access the system using the Resident App  102 R in his/her mobile device, and inspect to see if they did leave the door unlocked. 
         [0042]    In one or more embodiments, Resident App user interface, e.g.  102 R or  104 R, provides the user the capability to control one or more devices. For example, the User Interface allows a user to change the state of all manipulable devices under their control. They can drill down to an individual device level allowing the user to control multiple properties of the device. Thus, in the same example above, if the user determines that the door is unlocked, they can issue user-driven/custom commands to lock the door. 
         [0043]    In one or more embodiments, Resident App user interface, e.g.  102 R or  104 R, provides the user the capability to create Rules. Rules are generally automations that may cause the change of state of one or more devices based on one or more events or combination of events, e.g. device state, sensor readings in the tenant unit, weather conditions, resident state, etc. Rules may also provide various types of notifications based on one or more events. For example, if a moisture detector under a hot water heater detects moisture, the system can send an automated voice call, SMS, and/or Email alerting residents and/or managers to the condition. Additionally, the system may notify third party web services depending on the condition/event so that the third parties can act within their own processes. For instance, the system may notify the third party web service such that the third party&#39;s processes initiates its own maintenance sequence, e.g. sending a maintenance manager out in response to the event. 
         [0044]    The resident app  102 R may provide a visual interface that allows the creation of system executable scripts. These scripts, when executed for the user by the system, can asynchronously control multiple remote devices associated with the user on the user&#39;s behalf. 
         [0045]    One or more embodiments of the system of the present invention may be configured to collect real-time information about a user through the Resident App  102 R, e.g. his/her location, traffic/congestion on their route home, environmental conditions, etc. The system may be configured to use the information to supplement device state information for automation. For example, based on his/her location, traffic/congestion on their route home, and environmental conditions the system may determine when the user leaves work and how long it will take to get home. Thus, a cost saving automation may comprise an action of turning the temperature up/down at the right time to get the tenant unit to the preferred temperature by the time the resident gets home. 
         [0046]    Management Applications 
         [0047]    One or more embodiments of the present invention comprise Management App  102 M on a mobile client  102 ; Management App  104 M on Web Client  104 ; and Management App  204  in the System Management Unit  200 . In one or more embodiments, Management App  104 M in Web Client  104  is a web interface to Management App  204 . 
         [0048]    In one or more embodiments, Management App  102 M communicates by passing messages to a client application listener, e.g. Management App Listener  202 . The messages may be exchanged with the Management App Listener  202  using a standard data interchange language, e.g. JSON (Java Script Object Notation) implemented as RESTful Web services using Java 2 Platform, Enterprise Edition (J2EE) technologies. 
         [0049]    In one or more embodiments, Management App Listener  202  converts the messages to and from the Management App  102 M to match the message format in Management App  202  web application, which may be implemented using various client side markup languages, e.g. HTML, CSS, etc., and various JavaScript frameworks. 
         [0050]    Management App Listener  202  is the set of web services that allow communications between the system management unit functionality and mobile applications, e.g. Management App  102 M. In one or more embodiments, Management App Listener  202  may be configured to receive inbound commands from third party systems interfacing with the system of the present invention, e.g. application services provided by Yardi and RealPage. 
         [0051]    In one or more embodiments, Management App user interface, e.g.  102 M or  104 M, provides the user the capability to control one or more devices in a multi-tenant facility. Management App  204  generally has the capability to control one to many back-end devices. For instance, management may configure the system such that common area devices are shared with all residents or just a subset of residents allowing them access to devices and automated functionality in the common areas of the multi-tenant facility. 
         [0052]    In one or more embodiments, Management App user interface, e.g.  102 M or  104 M, provides the user the capability to manage residents, devices within units and communities in a multi-tenant facility. For example, Management App  204  may be used to manage accounts for all users accessible by a specific management account. In one or more embodiments, Management App  204  provides the capability to create, delete and edit resident accounts, unit accounts, and community accounts. 
         [0053]    In one or more embodiments, Management App user interface, e.g.  102 M or  104 M, provides the user the capability to inspect state of devices within the system. For example, the User Interface provides a management user the ability to examine the state of all devices registered to the system. They can drill down to an individual device level allowing the management user to see multiple properties of a device. 
         [0054]    In one or more embodiments, Management App user interface, e.g.  102 R or  104 R, provides the management user the capability to control one or more devices in the system. For example, the User Interface may be configured to allow a management user to change the state of all manipulable devices in the system. They can drill down to an individual device level allowing the management user to control multiple properties of the device. An exemplary management user control may be as follows: A moisture detector in the system detects a water leak in a resident&#39;s bathroom. The front office dispatches a maintenance worker to investigate. The maintenance worker shows up at the front door, using the management application maintenance worker may unlock the front door and enter the residence. 
         [0055]    In one or more embodiments, Management App user interface, e.g.  102 M or  104 M, provides the user the capability to create and modify bulk rules. That is, rules to allow the system to asynchronously control devices, e.g. thermostats. Bulk rules creation eases the burden of creating automations for one to many units at a time by providing templates to create bulk automations. Users can create/modify their own templates. 
         [0056]    For instance, assuming a property manager has five communities that have three managed common areas each. This is a total of fifteen managed common units. Also, assuming the business hours is from 7 am-7 pm and management wants the temperature set at 72 degrees during business hours, but 62 degrees outside of business hours. Management can create individual automations, i.e. rules, for all fifteen of these offices, or they can use the bulk rules capability to create a single automation that will be applied to each unit. 
         [0057]      FIG. 2  is an architectural representation of the system management unit  200  showing a breakdown of the Autonomous Processing Unit  214  and the logical connections for of a multi-tenant facility in accordance with one or more embodiments of the present invention. As illustrated, the client app listener, e.g. Management App Listener  202  and Resident App Listener  208 , are coupled to link processing unit  214 A. 
         [0058]    In one or more embodiments, the link processing unit is configured not to listen to internal processes or states in order to act. Thus, when the Client App Listener detects links, i.e. HTTP calls, in the Resident App  102 R or Management App  102 M, the links are executed immediately by devices (e.g. web servers, etc.) outside of system. These HTTP calls are handled immediately by that group of generic processes/web-services referred to herein as the Client App Listener, i.e. Management App Listener  202  and Resident App Listener  208 . 
         [0059]    As illustrated, one or more embodiment of the system  100  of the present invention further comprises Device Control and Broadcaster  210 ; Rules Engine  212 ; Autonomous Processing Units  214 ; Device Event Listener  216 ; and Event Queue  218  in the system management unit  200 . System  100  further comprises one or more DAPs  106 , e.g. Device Access Provider  1  to Device Access Provider n, where n is any number greater than or equal to 1. In a typical implementation, n is greater than 1 and may be much greater than 1. 
         [0060]    Device Control Broadcaster 
         [0061]    The Device Control Broadcaster  210  is the component responsible for communicating desired device changes to Device Access Providers  106 . In one or more embodiments, Device Control Broadcaster  210  manages and is responsible for translating device commands into messages for broadcast to Device Controller  108  in Device Access Providers (DAP)  106  through their required communication types, e.g. RESTful web services, Firebase, Thrift, custom SDKs, proprietary Enterprise Service Bus, etc. In one or more embodiments, Device Control Broadcaster  210  is implemented as a Java/Groovy managed component. Those of skill in the arts would appreciate that the use of Java/Groovy is exemplary and that other object-oriented programming languages may be used for Device Control Broadcaster  210  without departing from the spirit of the present invention. 
         [0062]    In one or more embodiments, Device Control Broadcaster  210  is coupled to Management App  204  and Resident App  206  for direct control of devices registered in the system, e.g. device  112  through Device Controller  108  of DAP  106 . 
         [0063]    In one or more embodiments, Device Control Broadcaster  210  is coupled to Rules Engine  212  for automated control of devices registered in the system, e.g. device  112  through Device Controller  108  of DAP  106 . 
         [0064]    Device Control Broadcaster  210  abstractly knows what types of DAPs it is coupled to, the API for the DAP, and handles the translations appropriately. 
         [0065]    Device Event Listener 
         [0066]    The Device Event Listener  216  is the component responsible for receiving device event states through Device Access Providers  106 . In one or more embodiments, Device Event Listener  216  is responsible for translating device states from Event Broadcaster  110  into messages to be queued in Event Queue  218 . Event Broadcaster  110  in Device Access Providers (DAP)  106  sends states of device  112  to Device Event Listener  216  using its communication type, e.g. RESTful web services, Firebase, Thrift SDK, custom SDKs, proprietary Enterprise Service Bus, etc. In one or more embodiments, Device Event Listener  216  is implemented as a Java/Groovy managed component. Those of skill in the arts would appreciate that the use of Java/Groovy is exemplary and that other object-oriented programming languages may be used for Device Event Listener  216  without departing from the spirit of the present invention. 
         [0067]    Rules Engine 
         [0068]    One or more embodiments of the present invention comprise a Rules Engine  212 . Rules Engine  212  comprises rules (or automations) that provide users the capability to automate system actions based on certain conditions/criteria. Thus, a rule in the rules engine  212  may be configured to trigger a specific set of actions when a specific condition occurs. For instance, a user may create a rule that when their front lock unlocks, they want the hall light to come on. 
         [0069]    The rules engine may be applied to every system event through processing units, e.g. autonomous processing units  214 , assigned to watch those specific events (e.g. device-based, time-based, etc.). For all events that occur, the rules engine discovers applicable rules and executes them. 
         [0070]    In one or more embodiments, the rules engine provides the system the capability to match patterns in device event states to create automations. These states can be coupled with other external conditions, e.g. weather, to create a desired outcome. For instance, the result may be matched to a desired or defined action by acting on system controlled resources, e.g. devices, or by creating notifications. Rules can be defined by residents, property owner /managers and system administrators. 
         [0071]    In one or more embodiments of the present invention, the rules engine  212  comprises time-based automations/rules. For instance, the system monitors when the defined time requirement is reached and executes the associated automation(s)/rule(s). 
         [0072]    An example of a time-based automation/rule could be: At 7:15 pm turn on Christmas Tree Lights and front Hallway Light. 
         [0073]    In one or more embodiments of the present invention, the rules engine  212  comprises link-based automations/rules. For example, by a user clicking a link in the client-side interface, e.g. Resident App  102 R, the event is logged and then the desired automation is triggered. There are a number of different expiration schemes for links, e.g. use-based, time-based, condition-based and event-based. 
         [0074]    In one or more embodiments of the present invention, the rules engine  212  comprises device-based automations. Device or event based automations/rules are those actions that are triggered by state changes in devices. 
         [0075]    An example of an event based automation/rule could be: If Front Door Lock Unlocks, Turn On Front Hall Light. 
         [0076]    In one or more embodiments of the present invention, the rules engine  212  comprises User-driven Automations. User-driven rules are “Run Now” automations/rules that allow the user to manually run automations without a condition being applied (i.e., no device event change or time requirement.) User-driven rules can be used to create an overall state for a user&#39;s residence. For example, a user may create a “Run Now” automation for “Shut Down House For Night”, which turns off all switches and locks all external locks in the house. 
         [0077]    Autonomous Processing Units 
         [0078]    In one or more embodiments, autonomous processing units  214  comprises one or more processing units, e.g. Link-based events processing, e.g.  214 A; Time-based events processing, e.g.  214 B; Device-based events processing, e.g.  214 C; and User-driven/custom events processing, e.g.  214 D. These processing units may be designed to sit and watch for one or more conditions in Event Queue  218 , for example. For instance, a device&#39;s state has changed and it&#39;s been reported to the system via device event listener  216  and logged in event queue  218 , e.g. a lock has been unlocked or a light has been turned out. Time-based processing unit  214 B watches for changes in time. Both Custom Processing unit  214 D and Link Processing unit  214 A are initiated by a specific user action (e.g. a button was clicked or a link was clicked). In any case, these processors sit and watch for changing conditions. When a condition they&#39;re watching changes, they use the Rules Engine to determine if the change is actionable. If it is actionable, the action(s) registered to it are executed. If it&#39;s not, the condition is logged. 
         [0079]    It should be noted that the autonomous processing units, e.g.  214 A through  214 D, may be implemented as virtual machines in a server computer, software objects, etc. 
         [0080]    One or more embodiments of the present invention comprise a multi-tenant facility, with one or more tenant units in the multi-tenant facility having one or more remote devices. As illustrated, each remote device  112  is coupled to a Device Access Provider  106 . Thus, each of the remote devices, e.g.  112 , communicates with other systems of the present invention via Device Access Providers (DAPs), e.g.  106 . 
         [0081]    In one or more embodiments, each Device Access Provider  106  acts as a Hub/Gateway allowing communication with and control of one or more remote devices  112  in a property. Each multi-tenant facility may comprise multiple Device Access Providers that are managed by systems and methods of the present invention, with one or more remote devices managed by each DAP. 
         [0082]    In one or more embodiments, a remote device and a DAP may be an integrated unit. For instance, where the Application Program Interface (API) lives on the device, the device may be operated as a DAP. 
         [0083]    Device Access Providers (DAP) 
         [0084]    In one or more embodiments of the present invention, Device Access Providers  106  provide the system with the capability to manage multiple devices in a unit. The system is abstracted in such a way that DAPs are treated as interfaces. Each DAP  106  may be easily added to the system and the specifics of working with each DAP is hidden from the rest of the system thus creating separation, i.e. each DAP has a unique identification in the system. This separation of concerns allows the system management unit to simply send commands to the interface, confident that the implemented interface will appropriately perform the request. 
         [0085]    In one or more embodiments of the present invention, Device Access Providers  106  provide the system with the capability to control remote devices in a tenant unit. Each tenant unit can have multiple devices, each with a unique DAP. The system only needs to communicate with the DAP, treating it like yet another interface within the system. Other embodiments may also include configurations wherein a Dap controls multiple remote devices. In such configurations, each remote device within the DAP&#39;s control should have a unique identification within the DAP. 
         [0086]    In one or more embodiments of the present invention, Device Access Providers  106  provide the system with the capability to receive state change information from remote devices  112 . Thus, each DAP is able to push state change information into the system. This data can then be acted upon by the Rules Engine allowing automations and notifications. This inbound state change data also may also be used by data processes to suggest appropriate automations, e.g. for cost savings, etc. 
         [0087]    Each DAP may interface with the system via third party dictated technologies such as RESTful web services, Fire base SDK, Thrift SDK, other custom SDKs, etc. 
         [0088]    Remote Devices 
         [0089]    Remote devices  112  are devices in a unit/common area in a multi-tenant facility that control access to the unit/common area, affect the state of the unit, provide information regarding the state of the unit, etc. Examples of remote devices include switches, locks, thermostats, smoke detectors, moisture detectors, carbon monoxide detectors, speakers, etc. 
         [0090]    In one or more embodiments of the present invention, remote device  112  communicates to the system via Device Access Providers (DAPs)  106  using a wireless protocol, e.g. Z-wave, Zigbee, Insteon, and Wi-Fi, Bluetooth, etc. 
         [0091]    In one or more embodiments, the system management may communicate with the DAPs through one or more wireless protocols, e.g. Bluetooth, Wi-Fi, 3G, etc. The system management unit controls the actions of a device and monitors the state of the device through the DAP connected to the device. 
         [0092]      FIG. 3  diagrams a general-purpose computer (e.g. server) and peripherals, when programmed as described herein, may operate as a specially programmed computer capable of implementing one or more methods, apparatus and/or systems of the solution described in this disclosure. Specifically, the system management unit  200  may be implemented as computer system  300 . Processor  307  may be coupled to bi-directional communication infrastructure  302  such as communication infrastructure system bus  302 . Communication infrastructure  302  may generally be a system bus that provides an interface to the other components in the general-purpose computer system such as processor  307 , main memory  306 , display interface  308 , secondary memory  312  and/or communication interface  324 . 
         [0093]    Main memory  306  may provide a computer readable medium for accessing and executed stored data and applications. Display interface  308  may communicate with display unit  310  that may be utilized to display outputs to the user of the specially-programmed computer system. Display unit  310  may comprise one or more monitors that may visually depict aspects of the computer program to the user. Main memory  306  and display interface  308  may be coupled to communication infrastructure  302 , which may serve as the interface point to secondary memory  312  and communication interface  324 . Secondary memory  312  may provide additional memory resources beyond main memory  306 , and may generally function as a storage location for computer programs to be executed by processor  307 . Either fixed or removable computer-readable media may serve as Secondary memory  312 . Secondary memory  312  may comprise, for example, hard disk  334  and removable storage drive  316  that may have an associated removable storage unit  318 . There may be multiple sources of secondary memory  312  and systems implementing the solutions described in this disclosure may be configured as needed to support the data storage requirements of the user and the methods described herein. Secondary memory  312  may also comprise interface  320  that serves as an interface point to additional storage such as removable storage unit  322 . Numerous types of data storage devices may serve as repositories for data utilized by the specially programmed computer system. For example, magnetic, optical or magnetic-optical storage systems, or any other available mass storage technology that provides a repository for digital information may be used. 
         [0094]    Communication interface  324  may be coupled to communication infrastructure  302  and may serve as a conduit for data destined for or received from communication path  326 . A network interface card (NIC) is an example of the type of device that once coupled to communication infrastructure  302  may provide a mechanism for transporting data to communication path  326 . Computer networks such Local Area Networks (LAN), Wide Area Networks (WAN), Wireless networks, optical networks, distributed networks, the Internet or any combination thereof are some examples of the type of communication paths that may be utilized by the specially program computer system. Communication path  326  may comprise any type of telecommunication network or interconnection fabric that can transport data to and from communication interface  324 . 
         [0095]    To facilitate user interaction with the specially programmed computer system, one or more human interface devices (HID)  330  may be provided. Some examples of HIDs that enable users to input commands or data to the specially programmed computer may comprise a keyboard, mouse, touch screen devices, microphones or other audio interface devices, motion sensors or the like, as well as any other device able to accept any kind of human input and in turn communicate that input to processor  307  to trigger one or more responses from the specially programmed computer are within the scope of the system disclosed herein. 
         [0096]    While  FIG. 3  depicts a physical device, the scope of the system may also encompass a virtual device, virtual machine or simulator embodied in one or more computer programs executing on a computer or computer system and acting or providing a computer system environment compatible with the methods and processes of this disclosure. In one or more embodiments, the system may also encompass a cloud computing system or any other system where shared resources, such as hardware, applications, data, or any other resource are made available on demand over the Internet or any other network. In one or more embodiments, the system may also encompass parallel systems, multi-processor systems, multi-core processors, and/or any combination thereof. Where a virtual machine, process, device or otherwise performs substantially similarly to that of a physical computer system, such a virtual platform will also fall within the scope of disclosure provided herein, notwithstanding the description herein of a physical system such as that in  FIG. 3 . 
         [0097]    While the invention herein disclosed has been described by means of specific embodiments and applications thereof, numerous modifications and variations could be made thereto by those skilled in the art without departing from the scope of the invention set forth in the claims.