Re: xPL Hal in a loop

["Mal Lansell" <mlansell@xxxxxxxxxxxxxx>]

It's tricky.

I would have expected an X10 status message to be used to report the state
of an X10 device itself (via a status request of an X10 device that
supports
it), whereas the X10.confirm is merely reporting that the CM12 has sent the
message down the powerline.

The built in support for X10 in xPLHal is surely there to aid the user in
setting up useful scripts - i.e. to avoid having to write real code
themselves (hence the wizard).  If that's a goal, it doesn't make sense
that
they shouldn't have to filter X10.confirm messages themselves.

I actually wonder whether the x10.confirm message is even necessary.  After
all, it only reports whether the message was put on the powerline, not
whether the X10 device reacted to it (impossible to know anyway since
status
request is missing from most X10 devices).

If confirmation is deemed necessary, then why not support confirmation of
any xPL message in a generic way, rather than by inventing special
modifications for each schema.  This could be done by adding xpl-cnfm as a
message type like xpl-stat, xpl-cmnd, and xpl-trig.  It would just echo
back
the contents of the received message (i.e. the same schema).  It would not
be mandatory for a service to confirm messages, but the specification would
be there for those that wanted to do it, with no chance that they would be
mistaken for something else.

Mal







----- Original Message -----
From: "Tony Tofts" <tony@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Wednesday, September 08, 2004 5:47 AM
Subject: RE: [ukha_xpl] xPL Hal in a loop


> > The above script should only fire when B2 is actually
> > switched on - not in response to a confirmation message, and
> > it shouldn't be up to the user to check the schema themselves.
>
> Hi Guys,
>
> I can't really agree here.
>
> There are 3 types of event (status, trigger, command) and the
particular
> event called is controlled by this type.
>
> Even though x10 is built-in, it should be treated no differently to
any
> other schema. If we start putting in exceptions for this, we'll set a
> precedent to start hardcoding exceptions for other schemas? Which to
me
> seems to defeat the point of the scripting system.
>
> If anything it seems to indicate that x10.confirm should be a status
rather
> than a trigger?
>
> Thoughts?
>
> Many thanks
> Tony
>
>
>
>
> 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
> Yahoo! Groups Links
>
>
>
>
>