Discussion:
[Nut-upsuser] I can't make changes to ups.delay.shutdown to stick
Mick
2014-04-05 11:18:54 UTC
Permalink
Hi All,

I'm using an iDowell UPS with the usbhid-ups driver:

$ upsc iDowell at localhost
battery.charge: 100
battery.charge.low: 15
battery.runtime: 650
battery.type: Pb acc
device.mfr: iDowell
device.model: iBox
device.serial: 00000001
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 0300
driver.parameter.vendorid: 075d
driver.version: 2.6.5
driver.version.data: iDowell HID 0.1
driver.version.internal: 0.37
input.transfer.high: 254
input.transfer.low: 105
output.frequency.nominal: 50
output.voltage: 230.0
output.voltage.nominal: 230
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 33
ups.mfr: iDowell
ups.model: iBox
ups.power.nominal: 257
ups.productid: 0300
ups.serial: 00000001
ups.status: OL CHRG
ups.timer.shutdown: 60
ups.timer.start: 0
ups.vendorid: 075d

I thought of increasing the ups.delay.shutdown value from 20 to a higher
value.

The changes seem to take:

$ upsc iDowell at localhost ups.delay.shutdown
20

$ upsrw -s "ups.delay.shutdown"="30" iDowell at localhost
Username (suzy): admin
Password:
OK

$ upsc iDowell at localhost ups.delay.shutdown
30


However, following a reboot the ups.delay.shutdown reverts to the default
value of 20s. I tried running the upsrw -s command as root, but also got 20s
after a reboot. This is what the access rights of the configuration files
look like:

$ ls -la /etc/nut
total 48
drwxr-xr-x 2 root root 4096 Apr 4 19:09 .
drwxr-xr-x 105 root root 12288 Apr 5 08:15 ..
-rw-r--r-- 1 root root 1546 Sep 22 2013 nut.conf
-rw-r--r-- 1 root root 3805 Sep 18 2011 ups.conf
-rw-r----- 1 root nut 2744 Oct 9 06:50 upsd.conf
-rw-r----- 1 root nut 2301 Oct 9 06:50 upsd.users
-rw-r----- 1 root nut 11982 Oct 9 06:47 upsmon.conf
-rw-r--r-- 1 root root 3891 Sep 22 2013 upssched.conf


How is this supposed to work?
--
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/20140405/c68dd33d/attachment-0001.sig>
Charles Lepple
2014-04-05 11:53:06 UTC
Permalink
Post by Mick
$ upsrw -s "ups.delay.shutdown"="30" iDowell at localhost
Username (suzy): admin
OK
This command is sending the value to the UPS (via the usbhid-ups driver).
Post by Mick
$ upsc iDowell at localhost ups.delay.shutdown
30
And this command ends up reading the value back from the UPS.
Post by Mick
However, following a reboot the ups.delay.shutdown reverts to the default
value of 20s. I tried running the upsrw -s command as root, but also got 20s
after a reboot. This is what the access rights of the configuration files
The permissions are not applicable here.

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.

Does the UPS respect the delay setting? (might be easier to see with a much larger delay value.) If not, there is a chance that the mappings from NUT variable names to HID identifiers are incorrect.
--
Charles Lepple
clepple at gmail
Mick
2014-04-05 12:52:21 UTC
Permalink
Thanks Charles,
Post by Charles Lepple
Post by Mick
$ upsrw -s "ups.delay.shutdown"="30" iDowell at localhost
Username (suzy): admin
OK
This command is sending the value to the UPS (via the usbhid-ups driver).
Post by Mick
$ upsc iDowell at localhost ups.delay.shutdown
30
And this command ends up reading the value back from the UPS.
Right, so things are apparently working as they ought to.
Post by Charles Lepple
Post by Mick
However, following a reboot the ups.delay.shutdown reverts to the default
value of 20s. I tried running the upsrw -s command as root, but also got
20s after a reboot. This is what the access rights of the configuration
The permissions are not applicable here.
Wasn't sure. Thanks for clarifying.
Post by Charles Lepple
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.
Post by Charles Lepple
Does the UPS respect the delay setting? (might be easier to see with a much
larger delay value.) If not, there is a chance that the mappings from NUT
variable names to HID identifiers are incorrect.
I can't really test the UPS in anger because it is feeding other devices (ADSL
modem and a couple of routers) which I do not want to lose power to.


This is what the USB device reports:
===================================
# lsusb -vv -d 075d:0300

Bus 003 Device 009: ID 075d:0300
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x075d
idProduct 0x0300
bcdDevice 0.01
iManufacturer 3 iDowell
iProduct 1 iBox
iSerial 2 00000001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x60
(Missing must-be-set bit!)
Self Powered
Remote Wakeup
MaxPower 10mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 412
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 20
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 20
Device Status: 0x0001
Self Powered
===================================


This is what the driver reports:
===============================
# /lib/nut/usbhid-ups -DD -a iDowell
Network UPS Tools - Generic HID driver 0.37 (2.6.5)
USB communication driver 0.31
0.000000 debug level is '2'
0.001089 upsdrv_initups...
0.004692 Checking device (1D6B/0002) (001/001)
0.025842 - VendorID: 1d6b
0.025888 - ProductID: 0002
0.025927 - Manufacturer: Linux 3.12.13-gentoo ehci_hcd
0.025972 - Product: EHCI Host Controller
0.026020 - Serial Number: 0000:00:1d.7
0.026066 - Bus: 001
0.026109 Trying to match device
0.026322 Device does not match - skipping
[snip ...]

0.865043 Checking device (075D/0300) (003/025)
0.899813 - VendorID: 075d
0.899832 - ProductID: 0300
0.899839 - Manufacturer: iDowell
0.899844 - Product: iBox
0.899849 - Serial Number: 00000001
0.899856 - Bus: 003
0.899862 Trying to match device
0.899896 Device matches
0.899930 failed to claim USB device: Device or resource busy
0.900102 detached kernel driver from USB device...
0.907834 HID descriptor length 412
0.962825 Report Descriptor size = 412
0.963065 Using subdriver: EXPLORE HID 0.1
0.966834 Path: UPS.PowerConverter.PowerConverterID, Type: Feature,
ReportID: 0x0b, Offset: 0, Size: 8, Value: 0
0.966856 Path: UPS.PowerConverter.Output.OutputID, Type: Feature, ReportID:
0x0b, Offset: 8, Size: 8, Value: 0
0.970828 Path: UPS.PowerConverter.Output.Voltage, Type: Feature, ReportID:
0x0e, Offset: 0, Size: 8, Value: 230
0.974824 Path: UPS.PowerConverter.Output.LowVoltageTransfer, Type: Feature,
ReportID: 0x13, Offset: 0, Size: 8, Value: 105
0.974844 Path: UPS.PowerConverter.Output.HighVoltageTransfer, Type:
Feature, ReportID: 0x13, Offset: 8, Size: 16, Value: 254
0.974862 Path: UPS.Flow.[4].FlowID, Type: Feature, ReportID: 0x0b, Offset:
16, Size: 8, Value: 0
0.978823 Path: UPS.Flow.[4].ConfigVoltage, Type: Feature, ReportID: 0x12,
Offset: 0, Size: 8, Value: 230
0.982822 Path: UPS.Flow.[4].ConfigFrequency, Type: Feature, ReportID: 0x0d,
Offset: 0, Size: 8, Value: 50
0.982845 Path: UPS.Flow.[4].ConfigApparentPower, Type: Feature, ReportID:
0x0d, Offset: 8, Size: 16, Value: 257
0.982861 Path: UPS.PowerSummary.PowerSummaryID, Type: Feature, ReportID:
0x0b, Offset: 24, Size: 8, Value: 0
0.982876 Path: UPS.PowerSummary.FlowID, Type: Feature, ReportID: 0x0b,
Offset: 32, Size: 8, Value: 0
0.986836 Path: UPS.PowerSummary.CapacityMode, Type: Feature, ReportID:
0x0c, Offset: 0, Size: 8, Value: 2
0.986861 Path: UPS.PowerSummary.RemainingCapacityLimit, Type: Feature,
ReportID: 0x0c, Offset: 8, Size: 8, Value: 15
0.986878 Path: UPS.PowerSummary.CapacityGranularity1, Type: Feature,
ReportID: 0x0c, Offset: 16, Size: 8, Value: 25
0.990825 Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, ReportID:
0x10, Offset: 0, Size: 8, Value: 4
0.990845 Path: UPS.PowerSummary.iManufacturer, Type: Feature, ReportID:
0x10, Offset: 8, Size: 8, Value: 3
0.990860 Path: UPS.PowerSummary.iProduct, Type: Feature, ReportID: 0x10,
Offset: 16, Size: 8, Value: 1
0.990875 Path: UPS.PowerSummary.iSerialNumber, Type: Feature, ReportID:
0x10, Offset: 24, Size: 8, Value: 5
0.990890 Path: UPS.PowerSummary.PercentLoad, Type: Feature, ReportID: 0x0e,
Offset: 8, Size: 8, Value: 33
0.990906 Path: UPS.PowerSummary.DesignCapacity, Type: Feature, ReportID:
0x0c, Offset: 24, Size: 8, Value: 100
0.990922 Path: UPS.PowerSummary.FullChargeCapacity, Type: Feature,
ReportID: 0x0c, Offset: 32, Size: 8, Value: 100
0.994821 Path: UPS.PowerSummary.RemainingCapacity, Type: Feature, ReportID:
0x16, Offset: 0, Size: 8, Value: 100
0.994841 Path: UPS.PowerSummary.RemainingCapacity, Type: Input, ReportID:
0x16, Offset: 0, Size: 8, Value: 100
0.994857 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Feature, ReportID:
0x16, Offset: 8, Size: 16, Value: 650
0.994872 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID:
0x16, Offset: 8, Size: 16, Value: 650
0.998820 Path: UPS.PowerSummary.PresentStatus.CommunicationLost, Type:
Input, ReportID: 0x01, Offset: 0, Size: 1, Value: 0
0.998839 Path: UPS.PowerSummary.PresentStatus.CommunicationLost, Type:
Feature, ReportID: 0x01, Offset: 0, Size: 1, Value: 0
0.998853 Path: UPS.PowerSummary.PresentStatus.Undefined, Type: Input,
ReportID: 0x01, Offset: 1, Size: 7, Value: 0
0.998867 Path: UPS.PowerSummary.PresentStatus.Undefined, Type: Feature,
ReportID: 0x01, Offset: 1, Size: 7, Value: 0
1.002820 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input,
ReportID: 0x02, Offset: 0, Size: 1, Value: 1
1.002846 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Input,
ReportID: 0x02, Offset: 1, Size: 1, Value: 1
1.002870 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Input,
ReportID: 0x02, Offset: 2, Size: 1, Value: 0
1.002893 Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit,
Type: Input, ReportID: 0x02, Offset: 3, Size: 1, Value: 0
1.002917 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Input,
ReportID: 0x02, Offset: 4, Size: 1, Value: 0
1.002938 Path: UPS.PowerSummary.PresentStatus.Good, Type: Input, ReportID:
0x02, Offset: 5, Size: 1, Value: 1
1.002960 Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type:
Input, ReportID: 0x02, Offset: 6, Size: 1, Value: 0
1.002977 Path: UPS.PowerSummary.PresentStatus.Overload, Type: Input,
ReportID: 0x02, Offset: 7, Size: 1, Value: 0
1.002992 Path: UPS.PowerSummary.PresentStatus.InternalFailure, Type: Input,
ReportID: 0x02, Offset: 8, Size: 1, Value: 0
1.003007 Path: UPS.PowerSummary.PresentStatus.Undefined, Type: Input,
ReportID: 0x02, Offset: 9, Size: 7, Value: 0
1.003021 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature,
ReportID: 0x02, Offset: 0, Size: 1, Value: 1
1.003036 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature,
ReportID: 0x02, Offset: 1, Size: 1, Value: 1
1.003050 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature,
ReportID: 0x02, Offset: 2, Size: 1, Value: 0
1.003065 Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit,
Type: Feature, ReportID: 0x02, Offset: 3, Size: 1, Value: 0
1.003080 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type:
Feature, ReportID: 0x02, Offset: 4, Size: 1, Value: 0
1.003095 Path: UPS.PowerSummary.PresentStatus.Good, Type: Feature,
ReportID: 0x02, Offset: 5, Size: 1, Value: 1
1.003110 Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type:
Feature, ReportID: 0x02, Offset: 6, Size: 1, Value: 0
1.003124 Path: UPS.PowerSummary.PresentStatus.Overload, Type: Feature,
ReportID: 0x02, Offset: 7, Size: 1, Value: 0
1.003139 Path: UPS.PowerSummary.PresentStatus.InternalFailure, Type:
Feature, ReportID: 0x02, Offset: 8, Size: 1, Value: 0
1.003157 Path: UPS.PowerSummary.PresentStatus.Undefined, Type: Feature,
ReportID: 0x02, Offset: 9, Size: 7, Value: 0
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
1.010852 Report descriptor retrieved (Reportlen = 412)
1.010860 Found HID device
1.010868 Detected a UPS: iDowell/iBox
1.010877 find_nut_info: unknown info type: load.off.delay
1.010885 find_nut_info: unknown info type: load.on.delay
1.010891 find_nut_info: unknown info type: load.off.delay
1.010907 upsdrv_initinfo...
1.010922 upsdrv_updateinfo...
1.013819 Got 2 HID objects...
1.013840 Path: UPS.PowerSummary.RemainingCapacity, Type: Input, ReportID:
0x16, Offset: 0, Size: 8, Value: 100
1.013859 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID:
0x16, Offset: 8, Size: 16, Value: 650
1.013868 Quick update...
1.013971 dstate_init: sock /var/lib/nut/usbhid-ups-iDowell open on fd 13
1.013990 upsdrv_updateinfo...
1.265832 libusb_get_interrupt: Connection timed out
1.265859 Got 0 HID objects...
1.265868 Quick update...
3.015637 upsdrv_updateinfo...
3.029830 Got 2 HID objects...
3.029856 Path: UPS.PowerSummary.PresentStatus.CommunicationLost, Type:
Input, ReportID: 0x01, Offset: 0, Size: 1, Value: 0
3.029872 Path: UPS.PowerSummary.PresentStatus.Undefined, Type: Input,
ReportID: 0x01, Offset: 1, Size: 7, Value: 0
3.029883 Quick update...
5.017634 upsdrv_updateinfo...
5.029829 Got 10 HID objects...
5.029855 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input,
ReportID: 0x02, Offset: 0, Size: 1, Value: 1
5.029872 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Input,
ReportID: 0x02, Offset: 1, Size: 1, Value: 1
5.029888 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Input,
ReportID: 0x02, Offset: 2, Size: 1, Value: 0
5.029904 Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit,
Type: Input, ReportID: 0x02, Offset: 3, Size: 1, Value: 0
5.029920 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Input,
ReportID: 0x02, Offset: 4, Size: 1, Value: 0
5.029935 Path: UPS.PowerSummary.PresentStatus.Good, Type: Input, ReportID:
0x02, Offset: 5, Size: 1, Value: 1
5.029951 Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type:
Input, ReportID: 0x02, Offset: 6, Size: 1, Value: 0
5.029966 Path: UPS.PowerSummary.PresentStatus.Overload, Type: Input,
ReportID: 0x02, Offset: 7, Size: 1, Value: 0
5.029981 Path: UPS.PowerSummary.PresentStatus.InternalFailure, Type: Input,
ReportID: 0x02, Offset: 8, Size: 1, Value: 0
5.029997 Path: UPS.PowerSummary.PresentStatus.Undefined, Type: Input,
ReportID: 0x02, Offset: 9, Size: 7, Value: 0
5.030007 Quick update...
7.019635 upsdrv_updateinfo...
7.029830 Got 2 HID objects...
7.029857 Path: UPS.PowerSummary.RemainingCapacity, Type: Input, ReportID:
0x16, Offset: 0, Size: 8, Value: 100
7.029875 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID:
0x16, Offset: 8, Size: 16, Value: 650
7.029885 Quick update...
9.021636 upsdrv_updateinfo...
9.029828 Got 2 HID objects...
9.029852 Path: UPS.PowerSummary.PresentStatus.CommunicationLost, Type:
Input, ReportID: 0x01, Offset: 0, Size: 1, Value: 0
9.029869 Path: UPS.PowerSummary.PresentStatus.Undefined, Type: Input,
ReportID: 0x01, Offset: 1, Size: 7, Value: 0
9.029880 Quick update...
11.023640 upsdrv_updateinfo...
11.029834 Got 2 HID objects...
11.029862 Path: UPS.PowerSummary.RemainingCapacity, Type: Input, ReportID:
0x16, Offset: 0, Size: 8, Value: 100
11.029881 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID:
0x16, Offset: 8, Size: 16, Value: 650
11.029892 Quick update...
====================================

Please ask for more info if needed.
--
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/20140405/699c6a0c/attachment.sig>
Charles Lepple
2014-04-05 14:39:33 UTC
Permalink
Post by Mick
Post by Charles Lepple
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.
Charles Lepple
2014-04-05 15:28:24 UTC
Permalink
Post by Charles Lepple
Post by Mick
Post by Charles Lepple
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
Mick
2014-04-06 11:39:56 UTC
Permalink
Post by Charles Lepple
Post by Charles Lepple
Post by Mick
Post by Charles Lepple
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
{ "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>
Mick
2014-06-03 05:28:34 UTC
Permalink
Post by Charles Lepple
Post by Charles Lepple
Post by Mick
Post by Charles Lepple
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
{ "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>
Charles Lepple
2014-06-04 02:07:27 UTC
Permalink
Post by Mick
Post by Charles Lepple
Post by Charles Lepple
Post by Mick
Post by Charles Lepple
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
{ "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
Mick
2014-06-04 05:20:51 UTC
Permalink
Post by Charles Lepple
Post by Mick
Post by Charles Lepple
Post by Charles Lepple
Post by Mick
Post by Charles Lepple
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
{ "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.
Post by Charles Lepple
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>
Roger Price
2014-06-04 06:45:01 UTC
Permalink
Post by Mick
Post by Charles Lepple
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
Charles Lepple
2014-06-06 03:06:56 UTC
Permalink
Post by Mick
Post by Charles Lepple
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.
Agreed, this seems to be the intended way to set the defaults.

Note that this is subtly different than using "default.ups.delay.shutdown" in ups.conf, because the "default.*" setting is to provide a value to upsc if the driver does not retrieve one from the UPS or its setting tables. The "default.*" values (and "override") do not go back "upstream" to the hardware, only downstream to clients of upsd.
I'm guessing that if these two lines are omitted, no value is sent to the UPS unit. Is this true?
the end effect is what you described, but the process is a little different:

On these UPSes, think of ups.delay.shutdown as a setting that is bundled with the shutdown command (and not sent to the hardware otherwise). The driver keeps a shadow copy that you can read with upsc, and can temporarily set with upsrw. The NUT variable "ups.delay.shutdown" gets initialized with the value of offdelay, which defaults to 20 seconds (see the output of "usbhid-ups -h").
--
Charles Lepple
clepple at gmail
Loading...