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

[massabuntu]

I think we could open a ticket, such as the dimming doesn't work too.

[hari]

don't forget thermostat :-)

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?

br, Hari

[guigolum]

Ho my..
I took a look in my code, and am just .. well, I can't find the words. Sooo dirty.
May i try to modify it a bit? removing a big part of those macros..

I would need a way to compile on lmce however.(or i can develop w/o a dev environment, but can't ensure it will compile :p )

I received a mail telling me there was a bug with :

Here's the thing.
We notice a problem in dimming and floatpoint telegram. I explain... the "shortdata" (guessing is 1 bit boolean datatype) telegram works fine. In both direction, menaing the DCE > EIB > eibd > KNX chain works fine and the KNX > eibd > EIB > DCE too.

We have problem with "more than 1 bit datatype" value telegram.
I post two pair of example of Telegram sended One by EIB and one by ETS3.

1) ShortData - Switch ON a Lamp with adress 0/0/4 from 0.0.0 (wich is the pysical adress of eibd).

ETS3  ->  29 BC 00 00 00 04 E1 00 81
EIB     ->  29 BC 00 00 00 04 F1 00 81

Both of those working fine even there's a difference in the in the 7th byte.
Instead:
2) Set the value of the dimmer to 123 (50% in mce) from phy.adress 0.0.0 to 1/0/0 Value object of the dimmer.

ETS3  ->  29 BC 00 00 08 00 E2 00 80 7F
EIB     ->  29 BC 00 00 08 00 F2 00 80 00

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:

class LightSwitchdimmable:public knxDevice
   {
      DEVICEHEADER( LightSwitchdimmable , 2, "\0\1" ) ;
      virtual Telegram *Command_On(){return createsTelegramFromAddress(1,0);};
      virtual Telegram *Command_Off(){return createsTelegramFromAddress(0,0);};
      virtual Telegram *Command_Set_Level(int level){return createcharTelegramFromAddress(level,1);};
   };

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

Code: [Select]

LoggerWrapper::GetInstance()->Write(LV_STATUS, "  setlevel made lvl %i from data %s", level, pMessage->m_mapParameters[COMMANDPARAMETER_Level_CONST].c_str()); between l 137 and 138


btw there is an obvious leak in EIB.cpp, l 165. after "sendTelegram(ptel);", one should had "delete(ptel)" which is allocated on the stack


damn, this editing form is small..

[massabuntu]

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.

I'm at your disposal.

Martino

[massabuntu]

YES! I saw  the problem and i found a way to fix it.

It's a little bit dirt beacuse it could don't work with other data type but now we know where we had the problem.

[guigolum]

may you explain me please?

[hari]

http://svn.linuxmce.org/trac.cgi/changeset/22147

[massabuntu]

Look at http://svn.linuxmce.org/trac.cgi/attachment/ticket/278/Telegram.cpp

It's difficult to explain it in english but i try.
Look at

Code: [Select]

220 void Telegram::generate_head()
221 {
222         _data[2] = _data[0];
223         _data[0]=(_type>>8) & 0x3;
224
225         if(_type==EIBWRITE && _length==0)
226         {
227                 _data[1]=(_type & 0xff) | (_shortdata & 0x3f);
228         }else{
229                 _data[1]=_type & 0xff;
230         }
231 }I added the row 222, because the 1 byte value was stored in data[0] and   after

Code: [Select]

_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])

Sorry fer the raw explanation.

PS:Now the challenge is for the other DTP.

[hari]

added delete(ptel): http://svn.linuxmce.org/trac.cgi/changeset/22148

[guigolum]

:s i didnt even remember i had done that Telegram part...
(but now i remember i had some bad time translating the float value..)

well, thank you guy, i had not even tried to look in telegram.h/cpp.

what is the other problem now?

[hari]

set temperature works after the following change:

Code: [Select]

Index: Telegram.cpp
===================================================================
--- Telegram.cpp (revision 22016)
+++ Telegram.cpp (working copy)
@@ -25,10 +25,10 @@
  if(_type==EIBREAD) return;
  _shortdata=0;
 
- _length=length=(length>MAXTELEGRAMDATALENGTH?MAXTELEGRAMDATALENGTH:length);
+ _length=length=(length>MAXTELEGRAMDATALENGTH-2?MAXTELEGRAMDATALENGTH-2:length);
  for(int i=0;i<length;i++)
  {
- _data[i]=data[i];
+ _data[i+2]=data[i];
  }
  generate_head();
 }
@@ -77,8 +77,8 @@
 
 int Telegram::getUserData(unsigned char *buffer, int maxsize) const
 {
- int leng=(maxsize<_length?maxsize:_length);
- for(int i =0;i<leng;i++) buffer[i]=_data[i];
+ int leng=(maxsize<_length-2?maxsize:_length-2);
+ for(int i =0;i<leng;i++) buffer[i]=_data[i+2];
  return leng;
 }
 
The generate_head was overwriting the first 2 byte of userdata..

br, Hari

[hari]

(this obsoletes the previous fix)

[massabuntu]

yeah, so let me understand, now we are ok with dimming and temp?

Later we have to discuss about the much higher number of KNX Object and the few who are handled by LinuxMCE.

Massabuntu.

[hari]

yes, dimming and set temp works now. The actual implementation already handles multiple GA per device..

br, Hari

[hari]

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

br, Hari