This page last changed on May 25, 2009 by jef2000.

Hi,

First of all I really appreciate your initiative that bring more openness in the closed world of home automation, but I'm a little bit disappointed about the KNX integration. I recently read that iKNX joined OpenRemote, but from what I know about iKNX and OpenRemote, the 2 are architecturally completely opposite. While OpenRemote is based on the ORB as a central layer talking on one side with the systems (home automation, tv, media, hifi) and on the other side with the control devices (remote controls, smartphones, PC's, ...), iKNX connects both sides directly without intervention of the ORB. For OpenRemote, I don't see the benefit of having a KNX stack on iphone. Shouldn't the KNX stack be running on the ORB? And you already have a panel software for iphone, no?

I found another disapponting thing in the composer UI. When creating a KNX button, you can set a label and a group address, but I can't figure out what value will be send to that group address. To be usable, it should be at least possible to specify which value to send (ON/OFF for switching actuators,  up/down/stop or percentage for dimmers and blinds, ....).

Another remark is that in KNX protcol stack, group addresses are just a mean to interconnect the group objects. It would be much cleaner to implement all layer of the stack and be able to get/set values of group objects instead of short-circuiting it by writing directly to group addresses. For unidirectional functionality, this short circuit doesn't make a big difference, but if one day you want to have some status feedback displayed on the UI, it will play an important role, because multiple group addresses can be assigned to a single group object and if you associate only one of them to the status indication, you'll not be guaranteed to have the right value displayed.

All KNX devices programmed with the ETS software define those group objects with the list of associated group addresses and the communication flags. I think it would be good to keep this structure with which KNX professionals are familiar.

For KNX bus access, I have a good experience with EIBD and I think it offers a good solution for bus access because it support a wide range of bus access devices (RS232, USB, ethernet, TPUART, ...) and provides an interface to communicate with the bus without having to deal with specificities of the different buas access devices. On top of EIBD, I have created my own project to implement the higher layers of the KNX stack and some automation features. Its' called LinKNX ( http://sourceforge.net/projects/linknx/ ). It uses EIBD for bus access, allows definition of group objects with their data-type, flags and list of group addresses and provides the primitives to set and get object values in text form. I defined an XML over TCP interface to communicate with the web UI. The UI can interact with linknx using requests like "<write><object id='kitchen_dimmer_val' value='80' /></write>" or "<read><object id='bedroom1_current_temp' /></read>" and receive somthing like "<read status='success'><object id='bedroom1_current_temp'>21.5</object></read>".

By using linknx XML over TCP interface, openremote controller software could easily get KNX bus access by just writing text values to object ID's, without having to worry about protocol details. And linknx could benefit from the multiple UI possibilities offered by OpenRemote.

Kr,

Jean-Fran├žois

For OpenRemote, I don't see the benefit of having a KNX stack on iphone. Shouldn't the KNX stack be running on the ORB? And you already have a panel software for iphone, no?

Different strokes for different people.

There's a KNX stack both on ORB and iPhone. If you want to get into some iPhone action quickly with an existing KNX installation, you can do that with iKNX. If you want to get more into integration, scripting, event processing scenarios, you'll want an ORB. But ORB is an extra component to install.

I found another disapponting thing in the composer UI. When creating a KNX button, you can set a label and a group address, but I can't figure out what value will be send to that group address. To be usable, it should be at least possible to specify which value to send (ON/OFF for switching actuators, up/down/stop or percentage for dimmers and blinds, ....).

Because what you are looking at is Milestone 1. As stated, milestone 1 is infrared only. Milestone 3 will have KNX integration (ON/OFF/DIM at first). iKNX already has this.

We do use Calimero as the Java implementation of KNX stack at the moment, I think you are well aware of it.

Welcome to OpenRemote and look forward to hearing more about linknx. Stop by to Amsterdam on June 3rd if you can.

– Juha

Posted by juha at May 25, 2009 22:33

Hi,

our "ORB" is an Apple Mac mini and I mean we have put all "benefits" in a deamon running on Mac ready !! Also, full bidirectional KNX/IP support. I've seen the tube video where you control Frontrow by IR. We can control FR and all other application with a simple XML based protocol over UDP or TCP. An open protocol gateway allow users to expand the service interface. In this case users can amplify very easy the base protocol. So you can control external devices like TV's, Beamers, Amplifires etc. over the same protocol stack...

Also available... an native application for iPhone or iPod touch to make your own free configurable user interface... It's very easy to handle and runs very stable.

For me it's of note to know how to integrate our protocol to openRemote... is it possible and what i need start...

kr
Mike

Posted by meudenbach at May 27, 2009 16:51

There's a couple of feature branches currently in the subversion that you can look at for tips how to add new protocols to the controller. These will make it to the trunk eventually. Notice that there's a slight API incompatibility change between M2 and M3 but this will be trivial to fix (the current feature branches are at M2 level).

The emerging pattern you should observe from all those contributions is the creation of an EventBuilder implementation which is responsible for mapping from the XML model (in controller.xml) to Java object model. More precisely to a Java Event implementation. The Event itself is parameterized by the EventBuilder (in other words, a OpenRemote Controller event is a 'Command' in GOF pattern terminology), and is responsible for implementing the required protocols based on the given parameterization (telnet, x10, knx, IP, HTTP, etc. serialization protocols).

This is in short how the current 1-way (from controller to device) communication works. The events are triggered by the HTTP (REST) front-end of the controller.

HTH,

– Juha

Posted by juha at May 27, 2009 17:33

thx Juha for your answer. I can't believe that this "model" will be succeed in future... but may I can be mistaken.

kr

Mike

Posted by meudenbach at May 28, 2009 14:31

Thanks for your help and good luck with your project!

Posted by juha at May 28, 2009 16:06
Document generated by Confluence on Jun 05, 2016 09:31