Re: xPL Hal in a loop

["Mal Lansell" <mlansell@xxxxxxxxxxxxxx>]

Changing xplhal was my first suggestion ;-)  Whatever the fix, I don't
think
the user should have to worry about filtering x10.confirm messages when
using the script wizard.  Either xplHal should ignore them, or the wizard
should add appropriate line to the script itself.

I haven't looked into the xAP/xPL wars enough to see what the arguments
were - I just chose xPL because it was supposed to be simpler, and for
xplRioNet.  I still think I made the right choice - writing the service to
xPL-enable my x10 rf receiver wasn't hard at all (a couple of sockets
issues, but that would have tripped me up no matter what protocol I'd
chosen!)

I hope to have my website finished in the next couple of days, so I can
make
my first service available for download, along with the source code for the
C++ xPL lib  that I wrote as a base for this and future projects (I just
need to check that it works on WinCE).

Mal



----- Original Message -----
From: "Ian Lowe" <ian@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Friday, September 10, 2004 9:35 AM
Subject: RE: [ukha_xpl] xPL Hal in a loop


>
> There was a discussion along these lines about a year ago - looking at
> the use of a completely separate xpl-cnfg message type for
configuration
> purposes - and we opted instead to basically stick with the message
> types we had, and try to implement the configuration process with that
> (as a test to see if the extra message type was required)
>
> The only reason I can see for not going the xpl-cnfm route... is that
> none of the protocol's behaviour is really optional. It's perhaps the
> key issue that made xAP so unpalatable - that chunks of the protocol
> were optional and might (or might not) be present in a given message,
> dependant not on some nice defined rule, but rather on whether the
> individual developer liked them or not!
>
> I can see that there's a gotcha in the X10 handling in xplhal, but I
> think the fix for this should involve a wee change to xplhal's
> behaviour, rather than an addition to the protocol.
>
> Just my 2p.
>
> Ian.
>
> -----Original Message-----
> From: Mal Lansell [mailto:mlansell@xxxxxxx]
> Sent: 10 September 2004 09:22
> To: ukha_xpl@xxxxxxx
> Subject: Re: [ukha_xpl] xPL Hal in a loop
>
>
> Thoughts?  Anyone?
>
> Mal
>
> ----- Original Message -----
> From: "Mal Lansell" <mlansell@xxxxxxx>
> To: <ukha_xpl@xxxxxxx>
> Sent: Wednesday, September 08, 2004 9:51 AM
> Subject: Re: [ukha_xpl] xPL Hal in a loop
>
>
> >
> > 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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
>