Forums : OpenRemote & KNX
This page last changed on May 25, 2009 by jef2000.
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.
|Document generated by Confluence on Jun 05, 2016 09:31|