Re: Re: Hardware thing names

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

David Buckley wrote:

>--- In xAP_developer@xxxxxxx, Kevin Hawkins <lists@u...> wrote:
>
>
>>However you can use multiple hierarchies after the : (which
>>segments the device from its multiple endpoints), so to that
>>extent the : is just another herarchy delimiter  - this I
>>think is what you are wanting to
>>achieve...for example
>>
>>
>>Address                                                      UID
>>
>>acme.dimmer.unit1                                          FF234500
>>acme.dimmer.unit1:lamp.lounge.table                        FF234501
>>[snip]
>>
>>
>
>Kevin
>
>Hadn't realised that - that'll do fine.
>
>This is me attempting to implement BSC on HomeBrain, and essentially
>the idea is that any controllable entity that HB has can be
>represented ("exposed") as a xAP BSC device, and real xAP BSC
>controllable things can be listened to and shouted at from HB.
>
>
>
>
Great stuff, glad that HomeBrain is progressing well, do keep us filled
in with news and as before very happy to be an early adopter if you
reach that stage.

Interestingly this was actually  half the purpose of BSC - to allow
controllers and sotware applications  a nice easy/standard way of adding
xAP support & interacting with the majority of simple I/O devices
without having recourse to schema specific knowledge.  You may find
recognising source UID's rather than addresses is a very compact and
useful mechanism too - 3 bytes per device. A dimmer could just monitor a
xAP switch by UID for example. However you cannot target a UID you must
use the full source address (as otherwise any listeners using
wildcarding would break)

One thing just to mention is that the BSC spec is a little ambiguous
currently (reminds me I must update it) . When a xAPBSC.info or
xAPBSC.event message is sent then the fundamental parameters are
mandatory ie ID and STATE for every device and additionally LEVEL or
TEXT if the device is a level or text device. The DisplayText remains
optional in all cases.  If you don't use STATE then set it to ON or OFF
permanently, some level devices do this for example.  However when
sending a xAPBSC.cmd then  all parameters except ID are optional
although to do anything useful you will need to include something else
of course.     ie you can send a LEVEL= command without a STATE or a
STATE without a LEVEL for example. This is needed to allow a device to
be turned ON and OFF or TOGGLED say without changing (knowing) a stored
level or vica versa.

A useful application is that a lamp ON at 100% can be turned OFF and set
to 50% and then turned ON and come back at 50% for example - effectively
a preset or stored  light level.  Some devices can't support this eg X10
lamp modules which typically come back on at full brightness - and so
when they are turned back ON they will actually send a Level=100/100
event ie 100% and depending on the implementation may remain there or
later dim to the expected 50% and send a Level=50/100 command or
something. Likewise a lamp that supported setting levels in 10%
increments ( 11 different levels) would report a 40% level as Level=4/10
and would report this using a .event even if a command was sent to ask
it to go to 44% - so any device monitoring or enquiring (.query) of the
status of the device is always updated with the true values.

K