[Nut-upsuser] Tripp lite SMART1000LCD

[Karl Dalen]

Hi,

After some more thinking  I probably won't need to run the server upsd.
The reports from usbhid-ups in debug mode can easily be parsed
to extract the only report I need, which is the PowerSummary.PresentStatus.
It's quite an impressive reporting capability in this driver.
What is the clean way of aborting usbhid-ups ? Is it 'kill -9' only ?

I only need to request the input reports every 5 minutes so I could
run usbhid-ups once every 5 minutes to collect the reports.
I probably can modify usbhid-ups.c to abort after it has read the

input report once.

I normally run Solaris 10 on my servers but I have one Linux
server. I have written a userland application for Solaris 10
that uses driver 'ugen' to read the PowerSummary.PresentStatus (report x32)
from other identical ups's.

Thanks,

/Karl D


> Date: Sun, 27 Jan 2008 11:54:04 +0100
> Subject: Re: [Nut-upsuser] Tripp lite SMART1000LCD
> From: nut+users at de-korte.org
> To: k_dal2 at hotmail.com
> CC: clepple at gmail.com; nut-upsuser at lists.alioth.debian.org
> 
> > Running usbhid-ups -DDD -a SMART1000LCD seems
> > to go into an infinite loop unless the driver is supposed to
> > send requests to the ups continuously.
> 
> The driver doesn't background when running in debug mode, so yes, this
> loop will seem to be infinite.
> 
> > The values returned
> > from the USB report requests seem to be valid though, for example,
> > Report ID 0x32 (UPS.PowerSummary.PresentStatus) has
> > correct value based on present state.
> 
> Indeed. So the problem probably doesn't lie between driver and UPS as they
> seem to communicate quite happily.
> 
> > Based on the error message when later  starting upsd
> > (Can't connect to UPS [SMART1000LCD] (usbhid-ups-SMART1000LCD): No such
> > file or directory) has the driver not reached the point where it creates
> > those files ?
> 
> No, that point will be reached regardless of running in debug mode or not.
> As I wrote in a previous reply, most likely there is a permissions
> problem. The easiest way to verify this, is to run both the driver and
> server as root, by passing the '-u root' option in the startup line.
> 
>     /usr/local/ups/bin/upsdrvctl -u root start
>     /usr/local/ups/sbin/upsd -u root
> 
> If the above solves the problem, it is a permissions problem.
> 
> Best regards, Arjen
> -- 
> Eindhoven - The Netherlands
> Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57
> 

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080127/756b2667/attachment.htm