Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jef2000

Pages: [1]
Developers / Re: knx, linuxmce, eib part, ... help?
« on: July 22, 2008, 02:20:38 pm »

Of course, if you add to lmce all that linknx could offer to it (storing the actual value, decoding binary messages coming from the bus, handle multiple group-adresses, ...) Then there is nothing more that linknx can offer. But If I understand correctly, the things you are speaking about are "not yet the case but would be really easy to do".
So my proposal was to have a quick solution based on GSD/ruby and linknx because it seems easy to do and doesn't need changes in lmce code. If nobody is interested in it, I'll put it in the fridge until I have a lmce core at home and decide at that time what's the best solution based on the alternatives that will be available then.

Good work,


Developers / Re: knx, linuxmce, eib part, ... help?
« on: July 21, 2008, 10:28:39 pm »


The way KNX connection is currently implemented in lmce is something like a big hack in the KNX protocol definition. Basically, it shortcuts all the upper layers dfined by the protocol and force you to have a 1 to 1 matching between devices and EIB group addresses. It's enough for  basic functionalities but most "advanced" EIB configurations like the ones made by professionals will suffer from these restrictions.

Example: you have a staircase lighting that you can switch on using group address ga1. When the time is over, the actuator switch the light off and send the OFF information on another group address (say ga2). In the pushbuttons for this stairs light, I program ga1 as the main address and ga2 as the second one so that the status coming back on ga2 will update the state of the object and the next time you push it, it will know the light was off and turn it on again. Without this status feedback on ga2, the pushbutton doesn't know that the light was shutdown by the staircase timer of actuator and thus will think the light is still on and try to turn it off.
So if you have only one group-address by device, the status of the light will not update according to it's real state in the above case. That the kind of limitations we can avoid by using linknx.




Developers / Re: knx, linuxmce, eib part, ... help?
« on: July 20, 2008, 02:33:10 pm »

I understand that in lmce philosophy, all the linknx configuration must be done via the lmce admin interface and agree with it.
For the import of the ETS group address, can you tell me how you export it from ETS, what does the exported file look like? text file?
In linknx, the configuration of a communication object can be as simple as <object id="light_stairs" gad="1/1/5"/> or as complicated as <object id="light_stairs" gad="1/1/6" type="EIS6" init="persist" flags="crwtu">Stairs light<listener gad="1/1/206"/><listener gad="1/1/106"/></object>
Is it possible to store all this infomation in the lmce SQL db?

Perhaps I understood something wrong, but I was thinking that the dcegen command was not needed if I use GSD and ruby.
What does "overoll" mean?



Developers / Re: knx, linuxmce, eib part, ... help?
« on: July 19, 2008, 12:23:54 am »

I'm not a ruby expert, but the ruby GSD seems to be a very simple way to interface with linknx.
Suppose that linknx is configured correctly with all group objects and listening on TCP port 1028 (the default)

I think that something like this in section "#Process Receive Command For Child #384" would do the job:
Code: [Select]
cmdId           = cmd.id_                                   # Command ID: ON, OFF, SET LEVEL
cmdTo           = cmd.devidto_                              # Device ID in LinuxMCE
devPort         = device_.childdevices_[cmdTo].devdata_[12] # 12 contains a port/channel
childType       = device_.childdevices_[cmdTo].devtemplid_  # Template ID to know type of device: switch or dimmer

case cmdId
      when 192 #192 is ON                     
           command = '<write><object id="'+devPort+'" value="on"/></write>\n\4'           
      when 193 #193 is OFF                       
           command = '<write><object id="'+devPort+'" value="off"/></write>\n\4'
      when 184 #184 is Level of dimmer
           dim_level = cmd.params_[76]
           command = '<write><object id="'+devPort+'" value="'+dim_level+'"/></write>\n\4'                   


I'm not a ruby expert, so perhaps the single/double quotes are wrong but anybody knowing XML and ruby would be able to fix it.
Every command sent to linknx must be terminated by ASCII character 4 (EOT).

I'm not sure what is the range for the dim_level value, but linknx expect something between 0 and 255.

With the above code, the status returned by linknx is ignored, but in most case it will be <write status="success"/> so no need to worry, at least for a proof-of-concept implementation.

Only the sending of commands from lmce to linknx is supported in the above code, and only ON/OFF and dim value is supported, but let's first see if it works and then improve it.

To have it working, the port/channel of the switch device must be equal to the object ID configured in linknx. You'll also have to configure the GSD to connect via TCP on port 1028 (or whatever you configured in linknx config) on the host where linknx is running.

The base I used to write this code is here:



Developers / Re: knx, linuxmce, eib part, ... help?
« on: July 18, 2008, 11:18:09 pm »

The first thing I don't understand very well about lmce is how the configuration made on webadmin interface is stored and transmitted to the DCE device connected to the bus.
Is it stored in a database, in files? Is it sent to the device via the DCE router or another mechanism, is this mechanism global or specific to each kind of DCE device. As I said in a previous post, linknx needs a configuration to tell it what are the EIB objects, their type, group addresses, flags .... All this can be loaded from a configuration file at linknx startup or configured dynamically using the TCP/XML protocol.

Do you think that this configuration step must be integrated in lmce or use a standalone configuration tool?

Once all the group objects are configured, the home automation plugin can use the object id's as port/channel to send commands to linknx using the DCE router.

Is there already a way to see the actual on/off state of lights in floorplans, or is it just pushbuttons to switch it on and off. Is there already a way to display also actual temperatures on the floorplan? I think I could write a DCE device without too much difficulty to be able to send and receive comands from/to the bus, but I would like to be sure that the plugins behind the DCE really have the functionalities I expect from a home automation visualization interface.

Do I need to have a PC with LMCE installed to be able to develop it, or can the development be done on a standard linux PC?



Developers / Re: knx, linuxmce, eib part, ... help?
« on: July 17, 2008, 10:17:25 pm »

I just discovered this discussion thread and am also intersted in the topic (a solution for integrating home automation into media-center)
I'm not an LMCE user (at least not yet) so I don't understand all the internal details of it, but I'm the programmer of linknx ( ) and can perhaps help on some topics.

The EIB/KNX model is based on communication objects and group addresses. Each group address represent a functionality.  Each communication object is able to send its value to at most one group address., but can receive value from zero, one or more group addresses. So that's not always a one-to-one relationship. In addition, each communication object has a collection of flags telling if it can transmit it's value on the bus, must update it's internal value if a new one is received from the bus, or answer to a read request coming from the bus.

All this behavior is part of the KNX object model but EIBD only implements the lowest protocol layer (send and receive READ, WRITE and READ_RESPONSE telegrams for group addresses). To fully implement the object model, we need an additional layer. That's one of the reasons why I developped linknx.
Additionally to this, linknx handle the conversion from the binary data format. Every communication object is configured in linknx with a name, group address to send to ( and potential additional group addresses to receive from), communication flags and its data-type (for decoding bus binary format to understandable text values).

All the configuration, reading and writing of object values to/from the bus can be done by connecting to linknx on a known tcp port and send/receive commands in XML format.

I suppose that a DCE router could easily be interfaced to it, but I don't have a clear view of what commands this DCE router must be able to send / receive. What are the limits of LMCE concerning home automation, how is the configuration (group addresses, flags, ...) stored in LMCE



Pages: [1]