It has been pointed out in our forum discussions that using HTTP as a protocol for a home automation consoles is not necessarily ideal.
The argument builds on the connectionless nature of HTTP and the need for a bidirectional information exchange between the ORB and panels and consoles.
For example, a home owner physically turning off lights from the switch will generate an event that will update the ORB and panels/consoles of the status of the light. This type of bidirectional communication is not natural for request-response oriented HTTP protocol.
However, the above can be solved (and has been solved) for HTTP using various polling techniques. The counter-argument is that this is inefficient use of resources. While the counter-argument is correct, the level and amount of events being generated is such that it should be well managed even with an ill-fitting HTTP protocol framework.
On the other side of the decision weighs the undisputed ubiquity of HTTP as a protocol, the wealth of knowledge in handling and processing HTTP protocol and existing tools and libraries to do it.
Therefore, HTTP is the choice of communication protocol for the initial implementations. Should it prove inadequate, better custom designed protocols are of course considered.