Re: Digi Watchport/T temperature sensor as /dev/ttyU

On Sun, Jul 24, 2016 at 9:55 AM, Ian Lepore <ian_at_freebsd.org> wrote:

> On Sun, 2016-07-24 at 10:51 +0200, O. Hartmann wrote:
> > Am Sun, 24 Jul 2016 08:38:59 +0200
> > Gary Jennejohn <gljennjohn_at_gmail.com> schrieb:
> >
> > > On Sun, 24 Jul 2016 08:03:30 +0200
> > > "O. Hartmann" <ohartman_at_zedat.fu-berlin.de> wrote:
> > >
> > > > Am Sat, 23 Jul 2016 14:49:11 -0600
> > > > Ian Lepore <ian_at_freebsd.org> schrieb:
> > > >
> > > > > On Sat, 2016-07-23 at 22:04 +0200, O. Hartmann wrote:
> > > > > > Am Fri, 22 Jul 2016 10:52:54 -0600
> > > > > > Ian Lepore <ian_at_freebsd.org> schrieb:
> > > > > >
> > > > > > > On Fri, 2016-07-22 at 18:35 +0200, O. Hartmann wrote:
> > > > > > > > For temperature monitoring, we have a bunch of Digi
> > > > > > > > Watchport/T
> > > > > > > > sensors:
> > > > > > > >
> > > > > > > > http://ftp1.digi.com/support/documentation/90000406_H.pdf
> > > > > > > >
> > > > > > > >
> > > > > > > [...]
> > > > > > >
> > > > > > > I think the attached patch will make it show up as a
> > > > > > > ttyU*/cuaU*
> > > > > > > device
> > > > > > > for you.  (You should probably use the /dev/cuaU* flavor,
> > > > > > > to avoid
> > > > > > > problems with tty layer and modem control signals).
> > > > > > >
> > > > > > > I keep wishing we had a mechanism, like a sysctl that could
> > > > > > > be set
> > > > > > > or
> > > > > > > something, that would let you supply a vendor/product pair
> > > > > > > and have
> > > > > > > the
> > > > > > > ugensa driver attach to that device, for quick testing of
> > > > > > > this sort
> > > > > > > of
> > > > > > > thing.
> > > > > > >
> > > > > > > -- Ian
> > > > > >
> > > > > > No, it doesn't change anything. I applied the patch to most
> > > > > > recent
> > > > > > CURRENT and it is
> > > > > > still the same. But thanks anyway.
> > > > > >
> > > > > > Kind regards,
> > > > > >
> > > > > > oh
> > > > >
> > > > > Oh, my bad, I forgot to mention:  You'll have to manually
> > > > > "kldload
> > > > > ugensa" before plugging in the device (or load it from your
> > > > > loader.conf).
> > > > >
> > > > > When the change gets committed (assuming it works), the devd
> > > > > usb
> > > > > scripts will get regenerated, and that's what handles the auto
> > > > > -load of
> > > > > the driver.
> > > > >
> > > > > -- Ian
> > > > man ugensa doesn't exist! As I wrote earlier, I tried everything
> > > > to load what I could
> > > > find. It seems, the patch and the hint about ugensa.ko did the
> > > > magic ;-) Thank you
> > > > very much! Could the patch be made permanent to FreeBSD CURRENT?
> > > >
> > > > And also important: where is the man page for ugensa? Can the the
> > > > module be compiled
> > > > staitcally into the kernel or are there pitfalls?
> > > >
> > >
> > > Even the most complete man page found in the internet, the one from
> > > Dragonfly, doesn't list your Digi International device as being one
> > > of those supported.
> >
> > Yes. That is a pity. But Linux seems to operate this serial device. I
> > have to check next
> > time I get hands on a Linux box, what driver is attached to the
> > sensor.
> >
> > >
> > > Still, having the man page under FreeBSD would at least provide a
> > > hint
> > > that the driver even exists.
> >
> > Agreed.
> >
> > >
> > > I added device ugensa to my config file and the kernel was
> > > generated
> > > without an error.
> >
> > Me, too.
> >
> > >
> > > > root_at_localhost: [src] kldload ugensa
> > > >
> > > > ugen2.7: <Digi International> at usbus2
> > > > ugensa0: <Digi International WatchportT, rev 1.10/1.00, addr 7>
> > > > on usbus2
> > > > ugensa0: Found 1 interfaces.
> > > > root_at_thor: [src] man ugensa
> > > > No manual entry for ugensa
> > > > root_at_localhost: [src] ll /dev/cuaU0*
> > > > 203 crw-rw----  1 uucp  dialer  -  0xcb Jul 24 07:51 /dev/cuaU0
> > > > 204 crw-rw----  1 uucp  dialer  -  0xcc Jul 24 07:51
> > > > /dev/cuaU0.init
> > > > 205 crw-rw----  1 uucp  dialer  -  0xcd Jul 24 07:51
> > > > /dev/cuaU0.lock
> > > >
> > > >
> > > > I'll try now to get informations out of the device, I let you
> > > > know whether that is a
> > > > success. But anyway, again, thank you for helping making the
> > > > device visible and
> > > > available.
> > >
> >
> >
> > I had no luck with retrieving informations out of the device by the
> > Perl5 script provided
> > by Nagios.org. A prerequisite for the Perl script is the FreeBSD port
> >
> > comms/p5-Device-SerialPort
> >
> > Patching the script is trivial, but I do not know whether the
> > backend,
> > comms/p5-Device-SerialPort, works a sexpected. So the first, dirty,
> > trial ended up in
> > nothing - since the information gained from the sensor is an empty
> > string/nothing.
> >
> > I'm not familiar with serial devices, so far, so probably there is
> > something trivial
> > missing.
>
> I looked around for some info on these Watchport devices.  Their manual
> indicates that they use both serial comms to send commands and receive
> data, and they use serial-comms modem control signals (RTS/CTS, DTR,
> etc).  Some googling makes it look like they use a TI 5052 USB serial
> chip.  On linux, that would be handled by the io_ti USB serial driver.
>
> All of that adds up to the freebsd ugensa driver (which is "generic
> serial IO") probably not working.  The ugensa driver has nothing chip
> -specific in it, it's for accessing devices which can do bulk
> read/write without needing to configure any of the other serial comms
> parameters.  The ugensa driver works with things like gps receivers
> that have simple text-only interfaces.
>
> I think these watchport devices will likely need real serial comms
> configuration -- baud rate at least, to even be able to talk to them.
>  In other words, freebsd needs a real driver for TI 5052 chips.  It
> looks like a fairly complete datasheet for the chip is available (but I
> don't have time to write a driver myself).
>
> -- Ian
>

There are several different USB serial drivers. Off-hand I see ubser, ubsa,
uchcom, ucom, ucycom, uftdi, ubgensa, umcs, umct, umoscom, uplcom,
usb_serial, uslcom, and uvscom. Whether any of these will support the TI
chip, I can't say. Most have man pages, but a few, as has been noted, are
lacking one.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman_at_gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683