An Operating System for the Home

HomeOS: An OS for the home HomeOS Video recording Remote unlock Climate control HomeStore Z-Wave, DLNA, UPnP, etc. HomeOS logically centralizes all devices Users interact with HomeOS, not individual devices HomeStore helps find compatible devices and apps

HomeOS architecture Application layer Management layer Device functionality layer (DFL) Device connectivity layer (DCL) Tasks Control Device Topological Heterogeneity source handled

DCL and DFL (Drivers) DCL provides basic connectivity to devices – Discovery – Abstract differences in protocols – Connectivity DFL exports device functionality as a service – Services are protocol-independent – Exposed as roles and operations – Kernel does not parse or understand services – Allows subscriptions (e.g. when light is toggled) – Applications do not require changes App layer Mgmt layer DFL DCL

Application layer Apps compose abstract rules from DFL Management layer interposes on accesses Manifests help with compatibility testing – Lists of mandatory and optional features – E.g., mandatory: {TV, SonyTV}, {MediaServer} optional : {Bass Speaker} App layer Mgmt layer DFL DCL

Interaction between Apps and Drivers Drivers Device (camera, thermostat) Core Platform Exports Ports Exposes Ports Applications

What are ports (classical definition) Hardware ports sockets that a device can plug into e.g., printer ports, mouse ports? Software ports locations/addresses that processes run e.g., Http (port 80), ssh (port 22) processes can read and write from ports

Ports in Home Lab (HomeHub) Ports are uses as a communication abstraction between Drivers  Platform (kernel)  Applications All modules (drivers, kernel, applications) can read/write using ports HomeHub ports are associated with Roles Read/write data Driver platform Applications

What are Roles? Roles define service and capabilities that a device offers Example role for a pan-tilt-zoom video camera: up, down, left, right, getImages Roles may be shared between devices same roles can be provided by multiple devices e.g. getTemperature() is a role that can be provided by a temperature sensor and a thermostat

Interaction between Apps and Drivers Drivers Device (camera, thermostat) Core Platform Exports Ports with Roles Exposes Ports with Roles Applications Bind Ports Invoke Roles implements roles

How would a camera device work? Drivers Pan/Tilt/Zoom Camera Core Platform Port roles (CameraRoles: move camera up, down,Left, right) Scan for ports that exports a CamerRole Camera Viewer Application Bind Ports Invoke Roles implements roles Invoke the roles exported by CameraRole

How would you implement different components like kernel, drives, and apps Design goals you want isolation between the kernel, drivers, and applications Sandbox execution of different components? How would you implement something like this?

What are different ways of implementing this? Processes High communication overhead High overhead for switching processes on and off Threads substantial amount of sharing minimal isolation

.Net provides Application domains to implement this? Somewhere in between process and threads The common language infrastructure runs as a process and the sub processes or applications runs within the CLI process Each application domain has a separate virtual address space Provides isolation Exception in one domain does not affect other application domain, each application domain are assigned different access levels, and multiple threads can run in one domain

How would you implement ports Use a framework called.Net Remote There are two ways to pass Objects from one process to the other By object copying and passing object references System.AddIn.AddIn Attributes provides a fairly complex way of implementing the communication using a similar idea. App domain 1 App domain 2 proxy responsible for marshalling/unmarshalling

Implications to Garbage collection Object passed across boundaries are garbage collection It is slower than garbage collection inside app domains Each application domain has a separate virtual address space

Programming Abstraction for HomeHub Drivers and Apps are modules Extends ModuleBase class provides four methods (start, stop, portregistered, portderegistered) Uses the System.AddIn.AddIn(“Appname”) attribute Modules export services and can use service Drivers and Apps therefore theoretically can export and use services Services are operations defined in roles associated with ports Input and output parameters of operations are of ParamType

ParamType Used for transferring data between modules using ParamType class has two fields MainType: this can be an integer, image, sounds, txt MainType can be simple of complex object Value: captures the actual object Example ParamType (maintype=image, value=byte[])

Helper Functions Logger class Generate log messages When a module is instantiated, HomeOS passes a pointer to the log object Redirect messages to a log or stdout logger.log(); SafeThread Focusses on communication between modules

Example of Using SafeThread Logic inside the thread Parameter passed to the thread

Writing Applications Two main steps for writing applications Discover Interesting ports Building application logic

Example (discovering and registering ports) Port object Gets all the ports that are registered with the HomeOS platform This serves a dual purpose: (1) callback when a new port is registered (2) determine ports of interest Finding a port of interest

Making calls to operations in roles Synchronous invocation port Role arguments Operations

Making calls to operations in roles (Asynchronous)

Putting all of this together lets see an example.

HomeOS apps + Web interface.Net App Web App Use WCF (Windows Communication Foundation) Allows communication between.Net and non-.Net entity This is unlike.Net Remote that is between.Net modules WCF framework

Web app is written in HTML+Javascript Web App (html, index.html) Invokes Javascript functions Calls made into.NET application

How does WCF work Javascript functions interface Service class that implements the interface Interfaces define the contracts contracts are the functionality that the server implements and the client uses has two attributes [ServiceContract] – interface attribute [OperationContract] – function attribute [WebInvoke] --- function attribute stating that the function would be invoked through Javascript/WCF Rest interface client server

Every HomeOS app has a index.html Dashboard | Dummy Dummy Application Update

The Javascript function function ShowDummyPortsInfo() { new PlatformServiceHelper().MakeServiceCall("webapp/GetReceivedMessages", "", GetReceivedMessagesCallback); } function GetReceivedMessagesCallback(context, result) { var portsInfo = result.GetReceivedMessagesResult; $("#DummyList").html(''); for (i = 0; i < result.GetReceivedMessagesResult.length; i++) { $("#DummyList").append(portsInfo[i] + " "); }

How to instantiate the service from the server DummyService dummyService = new DummyService(logger, this); serviceHost = new SafeServiceHost(logger,typeof(IDummyContract), dummyService, this, Constants.AjaxSuffix, moduleInfo.BaseURL()); serviceHost.Open(); string binarydir = moduleInfo.BinaryDir(); //directory of where the dlls and libraries are string baseurl = moduleInfo.BaseURL(); // baseurl for the application appServer = new WebFileServer(moduleInfo.BinaryDir(), moduleInfo.BaseURL(), logger); Start the server service

Lets take a look at the implementation of the service class

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

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 args = new List () { new ParamType(0) };

Writing Drivers (setting up Roles)

Writing Drivers (instantiating ports) portInfo = GetPortInfoFromPlatform(name) InitPort(portInfo) BindRoles(port, RoleList)

Writing Drivers logic (synchronous)

Putting all of this together lets see an example.

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

What do Scouts do Discover devices and report to the platform Host the UI for custom device configuration Hand over control to the platform by pointing to the generic device addition page