This page last changed on Oct 01, 2010 by marcf.

Following the example of iKNX I am thinking about the serverless console.

Serverless means the panel talks directly to the hardware without going through the ORB. This obviously only is relevant to simple control scenarios but nonetheless relevant. Take iKNX. When someone presses a button, the app opens a socket connection to the IP gateway and sends the CEMI frame.

The advantages of this approach are obvious and the reasons why iKNX is widely. Namely simplicity. You can upload an app to the iphone/android and off you go, you do not need to download and install and ORB (not that it is complicated).

The usage with composer would remain the same, namely that you develop panels in composer but the deployment is a file to the console and that is it.

We have been having this discussion already both at CEDIA and over email. Here is a transcript of email:

Lutron on iphone git me thinking about orbless. There are usually 2
parts to connecting to the gateway, either a lookup (a la GC) or a
configuration (a la KNX) but those are different binaries. The
formatting of the packets is the complicated part. HOWEVER once you
have configured the string to be sent over the connection i wonder how
much we can just put in the button information. So in essence,
instead of having a handle to the command in controller we have the
actual CEMI frame already prepared as a byte array and that is what
gets sent. This way all the fancy computing and class generation
happens IN COMPOSER and in the panel we just have a byte array
representation of the command to be sent AS IS. Is this making sense?

That's how it would work yes. It is one generic IP connector which you configure with a protocol specific payload.

This works for the simple case. It won't however work for over-engineered protocols like KNX due to them being... well, over-complicated. They are chatty in bidirectional ways.

So then you need a generic IP connector that you can feed with a script, instead of a basic string payload: "if you receive this, then send that, else..."

So this is a little more work. It is the right generic approach though, although it may in some cases be simpler to just implement a specific handler for protocol X instead. It's the trade-off between doing one generic right, or writing zillion little specific implementations.

And KNX goes further with its own complications that it does actually require a heartbeat management on the connection, so now we are talking about looping structures so a fairly complicated scripting on top of the generic IP connector. Had the brainiacs used TCP instead of UDP....

So the change would need to be that the information in the iphone and
android are just generic ORB and there is a keyword that says
"LOCAL:protocol" in which case we delegate to the local protocol IP
connection and pass it the byte array to be sent.
Everything else remains the same. Is this making sense to you? let me
know if I am missing something obvious. If it does I will go ahead
and start a more public thread around the idea.

Your general thinking is exactly right but missing the obvious "devil is in the details..."

In any case, this points to the payload being IN THE BUTTON. no
"mapping" on the server.

Yes, it will be like this, this is already been discussed/planned:

In panel.xml (the command element is merged from controller.xml):

<button id="24" name="">
<image src="home.png" />

<command protocol = "knx" >
<property name = "command" value = "on"/>
<property name = "groupAddress" value = "0/0/4"/>
<property name = "DPT" value = "1.001"/>

There's no mapping on the server, by definition, of it being serverless. The point here being that this still requires a specific protocol implementation for KNX (and possibly others) embedded into the console implementation, not merely a payload.

A generic payload would require a script element here, instead of command. The scripting would mean a new protocol can be embedded into the console without changing the application.

ORBless is already in 3.0 roadmap.

What I was trying to say was that the command would have an IP payload
already configured. Meaning that there is no real reason to have all
the classes on the console to generate the payload. So the composer
generates the binary string.
<command protocol="local:knx">
<property name = "payload" value = "2898ad737290ff345212ad020"/> // this is the properly formated array it is generated in composer.
and then the implementation on the console only deals with socket
protocol, nothing else. In the case of KNX that is still a headache.
In the other cases (GC) it would be rather a simple and somewhat
generic implementation.
Document generated by Confluence on Jun 05, 2016 09:31