The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

RE: xPLHal scripting matches


  • Subject: RE: xPLHal scripting matches
  • From: Kevin Hawkins
  • Date: Fri, 12 Sep 2003 17:53:00 +0000



> -----Original Message-----
> From: Tony Tofts
> Sent: 12 September 2003 16:57
> Subject: RE: [ukha_xpl] xPLHal scripting matches
>
> > > I had no plans to include bridging to xap.
> >
> > I don't think that the xAP inclusion has caused this - my
> > usage in this context may have been the first time it became
> > evident though ...
>
> I'm not blaming xap...
>
> I just can't forsee, except in very weird circumstances, where a pure
> xpl
> (as it was originally intended) system would have a need for this. If
> someone wanted to process all CID messages, this can just as easily be
> done
> with the existing system.
>
> E.g. if you wanted to capture all CID messages (and don't want to
write
> a
> device/app specfic script) then you can just set a filter up
> wildcarding
> everything except the schema class, which would be cid.
>
> schema msgtype="*" source_vendor="*"
source_device="*"
> source_instance="*"
> schema_class="CID" schema_type="*"
subs="CT" />

I think I am still missing something here because as I understand it if you
included the above line and also wanted to include say the following filter
later in the XML file

> schema msgtype="*" source_vendor="*"
source_device="CBus"
> source_instance="*"
> schema_class="*" schema_type="*"
subs="CT" />

Then for a device sending...

...
Source=UKUSA-CBus.kevin
...
}
CID.display
{
whatever
}

could never be picked up by my second filter because the first filter will
have trapped it. So I couldn't set up filters within xPLHal to intercept
all
class=CID messages and all device=CBus messages - neatly. I agree I could
add a test within the the CID trap to see if it was a CBus message and take
appropriate action but that is highly unstructured.

CID and CBus are bad examples but X10 and CBus is a better example when you
might have a hybrid implementation and need to trap all X10 and all C-Bus
messages (one trapped on class and one on device).

Ignoring xAP totally - my silly little example of wanting to trap all
displayed messages is something that someone might want to script for a log
application or something. Or another example they may well want to trap all
CID messages for example and log where the number is '01234567890' for
example.. but they just want to intercept and not break the filters.


>
> > action=continue or action=break
>
> Were trying to avoid modifying anything that would break an existing
> install
> though.

I think you missed the next line in my original message which you
<snipped>
it reads...

Kevin Hawkins said...
>In this way each filter has the option to ask the matching to continue
-
>and if you assume a default of 'break' if this parameter is missing
then
>all existing systems will be unaffected ...

Maybe it wasn't clear what I was trying to convey here but what I
meant is that if the 'action' parameter is absent in the XML file then you
default it to 'break' which is exactly what happens currently... every
current script would continue to run unmodified wouldn't it ???

>
> I pretty much consider xplhal (and xpl) to be 'in production' so to
> speak.
> The core is complete, were just adding improved/extra functionality
> (e.g.
> script reload recovery, xap support) and sorting any odd undocumented
> features (bugs?). Ideally this needs to be able to be dropped into any
> existing install without disrupting it, if possible.

I think my proposal achieves this - whereas the other option would cause a
change in script actions and/or would require changes to the XML file.
Which
is exactly what you're trying to avoid isn't it ??



Kevin






xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.