Nut upsuser - Jun 2014 - I can't make changes to ups.delay.shutdown to stick

On Jun 3, 2014, at 1:28 AM, Mick wrote:
> On Saturday 05 Apr 2014 16:28:24 Charles Lepple wrote:
>> On Apr 5, 2014, at 10:39 AM, Charles Lepple wrote:
>>> On Apr 5, 2014, at 8:52 AM, Mick <michaelkintzios at
gmail.com> wrote:
>>>>> The upsrw command was designed for changing variables that
are
>>>>> typically stored in non-volatile memory on the UPS.
Unfortunately,
>>>>> your UPS doesn't seem to do that.
>>>> 
>>>> Well, if it doesn't do that, how come upsc reports the
changed value?
>>>> It is only after I reboot the PC (not the UPS) or restart the
driver
>>>> that the default value of 20s is shown again.
>>> 
>>> I'd have to check the code, but I'm fairly certain that
writing a
>>> variable invalidates at least part of the HID cache in the driver.
>>> 
>>> However, it is possible that something in the driver initialization
is
>>> resetting that variable. Are there any extra settings in ups.conf?
Can
>>> you please send a driver log with -DDDD, gzipped and attached (so
as not
>>> to wrap the lines)? Same length of time as before is good.
>> 
>> Mick, hold that thought.
>> 
>>  1.006824	Path: UPS.PowerSummary.DelayBeforeShutdown, Type: Feature,
>> ReportID: 0x0f, Offset: 0, Size: 24, Value: 60
>>  1.010820	Path: UPS.PowerSummary.DelayBeforeStartup, Type: Feature,
>> ReportID: 0x11, Offset: 0, Size: 24, Value: 0
>> 
>> Arnaud, is HU_FLAG_ABSENT the right flag here? That seems to indicate
that
>> the variable is not actually implemented on the UPS:
>> 
>> drivers/idowell-hid.c:99:
>>        { "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10,
>> "UPS.PowerSummary.DelayBeforeStartup", NULL, DEFAULT_ONDELAY,
>> HU_FLAG_ABSENT, NULL}, { "ups.delay.shutdown", ST_FLAG_RW |
>> ST_FLAG_STRING, 10, "UPS.PowerSummary.DelayBeforeShutdown",
NULL,
>> DEFAULT_OFFDELAY, HU_FLAG_ABSENT, NULL},
>> 
>> It is not clear how this value is being used.
> 
> Was there ever a conclusion to this thread?  I didn't get any other
messages.
> 
I asked Arnaud about this off-list, and didn't get a complete reply. He said
the code looked right. Not sure if I understand this part of the usbhid-ups code
yet, but I'll give it a shot.

Some of the variables (those with HU_FLAG_ABSENT) are apparently not stored on
the UPS itself-- they are sent to the UPS when the shutdown command is executed.
Sending the value starts the timer, in some cases, but I think the
ups.delay.start value should be safe to send at the time when it is set.

You mentioned at the time that you couldn't test the shutdown sequence. Next
maintenance window, can you shut down via NUT (e.g. "upsmon -c fsd"),
and see if your UPS uses that delay value? (Same sort of logs as before, in case
there is a problem.)

I'll admit I haven't tweaked these values on my PDC HID UPS-- the
default percentage-based thresholds were sufficient. Unfortunately, that UPS has
a fried charger circuit, so I can't test that now.

-- 
Charles Lepple
clepple at gmail

On Wednesday 04 Jun 2014 03:07:27 Charles Lepple wrote:
> On Jun 3, 2014, at 1:28 AM, Mick wrote:
> > On Saturday 05 Apr 2014 16:28:24 Charles Lepple wrote:
> >> On Apr 5, 2014, at 10:39 AM, Charles Lepple wrote:
> >>> On Apr 5, 2014, at 8:52 AM, Mick <michaelkintzios at
gmail.com> wrote:
> >>>>> The upsrw command was designed for changing variables
that are
> >>>>> typically stored in non-volatile memory on the UPS.
Unfortunately,
> >>>>> your UPS doesn't seem to do that.
> >>>> 
> >>>> Well, if it doesn't do that, how come upsc reports the
changed value?
> >>>> It is only after I reboot the PC (not the UPS) or restart
the driver
> >>>> that the default value of 20s is shown again.
> >>> 
> >>> I'd have to check the code, but I'm fairly certain
that writing a
> >>> variable invalidates at least part of the HID cache in the
driver.
> >>> 
> >>> However, it is possible that something in the driver
initialization is
> >>> resetting that variable. Are there any extra settings in
ups.conf? Can
> >>> you please send a driver log with -DDDD, gzipped and attached
(so as
> >>> not to wrap the lines)? Same length of time as before is good.
> >> 
> >> Mick, hold that thought.
> >> 
> >>  1.006824	Path: UPS.PowerSummary.DelayBeforeShutdown, Type:
Feature,
> >> 
> >> ReportID: 0x0f, Offset: 0, Size: 24, Value: 60
> >> 
> >>  1.010820	Path: UPS.PowerSummary.DelayBeforeStartup, Type:
Feature,
> >> 
> >> ReportID: 0x11, Offset: 0, Size: 24, Value: 0
> >> 
> >> Arnaud, is HU_FLAG_ABSENT the right flag here? That seems to
indicate
> >> that the variable is not actually implemented on the UPS:
> >> 
> >> drivers/idowell-hid.c:99:
> >>        { "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING,
10,
> >> 
> >> "UPS.PowerSummary.DelayBeforeStartup", NULL,
DEFAULT_ONDELAY,
> >> HU_FLAG_ABSENT, NULL}, { "ups.delay.shutdown",
ST_FLAG_RW |
> >> ST_FLAG_STRING, 10,
"UPS.PowerSummary.DelayBeforeShutdown", NULL,
> >> DEFAULT_OFFDELAY, HU_FLAG_ABSENT, NULL},
> >> 
> >> It is not clear how this value is being used.
> > 
> > Was there ever a conclusion to this thread?  I didn't get any
other
> > messages.
> 
> I asked Arnaud about this off-list, and didn't get a complete reply. He
> said the code looked right. Not sure if I understand this part of the
> usbhid-ups code yet, but I'll give it a shot.
> 
> Some of the variables (those with HU_FLAG_ABSENT) are apparently not stored
> on the UPS itself-- they are sent to the UPS when the shutdown command is
> executed. Sending the value starts the timer, in some cases, but I think
> the ups.delay.start value should be safe to send at the time when it is
> set.
I see.  So if for some reason I wanted to change ups.delay.shutdown on a more 
permanent basis and the UPS won't store the changed setting, I would need to
run a script on the server to submit the changed value to the UPS each time 
the server boots up.

> You mentioned at the time that you couldn't test the shutdown sequence.
> Next maintenance window, can you shut down via NUT (e.g. "upsmon -c
fsd"),
> and see if your UPS uses that delay value? (Same sort of logs as before,
> in case there is a problem.)
> 
> I'll admit I haven't tweaked these values on my PDC HID UPS-- the
default
> percentage-based thresholds were sufficient. Unfortunately, that UPS has a
> fried charger circuit, so I can't test that now.

No problem - thanks for getting back to me!

I hope to test it sometime within a month or so and see what it does.

-- 
Regards,
Mick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140604/8bdcb550/attachment.sig>

On Wed, 4 Jun 2014, Mick wrote:
>> Some of the variables (those with HU_FLAG_ABSENT) are apparently not
stored
>> on the UPS itself-- they are sent to the UPS when the shutdown command
is
>> executed. Sending the value starts the timer, in some cases, but I
think
>> the ups.delay.start value should be safe to send at the time when it is
>> set.
>
> I see.  So if for some reason I wanted to change ups.delay.shutdown on a
more
> permanent basis and the UPS won't store the changed setting, I would
need to
> run a script on the server to submit the changed value to the UPS each time
> the server boots up.
I had the same problem with an Eaton Ellipse ECO 1500. 
ups.delay.shutdown got lost at each power cycle.  I fixed it by setting

      offdelay = 30
      ondelay = 40

in ups.conf.  This seems to me to be a better solution than writing a 
script.  I'm guessing that if these two lines are omitted, no value is 
sent to the UPS unit.  Is this true?

Roger