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

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.

-- 
Charles Lepple
clepple at gmail

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.
In case it helps I attach the driver log with increased debugging (using 
explore in ups.conf).  Also, this is what the normal ups.conf shows:

$ grep ^[^#] /etc/nut/ups.conf 
[iDowell]
	driver = usbhid-ups
	port = auto
	vendorid = 075d
	productid = 0300
	desc = "iBox by iDowell"


Additional info:
========================$ upsrw iDowell at localhost
[ups.delay.shutdown]
Interval to wait after shutdown with delay command (seconds)
Type: STRING
Value: 20

[ups.delay.start]
Interval to wait before (re)starting the load (seconds)
Type: STRING
Value: 30


$ upscmd -l iDowell
Instant commands supported on UPS [iDowell]:

load.off - Turn off the load immediately
load.off.delay - Turn off the load with a delay (seconds)
load.on - Turn on the load immediately
load.on.delay - Turn on the load with a delay (seconds)
shutdown.return - Turn off the load and return when power is back
shutdown.stayoff - Turn off the load and remain off
shutdown.stop - Stop a shutdown in progress
==========================================
Please ask if you need more.
-- 
Regards,
Mick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iDowell_driver_dump.log.gz
Type: application/gzip
Size: 4650 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140406/d1448bd2/attachment.bin>
-------------- 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/20140406/d1448bd2/attachment.sig>

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.

-- 
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/20140603/e07372a8/attachment.sig>

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