RE: Renaming of instances and SubInstances?

[Ian B]

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

Yep

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

This is not current although I have given it a little thought after our
chat
at UKHA. In this case it would be a good idea to send a change of state
message. If a command comes in to set a relay say 'on' I currently send
back
a success heartbeat message. It would be easy enough to make this a more
relay oriented message. In many ways this would be good as a relay can
change state when a timer expires (just remembered that). Of course all 8
relays can change state at once like this so is this a compound message
body
or 8 simple messages? I don't really want to get into multi body messages
for this.

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

For inputs I send a message relating to the input that has changed which I
think is correct. If a status request message is sent to the inputs (using
the inputs schema) I return all their states.

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

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

You have a point here. I did code this bit way back at v1.1 stage so maybe
it is time for a rethink. It actually makes life simpler to only rename one
SubInstance at once although any saving is taken up in checking for other
duplicates.

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

A good question here. I will ignore this at the moment I think as I cannot
think of a good reply. I can always code it as an upgrade be it free or
otherwise.

>You can't (target) address based on UID

This makes life a little simpler!!

>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 think this is part of the aforementioned rethink.

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

When a message is inbound I parse the header as it comes in and don't store
anything of the data. When I get to the body I store it (the body between
the brackets) in the 80 bytes of RAM allocated to the task. I can analyse
and action it at my leisure.
When sending a message I don't build it in memory but send the predefined
strings from either flash or EEPROM adding on the indexes e.g. for the
input
number as I go along. All this is done using virtually no memory other than
a send buffer and working variables. I have 16 bytes for inbound and 8
bytes
for outbound buffers which are used completely by the interrupt driven
serial I/O.

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

Errr no. The heartbeat is a simple success or fail message - no status. As
above I think it would be worth rethinking this for relay commands and
changes of 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'.

Good plan. I await the basic schema eagerly ;-))

Seriously this does sound good though it might be hard to implement. Bat
some ideas over and lets see how it stacks up. If it can do both our
devices
I would think we are a good way there.

Thanks

Ian