Configuration Phase
A deployment of an OpenRemote system typically starts with modeling and configuration of your system online. Using the Beehive device database you can browse for the components to include in your setup. Today, Beehive contains infrared codes for various IR controlled devices recorded by the LIRC community. We expect to continue to contribute to and extend this part of the database. We are looking at what other configuration lends itself to easy sharing of codes via Beehive. Examples include devices with telnet interfaces (e.g. MythTV) and RS-232 interfaces.
Another aspect of Beehive is storing "private" (non-shared) device configuration information. For certain cases (e.g. KNX group addresses and device properties bound to them), sharing the configuration publicly doesn't make sense as the semantics change with every installation. For these cases Beehive may act as a convenient store of information uploaded by the installer, making the house or building design easier to manage and maintain over time.
The second part of the configuration phase is composing of user interfaces for panel hardware. Today that means composing layout, buttons and other UI elements for iPhone or iPod Touch. We will support other panel devices with generic web interfaces and/or Flash application(s). The user interface will be fully customizable and can be created separately for each individual user.
The initial user interface may be constructed by the installer based on the mappings and model he has created. However, the goal of the UI composer is to become easy enough for an end-user to create small tweaks to the interface, reorganizing buttons and other UI elements. To reach this goal, expect the UI Composer to evolve into a clearly separate view from protocol mapping, reducing exposure to low-level protocol details and addressing.
You can try the current iteration (M1) of both UI Composer and Beehive at http://composer.openremote.org/demo. Please note that it hasn't been adjusted to all common web browsers yet, using Firefox is recommended for now.
Deployment Phase
The control mappings and user interface layout(s) can be download from the UI Composer once completed. What you will get from the download is a single ZIP file with all the required elements. These need to be deployed on the ORB.
Note that this deployment phase is very much unfinished at this stage (it is manual) and will still be unfinished with the 1.0 release. For an end-user product the deployment(s) should be automated with user control over which components, component versions and configurations are deployed on the ORB. This is mainly the reason why OpenRemote 1.0 release targets advanced technical users only (for details of the necessary technical skills, see the Code Updates blog).
The deployment files are:
- controller.xml
- iphone.xml
- lircd.conf
- panel.irb
The controller.xml is the main configuration for mappings. An incoming HTTP request is mapped to an event that contains the information how to connect from the ORB to the device and execute the desired command. The iphone.xml contains the user interface layout which the iPhone console reads and renders. The panel itself therefore has no knowledge of the mappings, it's a "dumb" user interface in a sense.
The lircd.conf is a standard LIRC configuration file containing all the selected infrared remotes in the configuration. This is used by the infrared events in the controller when IR extension to ORB is enabled.
The panel.irb you can ignore. It contains the UI Composer state information in case you want to upload your configuration back to the UI Composer to make additional changes.
Runtime
The runtime is disconnected from the online tools and operates independently between the panels, ORB and controlled devices. The transport layer between panels and ORB is HTTP currently, with ORB exposing its API as a REST interface. As the user generates UI events from the panel, these are transmitted and mapped to events that operate on different media and control protocols via the controller.xml mapping in the ORB.
Each integrated media has an associated "event" to handle the wire protocol or communication required to connect to the device. Adding new ones involves creating a new event implementation. Already contributions have come in for generic IP socket, HTTP and telnet events to integrate with IP gateways and devices supporting these interfaces.
The flow in the first iteration is one-way with commands being sent. The two-way communication capability for status updates is clearly on our radar though. Also various bus architectures to decouple services are not addressed in the first iterations. While the controller so far is very simple, we are generating a lot of ideas from community feedback which will eventually be addressed with a more complete controller implementation (rules, scripting support, decoupled services, etc).
