On 7/24/2016 03:51, O. Hartmann wrote:
> Am Sun, 24 Jul 2016 08:38:59 +0200
> Gary Jennejohn <gljennj...@gmail.com> schrieb:
>
>> On Sun, 24 Jul 2016 08:03:30 +0200
>> "O. Hartmann" <ohart...@zedat.fu-berlin.de> wrote:
>>
>>> Am Sat, 23 Jul 2016 14:49:11 -0600
>>> Ian Lepore <i...@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 <i...@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@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@thor: [src] man ugensa
>>> No manual entry for ugensa
>>> root@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 them up and those little SOBs are expensive!  I was considering
grabbing one just to play with, but not at that price :)

You should be able to "cu" to the port and send the ASCII command it
wants to provide a reading; that would verify it is working.

-- 
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to