xml1-wire-devel

Re: [Xml1-wire-devel] more on hubs and door locks

[Jac K. <j.k...@th...>]

On Thu, 18 Jan 2001, Bruce Boyes wrote:

> Someone else raised the scenario of a vandal plugging in a OW enabled PC
> into the blue dot reader, looking for DS2406s on all DS2409 branches, and
> turning them on in hopes of activating the door strike. Or plugging 120 VAC
> into the blue dot reader!

The 2409 solved the problem of outside access to other parts of the
one-wire net, but the 230VAC (for us europeans) issue is one that keeps
bugging me. Over a year ago I tried to raise this issue on the one-wire
list, but there was no response at all. Like no-one else cared.

Would it be possible to use some cheap parts (almost like the 2409 but
with some component in the ground connection too) to isolate the reader
from the rest of the net? Or would it be like protecting a transistor with
a fuse? (A transistor protected by a fast-acting fuse will protect the
fuse by blowing first.)

Regards,

Jac

--
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com

Re: [Xml1-wire-devel] New hub design, request for input

[Jac K. <j.k...@th...>]

On Thu, 18 Jan 2001, Bruce Boyes wrote:

> One thing we have been tipped off by Dallas about is that if you short an
> active branch on the 2409 it will hang the network and the 2409 can't
> recover except by power cycling. This is a bug in the 2409 design which
> isn't likely to change soon.

That's the end of my access control design. One can't rely on users to
slot their iButtons into the reader (the one with led) without causing a
short every now and then. Back to the drawing board :-(

> So we are pondering a watchdog which would power cycle the 2409. When the
> 2409 is power  cycled it disabled both branches.

What about a watchdog that resets the 2409 whenever the active branch is
short? If the one-wire signal level stays below a threshold for over 1
second just reset the part. This way there would be no need for almost
continues one-wire activity.

Regards,

Jac

--
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com

[Xml1-wire-devel] another tagging idea DS2409 main vs branches

[Bruce B. <bb...@sy...>]

We are also planning a new OneWire board which is essentially the
main/trunk portion of the new hub board. It has terminals for OW
connection, a DS2433 and an iButton clip.

Imagine adding it to each branch of a hub. Voila! You now have branch
tagging if you want it.

Bruce
-----------------------------------------
           WWW.SYSTRONIX.COM
 Fast 8051s, embedded Java and much more
 new! 8x1-Wire I/O board for 1-Wire nets
  +1-801-534-1017  Salt Lake City, USA
-----------------------------------------

RE: [Xml1-wire-devel] New hub design, request for input

[Byron K. A. <b.k...@ie...>]

> If the tag on the DS2433 contains the 1-Wire Address's
> of the DS2409's then it can be anywhere.  I would prefer
> to have it not down a branch so that you could
> know what a branch is before opening it.

A valid approach, probably the right one. My only thought is that if you
have a network containing several memory devices, not all containing tagging
information, you will have to check  each of them and determine whether or
not they contain a tag, and then process that tag. If, however, it was a
rule that braches are always tagged on their aux branch, you would already
know where to find what tagging information. On the other hand, if you have
prior knowledge of the network, it would make sense to put all of the
information for all of the branches in a single tag on the main branch.

Byron

> -----Original Message-----
> From: xml...@li...
> [mailto:xml...@li...]On Behalf Of David
> Smiczek
> Sent: Thursday, January 18, 2001 7:25 AM
> To: Byron K. Appelt; 1-wire TAG list
> Subject: RE: [Xml1-wire-devel] New hub design, request for input
>
>
> > The problem is that if you have multiple DS2433's, especially
> if they are
> > associated with multiple DS2409 branches, you can't tell which DS2433 is
> > associated with which branch.
>
> If the tag on the DS2433 contains the 1-Wire Address's
> of the DS2409's then it can be anywhere.  I would prefer
> to have it not down a branch so that you could
> know what a branch is before opening it.
>
> Dave
>
>
> > -----Original Message-----
> > From: xml...@li...
> > [mailto:xml...@li...]On Behalf Of Byron
> > K. Appelt
> > Sent: Wednesday, January 17, 2001 6:06 PM
> > To: 1-wire TAG list
> > Subject: RE: [Xml1-wire-devel] New hub design, request for input
> >
> >
> > The problem is that if you have multiple DS2433's, especially
> if they are
> > associated with multiple DS2409 branches, you can't tell which DS2433 is
> > associated with which branch. Requiring that the DS2409 be
> > switched insures
> > that you know this. BTW, I am all for having a DS2433 or at least
> > space for
> > one, on the aux branch.
> >
> > Byron K. Appelt
> > Universal Vinculum Incorporated
> > http://www.vinculum.com
> >
> >
> > > -----Original Message-----
> > > From: xml...@li...
> > > [mailto:xml...@li...]On Behalf Of Jac
> > > Kersing
> > > Sent: Wednesday, January 17, 2001 5:16 PM
> > > To: Bruce Boyes
> > > Cc: xml...@li...
> > > Subject: Re: [Xml1-wire-devel] New hub design, request for input
> > >
> > >
> > > On Sun, 14 Jan 2001, Bruce Boyes wrote:
> > >
> > > > Naturally we'd want to include tagging ability, perhaps a
> > > DS2433 on the aux
> > > > branch of each DS2409. Then the main branch output is the
> > > active branch of
> > > > OneWire devices. Then you can tell for sure that the tagging
> > > 2433 you are
> > > > reading is definitely the correct one since it's the only
> > > device on the aux
> > > > output.
> > >
> > > What about adding a DS2433 on the main bus? That way there's
> no need to
> > > address the DS2409 to get to the tagging information. Being
> able to read
> > > the configuration information for the first layer of the 1-wire net
> > > without switching DS2409 to AUX branch seems easier.
> > >
> > > > Alternatively, if you use both 2409 outputs as switched
> > > branches, then you
> > > > get twice as many but the tagging is not quite so clean. If the
> > > 2433 was on
> > > > each output, then it's hard to tell if the 2433 you are
> reading is the
> > > > tagging 2433 of this 2409 or some other 2433 on the branch.
> > >
> > > If the tagging contains the 1-wire address of the 2409 that
> > shouldn't be a
> > > problem. And having both main and aux available would be very
> nice. That
> > > way one of the 2409 could be used as a door controller. If aux isn't
> > > available one would have to use a second 2409 main also for
> > this purpose.
> > >
> > > > The branches would have pluggable screw terminals, maybe also RJ12s
> > > > for the maximum of flexibility.
> > >
> > > Please add RJ12s for easy connection of blue dots, 8x1wire etc.
> > >
> > > Regards,
> > >
> > > Jac
> > >
> > > --
> > >  Jac Kersing            Technical Consultant   The-Box Development
> > >  j.k...@th...                         http://www.the-box.com
> > >
> > >
> > > _______________________________________________
> > > Xml1-wire-devel mailing list
> > > Xml...@li...
> > > http://lists.sourceforge.net/lists/listinfo/xml1-wire-devel
> > >
> >
> >
> > _______________________________________________
> > Xml1-wire-devel mailing list
> > Xml...@li...
> > http://lists.sourceforge.net/lists/listinfo/xml1-wire-devel
> >
>
>
> _______________________________________________
> Xml1-wire-devel mailing list
> Xml...@li...
> http://lists.sourceforge.net/lists/listinfo/xml1-wire-devel
>

[Xml1-wire-devel] more on hubs and door locks

[Bruce B. <bb...@sy...>]

Someone else raised the scenario of a vandal plugging in a OW enabled PC
into the blue dot reader, looking for DS2406s on all DS2409 branches, and
turning them on in hopes of activating the door strike. Or plugging 120 VAC
into the blue dot reader!

If you keep the Blue dot reader on one branch of the 2409 and the strike on
the other, then a vandal can't ever see the strike from the blue dot reader.

Also I wonder about using an iButton on the hub to increase security, a SHA
button or one of the secure memory buttons? You could keep there a local
list of authorized access ID numbers, or some handshake password. Thoughts?
Our hub will have an iButton socket. 

There's no way I know to insert optical isolation into the OW net, you need
to have separate TX and RX signals to do this (such as at the DS2480 UART
adapter). I don't know if any other isolation (transformer) is any different.

Bruce
-----------------------------------------
           WWW.SYSTRONIX.COM
 Fast 8051s, embedded Java and much more
 new! 8x1-Wire I/O board for 1-Wire nets
  +1-801-534-1017  Salt Lake City, USA
-----------------------------------------

Re: [Xml1-wire-devel] New hub design, request for input

[Bruce B. <bb...@sy...>]

At 00:15 1/18/2001 +0100, you wrote:
>On Sun, 14 Jan 2001, Bruce Boyes wrote:
>
>> Naturally we'd want to include tagging ability, perhaps a DS2433 on the aux
>> branch of each DS2409. Then the main branch output is the active branch of
>> OneWire devices. Then you can tell for sure that the tagging 2433 you are
>> reading is definitely the correct one since it's the only device on the aux
>> output.
>
>What about adding a DS2433 on the main bus? That way there's no need to
>address the DS2409 to get to the tagging information. Being able to read
>the configuration information for the first layer of the 1-wire net
>without switching DS2409 to AUX branch seems easier.

Yep, we've decided to do this and use both branches of the 2409 as switched
branches, for four such branches per hub (using 2 2409s).

>If the tagging contains the 1-wire address of the 2409 that shouldn't be a
>problem. And having both main and aux available would be very nice. That
>way one of the 2409 could be used as a door controller. If aux isn't
>available one would have to use a second 2409 main also for this purpose.
>
>> The branches would have pluggable screw terminals, maybe also RJ12s
>> for the maximum of flexibility.
>
>Please add RJ12s for easy connection of blue dots, 8x1wire etc.

Yep, decided that too. That way you have easy bench hookup as well as
rugged field hookup, in any combination. RJs and modular cable are fine for
short runs (<< 100 feet) with longer runs needing Cat5 and screws.

One thing we have been tipped off by Dallas about is that if you short an
active branch on the 2409 it will hang the network and the 2409 can't
recover except by power cycling. This is a bug in the 2409 design which
isn't likely to change soon.

So we are pondering a watchdog which would power cycle the 2409. When the
2409 is power  cycled it disabled both branches.

All the commercial watchdogs have a 1 second max timeout. Do you think this
is practical with TINI? I.e. there would have to be some trunk OW activity
every second to keep the watchdog from barking. This could be jumpered to
disable it, or maybe remotely controlled via a DS2406 on the hub trunk,
defaulting to no watchdog.

The hub will have a 5V 1A switcher so it can provide an average of 250 mA
per branch of regulated 5V per hub. Input will be 12-24 VDC which should
satisfy all the industrial folks and allow powering relays direct from a
12V or 24VDC raw branch supply (such as n electric door strike).

Bruce
-----------------------------------------
           WWW.SYSTRONIX.COM
 Fast 8051s, embedded Java and much more
 new! 8x1-Wire I/O board for 1-Wire nets
  +1-801-534-1017  Salt Lake City, USA
-----------------------------------------

RE: [Xml1-wire-devel] New hub design, request for input

[David S. <dav...@da...>]

> The problem is that if you have multiple DS2433's, especially if they are
> associated with multiple DS2409 branches, you can't tell which DS2433 is
> associated with which branch.

If the tag on the DS2433 contains the 1-Wire Address's
of the DS2409's then it can be anywhere.  I would prefer
to have it not down a branch so that you could
know what a branch is before opening it.

Dave


> -----Original Message-----
> From: xml...@li...
> [mailto:xml...@li...]On Behalf Of Byron
> K. Appelt
> Sent: Wednesday, January 17, 2001 6:06 PM
> To: 1-wire TAG list
> Subject: RE: [Xml1-wire-devel] New hub design, request for input
>
>
> The problem is that if you have multiple DS2433's, especially if they are
> associated with multiple DS2409 branches, you can't tell which DS2433 is
> associated with which branch. Requiring that the DS2409 be
> switched insures
> that you know this. BTW, I am all for having a DS2433 or at least
> space for
> one, on the aux branch.
>
> Byron K. Appelt
> Universal Vinculum Incorporated
> http://www.vinculum.com
>
>
> > -----Original Message-----
> > From: xml...@li...
> > [mailto:xml...@li...]On Behalf Of Jac
> > Kersing
> > Sent: Wednesday, January 17, 2001 5:16 PM
> > To: Bruce Boyes
> > Cc: xml...@li...
> > Subject: Re: [Xml1-wire-devel] New hub design, request for input
> >
> >
> > On Sun, 14 Jan 2001, Bruce Boyes wrote:
> >
> > > Naturally we'd want to include tagging ability, perhaps a
> > DS2433 on the aux
> > > branch of each DS2409. Then the main branch output is the
> > active branch of
> > > OneWire devices. Then you can tell for sure that the tagging
> > 2433 you are
> > > reading is definitely the correct one since it's the only
> > device on the aux
> > > output.
> >
> > What about adding a DS2433 on the main bus? That way there's no need to
> > address the DS2409 to get to the tagging information. Being able to read
> > the configuration information for the first layer of the 1-wire net
> > without switching DS2409 to AUX branch seems easier.
> >
> > > Alternatively, if you use both 2409 outputs as switched
> > branches, then you
> > > get twice as many but the tagging is not quite so clean. If the
> > 2433 was on
> > > each output, then it's hard to tell if the 2433 you are reading is the
> > > tagging 2433 of this 2409 or some other 2433 on the branch.
> >
> > If the tagging contains the 1-wire address of the 2409 that
> shouldn't be a
> > problem. And having both main and aux available would be very nice. That
> > way one of the 2409 could be used as a door controller. If aux isn't
> > available one would have to use a second 2409 main also for
> this purpose.
> >
> > > The branches would have pluggable screw terminals, maybe also RJ12s
> > > for the maximum of flexibility.
> >
> > Please add RJ12s for easy connection of blue dots, 8x1wire etc.
> >
> > Regards,
> >
> > Jac
> >
> > --
> >  Jac Kersing            Technical Consultant   The-Box Development
> >  j.k...@th...                         http://www.the-box.com
> >
> >
> > _______________________________________________
> > Xml1-wire-devel mailing list
> > Xml...@li...
> > http://lists.sourceforge.net/lists/listinfo/xml1-wire-devel
> >
>
>
> _______________________________________________
> Xml1-wire-devel mailing list
> Xml...@li...
> http://lists.sourceforge.net/lists/listinfo/xml1-wire-devel
>

RE: [Xml1-wire-devel] New hub design, request for input

[Byron K. A. <b.k...@ie...>]

The problem is that if you have multiple DS2433's, especially if they are
associated with multiple DS2409 branches, you can't tell which DS2433 is
associated with which branch. Requiring that the DS2409 be switched insures
that you know this. BTW, I am all for having a DS2433 or at least space for
one, on the aux branch.

Byron K. Appelt
Universal Vinculum Incorporated
http://www.vinculum.com


> -----Original Message-----
> From: xml...@li...
> [mailto:xml...@li...]On Behalf Of Jac
> Kersing
> Sent: Wednesday, January 17, 2001 5:16 PM
> To: Bruce Boyes
> Cc: xml...@li...
> Subject: Re: [Xml1-wire-devel] New hub design, request for input
>
>
> On Sun, 14 Jan 2001, Bruce Boyes wrote:
>
> > Naturally we'd want to include tagging ability, perhaps a
> DS2433 on the aux
> > branch of each DS2409. Then the main branch output is the
> active branch of
> > OneWire devices. Then you can tell for sure that the tagging
> 2433 you are
> > reading is definitely the correct one since it's the only
> device on the aux
> > output.
>
> What about adding a DS2433 on the main bus? That way there's no need to
> address the DS2409 to get to the tagging information. Being able to read
> the configuration information for the first layer of the 1-wire net
> without switching DS2409 to AUX branch seems easier.
>
> > Alternatively, if you use both 2409 outputs as switched
> branches, then you
> > get twice as many but the tagging is not quite so clean. If the
> 2433 was on
> > each output, then it's hard to tell if the 2433 you are reading is the
> > tagging 2433 of this 2409 or some other 2433 on the branch.
>
> If the tagging contains the 1-wire address of the 2409 that shouldn't be a
> problem. And having both main and aux available would be very nice. That
> way one of the 2409 could be used as a door controller. If aux isn't
> available one would have to use a second 2409 main also for this purpose.
>
> > The branches would have pluggable screw terminals, maybe also RJ12s
> > for the maximum of flexibility.
>
> Please add RJ12s for easy connection of blue dots, 8x1wire etc.
>
> Regards,
>
> Jac
>
> --
>  Jac Kersing            Technical Consultant   The-Box Development
>  j.k...@th...                         http://www.the-box.com
>
>
> _______________________________________________
> Xml1-wire-devel mailing list
> Xml...@li...
> http://lists.sourceforge.net/lists/listinfo/xml1-wire-devel
>

Re: [Xml1-wire-devel] New hub design, request for input

[Jac K. <j.k...@th...>]

On Sun, 14 Jan 2001, Bruce Boyes wrote:

> Naturally we'd want to include tagging ability, perhaps a DS2433 on the aux
> branch of each DS2409. Then the main branch output is the active branch of
> OneWire devices. Then you can tell for sure that the tagging 2433 you are
> reading is definitely the correct one since it's the only device on the aux
> output.

What about adding a DS2433 on the main bus? That way there's no need to
address the DS2409 to get to the tagging information. Being able to read
the configuration information for the first layer of the 1-wire net
without switching DS2409 to AUX branch seems easier.

> Alternatively, if you use both 2409 outputs as switched branches, then you
> get twice as many but the tagging is not quite so clean. If the 2433 was on
> each output, then it's hard to tell if the 2433 you are reading is the
> tagging 2433 of this 2409 or some other 2433 on the branch.

If the tagging contains the 1-wire address of the 2409 that shouldn't be a
problem. And having both main and aux available would be very nice. That
way one of the 2409 could be used as a door controller. If aux isn't
available one would have to use a second 2409 main also for this purpose.

> The branches would have pluggable screw terminals, maybe also RJ12s
> for the maximum of flexibility.

Please add RJ12s for easy connection of blue dots, 8x1wire etc.

Regards,

Jac

--
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com

RE: [Xml1-wire-devel] New hub design, request for input

[David S. <dav...@da...>]

Bruce,

> Naturally we'd want to include tagging ability, perhaps a DS2433
> on the aux branch of each DS2409.

If the 'tag' file in the DS2433 contains the 1-Wire Net Address
of both of the DS2409's then it can be anywhere including
on the trunk.

> The power could be switched so that it was only on
> when the branch was selected.

OK, but note the DS2409 powers a branch (keeps it high) even
when the branch is off.  This prevents a big load of powering-
up devices being dumped on the trunk when a branch is turned
on.

> An interesting question is how quickly TINI could switch branches and
> perform some useful task, so that a switched branch could do something
> interesting like door access, if possible.

We are working on a TINI door access demo using a DS2409:
ftp://ftp.dalsemi.com/pub/auto_id/temp/TINIDoorControllerSchematicB.PDF

I believe the response time is about 50ms per door from TINI.
All of the code and documentation will be posted soon.

Dave


> -----Original Message-----
> From: xml...@li...
> [mailto:xml...@li...]On Behalf Of Bruce
> Boyes
> Sent: Sunday, January 14, 2001 6:46 PM
> To: xml...@li...
> Subject: [Xml1-wire-devel] New hub design, request for input
>
>
> We are thinking very seriously of doing a quick OneWire hub design, which
> would have at least two DS2409s on it, for at least two branch outputs.
>
> Naturally we'd want to include tagging ability, perhaps a DS2433
> on the aux
> branch of each DS2409. Then the main branch output is the active branch of
> OneWire devices. Then you can tell for sure that the tagging 2433 you are
> reading is definitely the correct one since it's the only device
> on the aux
> output.
>
> Alternatively, if you use both 2409 outputs as switched branches, then you
> get twice as many but the tagging is not quite so clean. If the
> 2433 was on
> each output, then it's hard to tell if the 2433 you are reading is the
> tagging 2433 of this 2409 or some other 2433 on the branch.
>
> Our intent is that this "hub" would be something you would string along a
> OneWire "backbone". For example one hub per floor or section of a
> building,
> with one branch per office or room.
>
> Each hub would also have a rugged switching regulator which could supply
> power to its branches. The power could be switched so that it was only on
> when the branch was selected. It would be the same or similar to our STEP
> boards, at least 8-24VDC input, 1A 5V output. The hub power would go just
> to the branches, the backbone would be powered by the sockets board.
> Shorting out one branch would only affect that branch (assuming we switch
> each branch's regulated 5V), if we didn't then it would still only affect
> the branches of that hub.
>
> If memory serves, some branches would want to be powered all the time so
> that, for example, temperature alarms could be sampled at once?
> Has someone
> used these devices in this mode?
>
> The hubs could also be cascaded so that a branch could have switched
> "leaves", although it seems this level of complexity could drive you nuts
> pretty quickly. Point is, the hub and its power circuit would allow this.
>
> This would be a rugged industrial grade device with series resistors on
> each branch and diode clamps, etc to guard against long cable runs on each
> branch.
>
> The "trunk" oneWire would have RJ12s and screw terminals for easy
> connection to any common Dallas-compliant TINI socket board (all the eXX
> and all Systronix sockets use the same pinout). The branches would have
> pluggable screw terminals, maybe also RJ12s for the maximum of
> flexibility.
>
> Each 2409 would also have an LED to indicate status and power.
>
> An interesting question is how quickly TINI could switch branches and
> perform some useful task, so that a switched branch could do something
> interesting like door access, if possible.
>
> Any security issues which might affect hardware design? We could
> include an
> iButton socket on the hub board - where should it be? On the aux output
> with the tagging device?
>
> Input welcome.
>
> - Bruce
> -----------------------------------------
>            WWW.SYSTRONIX.COM
>  Fast 8051s, embedded Java and much more
>  new! 8x1-Wire I/O board for 1-Wire nets
>   +1-801-534-1017  Salt Lake City, USA
> -----------------------------------------
>
> _______________________________________________
> Xml1-wire-devel mailing list
> Xml...@li...
> http://lists.sourceforge.net/lists/listinfo/xml1-wire-devel
>

[Xml1-wire-devel] New hub design, request for input

[Bruce B. <bb...@sy...>]

We are thinking very seriously of doing a quick OneWire hub design, which
would have at least two DS2409s on it, for at least two branch outputs.

Naturally we'd want to include tagging ability, perhaps a DS2433 on the aux
branch of each DS2409. Then the main branch output is the active branch of
OneWire devices. Then you can tell for sure that the tagging 2433 you are
reading is definitely the correct one since it's the only device on the aux
output.

Alternatively, if you use both 2409 outputs as switched branches, then you
get twice as many but the tagging is not quite so clean. If the 2433 was on
each output, then it's hard to tell if the 2433 you are reading is the
tagging 2433 of this 2409 or some other 2433 on the branch.

Our intent is that this "hub" would be something you would string along a
OneWire "backbone". For example one hub per floor or section of a building,
with one branch per office or room.

Each hub would also have a rugged switching regulator which could supply
power to its branches. The power could be switched so that it was only on
when the branch was selected. It would be the same or similar to our STEP
boards, at least 8-24VDC input, 1A 5V output. The hub power would go just
to the branches, the backbone would be powered by the sockets board.
Shorting out one branch would only affect that branch (assuming we switch
each branch's regulated 5V), if we didn't then it would still only affect
the branches of that hub.

If memory serves, some branches would want to be powered all the time so
that, for example, temperature alarms could be sampled at once? Has someone
used these devices in this mode?

The hubs could also be cascaded so that a branch could have switched
"leaves", although it seems this level of complexity could drive you nuts
pretty quickly. Point is, the hub and its power circuit would allow this.

This would be a rugged industrial grade device with series resistors on
each branch and diode clamps, etc to guard against long cable runs on each
branch.

The "trunk" oneWire would have RJ12s and screw terminals for easy
connection to any common Dallas-compliant TINI socket board (all the eXX
and all Systronix sockets use the same pinout). The branches would have
pluggable screw terminals, maybe also RJ12s for the maximum of flexibility.

Each 2409 would also have an LED to indicate status and power.

An interesting question is how quickly TINI could switch branches and
perform some useful task, so that a switched branch could do something
interesting like door access, if possible.

Any security issues which might affect hardware design? We could include an
iButton socket on the hub board - where should it be? On the aux output
with the tagging device?

Input welcome.

- Bruce
-----------------------------------------
           WWW.SYSTRONIX.COM
 Fast 8051s, embedded Java and much more
 new! 8x1-Wire I/O board for 1-Wire nets
  +1-801-534-1017  Salt Lake City, USA
-----------------------------------------

Re: [Xml1-wire-devel] Warning: I'm no EE

[Sean K. <ke...@ad...>]

Nevermind ... I found the note on systronix.com.

Thanks.
--Sean

----- Original Message ----- 
From: "Sean Kelly" <ke...@ma...>
To: "XML 1-Wire Tag List" <xml...@li...>
Sent: 8 January 2001 5.19 PM
Subject: [Xml1-wire-devel] Warning: I'm no EE


> Folks:
> 
> Why is it that when I plug my 8x1-wire
> into my TILT, the TINI resets?
> 
> --k
> 
> 
> 
> _______________________________________________
> Xml1-wire-devel mailing list
> Xml...@li...
> http://lists.sourceforge.net/mailman/listinfo/xml1-wire-devel
> 

[Xml1-wire-devel] Warning: I'm no EE

[Sean K. <ke...@ma...>]

Folks:

Why is it that when I plug my 8x1-wire
into my TILT, the TINI resets?

--k

[Xml1-wire-devel] New Changes

[Byron K. A. <b.k...@ie...>]

I have just committed changes implementing the below described suggestion of
Sean's. I have also changed parserTester to use this interface. OWDevice
objects now have a field with accessor and mutator methods to get the name
of the cluster within which the device is contained. There is also a package
net.sourceforge.xml1wire.devicefilters which contains implementations of a
filter to get switches and levelsensors.

The code needs a little cleanup which I will get to shortly.

Byron K. Appelt
Universal Vinculum Incorporated


> While doing so, there was something that rubbed me wrong
> about the Switches, LevelSensors, etc., methods.  What
> happens when we add class OWMemoryCan ... then we'll need
> OWMemoryCans(Reader) and OWMemoryCans(Reader, String)
> methods.  Then add OWThermometer, with its two
> Thermometer methods.  The TagParser interface is going to
> get huge.
>
> Let's take an approach similar to
> java.io.File.list(FilenameFilter).  The user passes in a
> filtering object which gets a chance to approve or
> disapprove of each OWDevice (or subclass) about to be
> created.  The filter object implements a specified
> interface.
>
> It'd be something like this:
>
> public interface Filter {
>     boolean accept(String className, String clusterName,
>         int familyCode, String netAddress);
> }
>
> Then, class TagParser would have these methods:
>
> public class TagParser {
>     ...
>     /** Return all devices. */
>     public Enumeration devices(Reader in) {
>         return devices(ALWAYS_PASS_FILTER);
>     }
>
>     /** Return all devices passing the given filter. */
>     public Enumeration devices(Reader in, Filter filter)
>         throws SAXException, IOException {
>         ...
>     }
>
>     /** This filter always passes all devices. */
>     public static class AlwaysPassFilter implements Filter {
>         public boolean accept(String className,
>             String clusterName, int familyCode,
>             String netAddress) {
>             return true;
>         }
>     }
>
>     /** One of these is all you'll ever need. */
>     public static final ALWAYS_PASS_FILTER = new AlwaysPassFilter();
> }
>
> Calling TagParser.devices(Reader) returns all devices, as
> you'd expect.  Calling TagParser.devices(Reader, Filter)
> returns a devices that pass the filter.  The user gets a
> chance to filter based on four criteria.
>
> Since the Fitler interface is lightweight, anonymous inner
> classes would make this a breeze to use, too.
>
> Comments?
>
> --Sean

RE: [Xml1-wire-devel] javadoc

[Byron K. A. <b.k...@ie...>]

The filter interface sounds like a good idea. We could still write a package
of filter implementations for the commonly used objects. One issue that has
occurred to me is, how to handle nested clusters. Currently, if you ask for
the switches in a particular cluster, you will get all the switches in that
cluster and all of its subclusters. Is this the desired behavior, or should
you only get the devices that are not nested further? Or is some more
flexible interface required? We will eventually also have similar issues
with branches, which I am thinking will probably be a subclass of clusters.

Byron



> -----Original Message-----
> From: xml...@li...
> [mailto:xml...@li...]On Behalf Of Sean
> Kelly
> Sent: Monday, December 18, 2000 9:21 PM
> To: XML 1-Wire Tag List
> Subject: [Xml1-wire-devel] javadoc
>
> Let's take an approach similar to
> java.io.File.list(FilenameFilter).  The user passes in a
> filtering object which gets a chance to approve or
> disapprove of each OWDevice (or subclass) about to be
> created.  The filter object implements a specified
> interface.
>
> It'd be something like this:
>
> public interface Filter {
>     boolean accept(String className, String clusterName,
>         int familyCode, String netAddress);
> }
>
> Then, class TagParser would have these methods:
>
> public class TagParser {
>     ...
>     /** Return all devices. */
>     public Enumeration devices(Reader in) {
>         return devices(ALWAYS_PASS_FILTER);
>     }
>
>     /** Return all devices passing the given filter. */
>     public Enumeration devices(Reader in, Filter filter)
>         throws SAXException, IOException {
>         ...
>     }
>
>     /** This filter always passes all devices. */
>     public static class AlwaysPassFilter implements Filter {
>         public boolean accept(String className,
>             String clusterName, int familyCode,
>             String netAddress) {
>             return true;
>         }
>     }
>
>     /** One of these is all you'll ever need. */
>     public static final ALWAYS_PASS_FILTER = new AlwaysPassFilter();
> }
>
> Calling TagParser.devices(Reader) returns all devices, as
> you'd expect.  Calling TagParser.devices(Reader, Filter)
> returns a devices that pass the filter.  The user gets a
> chance to filter based on four criteria.
>
> Since the Fitler interface is lightweight, anonymous inner
> classes would make this a breeze to use, too.
>
> Comments?
>
> --Sean
>
>
>
>
>
> _______________________________________________
> Xml1-wire-devel mailing list
> Xml...@li...
> http://lists.sourceforge.net/mailman/listinfo/xml1-wire-devel
>

[Xml1-wire-devel] latest changes

[Byron K. A. <b.k...@ie...>]

After fighting with some problems related to case sensitivity and lack
thereof on my windows client. I have fixed the class names to match
conventions for real this time. I have also now moved the errorhandler
methods into TAGHandler.

Byron

RE: [Xml1-wire-devel] New Code added to repository

[Byron K. A. <b.k...@ie...>]

I have made changes to adhere to Sun's naming convention. I actually looked
it up for the first time, and, in addition to the capitalization
conventions, methods are supposed to start with verbs. Therefore, I have
made various changes such as, Clusters(Reader in) is now
getClusters(Reader in). If I have missed any violation of the convention,
please point them out.  I haven't changed TAGerrorhandler because it will be
absorbed by TAGHandler.

Byron

> -----Original Message-----
> From: Sean Kelly [mailto:ke...@ad...]
> Sent: Monday, December 18, 2000 8:37 PM
> To: Byron K. Appelt; 1-wire TAG list
> Subject: Re: [Xml1-wire-devel] New Code added to repository
>
>
> > I have just committed changes to the repository implementing these sorts
> of
> > methods. I will soon be creating some JavaDocs. Comments, as always are
> > desired.
>
> Looking good.  Thanks for committing this.
>
> A couple high-level comments ... the
> TAGerrorhandler class isn't pulling its weight, in my
> opinion.  I'd go ahead and just make the TAGparser itself
> implement the error handler interface and subsume its
> methods.
>
> Moreover, I don't mind having the warning() method just
> log the error, but both the error() and fatalError()
> methods ought to throw back the SAXParseException they're
> given.  If there's an error, the user needs to know about
> it and stop processing or handle the error in his/her own
> way.
>
> Also, all error messages, in the TAGerrorhandler,
> TAGhandler, and TAGparser, should go to System.err, not
> System.out.
>
> Finally, I'd recommend we use the Sun naming convention
> standards.  As you know, Java's overly happy with using
> the "." operator.  For example, in
>
>     a.b.c.d.e.f();
>
> about the only thing you can say safely is that "f is a
> method."  But is it package "a.b.c" class d, field e,
> method f?  Or is it package "a", class b, inner class c,
> field d, static inner class e, method f?  Or something
> else?
>
> The Sun naming convention helps disambiguate that:
> packages are all lower case, ClassNames are like that,
> methods areLikeThis, and constants are ALL_UPPER_CASE.
> This would affect the DevicesByName, LevelSensors, etc.,
> methods.
>
> Thoughts?
>
> Thanks again.
> --Sean
>
>

[Xml1-wire-devel] javadoc

[Sean K. <ke...@ad...>]

I've just fleshed out the javadocs in our classes so far.
Running "ant doc" creates a pretty nice set of reference
documentation.  Do a "cvs update" to get the latest.

While doing so, there was something that rubbed me wrong
about the Switches, LevelSensors, etc., methods.  What
happens when we add class OWMemoryCan ... then we'll need
OWMemoryCans(Reader) and OWMemoryCans(Reader, String)
methods.  Then add OWThermometer, with its two
Thermometer methods.  The TagParser interface is going to
get huge.

Let's take an approach similar to
java.io.File.list(FilenameFilter).  The user passes in a
filtering object which gets a chance to approve or
disapprove of each OWDevice (or subclass) about to be
created.  The filter object implements a specified
interface.

It'd be something like this:

public interface Filter {
    boolean accept(String className, String clusterName,
        int familyCode, String netAddress);
}

Then, class TagParser would have these methods:

public class TagParser {
    ...
    /** Return all devices. */
    public Enumeration devices(Reader in) {
        return devices(ALWAYS_PASS_FILTER);
    }

    /** Return all devices passing the given filter. */
    public Enumeration devices(Reader in, Filter filter)
        throws SAXException, IOException {
        ...
    }

    /** This filter always passes all devices. */
    public static class AlwaysPassFilter implements Filter {
        public boolean accept(String className,
            String clusterName, int familyCode,
            String netAddress) {
            return true;
        }
    }

    /** One of these is all you'll ever need. */
    public static final ALWAYS_PASS_FILTER = new AlwaysPassFilter();
}

Calling TagParser.devices(Reader) returns all devices, as
you'd expect.  Calling TagParser.devices(Reader, Filter)
returns a devices that pass the filter.  The user gets a
chance to filter based on four criteria.

Since the Fitler interface is lightweight, anonymous inner
classes would make this a breeze to use, too.

Comments?

--Sean

Re: [Xml1-wire-devel] New Code added to repository

[Sean K. <ke...@ad...>]

> I have just committed changes to the repository implementing these sorts
of
> methods. I will soon be creating some JavaDocs. Comments, as always are
> desired.

Looking good.  Thanks for committing this.

A couple high-level comments ... the
TAGerrorhandler class isn't pulling its weight, in my
opinion.  I'd go ahead and just make the TAGparser itself
implement the error handler interface and subsume its
methods.

Moreover, I don't mind having the warning() method just
log the error, but both the error() and fatalError()
methods ought to throw back the SAXParseException they're
given.  If there's an error, the user needs to know about
it and stop processing or handle the error in his/her own
way.

Also, all error messages, in the TAGerrorhandler,
TAGhandler, and TAGparser, should go to System.err, not
System.out.

Finally, I'd recommend we use the Sun naming convention
standards.  As you know, Java's overly happy with using
the "." operator.  For example, in

    a.b.c.d.e.f();

about the only thing you can say safely is that "f is a
method."  But is it package "a.b.c" class d, field e,
method f?  Or is it package "a", class b, inner class c,
field d, static inner class e, method f?  Or something
else?

The Sun naming convention helps disambiguate that:
packages are all lower case, ClassNames are like that,
methods areLikeThis, and constants are ALL_UPPER_CASE.
This would affect the DevicesByName, LevelSensors, etc.,
methods.

Thoughts?

Thanks again.
--Sean

[Xml1-wire-devel] New Code added to repository

[Byron K. A. <b.k...@ie...>]

I have just committed changes to the repository implementing these sorts of
methods. I will soon be creating some JavaDocs. Comments, as always are
desired. Currently, the TAGParser class takes a java.io.Reader instead of an
InputSource, I will probably change this very soon.

Byron

> -----Original Message-----
> From: Sean Kelly [mailto:ke...@ad...]
> Sent: Friday, December 15, 2000 11:11 AM
> To: Byron K. Appelt; 1-wire TAG list
> Subject: Re: [Xml1-wire-devel] More downcasting avoidance
>
>
> > //Yields OWCluster
> > public Enumeration clusters(InputSource xml);
> >
> > //Yields all OWSwitches
> > public Enumeration switches(InputSource xml);
> >
> > //Yields all OWSwitches in cluster with description "8x1 board"
> > public Enumeration switches(InputSource xml, "8x1 board");
>
> Perfect!  Let's do it!
>
> --k
>
>

[Xml1-wire-devel] ANNOUNCE: TiniAnt 1.0.0

[Sean K. <ke...@ad...>]

TiniAnt 1.0.0 is now available for downloading from
http://www.ad1440.net/~kelly/sw/tiniant/

TiniAnt is an extension to Ant that enables cross-platform
building and maintenance of TINI applications.

Ant is a cross-platform, Java-based build tool that replaces
system-specific build scripts and makefiles.  Instead, you
write a build.xml file describing your project and Ant does
the rest.  You can get Ant from
http://jakarta.apache.org/ant/.

TINI is a Java Virtual Machine with Ethernet and other
interfaces on a SIMM board, enabling a web server and
computer control in the tiniest of spaces.

TiniAnt provides two task extensions to Ant that are
specially designed to create .tini files.  It provides
<tini> and <onewire> elements for your build.xml file, for
building applications that don't or do use one wire
container classes.

TiniAnt is free software.  Bug reports to me, please.

--Sean

--
Sean Kelly
Independent Consultant
Java / XML / Etc.

Re: [Xml1-wire-devel] More downcasting avoidance

[Sean K. <ke...@ad...>]

You know what else would be cool?  Getting
an org.xml.sax.InputSource from a
com.dalsemi.onewire.container.MemoryBank.

--Sean

Re: [Xml1-wire-devel] More downcasting avoidance

[Sean K. <ke...@ad...>]

> //Yields OWCluster
> public Enumeration clusters(InputSource xml);
> 
> //Yields all OWSwitches
> public Enumeration switches(InputSource xml);
> 
> //Yields all OWSwitches in cluster with description "8x1 board"
> public Enumeration switches(InputSource xml, "8x1 board");

Perfect!  Let's do it!

--k

RE: [Xml1-wire-devel] More downcasting avoidance

[Byron K. A. <b.k...@ie...>]

I like that a lot! how about:

//Yields OWCluster
public Enumeration clusters(InputSource xml);

//Yields all OWSwitches
public Enumeration switches(InputSource xml);

//Yields all OWSwitches in cluster with description "8x1 board"
public Enumeration switches(InputSource xml, "8x1 board");

> -----Original Message-----
> From: xml...@li...
> [mailto:xml...@li...]On Behalf Of Sean
> Kelly
> Sent: Friday, December 15, 2000 8:22 AM
> To: XML 1-Wire Tag List
> Subject: [Xml1-wire-devel] More downcasting avoidance
> 
> 
> For situations where developers can't or don't want to
> let polymorphism solve the problem of doing useful work
> with their tagging, we could offer an alternative
> similar to what's in the owapi: a way of targeting what
> comes out of parsing the XML.  Example:
> 
> // Yields OWDevices
> public Enumeration devices(InputSource xml);
> 
> // Yields OWSwitches
> public Enumeration switches(InputSource xml);
> 
> // Yields OWThermometers
> public Enumeration thermometers(InputSource xml);
> 
> // Yields OWMemories
> public Enumeration memories(InputSource xml);
> 
> ...
> 
> Or:
> 
> // Yields OWDevices
> public Enumeration devices(InputSource xml);
> 
> // Yields OWDevices with the given family code
> public Enumeration devices(InputSource xml, int targetFamilyCode);
> 
> --k
> 
> 
> _______________________________________________
> Xml1-wire-devel mailing list
> Xml...@li...
> http://lists.sourceforge.net/mailman/listinfo/xml1-wire-devel
> 

[Xml1-wire-devel] DocumentHandler and test program

[Byron K. A. <b.k...@ie...>]

I have just added a few files to the repository.

OWCluster.java extends Vector to contain a description field
TAGhandler.java is a DocumentHandler
TAGparser.java parses a document and returns a vector of OWClusters

also, in the top level is parserTester.java and 8x1.XML which can be used to
test the previous files. parserTester will read the XML file describing and
8x1 board and then start cycling the LEDs in order and polling the switched,
printing the description of any switch that is presses.

This code handles nested OWClusters, which is not actually specified in the
DTD, but should be. The code can not yet handle OW:Class elements, although
it should successfully ignore them.

Suggestions and criticisms of this code are very welcome.