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: Renaming of instances and SubInstances?


  • Subject: RE: Renaming of instances and SubInstances?
  • From: Kevin Hawkins
  • Date: Sun, 31 Aug 2003 17:55:00 +0000

Hi Ian...

> -----Original Message-----
> From: Ian B
>
> 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.

Sounds good...
>
> 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?

I think you need to send a message for each UID - this is because something
could be watching for the UID to change state ( based only on the source
UID
)- so two message should go out in succession.

Whether there should also be a message sent out on the '00' UID that
contains a list of the channels that have changed state is really the same
issue that I raised in the adjacent thread - no-one seems to have a view on
that ;-)

>
> 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?

Again - that was what I too asked in the adjacent Topic 1 thread - there
are
two possible ways of doing it - multiple names within one body or multiple
body parts - I sort of favour the multiple body parts as it allows an
easier
way of spanning two messages together, and it fits in with James' usage in
say the news xAP - and you prefer the single body - anyone else any views
here ??

>
> 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.

I think that makes sense - the '00' UID is really the whole device or the
xAP application - as such it should report things related to the whole
device - maybe when two things change state a message should go out from
each one - but the message from the '00' sub instance should give a status
update for all of the I/O possibly - a sort of summary ??

K

>
> Thanks
>
> Ian
>
> >-----Original Message-----
> >From: Kevin Hawkins [mailto:<a
href="/group/xAP_developer/post?postID=oxA-rmmq-0e4FC0j6KSzaiflQINATSOMJCNAm20_2Q8Dl3_Bk98btKx2LGovxz5hP2V4OMk4C_PBSG77Ol8">lists@u...</a>]
> >Sent: 26 August 2003 19:05
> >To: <a
href="/group/xAP_developer/post?postID=bw75QFRExNHM67JssUKeh-koQ0IUa-4uhrflb20GlItt_QiJ5PKXfXt_bTDCjoRoDNPqkPWxXu-zLpCdZlOL6bLMP_hVwQ">xAP_developer@xxxxxxx</a>
> >Subject: RE: [xAP_developer] Renaming of instances and
SubInstances?
> >
> >
> >
> >
> > > From: <a
href="/group/xAP_developer/post?postID=9OsXzgwuWXgyqceySumBS5dz0oKGKbgby3SWt-r1BVf9U31On1or-WbA7CjpGdUFF5Hp3wjoWw">i.bird@t...</a>
[mailto:<a
href="/group/xAP_developer/post?postID=ZbY34175RS3vwImk2yglXlucGMI3gg3dg-jNWRsWIxrR_NWf32eijSv7ffA4L9-2RMnJeNYWWP66kA">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
>
>
>
> ------------------------ Yahoo! Groups Sponsor
---------------------~--
> >
> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
> Printer at Myinks.com. Free s/h on orders $50 or more to the US
&amp;
> Canada. <a href="http://www.c1tracking.com/l.asp?cid=5511";>http://www.c1tracking.com/l.asp?cid=5511</a>
> <a href="http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/dpFolB/TM";>http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/dpFolB/TM</a>
>
---------------------------------------------------------------------~-
> >
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xAP_developer/post?postID=PkXlaw_ap--jHx-7v9tZWFJR55vSaXSm__fDa435qSmo5HojUoxMlCDyXrApboweVpZeXkHtksW_ik6RR5OooYw-jIAbb6o1u6zeQBziEeppnrY">xAP_developer-unsubscribe@xxxxxxx</a>
>
>
>
> Your use of Yahoo! Groups is subject to
> <a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a>







xAP_Development Main Index | xAP_Development Thread Index | xAP_Development 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.