knx, linuxmce, eib part, ... help?

[guigolum]

well, i don't really understand how to use the sdk. i hope the installation won't require people to install parts of the programm too(i think it shouldnot, but well..)

trying to understand the dsk doc..

btw it seems the youngest version of the doc is
http://www.auto.tuwien.ac.at/~mkoegler/eib/sdkdoc-0.0.3.pdf

[domotiqa.com]

have a look at the 7.7.2 section,

7.7.2. EIBD client library - C version

if you use the C langage

or

7.6. EIBnet/IP server front end . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.7. EIBD front end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.7.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.7.2. EIBD client library - C version . . . . . . . . . . . . . . . . . . . 111
7.7.3. EIBD client library - PHP version . . . . . . . . . . . . . . . . . . 114
7.7.4. EIBD client library - Java version . . . . . . . . . . . . . . . . . . 115
7.7.5. EIBD client library - other languages . . . . . . . . . . . . . . . . 116
7.7.6. Using the EIBD client library . . . . . . . . . . . . . . . . . . . . 116

[domotiqa.com]

C version use socket, php (experimental) use class (that look's easyer)

the 776 section explain pretty well the process to use !

EIBD implements for all control tra?c only up to layer 4. To interact with your EIB
devices, 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 and
group addresses. Each device has an individual address. This address is mainly
usedformanagmentpurposesandisinsertedasfromaddressineachtelegrams. All
control tra?c is sent to a group address, for which di?erent devices are listening.
Forindividualaddresses, thestandard displayformatisa.b.c. a contains theupper
4 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 5
bits, b the following 3 bits and c the lower 8 bits. An other format is a/b. In this
case 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 a
lighton). TheformatisXXXX XX00 10VV VVVV (2bytes). Ifthedatatype
to transmit is between 1 and 6 bit longs, the lower 6 bits (V) contain the
value. If the value is 1 (or more) bytes long, all Vs are zero and the value is
appended after the two bytes.
A
GroupValue Read This APDU is sent, to tell a device, that it should send the
current values of the group object in a A GroupValue Response. The format
it XXXX XX00 00XX XXXX (2 bytes).
A GroupValue Response This APDU is used to answer a A GroupValue Read
request. The format is XXXX XX00 01VV VVVV (2 bytes). If the datatype
to transmit is between 1 and 6 bit longs, the lower 6 bits (V) contain the
value. If the value is 1 (or more) bytes long, all Vs are zero and the value is
appended after the two bytes.
All bits marked with X should be ignored, when decoding a APDU and set to
zero, when generating a APDU.

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

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

• Send(receive) for one group address
In this case, you must first call EIBOpenT
Group to associate the connection with
the group address. The parameter write only must be set to true, if you don’t
want to receive telegrams.
You can call any time EIBSendAPDU (even not serialized) on the connection to
send an APDU.
To receive telegrams, you must call EIBGetAPDU Src. You must serialize all calls
to EIBGetAPDU Src on one connection.

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

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

[guigolum]

well, well, thanx a lot..

one part of the doc i had not taken time to look at. looking at, incoming responses

[jef2000]

Hi,

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

[tschak909]

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.

-Thom

[bulek]

Hi,

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 ?

Looking forward to any opinions....

regards,

Bulek.

[domotiqa.com]

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...

have a look there:
http://wiki.linuxmce.org/index.php/EIB

By the way three possible interface as we said with guigolum:
1/ use low level communication with eibd
2/ use xml interface with project like linknx to be able to read value
3/ 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!

[jef2000]

Hi,

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?

Regards,

Jean-François

[jef2000]

Hi,

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'                   
end

conn_.Send(command)

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:
http://wiki.linuxmce.org/index.php/How_to_add_your_own_GSD_device

Regards,

Jean-François

[domotiqa.com]

hy i don't have internet,

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

yes lmce can dim, on off ...

[jef2000]

Hi,

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?

Regards,

Jean-François

[domotiqa.com]

ok,
i will send an ets file export tomorrow, for overoll it s a mistaque: inheritance sorry

for ruby code you are wright no need of dcegen, that only needed if we want to write ut in c, and it create db...
for storing info in db, i guess it s possible, why not

[guigolum]

hmm..
(french) surcharger se dit overload(/french)

i hope someone will correct me if i am wrong


i don't see the interest in using lniknx

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..

[domotiqa.com]

I agree with you, however the link with linknx was simpliest, and for me, I needed the knx function, so I installed the linknx and make a link to linknx in order to have the read working !