RE: Renaming of instances and SubInstances?

[Kevin Hawkins]

> From: <a
href="/group/xAP_developer/post?postID=u9SQNGJtFSspksUTixyBLVAhaF6qYwu_DkG0-ro2c1M4K8n9Bre3NKT5WX_Bm68ENYhlwR_9Lg">i.bird@t...</a>
[mailto:<a
href="/group/xAP_developer/post?postID=mALM3dMaUbfQmnC2cQq5u2tJnjT-B1ty8AU6PZRMqG3HMKkGOhzS-bffmUfnN1Ag7DSTvqAikrKi5DxdTg">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