Some updates on what's happening in this branch:

Control Protocol SPI

Between X10 protocol handler (which is a service wrapper around Wade's Java X10 project) and the mock INSTEON protocol handler have started sketching an SPI for control protocol implementations. The first rough cut is about 1/3 done which is to say the API to register with the router to receive a controller-wide addresses is there. The messages (commands) currently pushed towards protocol handlers are still in their wire (serialization) formats. This part needs fleshing up with Java API to reduce the overall burden of the plugin developer on parsing and manipulating the wire format. That should be the part 2 of 3 of the SPI.

For the Java allergic, one of the reasons to build things up from the wire format is to ensure other runtimes are able to integrate easily. But at the moment Java bindings are in the focus, alternative runtimes need to provide their own bindings above the serialization format if they wish to avoid accessing it directly.

Note to Will: noted your proposal on message formats. It may be worth consolidating once the initial revisions of the software are done. I don't think there are fundamental incompatibilities.

The 3/3 part of the SPI will be handling the incoming messages (events) from the devices (messages other than device registrations). This remains largely undone although Java X10 API (and to some extent RXTX API) provides guidance.

Direct Serial Access

Idea is to provide a generic low-level serial I/O component, create an API and provide a scripting language bindings that enables scrpting languages to be used for quick serial protocol integration of various devices. Reviewed RXTX for this and while it works well over virtual null modem the implementation is likely to cause issues with a dynamically updated Java runtime (static class initialization blocks, use of Class.forName(), java.lib.path requirements for native libraries).

The alternative is to spawn serial communication to a separate process from the main controller -- this would work best with a standalone native serial port implementation though. Consolidating other uses of RXTX (i.e. Java X10) to a single daemon process for native layer I/O would be beneficial.

At the moment looking at possibilities to workaround some of the RXTX Java bindings that might cause issues.

X10 Integration

Java X10 project has been integrated by providing a service wrapper that can be deployed to the ORC container. The service wrapper provides configuration options to deploy X10 either in-vm or as an external process (see points about consolidating these into a single native daemon above). The current Java X10 version used supports CM11A and CM17A serial modules. While Java X10 is obviously tested by the community the integration to ORC has not been tested yet lacking X10 hardware.