hbeats and virtual devices

[Gregg Liming <gregg@xxxxxxxxxxx>]

I'm currently working on BSC support for misterhouse (mh).  Mh
"suffers"=20
from an excess of devices to be treated as subaddresses (X10 alone=20
causes a problem) and, therefore, I've started creating "virtual=20
devices".  Here's an example:

mhouse.mh.main.core
- mhouse is vendor, mh is the "type of device", main is the
instance=20
and core refers to core functionality
mhouse.mh.main.x10_device
- just like above, but is used to address all of the x10 devices (except 2=
)

Essentially, any device other than "core" is considered
"virtual".=20=20
Currently, "core" is the one that is the source when
transmitting=20
heartbeats.  I happen to be using message viewer and notice that the=20
virtual device messages go "blind" (gray) after a period of
time--which=20
caused me to start thinking about the following:
(1) do I need to make each "virtual device" listen on it's own
(separate=20
from all others) ephemeral port and send a heartbeat to register it w/=20
the hub?, or
(2) can I just not send out heartbeats that are associated w/ the=20
virtual devices (message viewer's graying out is fine but I'd prefer not=20
to "break" something that depends on heartbeats)? or
(3) can I "register" w/ the hub as
"mhouse.mh.main"--essentially, up one=20
level?, or
(4) something else?

The second option is the easiest as I just leave things as they are; it=20
still allows hub registration sufficient to receive messages destined=20
for the virtual devices.  The first option strikes me as being perhaps=20
the most "correct", but the requirement to manage a potentially
large=20
number of virtual devices as "real" devices is admittedly a lot
of extra=20
effort--which I'd prefer to avoid if the UID subaddressing issue is=20
going to be addressed soon.

Gregg