Somewhat overdue, a few updates on what has been happening in the OpenRemote code repository lately.

Summarizing shortly, we've completed and released the source code for OpenRemote 1.0 Milestone 1 (M1). This is the first milestone checkpoint towards the final OpenRemote 1.0 release and it includes all the necessary code to deploy an OpenRemote infrared control end-to-end – sending commands from your iPhone or iPod Touch through the OpenRemote Box (ORB) to the infrared controlled end-device such as your TV, stereo or set-top box.

There's a couple of videos we've posted to demonstrate this in action: Infrared Demo Video and Jean-Luc's It works! blog.

What Is a Milestone?

Milestones are developer releases intended as stable checkpoints for community developers to try and test features in our releases, and provide their own tweaks, fixes and extensions. Milestones are not intended as full product releases. In order to use OpenRemote milestones, you should be very comfortable with all the required development tools:

• Java Development Tools including Apache Ant for building the code from source and deploying software on Apache Tomcat
• Linux development tools including installing Linux distributions, compiling and installing LIRC (Linux Infrared Remote Control) and deploying Tomcat instances

That being said, we do intend to provide more complete documentation on how to use the above tools and install OpenRemote milestones for development and testing. Stay tuned for that.

Where's the Source?

For developers comfortable with a pure source release and very little supporting documentation (we are happy to give you a hand and answer questions on the forums and chat), you can checkout the source code from the subversion repository:

  svn co http://openremote.svn.sourceforge.net/svnroot/openremote/tags/OpenRemote_1_0_0_Milestone1

The source release infrastructure is still pretty raw. You have been warned.

What you will get from the checkout is:

1. Beehive 1.0 Beta 3
2. UI Composer 1.0 Beta 2
3. Controller 1.0 Beta 2
4. iPhone Console 1.0 Beta 1

Beehive and UI Composer

The versions of Beehive and UI Composer are already deployed and available for you to use at http://composer.openremote.org/demo.
You can browse for infared remote model and compose an user interface to deploy on the iPhone/iPod Touch. The "Download" button will give you the required configuration files for the controller.

Controller

The controller implementation is a Tomcat deployable WAR (Java Web Archive) which you can deploy more or less wherever you can get Tomcat and LIRC to run. It works on our ALIX reference implementation, B202 with Ubuntu or your regular Linux PC. Please check the information about the infrared hardware we've tested with and instructions on how to get LIRC + CommandIR working.

iPhone Console

The iPhone Console is the user interface renderer for iPhone and iPod Touch. It will render the user interface based on the configuration files generated by the UI Composer. In order to get the iPhone console running you will need a Mac OS X and Xcode IDE environment. We are still going through the paperwork (faxing documents back and forth) with Apple but expect an OpenRemote App Store to appear very soon where you can directly download the iPhone distributables.

What's Next?

We are well on our way towards Milestone 2 (M2) and for those loving the life on the bleeding edge, you can already download the source code from the trunk of the OpenRemote subversion repository. The current M2 includes improvements to the iPhone user interface with ability to create multiple pages of buttons (accessible with the iPhone swipe gesture), buttons of different sizes and customizing the look & feel with uploadable icon images. We will be branching and tagging M2 codebase in the next few weeks to make those features and codebase more consumable to developers as well.

On the community contribution side, we have been extremely delighted to see Marcus Redeker already pick up the raw codebase and modifying it to suit his home installation with IRTrans (IP to infrared), JetPort (IP to RS-232), EZcontrol (IP to proprietary RF) and MythTV (via telnet) integration completed. Marcus is already using OpenRemote to control his A/V set up at home, and we are working on getting these contributions shared with the rest of the community.

So expect more release news, more code-drops and more OpenRemote to arrive in the coming weeks,

– Juha

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).