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

[jef2000]

Hi,

@guigolum:

The way KNX connection is currently implemented in lmce is something like a big hack in the KNX protocol definition. Basically, it shortcuts all the upper layers dfined by the protocol and force you to have a 1 to 1 matching between devices and EIB group addresses. It's enough for  basic functionalities but most "advanced" EIB configurations like the ones made by professionals will suffer from these restrictions.

Example: you have a staircase lighting that you can switch on using group address ga1. When the time is over, the actuator switch the light off and send the OFF information on another group address (say ga2). In the pushbuttons for this stairs light, I program ga1 as the main address and ga2 as the second one so that the status coming back on ga2 will update the state of the object and the next time you push it, it will know the light was off and turn it on again. Without this status feedback on ga2, the pushbutton doesn't know that the light was shutdown by the staircase timer of actuator and thus will think the light is still on and try to turn it off.
So if you have only one group-address by device, the status of the light will not update according to it's real state in the above case. That the kind of limitations we can avoid by using linknx.

Regards,

Jean-François

 

[guigolum]

you're right for the need in allowing more knx based protocol. be sure i am aware of the limitations of the lmce EIB.


however, i still don't see the interest in linknx:

giving a lamp another address (the state address group) is really not hard at all. you just go int the template in the webadmin, and instead of 6/0/1 your type 6/0/1|6/1/1 . then the config file is given both address

then, when your EIb part of lmce gets an order to the lamp it only reads "i need to send a COMMAND_POWER_ON " to the lamp, it gets its address(6/0/1) and then writes to the bus
on the other side, when the EIB part of lmce gets a telegram from the bus, is parses every peripheral it has been given the config, and according to that peripheral config, may send a message to the router (eg, when the lamp is switched on, it should send a EVENT_STATECHANGED 1 from the lamp DCE_id to the router. ). actually that is not yet the case, but it is really very easy to do(i had done it on the elder version of the source i had).
then one shall modify the LightingPlugin so that it recognizes the event from the lamp. the DCERouter actually doesn't keep the state of the devices in memory, but the plugins can: so you need to handle light events in the plugin, to 'centralize' them: thus the orbiter can ask the lighting plugin if the devices are switched on/off, or their %. and you may prevent the lightingplugin to listen to write orders on the lamp's order groupaddres, and instead make it hear the lamp's return groupaddress.


now, we only need to make the lightplugin handle return address instead of order address, and the lmce able to send/receive through knx. it is already able to make some discussion, but i have to let lmce communicate through other supports than com port(say, usb, ethernet, ..), plus let EIB send messages back(that one is VERY easy). for the 'other support', i am trying to implement eibd atm. but i have some matters with the source code atm..


so, maybe you could tell me how/what is linknx supposed to implement?

[domotiqa.com]

ok and in the case that the light don't switch off (error btw), the message is still send to other group adress !!

[jef2000]

Hi,

Of course, if you add to lmce all that linknx could offer to it (storing the actual value, decoding binary messages coming from the bus, handle multiple group-adresses, ...) Then there is nothing more that linknx can offer. But If I understand correctly, the things you are speaking about are "not yet the case but would be really easy to do".
So my proposal was to have a quick solution based on GSD/ruby and linknx because it seems easy to do and doesn't need changes in lmce code. If nobody is interested in it, I'll put it in the fridge until I have a lmce core at home and decide at that time what's the best solution based on the alternatives that will be available then.

Good work,

Jean-François

[hari]

now, we only need to make the lightplugin handle return address instead of order address, [...]

sorry, that's crap. All the KNX specifics must be encapsulated by the DCE device.

best regards,
Hari

[guigolum]

what i see crap is that the plugin assumes that a lamp which has been sent the order 'set yourself on' is assumed to be set on 'on' mode. i mean, maybe the lamp is supposed to be put to 50%, not 100%, in case of a dimmable?

i propose that the plugin would try to understand if the lamp has more than one group address, and more than two in case of a dimmable. if not, it assumes the lamp to obey the message(so that non knx protocol could work). if yes, it drops off any order to write on that lamp, but instead considers the event 'EVENT_STATE_CHANGED' to know if/how to modify the lamp state.

or should the lighting plugin only listen to event from the lamp to the router, and anyhow assume the lamp has obeyed the order? then correct its state if it got a state_changed event?

[hari]

what i see crap is that the plugin assumes that a lamp which has been sent the order 'set yourself on' is assumed to be set on 'on' mode. i mean, maybe the lamp is supposed to be put to 50%, not 100%, in case of a dimmable?

therefore we have two light devices in lmce, a binary one and a dimmable.

i propose that the plugin would try to understand if the lamp has more than one group address, and more than two in case of a dimmable. if not, it assumes the lamp to obey the message(so that non knx protocol could work). if yes, it drops off any order to write on that lamp, but instead considers the event 'EVENT_STATE_CHANGED' to know if/how to modify the lamp state.

again, that is *crap*. The address specifics of every protocol _must_ be encapsulated in the dce device. Please look at the existing DCE interface devices to understand the concept.

or should the lighting plugin only listen to event from the lamp to the router, and anyhow assume the lamp has obeyed the order? then correct its state if it got a state_changed event?

hu? the lamp is your child device. Of course you have to send the proper events on state changes. The lighting plugin has handlers for that.

best regards,
Hari

[guigolum]

right, i consider DCEdevice like EIBdevice.. sorry.

i meant, that in the case of knx, it's not because a lamp has been sent the order to be 'on' that it is 'on' just after.

for instance, a dimmable lamp could be set to 75% when it receives a 'set on' command, instead of 100% - or even, return to the level it had before being switched off. or go to the level ordered by a sensor before. or.. well, i don't know, but behind a simple 'dimmable lamp' you can have some programmation already done.
you can even have lamp that could not be set under 10%, or for wich 'set off' means go from 20 to 5 in 5 min.

[guigolum]

hi

i'm proud to tell you i made something like the EIB but working with eibd.

it still isn't configurable, since i didn't touch the template. it gives the same things that gives the actual EIB, even if there seems to be some bugs still(maybe due to eibd itself ..)
actually i build it with the 710 branch's source, and took much fro the former EIB. to make it work you need to install the eibd:
http://www.auto.tuwien.ac.at/~mkoegler/index.php/eibdeb

thanx alot to hari who told me to use pthreads, i didn't know them before and.. well, they seem to work.

now i need to implement the real knx protocol, that is, listening from knx's lamps all the stuff to fire correct events. i need to change its template too, and then implement its configuration... but i don't know how to (i mean, i would need to use sqlcvs..)
how i am supposed to u/l the sources, btw?
the code is atm in 'debugging' mode; so the logs are VERY FULL. there is no more segfault atm, but it will for sure need more tests.

[hari]

cool, keep up your great work!

What exact device template changes are you thinking about?

best regards,
Hari

[guigolum]

eibd needs to know what is the bus it uses to reach the knx:
eibd --help
(...)
supported URLs are:
ft12:/dev/ttySx
bcu1:/dev/eib
tpuart24:/dev/tpuartX
tpuart:/dev/tpuartX
ip:[multicast_addr[:port]]
ipt:router-ip[:dest-port[:src-port]]]
bcu1s:/dev/ttySx
tpuarts:/dev/ttySx
usb:[bus[:device[:config[:interface]]]]
(...)

atm i use eibd with ipt:192.168.80.130


i just need to fill the function
void EIB::getAway() in eib.cpp to modify string EIB.sgateway so that it gets the correct eibd format

so i would need:
either ppl to put the full line as arg,
or ppl to just fill the kind of connection to use, + the address
we could anyhow use the three, and modify sgateway according to what was filled. but i think the best would be to ask ppl to fill interface + address.

[domotiqa.com]

hy gui,
please to hear you make a good job ;-)

now i need to implement the real knx protocol, that is, listening from knx's lamps all the stuff to fire correct events. i need to change its template too, and then implement its configuration... but i don't know how to (i mean, i would need to use sqlcvs..)
how i am supposed to u/l the sources, btw?

have a look there for checkin
http://wiki.linuxmce.org/index.php/SqlCVS

what do you mean by ppl ?

[domotiqa.com]

and here also:
sqlcvs webadmin that look nice
http://forum.linuxmce.org/index.php?topic=5758.msg34057#msg34057

[guigolum]

"ppl" is normal linuxmce users.

when you install one dcedevice, you have to configure it. for eibd, you need to know how it connects to gateway. so users must enter either the fulla arg path to eibd, or the couple"bus/address"

and i can't u/l my sources on sqlcvs. only the sqltemplates. and i don't want to make things crash :/

i'm changing the EIB template now. then i will update my code to let users fill their configuration, and make some doc on my code. then i have to get newest templates in order to get a good knx implementation.(EVENT_Level_Changed ...)

then i should change the switch lamp, since it should not receive a COMMAND_SET_LEVEL when one tells it to be put to "on"..
anyhow, i still need to u/l my sources..

[guigolum]

ok, i remade the full code (but still used some part), to be able to make future changes more easy.

i still need to handle the sensors, but that's versy easy. and then, to test.. and make doc. the doc i am making should allow later changes in the templates, quite easily(made of how-to)

the installation is described in the README.txt

basically, i just need now to do some minor changes, then i will send a version to hari. hopping it will work on charon-merge, i have not been able to compile on it(sefgaults when loading getConfig() )


there still may be some bugs, such as memory lacks, i'm not used to map and vector use, plus the templates need to be done(several of them)


ps: i spent today 17H to rewrite the full code. but it was very funny! sure i liked this project!