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: Hardware thing names




David Buckley wrote:

>
>
>Having a little confusion with naming conventions.
>
>Its to do with when one device "represents" many devices,
much in the
>way that the HomeSeer interface and the CBus interface do.  I have
>neither of these things so I'm going at this from some distance.
>
>I think what these interfaces do is to represent the foreign devices
>as a sort of interface:device type format, whereby all the represented
>devices are subaddresses of a single device, eg
>    acme.homeseer.pc1:loungetablelamp
>    acme.homeseer.pc1:loungeceilinglamp
>
>
>Is there any specification reason why the interface representing these
>devices cant pretend to be lots of hardware devices
>    acme.lamp.lounge.table
>    acme.lamp.lounge.ceiling
>
>Much as they would be if there were not represented devices but real
>devices???
>
The idea is that the 'application' or 'device' uses only one address and
the enpoints that are presented by that device are sub addresses. An 8
channel temperature sensor for example is one device with 8 endpoints.
As Ian says the idea is that you have one master address which might be
acme.homeseer.pc1 and uses a UID ending in 00 eg FF222200 and then all
the sub addresses for the endpoints that the device handles sit off that
master using other UID's eg FF222201 FF222202 etc .  Only the master
sends a heartbeat and it is the master that you address to handle
information pertinent to the whole device.  These messages will permit
such things as wildcard addressing of the endpoints, configuration,
discovery, BSC handling, groups & scenes, data caching and network
monitoring.  Particularly with say wildcarding then the only way to
ensure consistency of multiple synchronised changes is via a master
address where all (or none) of the changes happen. If each endpoint acts
individually then it si possible that some may , and some may not change
state.

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
acme.dimmer.unit1:lamp.lounge.ceiling                      FF234502
acme.dimmer.unit1:lamp.hall.ceiling                        FF234503
acme.dimmer.unit1:fan.conservatory                         FF234504
acme.dimmer.unit2                                          FF234500
acme.dimmer.unit2:lamp.lounge.Downlighters                 FF234501
acme.dimmer.unit2:lamp.hall.table                          FF234501

Here acme make a 4 cahnnel 'dimmer' device of which there are two
installed called 'unit1' and 'unit2'

Now you can address say all your lights on dimmers as
Target=acme.dimmer.*:lights.>  or everything in the lounge as
Target=*.*.*:*.lounge.>  .

Yes you could set everything up as individual devices on xAP but each
would require to generate heartbeats and there really isn't any
hierarchical relationship in the hardware as they would then be flat
structure individual devices.

You will note that there are only 254 unique UID's available per device
(01-FE)which seems a lot and satisfies nearly every need but  when
coupled with 'virtual X10' devices as used by say HomeSeer we needed
more. (A1 to Z99 and more) . In such a case the approach used was to
break the application into several individual (virtual) applications -
one for each housecode and each one sending a heartbeat.  (There is also
a proposal to support an extended UID structure in discussion at the
moment which would expand the 254 to 16 million using 6 hex digits ).

One other neat aspect of UID's is that you can uniquely identify a
source based on the UID rather than the long source address and also
identify its 'master' and the related devices. Also using BSC, discovery
is supported allowing you to target the 'master' and it tells you all
about the existance, capability and state of the sub addresses.

Kevin




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.