Systems for Smart Home Automation Nilanjan Banerjee Published in NSDI (Networked Systems Design and Implementation) 2012

Writing Drivers Five steps for writing applications Instantiating Roles Instantiating Ports Binding roles to ports Registering the port with the platform Implementing functions for handling operation invocations The application layer is where developer-written code runs to use and compose the devices in the home. The key feature that HomeOS provides at app layer is the ability to ascertain if an application is compatible with the home. - Today, when users bring software home, they have little assurance that it will work in their environment. HomeOS applications provide a manifest describing what services they need to function. - Helps check compatibility. - If not compatible, HomeOS can also determine what additional devices are needed. Explain manifests. Our current manifest descriptions cannot encode complex requirements (e.g., two devices in the same room). - They handle what we deem as the common case. - Can extend later if needed

Roles Data Structure Base class: Role (Your role will extend Role) e.g.: DummyRole:Role Roles have Operation Operation (name, arguments, returnvalue) name: :dummy:->echo (Name, function name) arguments, returnvalue of type ParamType List<VParamType> args = new List<VParamType>() { new ParamType(0) }; The application layer is where developer-written code runs to use and compose the devices in the home. The key feature that HomeOS provides at app layer is the ability to ascertain if an application is compatible with the home. - Today, when users bring software home, they have little assurance that it will work in their environment. HomeOS applications provide a manifest describing what services they need to function. - Helps check compatibility. - If not compatible, HomeOS can also determine what additional devices are needed. Explain manifests. Our current manifest descriptions cannot encode complex requirements (e.g., two devices in the same room). - They handle what we deem as the common case. - Can extend later if needed

Writing Drivers (setting up Roles) The application layer is where developer-written code runs to use and compose the devices in the home. The key feature that HomeOS provides at app layer is the ability to ascertain if an application is compatible with the home. - Today, when users bring software home, they have little assurance that it will work in their environment. HomeOS applications provide a manifest describing what services they need to function. - Helps check compatibility. - If not compatible, HomeOS can also determine what additional devices are needed. Explain manifests. Our current manifest descriptions cannot encode complex requirements (e.g., two devices in the same room). - They handle what we deem as the common case. - Can extend later if needed

Writing Drivers (instantiating ports) portInfo = GetPortInfoFromPlatform(nameofdevice) port = InitPort(portInfo) List<VRole> listroles = new List<Vrole>(){Role.Instance} BindRoles(port, RoleList) The application layer is where developer-written code runs to use and compose the devices in the home. The key feature that HomeOS provides at app layer is the ability to ascertain if an application is compatible with the home. - Today, when users bring software home, they have little assurance that it will work in their environment. HomeOS applications provide a manifest describing what services they need to function. - Helps check compatibility. - If not compatible, HomeOS can also determine what additional devices are needed. Explain manifests. Our current manifest descriptions cannot encode complex requirements (e.g., two devices in the same room). - They handle what we deem as the common case. - Can extend later if needed

Writing Drivers logic (synchronous) The application layer is where developer-written code runs to use and compose the devices in the home. The key feature that HomeOS provides at app layer is the ability to ascertain if an application is compatible with the home. - Today, when users bring software home, they have little assurance that it will work in their environment. HomeOS applications provide a manifest describing what services they need to function. - Helps check compatibility. - If not compatible, HomeOS can also determine what additional devices are needed. Explain manifests. Our current manifest descriptions cannot encode complex requirements (e.g., two devices in the same room). - They handle what we deem as the common case. - Can extend later if needed

Putting all of this together lets see an example. The application layer is where developer-written code runs to use and compose the devices in the home. The key feature that HomeOS provides at app layer is the ability to ascertain if an application is compatible with the home. - Today, when users bring software home, they have little assurance that it will work in their environment. HomeOS applications provide a manifest describing what services they need to function. - Helps check compatibility. - If not compatible, HomeOS can also determine what additional devices are needed. Explain manifests. Our current manifest descriptions cannot encode complex requirements (e.g., two devices in the same room). - They handle what we deem as the common case. - Can extend later if needed

Scouts Scouts are used for discovering devices Discovers devices in the environment Makes the core platform aware of the devices User can query the platform for discovered devices that are not part of the platform Device setup is performed through HTML pages Initial page enables setting up the configurations The application layer is where developer-written code runs to use and compose the devices in the home. The key feature that HomeOS provides at app layer is the ability to ascertain if an application is compatible with the home. - Today, when users bring software home, they have little assurance that it will work in their environment. HomeOS applications provide a manifest describing what services they need to function. - Helps check compatibility. - If not compatible, HomeOS can also determine what additional devices are needed. Explain manifests. Our current manifest descriptions cannot encode complex requirements (e.g., two devices in the same room). - They handle what we deem as the common case. - Can extend later if needed

Core function that you have to implement in Scouts public List<Common.Device> GetDevices() { Device device = new Device("dummydevice", "dummydevice", "", DateTime.Now, "HomeOS.Hub.Drivers.Dummy", false); Device device1 = new Device("dummy2device", "dummy2device", "", DateTime.Now, "HomeOS.Hub.Drivers.Dummy2", false); //intialize the parameters for this device device.Details.DriverParams = new List<string>() { device.UniqueName }; device1.Details.DriverParams = new List<string>() { device1.UniqueName }; return new List<Device>() {device, device1}; } The application layer is where developer-written code runs to use and compose the devices in the home. The key feature that HomeOS provides at app layer is the ability to ascertain if an application is compatible with the home. - Today, when users bring software home, they have little assurance that it will work in their environment. HomeOS applications provide a manifest describing what services they need to function. - Helps check compatibility. - If not compatible, HomeOS can also determine what additional devices are needed. Explain manifests. Our current manifest descriptions cannot encode complex requirements (e.g., two devices in the same room). - They handle what we deem as the common case. - Can extend later if needed