the infrastructure in the driver is pretty much complete, we just need to fiddle a few bits and bytes. I hope I'll find the time to read into the specs soon. Any KNX wizards here that could give us some hints on EIS DPT?

The ETS one works, in fact we found the Level Value in the last byte (7F), the EIB one is broken, we didn't have (always 00) in the value Byte.

I think there's a problem in the function that Build the telegram.

Can u tell me where i can look for debugging? i looked in the 8.10 EIB-eibd source but i did'n found the problem.

"if my memory works fine", when sending a shortdata, a part of the bis are useless, but necessary to reach a given length(see CSMA/CD protocol, which requires the frames to be long enough to allow jamming repliance on an error).

i'd rather get the knx specifications for the second part though..

question:what template did you use? "dimming lamp"?(if you don't understand my question, then i need to get a fresh look at lmce ^^ )btw, does it work if you use shutters/blinders/drapes/thermostat template?

I didnt see any obvious bug(but my lack of using cpp templates and inheritance properly.. and my baaad english :p ), so it MAY be a bug from martin koegler's eibd.what I actually did: I used another program(with the agreement from its creator), wich name is "eibd", and that translate telegrams to the port we use(such as usb, serial port..)my programm only tells how lmce shall behave with that one program(it's a wrapper - and a weird one), both in emitting orders and in receiving datas. While emitting, on a dimming light, you have the following code in knxdevice.h:

that means, a EIB lightswitchdimmable, when receiving the order "set_level' from lmce, will create a "char" telegram(that means, with a small data) with the data given inside, and send it to it's adress number "1"(so, the second one you fill in lmce administration pannel) with order "set".the translation from lmce to the "knxdevice" (in my code) is made in function "EIB::ReceivedCommandForChild(args)" in file EIB.cpp, l113. Basically, what we do is:- check if the device exists in lmce- translate the data according to the order to send to this and the knxdevice we refer to. In the case of a set_lvl, the line 137 tells us we transalte the level in this way:" int level= ((unsigned int)atoi(pMessage->m_mapParameters[COMMANDPARAMETER_Level_CONST].c_str())*255)/100;". that is, we use the parameter referenced by "COMMANDPARAMETER_Level_CONST" in the order sent, which is an int, and translate it from a % base ton a /255 base. maybe an error here, if the COMMANDPARAMETER_Level_CONST is not used in lmce.so, what one should do is:- add a spy to know if the data is well transfered(I mean, print the value of level on the logger on this line 137)- if it works, print the ptel data after it is created, to see if it has a good shortdata. Actually, that is already done in the EIB log (/var/log/EIB ? can't remember), by the line 160 in EIB.cpp.so, the code you may add is

In fact the fisrt thing i did was check if "data" contains the right value until the end, and actually it does. (is transformed to a 0 to 100 in a 0-255 scale in "EIB::ReceivedCommandForChild(args)" in file EIB.cpp, l113" and then goes to another function, i didn't remeber now which one, but the data value is still correct".

For sure i have to clear myself the Knx Spec to a better understanding. But i suppose our problem is in the lenght of the telegram.

We know data is good but we see it is cutted off in the telegram, where the last byte is always "00".

For the compiling/testing i could help you if you doesn't have a lmce installed somewhere, but this way the thing could take muuucch time. Maybe in #irc we could make things faster.

_data[0]=(_type>>8) & 0x3; we lost this value because data[0] become "0x00"

In 1 bit telegram (<6bit), our _length is 0,so we go on the if block, and data[1] become "0x80" in off case and "0x81" in the on case and the telegram total lengh is 9 byte (XX XX XX XX XX XX XX XX VV) VV could be 0x80 or 0x81.

In 1 byte telegram , we go on the else, our _data[1] become "0x80" but we need another byte to complete the Telegram ( That in >6 bit case is almost 1 byte longer than the <6 bit one)

So at the and we have a Telegram like:XX XX XX XX XX XX XX XX 80 VV ( where VV is _data[2])

ah i forgot, my biggest problem at the moment is that I can't do the "bcuaddrtab -w 0" via ft12 on my interface. I get an error. Maybe the problem is that I never programmed a physical address into it (as I lack a second bcu).