Re: Updated X10 connectors

[René de Rijke <renederijke@xxxxxxxxx>]

Kevin,

Thank you for the explanation, the .> wildcard looks usefull to me,
to switch all lights in the same room.

In my main HA program I don't use wildcards, I'm a beginner, so I like
to see what happens on my xAP/xPL-X10 network. This was a nice test
for the new connector and myself.

I catched the full message with xAP-viewer changed it and resend it.
I put in wildcards step by step, with this message the lamp does go on
and floorplan receives it also.

xap-header
{
v=3D12
hop=3D1
uid=3DFF123400
class=3DxAPBSC.cmd
source=3D*.*.*
target=3DERSP.X10.*
}
output.state.1
{
id=3D05
state=3Don
}

This one works also:

xap-header
{
v=3D12
hop=3D1
uid=3DFF123400
class=3Dxap-x10.request
source=3D*.*.*
target=3DERSP.X10.*
}
xap-x10.request
{
command=3Doff
device=3DA5
}





Ren=E9.



--- In xap_automation@xxxxxxx, "Kevin Hawkins" <lists@...>
wrote:
>
> Hi Rene,
>=20
>    Thanks for trying this as it really helps :-) Aside from the
> wildcards it's most bewildering that ON's are obviously working for
> you as well as OFF's , 'ON's do not work for me :-(  I'm going to
> double check again as I can't believe this hasn't been picked up
> before it it really is an issue - maybe it's me ...
>=20
>     However that second construct for a target
>=20
>     target=3DERSP.X10.*
>=20
>   should not match any X10 endpoint and none should react. The correct
> wildcard for 'all endpoints' would be ERSP.X10.*:> or even better
> target=3DERSP.X10.*:*.>   The wildcard you  have used matches only
the
> main application itself (sub address 00) and specifically matches no
> endpoints (sub addresses 01-FF).
>=20
>     Just to clarify this target=3DERSP.X10.*:>  matches the
application
> itself and all endpoints and target=3DERSP.X10.*:*.> matches all
> endpoints but not the main application  (on the basis that * requires
> a value present)
>=20
>    Kevin
>=20
>=20
>=20
>    --- In xap_automation@xxxxxxx, Ren=E9 de Rijke
> <renederijke@> wrote:
> >
> > Hello,
> >=20
> > I have tested some wildcards on my system and all seems to
function
> > well. when I send:xAPBSC.cmd,source=3D*.*.*=20
> >=20
> > target=3DERSP.X10.*:hal.>
> > output.state.1
> > id=3D*
> > state=3Don , both lights in the hal goes on, en nothing else.
> > state off, both lights in the hal goes off, en nothing else.
> >=20
> > target=3DERSP.X10.*
> > output.state.1
> > id=3D05
> > state=3Don, only one light in the hal goes on.
> > state off, only one light in the hal goes off.
> >=20
> > Ren=E9.
> >=20
> >=20
> >=20
> > --- In xap_automation@xxxxxxx, Kevin Hawkins <lists@>
wrote:
> > >
> > > Actually before I wasn't using wildcarding at all - in fact
I
haven't=20
> > > used the X10 conduit for a while as my X10 was being relayed
in=20
> > > HomeSeer.  I was just testing my  inbuilt BSC mapper and
your X10=20
> > > conduit (and the Netiom) seemed the most likely applications
people=20
> > > might be using with it so I wanted to ensure it worked.  Was
> trying to=20
> > > get the C-Bus wireless remote controlling X10.
> > >=20
> > >     Kevin
> > >=20
> > > Edward Pearson wrote:
> > > >
> > > > I've not changed any code related to the areas you
mention for
> > quite a=20
> > > > while. Are you saying that these are new behaviours
seen with
this=20
> > > > release or just that you are testing this one with more
demanding=20
> > > > wildcard sequences than before?
> > > >
> > > >=20=20=20=20
> >
------------------------------------------------------------------------
> > > >     *From:* xap_automation@xxxxxxx
> > > >     [mailto:xap_automation@xxxxxxx] *On
Behalf Of *Kevin
> > Hawkins
> > > >     *Sent:* 06 August 2006 03:01
> > > >     *To:* xap_automation@xxxxxxx
> > > >     *Subject:* Re: [xap_automation] Updated X10
connectors at
> > > >     www.erspearson.com
> > > >
> > > >     I seem to have a couple more problems Edward
> > > >
> > > >     1) I seem to be able to turn a device off but not
on - if I
> send a
> > > >     BSC off it works fine but change the state=3D 'off'
to 'on'
and it
> > > >     doesn't. With the 'off' I see in the GUI the xAP
receive
> > > >     xAPBSCcmd:<devicename> with 1 block followed
by a transmit of
> > the X10
> > > >     event and then the BSC info or event message . With
the on
> > command I
> > > >     just see the xAP Receive
xAPBSC.cmd:<devicename>
> > > >
> > > >     2) I am having a load of problems with wildcards .
Temporarily I
> > > >     have set up my names like this example to initially
preserve
> > some X10
> > > >     information whilst I get it working.
> > > >
> > > >     ERSP.X10.machine:D7.Hall.TableLamp
> > > >
> > > >     I tried targeting ERSP.X10.*:D7.> and nothing
worked , in fact
> > I am
> > > >     not sure anything works with a : in it once
wildcarded. So I
> then
> > > >     guessed at
> > > >
> > > >     ERSP.X10.*.D7.> and I got a load of devices
changing state
even
> > > >     though
> > > >     only one of mine has D7 in it. About half my X10
devices
changed
> > > >     state. When I fully qualified the target it seemed
to work OK.
> > BTW I
> > > >     am using ID=3D*
> > > >
> > > >     One of the reasons the wildcarding is quite
important for me
> > is that
> > > >     my little embedded mapper has limited target
address space so
> > > >     anything I
> > > >     (or users) can wildcard saves target string storage
eg >:D7.>
> > is much
> > > >     more compact than the full address although
*.X10.>:D7.> is
> > probably
> > > >     more focussed. Eventually I will probably go for
> > > >     >:*.Hall.TableLamp or
> > > >     *.X10.>:*.Hall.TableLamp though or better still
remove the X10
> > > >     house/device code totally.
> > > >     The : is now very important in wildcarding since
sub
> addressing to
> > > >     divide the address into the two components with the
first >
> > matching
> > > >     'only' to the : and the second to the end of the
sub address
> ie a
> > > >     match
> > > >     anything is >:> and not *.> (the latter
would not match
> > anything that
> > > >     had a sub address) although it would match every
application. I
> > > >     wonder
> > > >     if maybe this is a carry over from Stuart not fully
> > integrating sub
> > > >     addressing into xFX ?
> > > >
> > > >     Kevin
> > > >
> > > >     Kevin Hawkins wrote:
> > > >     >
> > > >     > This could be just my setup here Edward (gosh
how I hate
X10)
> > > >     but I am
> > > >     > not reliably seeing the commands showing in
the X10
> > connector window
> > > >     > (just getting housecodes)., and
consequentially no events
> > sent. So I
> > > >     > send D4 ON and all I see is X10 receive
Address: house=3DD
> unit=3D4.
> > > >     Will
> > > >     > try another site for my X10 receiver and see
if it
> improves. The
> > > >     lamp
> > > >     > elsewhere does change state correctly but my
CM12U is very
> close
> > > >     to lots
> > > >     > of PC's so it may be getting noise. The
transmitted X10
> from the
> > > >     CM12U
> > > >     > gets through fine. As some commands do get
through it's
> looking
> > > >     like an
> > > >     > X10 hardware issue.
> > > >     >
> > > >     > Kevin
> > > >     >
> > > >     > Edward Pearson wrote:
> > > >     > >
> > > >     > > After a week beset with configuration
problems with
v2.6 of
> > > >     the X10
> > > >     > > connector, I have now got the build
scripts sorted, CVS
> > behaving
> > > >     > > itself again and uploaded the latest
builds (v2.6.3) at
> > > >     > > www.erspearson.com <http://www.erspearson.com
> > > >     <http://www.erspearson.com>
> > > >     > <http://www.erspearson.com <http://www.erspearson.com>>>.
> > > >     > >
> > > >     > > Please email if you find any more issues
with these
> versions.
> > > >     > >
> > > >     > > Edward
> > > >     > >
> > > >     >
> > > >     >
> > > >
> > > >
> > >
> >
>







=20