RE: Renaming of instances and SubInstances?

[Ian B]

Hi all

OK, I have my relays reporting a change of state now be it from a command
which sets one on etc. or a timer expiring.

Now, the question is:
When more than one relay changes state at the same time from either timers
expiring, a wildcard command or a direct set command that sets all of them
at once what do I use in the UID?

Secondly and related. When more than one changes state do I have multiple
pairs in the body i.e. 'SubInstance name=new state' repeating or multiple
messages. I don't want to have multiple body messages.

What do you think?

I have also altered the changing of the SubInstance names so only one can
be
done at once and there can not be any duplicates. I have declared the UID
last two digits as 01 to 08 for the outputs and 09 to 16 or 24 (but in hex
of course) for the inputs depending how many are fitted. 00 - not sure
about
this one but really it is the instance reporting i.e. a heartbeat or for
status messages.

Thanks

Ian

>-----Original Message-----
>From: Kevin Hawkins [mailto:<a
href="/group/xAP_developer/post?postID=iy5gwKP8Tj-27hxBVPxaOvrVJxptSJhbAFcA7GlvL-sCifNHrutO-xpe_cL8w6BTL_D8z_WsYDbM2_DpfH4">lists@u...</a>]
>Sent: 26 August 2003 19:05
>To: <a
href="/group/xAP_developer/post?postID=xastrp7lYw74XsGrkl0pC63dcdIZ3tSuyXpdDYtLe2YsZXTfyrMZNSfMOIh1m7dJgZOXH4HDd0ZMUCdIWopleIGIBnQ">xAP_developer@xxxxxxx</a>
>Subject: RE: [xAP_developer] Renaming of instances and SubInstances?
>
>
>
>
> > From: <a
href="/group/xAP_developer/post?postID=qr7tB9gyI1lgnjXykPxuDEvBzXoHyco-7cGrhLI3WPnnu7I0yhVx_y0w5H5PbJ-9m9fjUq41QWix">i.bird@t...</a>
[mailto:<a
href="/group/xAP_developer/post?postID=CK-77k9PkyXqDVDu1dKbWLS1D_TyW8dYhZKP3nd2yPPqYHSdC9mJFJlO_Z8klP2ElqdsxmzchnS1P-eKKA">Ian@M...</a>]
> > Sent: 26 August 2003 16:43
> > I have assigned my inputs separate UID suffixes as you
>describe. Input1
> > is
> > 01 etc. My inputs can generate change of state messages and as
such do
> > use
> > the UID suffix.
>
>That's great - it allows the 'tiny' receivers to track your inputs if
they
>are just watching UID's rather than the full source address.
>
> > I have not done this for the relays as they cannot
> > generate
> > a xAP message so will therefore never need to send a UID.
>
> I guess that makes sense if your tight for space - the only thing
>it stops is a confirmation coming back from the relay that it has
changed
>state (see later) - for example if one of your switches can be linked
>internal to your device to toggle a relay then it would not be
>informing the
>rest of the xAP community that it had changed state.
>
> > The only
> > option
> > is a status request which comes from the 00 UID listing all the
relay
> > states. As mentioned elsewhere I don't support addressing by UID.
>
> Whether or not every device should send a message when it changes
>state I guess is up for discussion - certainly inputs should but
>outputs are
>less clearcut. I guess an example is if I wanted to use your device
with
>HomeSeer or have a xAP based indicator light inside the house that
showed
>when my sprinklers were on. (This level of plug and play interaction
has to
>be our goal). The 'easy' way would be to monitor the change of
>state message
>from a relay, particularly if this was in xAP 'Basic' schema form. If
you
>don't have such a message then either you need to watch the messages
from
>other devices that could cause the relay to change state - which would
>require knowledge of the filters in the relay. Not sure - do you
>send a full
>status message for all relays and inputs whenever anything changes
state ??
>(see later) - HS would then have to know to parse this - which leads to
the
>key Q..
> What is the best way to send a status message given that something
>'should' be sent whenever anything changes state ?? Should we send one
>message just for the I/O that has changed state (which is how I'd
>thought of
>it) or send one complete message for all I/O contained within the
device.
>The latter approach will not identify which I/O line has changed
>state, only
>that one has - you would need to keep a state table to know what
changed
>which seems a disadvantage but it maintains 'synch'.
>
> >
> > I only support wildcarding on the SubInstances not the
>Instance. I have
> > found in testing it is useful to be able to set multiple
SubInstances
> > at
> > once simply for speed. I agree this is a little unique but the
user
> > doesn't
> > have to use it if they don't want to. An example might be a set
of 4
> > lights
> > in the garden which I may want to control together. It simply
makes
> > setting
> > them up quicker at the end of the day plus they can then all be
> > addressed
> > at the same time.
>
>You say you support wildcarding on sub instances which is fine but
surely
>then you would use a construct like...
>
>Source = ACME.IOdevice.Garden.Front:Lights.Flowerbed
>Source = ACME.IOdevice.Garden.Front:Lights.Lawn
>Source = ACME.IOdevice.Garden.Lawn.Front:Sprinkler
>Source = ACME.IOdevice.Garden.Lawn.Front:HangingBasket
>
>Target = ACME.IOdevice.Garden.Front:Lights.* would address all lights
in
>your front garden - setting up duplicate addresses is like using
>X10 devices
>all set to the same housecode - you can't address them individually or
tell
>which one sent any status reponse.
>
>Actually there is a whole other topic which is groups and scenes which
is a
>way of grouping many different xAP devices into one umbrella address
and
>asking them all to act as one when the group is changed. This may suit
what
>you want better, particularly if you don't support wildcarding. However
>devices (each UID) would have to know which group they were a
>member of - or
>there would have to be a central controller that translated a group
address
>into the individual members addresses and forwarded a targeted message
to
>each member. It's one of the open discussion topics.
>
> > However I cannot turn one on or off as it cannot be
> > distingushed from the others but this is acceptable. If I
supported
> > addressing by UID and the outputs all had their own UID suffix I
would
>
>You can't (target) address based on UID
>
> > have
> > the best of both worlds but that is not so just yet.
>
>If you can't address the individually what is the advantage (as 4
different
>relays ) over just one relay - (ignoring the current rating) - Might
they
>each have different time cycles perhaps ?? If so you get back to the
status
>message issue as they can change state of their own accord so must
generate
>a xAP message.
>
> >
> > I don't have the memory to hold a body with several SubInstances
to
> > rename.
> > If I remember correctly we decided in the dim and distant
>past that the
> > body would have the new value in it e.g. value=newname rather
than
> > several
> > lines of oldname=newname. I have 80 bytes to store everything
between
> > the
> > opening and closing curly brackets so large bodies are not really
in.
>
>I can see you are tight on message space - but building up a
>status response
>for all your I/O as one message creates bigger messages surely -
>rather than
>1 I/O line being included in one message. Or have you a higher buffer
size
>for transmitted messages than received ones ?? I think I've got a bit
lost
>here , can you put me back on track Ian...
>
> >
> > At the moment I return a status in a hearbeat message giving the
> > outcome of
> > the command. Only 2 levels as it either works or fails, no in
between.
> > I
> > can always increase the number of levels but at the moment there
is no
> > need.
>
>Ahh - so you don't send a status message for relays at the time they
change
>state - you store them up and add them (possibly several) to a
>heartbeat ???
>Or do you send irregular heartbeats, whenever I/O changes state ?
>
>
> What I'm trying to get to is a simple and standard way in which
devices
>can interrogate and control I/O status on a xAP device. If we can do
that
>then software and controllers can track all xAP devices and can also
>instruct them WITHOUT having to know anything about the particular
device
>schema or implementation - that's' what I'm calling a 'basic' schema
and a
>standard policy layer. Ultimately you should be able to attach your
relay
>board to your network - turn it on and HomeSeer for example can
(possibly
>even automatically) create a device , or devices, that it can display
the
>status of and control without having inbuilt support for 'Ian's relay
>controller' or 'Kevin's C-Bus controller'.
>
> Kevin