<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Hi,<br><br>After some more thinking I probably won't need to run the server upsd.<br>The reports from usbhid-ups in debug mode can easily be parsed<br>to extract the only report I need, which is the PowerSummary.PresentStatus.<br>It's quite an impressive reporting capability in this driver.<br>What is the clean way of aborting usbhid-ups ? Is it 'kill -9' only ?<br><br>I only need to request the input reports every 5 minutes so I could<br>run usbhid-ups once every 5 minutes to collect the reports.<br>I probably can modify usbhid-ups.c to abort after it has read the<br>
input report once.<br><br>I normally run Solaris 10 on my servers but I have one Linux<br>server. I have written a userland application for Solaris 10<br>that uses driver 'ugen' to read the PowerSummary.PresentStatus (report x32)<br>from other identical ups's.<br><br>Thanks,<br><br>/Karl D<br><br><br>> Date: Sun, 27 Jan 2008 11:54:04 +0100<br>> Subject: Re: [Nut-upsuser] Tripp lite SMART1000LCD<br>> From: nut+users@de-korte.org<br>> To: k_dal2@hotmail.com<br>> CC: clepple@gmail.com; nut-upsuser@lists.alioth.debian.org<br>> <br>> > Running usbhid-ups -DDD -a SMART1000LCD seems<br>> > to go into an infinite loop unless the driver is supposed to<br>> > send requests to the ups continuously.<br>> <br>> The driver doesn't background when running in debug mode, so yes, this<br>> loop will seem to be infinite.<br>> <br>> > The values returned<br>> > from the USB report requests seem to be valid though, for example,<br>> > Report ID 0x32 (UPS.PowerSummary.PresentStatus) has<br>> > correct value based on present state.<br>> <br>> Indeed. So the problem probably doesn't lie between driver and UPS as they<br>> seem to communicate quite happily.<br>> <br>> > Based on the error message when later starting upsd<br>> > (Can't connect to UPS [SMART1000LCD] (usbhid-ups-SMART1000LCD): No such<br>> > file or directory) has the driver not reached the point where it creates<br>> > those files ?<br>> <br>> No, that point will be reached regardless of running in debug mode or not.<br>> As I wrote in a previous reply, most likely there is a permissions<br>> problem. The easiest way to verify this, is to run both the driver and<br>> server as root, by passing the '-u root' option in the startup line.<br>> <br>> /usr/local/ups/bin/upsdrvctl -u root start<br>> /usr/local/ups/sbin/upsd -u root<br>> <br>> If the above solves the problem, it is a permissions problem.<br>> <br>> Best regards, Arjen<br>> -- <br>> Eindhoven - The Netherlands<br>> Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57<br>> <br><br /><hr />Express yourself instantly with MSN Messenger! <a href='http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/' target='_new'>MSN Messenger</a></body>
</html>