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: i.bird@xxxx
  • Date: Tue, 26 Aug 2003 16:42:00 +0000

Yep - sadly work has not been very restful which is why this will also be a
little brief.

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. I have not done this for the relays as they cannot generate
a xAP message so will therefore never need to send a UID. 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.

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. 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 have
the best of both worlds but that is not so just yet.

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.

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.

Ian




Original Message:
-----------------
From: Kevin Hawkins <a
href="/group/xAP_developer/post?postID=3iKqfPDcPhEOEl-jzct3aP8sWJoOSQNjpLqu1cIquYlVAiZz4u3aQssPtny0FhI3IGuXj2wjmM4yALJ6zg">lists@u...</a>
Date: Tue, 26 Aug 2003 12:00:02 +0100
To: <a
href="/group/xAP_developer/post?postID=PIp0ISfp3Q5aYbM5W4nE4v1V3IUiGsqc17FquxlFWAq-WW_PX3OVF3k-AsYCdw9ZFRMeuh0L4QfLYZF9AEr8R7DcvZ1EMEI">xAP_developer@xxxxxxx</a>
Subject: RE: [xAP_developer] Renaming of instances and SubInstances?


Hi Ian - It's always a sign of a good holiday when you come back for
a rest.
Would the below (wildcarding) not mean though that you had source
addresses that now became identical and you would therefore be unable to
target correctly ?? I am not sure if the '*' construct is valid here - I
can see that you would have different UID's still but you would be changing
one without the other (albeit in setup only).
I think in my implementation I will have default names 'Ouput1
Output2 ..' with UID's 'FFxxxx01 FFxxxx02..' and I will either rename based
on targeting or based on addressing the xAPp without a sub address at all
and with a UID of FFxxxx00 and then listing the sub instance name changes
in
one body - but I am not sure of the validity or usefulness of wildcarding
here. I may even check that a duplicate isn't created and send an error if
it is.
I had always envisaged that the last two digits of the ID would be
hardcoded by the developer. This would help in any hardware central profile
that was held for a device perhaps used in 'discovery' - a central
(internet) server could provide a profile for say HomeVison showing that
ACME.HomeVison.Node0:HeatReq with a UID of FF123405 meant 'output 5' on
'parallel port A' for example. Simialr to the schema server idea. The 05 on
the end of the UID would be developer fixed and mapped in a device
'profile'
and the documentation - your relays and inputs could be the same - then you
always know which terminal you are talking about - although you can choose
to name it whatever you want.
One thing I am using in my C-Bus implementation is an 'error' or
'debug' schema - these are messages that are sent out when something is
wrong, or may need examining - and could potentially be logged by a xAP
network monitor application. I personally use a severity level of 0-9 with
0
being a fatal type. Mostly I use these for debug at levels 7, 8 and 9 - and
they can be turned off with a xAP message - perhaps this (or a variant)
would be a sensible thing to standardise. Probably DEBUG and ERROR should
be
two different body types allowable with one schema. (NETWORK, HEALTH,
STATUS, MONITOR, INFO, or something).

K



> Anyway, if it helps I use targeting for all my renaming. I can rename
> multiple SubInstances at once to the same name but only one back to
> another
> name i.e. if my SubInstances were all named relay something then
rename
> 'relay*' to 'output' at once no limits. This gives me say 8
> SubInstances all
> with the name output. If I now say rename 'output' to 'watering' the
> program
> will only rename the first SubInstance and not all of them otherwise I
> would
> get into a loop I could not recover from.




To unsubscribe from this group, send an email to:
<a
href="/group/xAP_developer/post?postID=bfwESf2_Tf4kmmydGvgYxUfY20cYmD_lrMYBmp4195dT_tPQH4lMh12vAOxay6EIqN3iLtr8c1g2UNueyhxeEsMUMtZPQRGz8-9nCUgqaZcGKR-3">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>



--------------------------------------------------------------------
mail2web - Check your email from the web at
<a href="http://mail2web.com/";>http://mail2web.com/</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.