EIBD implements for all control tra?c only up to layer 4. To interact with your EIBdevices, each application needs to implement the following things:

1. Converting numeric EIB address from/to strings

EIB has two di?erent address type, which are both 16 bit long: individual andgroup addresses. Each device has an individual address. This address is mainlyusedformanagmentpurposesandisinsertedasfromaddressineachtelegrams. Allcontrol tra?c is sent to a group address, for which di?erent devices are listening.Forindividualaddresses, thestandard displayformatisa.b.c. a contains theupper4 bits, b the follwing 4 bits and c the lower 8 bits (all values are unsigned).For group addresses, the most common format is a/b/c. a contains the upper 5bits, b the following 3 bits and c the lower 8 bits. An other format is a/b. In thiscase a contains the upper 5 bits and b the lower 11 bits.

2. Decoding/Encoding of APDUs

For control tra?c, there are 3 important APDUs:A GroupValue Write This APDU is used to update a group object (ie. switch alighton). TheformatisXXXX XX00 10VV VVVV (2bytes). Ifthedatatypeto transmit is between 1 and 6 bit longs, the lower 6 bits (V) contain thevalue. If the value is 1 (or more) bytes long, all Vs are zero and the value isappended after the two bytes.AGroupValue Read This APDU is sent, to tell a device, that it should send thecurrent values of the group object in a A GroupValue Response. The formatit XXXX XX00 00XX XXXX (2 bytes).A GroupValue Response This APDU is used to answer a A GroupValue Readrequest. The format is XXXX XX00 01VV VVVV (2 bytes). If the datatypeto transmit is between 1 and 6 bit longs, the lower 6 bits (V) contain thevalue. If the value is 1 (or more) bytes long, all Vs are zero and the value isappended after the two bytes.All bits marked with X should be ignored, when decoding a APDU and set tozero, when generating a APDU.

There are di?erent ways to use a EIBD connection. The rule is, that you can use oneconnection only for one of the listed purposes:

• Query/poll the status of group addressesCache Read Sync any time you need a value. TheIn this case, you call EIBcaching must be enabled in eibd. This can either be done by the -c command lineswitch or by calling EIB Cache Enable at least once. You must serialize all callsto EIB Cache Read Sync on one connection.This method only works for status based group objects. To get correct results, thegroup address should be readable and some device should sent an update telegramon status changes.

• Send(receive) for one group addressIn this case, you must first call EIBOpenTGroup to associate the connection withthe group address. The parameter write only must be set to true, if you don’twant to receive telegrams.You can call any time EIBSendAPDU (even not serialized) on the connection tosend an APDU.To receive telegrams, you must call EIBGetAPDU Src. You must serialize all callsto EIBGetAPDU Src on one connection.

• Send(receive) for all group addressesIn this case, you must first call EIBOpen GroupSocket. The parameter write onlymust be set to true, if you don’t want to receive telegrams.You can call any time EIBSendGroup (even not serialized) on the connection tosend an APDU.

Toreceivetelegrams(APDU),youmustcallEIBGetGroup Src. Youmustserializeall calls to EIBGetGroup Src on one connection.Each call has an corresponding asynchronous version. These functions split the callin two parts: The name async function starts the processing. EIBComplete waits, untilthe call has finished. Depending on the language there are di?erent ways to poll for thecompletion.

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 ( http://sourceforge.net/projects/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

I would suggest reading the Programmers Guide on the wiki, especially in regards to DCE.

The whole system is very open-ended, but the basic logic modules for lighting, climate, and security do impose some high level logic.

EIB in the context of LinuxMCE is merely an interface layer, the DCE device needs to translate commands from a high level perspective, ON, OFF, etc.. to the appropriate commands to send out over the buss.

Addressing is not really a concern other than the devices to be controlled are children of the EIB interface, and it's the interface's responsibility to take the individual Port/Channel data fields, and make them useful in its own context.

All of the higher level aspects are taken care of by the Lighting Plugin, and there currently isn't much beyond zone and grouping abstractions, but even then, the lighting plugin will always separate the zone and grouping commands into their component parts to send to the interface.

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 ( http://sourceforge.net/projects/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

Regards,

Jean-françois

Hi,

Jeff... Nice to see you on this forums (I'm the one asking for using KnxWeb on another automation system and guess what, I'm LMCE user and my plans are tied to it)....

If I may propose, maybe it would be wise to separate EIB interface from linknx so we could be able to use linknx (and of course KnxWeb) also for all devices under LMCE... So I propose :- to make proper wrapper for EIB (I'm not a programmer, but making full blown wrapper in Ruby would be much easier and more people could contribute)....

- and then try to connect linknx to LMCE via another wrapper... In this way we could use knxweb (which is BTW great, easy expandable web-Ajax visualization) for virtuall all devices connected to LMCE (including media players, etc...). In this way KnxWeb could become interesting web interface to whole LMCE system.... I guess we could use EIB Address slot for LMCE ID instead for non-EIB devices... Is there any more info somewhere how linknx communicates with EIBD ?

hy jeff,yet, the eib interface can write to the bus!For that you need, for example to a floorplan and drag n drop a standrad input... or what else on the plan. Then after (adding the eib interface and sensor, devices..) you have to affect the value for group adress...

By the way three possible interface as we said with guigolum:1/ use low level communication with eibd2/ use xml interface with project like linknx to be able to read value3/ use all linknx function via a link to linknx webpages

however, the user interface of lmce is like linknx with object upon a house photo or a plan, then drag n drop devices!So in fact we only need (at first) to use the read/write command!

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?

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:

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.

to be quick, i think a webinterface in lmce admin website should be the best with the import of the ets group adress then a dropdown list to declare the device type. and a add buton that create the device in linknx and in lmce with the sql db.have a look to the dcegen cmd in the wiki

another way should be to declare in linknx the devices, then declare it in lmce and use the linknx device number as value for group adress (try to add eib interface then child devices). once done we need to overoll the read / write function

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?

in lmce, peripherals attached to the eib are identified with a template number, for instance light switch on/off is device template #37

when the dcerouter's EIB peripheral starts up, it receives a config file with it (see src/Gen_Devices/EIBBase.h), that it parses and stores (see src/DCE/Command_Impl.h : DeviceData_Impl *m_pData stores the devices config).

so basically once it is started you just wait for a messsage(src/DCE/Message.h), and compare it with the templates names defined in src/pluto_main/Define_Device_Template.h "#define DEVICETEMPLATE_Light_Switch_onoff_CONST 37" for instance; and act according to their behaviour, and the order sent, and send corresponding events on the knx. on the other side,you listen to the knx bus and throw events back to the dceRouter if they are handled by the devices witch config have been sent(basically, when you see a write on a switch lamp return_state group address, you just send a 'event_state_changed' to the router, which should be hendled by the lighting plugin).

basically it's was we(i?) are supposed to do, because i am keeping segfaulting and i really don't understand..