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
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..
Show Posts
but if you want to help me, please try to use my program, and then tell me your feelings, and improvments i could do