[Nut-upsdev] APC Back-UPS 500

[Rob Crittenden]

Peter Selinger wrote:
> Hi Rob,
> 
> I am replying to a message from December, so sorry if I have lost the
> thread of conversation or your UPS has meanwhile been given to the
> archaeological society. 
> 
> The problem with the missing Back-UPS 500 status variables was fixed
> on January 27 in the Development branch.
> 
> I am not sure about the status of the timeout problem. You wrote:
> 
> 
>>>>I'm using nut 2.0.2 from Fedora Core 4 and had some trouble getting my
>>>>APC Back-UPS 500 working. I ended up having to rebuild the RPM myself
>>>>after making some code changes.
> 
> 
> If you still have them, please send these "code changes". -- Peter

I just bumped up the wait time.

--- nut-2.0.2/server/upsd.h     2005-01-27 09:33:19.000000000 -0500
+++ nut-2.0.2-rcrit/server/upsd.h       2005-12-23 22:51:27.000000000 -0500
@@ -43,7 +43,7 @@
  #include "ctype.h"
  #include "upstype.h"

-#define INITIAL_WAIT_MAX 5     /* max 5 seconds for DUMPDONEs to arrive */
+#define INITIAL_WAIT_MAX 15    /* max 5 seconds for DUMPDONEs to arrive */
  #define NUT_NET_ANSWER_MAX SMALLBUF

  /* prototypes from upsd.c */

Unfortunately that UPS seems kaput. It started oscilating between online 
and battery every second or so. Talk about creepy. I've replaced it with 
an RS 1500. This new one doesn't seem to require the additional time, 
though I haven't tested it. But observing the ups startup it seems to 
connect much faster than the 500.

rob

> 
> Rob Crittenden wrote:
> 
>>Charles Lepple wrote:
>>
>>>On 12/29/05, Rob Crittenden <rcrit at greyoak.com> wrote:
>>>
>>>
>>>>I'm using nut 2.0.2 from Fedora Core 4 and had some trouble getting my
>>>>APC Back-UPS 500 working. I ended up having to rebuild the RPM myself
>>>>after making some code changes.
>>>>
>>>>I had to increase the upsd synchronization timeout from 5 to 15 seconds.
>>>>It seems like 10 is the sweet spot but allowing a few extra seconds
>>>>doesn't seem to hurt anything. At 5 the UPS would timeout 5 out of 6 times.
>>>
>>>
>>>Depending on which timeout this is (I don't have the code handy), this
>>>might be something that could be exposed as a configuration variable.
>>>I think some of the MGE USB UPSes take a while as well, due to the
>>>slow internal baud rate, and the low-speed USB transfers.
>>
>>Yup, sounds like a great idea to me.
>>
>>
>>>>The second problem is that my UPS, a USB model using the newhidups
>>>>driver, doesn't send PresentStatus (840002) in its updates. This means
>>>>that ups.status is always empty and upsmon has a fit over it.
>>>>
>>>>My fix was to simply remove "PresentStatus." from the ups.status entries
>>>>in apc-hid.h. I haven't been able to come up with any sort of
>>>>semi-elegant solution for this. My fix could break any UPS that relies
>>>>on PresentStatus for its updates.
>>>
>>>
>>>Does the debug output indicate an alternative variable that provides
>>>on battery/online status? (In this case, '-D -D' is probably a decent
>>>debug level for newhidups.)
>>
>>Sorry, I wasn't clear. Normally ups.status, at least in apc-hid.h, 
>>consists of UPS.PowerSummary.PresentStatus.ACPresent, Discharching, 
>>Charging, BelowRemainingCapacityLimit, etc.
>>
>>I have the variables UPS.PowerSummary.ACPresent, Discharging and 
>>Charging available but there is no path for 
>>UPS.PowerSummary.PresentStatus. So by removing the PresentStatus from 
>>apc-hid.h I can get direct access to those variables. It is probably a 
>>bucket issue. On some UPS's these are dropped into the PresentStatus 
>>bucket, in others just in PowerSummary.
>>
>>I haven't actually done a "pull the plug and watch the status change" 
>>test yet since I have equipment plugged in at the moment, but since I 
>>see those status variables I have some amount of faith that it will do 
>>the right thing.
>>
>>rob
>>
>>_______________________________________________
>>Nut-upsdev mailing list
>>Nut-upsdev at lists.alioth.debian.org
>>http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>>
> 
>