new X10 component: medusa-cm11

[Tom Van den Panhuyzen <tomvdp@xxxxxxxxx>]

Hi all,

I am currently testing an xpl app that may serve as a replacement for
the CM12 service.  In my setup the CM12 misses too many X10 commands.
Also, it does not treat sending the same X10 function to multiple
devices well (at all?).

So... I rewrote from scratch a new xpl service: medusa-xplcm11.

A few questions/suggestions...

1) HAL Scripting

Because it is possible to control multiple devices with 1 X10 command,
I was wondering how this translates in the "events" that are
raised in
HAL-script.

I.e. the following is called if an X10_ON for device G1 is received:
sub X10_G1_ON_Trigger(xplmsg)

But what if X10_ON is received for G1 and G2 ?  Will HAL translate
this into 2 calls ?
sub X10_G1_ON_Trigger(xplmsg)
sub X10_G2_ON_Trigger(xplmsg)


2) x10.basic

I couldn't find a use for the "house" attribute... so it isn't
implemented (yet). All X10 commands expect at least 1 device.  Signals
from the powerline may contain only a housecode, but then the
"device"
attribute is used.
E.g. a trigger :
command=BRIGHT
device=G
level=17

Sending an X10 function to multiple devices is only possible for
devices that share the same housecode.  The following is nonsense:
command=ON
device=A1,B2

I suggest the following amendment to the schema:
DEVICE=<list of x10 devices, comma seperated, only the first device
contains a housecode>
This then is a valid command:
command=ON
device=B2,7,8

It forces the sender to construct syntactical correct X10 commands.  I
don't think it will have an impact on existing applications as these
are probably not using the construct device=B2,B7,B8 because I believe
there currently exists no application that correctly implements this.


Features of medusa-xplcm11:
- multiple devices accepted in the "device" attribute;
- asynchronous: incoming X10 commands are queued for execution;
- incoming X10 signals from the powerline do not interfere with
incoming X10 commands (via xpl);
- threads communicate via synchronization objects (no time wasted in
Thread.Sleep);
- stress-tested
The component survives and executes the following scenario:
X10 commands ON/OFF are sent in a loop, building up a queue of
commands waiting to be executed.  While the commands are executed one
after the other, as fast as the CM11 can handle them, X10 signals are
put on the powerline (by pressing a remote KR22 and/or wall switches
connected to a TMA4).  The sending is interrupted and the component
reports the signals.  The sending continues when the powerline is
clear.  Eventually all commands will be executed and all incoming
signals reported.


It is currently in test on my HA pc.  I didn't have to modify anything
in the HAL scripts that were in use before.  So long everything is
working ok.  I will release the component and source soon.  First we
should agree on the x10.basic schema amendment and see if/how HAL
handles multiple devices in a trigger message.

Anybody using X10 extended commands ?  I can only see that what is
sent to the CM11 is accepted, I don't have devices that use these
commands.

Feedback welcome!
Regards,
Tom


xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx