Re: Strange Viewer issue

["mark_harrison_uk2" <mph@xxxxxxxxxxxxxxx>]

--- In xAP_developer@xxxxxxx, Stuart Booth <lists@x> wrote:
> I'll have to dig through some old emails to uncover why HS works this
> way, unless James jumps in.

I think I can answer that one, because xAPHomevision works in (almost)
the same way, for the same reasons :-)


xAPHomevision and xAPHomeseer both use multiple SOURCE addresses to
get round the fact that there are only 254 subaddresses in the UID
available for endpoints. (256 = 2 Hex digits, but 00 and FF are
reserved, leaving 254 usable.)

The reason this is a problem is that X10 has 256 possible devices in
"normal" X10, and about 5000 with the Homeseer extensions (lots
of
virtual housecodes, lots of virtual device codes within each
housecode, so something like C25 is valid, as are X14 or Y37.)

Hence, to give a deterministic mapping between X10 devices and
SubUIDs, we chose to make each application (xAPHomeseer and
xAPHomevision) appear with multiple UIDs, in particular one for each
X10 code.

Homevision could have got away with sharing 2 UIDs, but we used one
per housecode for consistency with HomeVision, which needs that many more.

Given it was already using 16 SOURCES, it was a natural step to make
Homevision use a few more for the ports, flags and variables,
particularly given there might be large numbers of each of those.

The "UDP Port" issue is more complex. xAPHomeVision binds a new
instances of xapax.ocx for each broadcasting SOURCE (this makes comms
very straightforward.)

I had believed that each bound instance of the OCX would grab a
different UDP port...

... but I honestly don't know now :-(

M.