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: Addressing vs sub-adressing



--- In xAP_developer@xxxxxxx, "Patrick Giasson"
<patrick.giasson.maillinglist@...> wrote:
>
> > >
> > > I want to separate the 1-wire architecture from the 1-wire
> adressing,
> > > and that's the whole interrogation I have: is it a good
idea?
> Suppose
> > > I want to do the same thing as above, but using a DS18B20
(temp)
> and
> > > a DS2450 (ADC for humidity) in the same "plastic
box". Is it ok
> to
> > > use the same addressing, :temperature and :humidity, even
though
> they
> > > are not the same physical (1-wire) device?
> >
> > Yes - the address segments to the left of the : are the whole
device
> > (the Tini)
> > and to the right are endpoints on that one device .
>
> Oh, I wanted the tini to be transparent too:
>
> I was thinking of the left side "virutal devices" made of
1-wire
> chips and the right side as groups of output from such virtual
> devices.
>
> My blind controls are made of a PCB with a DS2408 and a DS2405. They
> work as a single unit and would prefer not see the physical Dallas
> chips appear on the XAP.

How,and which endpoints you present via xAP is totally up to you, you
can hide some and even create virtual ones should you wish. Just
create a construct

source=a.b.c:1wire.whatever.you.want

Have the 1wire be the virtual device but effectively a constant field
for all 1wire devices

>
> A DS2408 (1-wire chip with 8 I/O lines) could also be used as 8
> distinct subaddresses in another use behind the same tini.

source=a.b.c:1wire.output.1
source=a.b.c:1wire.output.2
source=a.b.c:iwire.output.3

etc

>
> Finally, I'd sometime like to "split" a Dallas chip in two
by
> adressing it through 2 XAP addresses (two locations).

If by location you mean to the left of the : - well you can do this of
course but I'm not sure I see any advantage. You will incur overhead
as each distinct device (address to the left of the :) has
responsibilities - generating heartbeats, start / stopped messages,
xAP intranet membership, responding to queries targeted at the main
application (00) sub address etc, wildcard interpretation etc.  Also
it will be perceived as separate devices and yet there is an
interdependence in that if one device fails then the others instantly
vanish too.  Conversly external devices can't interpret the
interdependence either.


>
>
>
> Example:
>
> The 1-wire network behind the tini will be full of different devices
> like window blinds, lcd displays, temperature sensors, etc. I though
> of making the software in the tini route xap requests of different
> addresses into the 1-wire transparently. Is it something
"allowed":
>
> elperepat.blind.southeastwindow
> elperepat.display.bedroom
> elperepat.sensor.outdoor:temperature

Well yes but you have three xAP applications (devices) now and each
will have the responsibilities and overhead outlined above which
wastes codespace and time. Maybe I'm missing something but I don't see
any advantage , and see disadvantages, compared with

elperepat.node.master:blind.southeastwindow
elperepat.node.master:display.bedroom
elperepat.node.master:sensor.outdoor:temperature

elperepat.node.master:sensor.indoor:temperature
elperepat.node.master:serial.connection.callerID

now only one xAP device
elperepat.node.master

K

>
>
> That's the way I thought to address the devices from the example
> above. They would all route through the tini to the 1-wire network.
>
>
> I know it'll be something large, but it would be so versatile. Also,
> at the price at which devices like tini are, I'd prefer having them
> do as much as possible.
>
>
> Patrick
>






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.