I'm doing testing of the UPS-side code, including being able to tell the UPS
to shutdown and then come back up after a while (if power has returned).
I'm trying to use upscmd so that I don't have to do an actual shutdown,
but when I have it list the commands for my UPS, I just see 4 commands, and
they're not the ones I thought I had specified.
load.on
load.off
shutdown.return
shutdown.stayoff
I looked in the usbhid-ups file, and I see where, if it finds load.on.delay or
load.off.delay, then it adds the 4 commands shown above. Now, load.on.delay and
load.off.delay are the only two commands I *want* to support. So I put them in
my hid2nut table:
/* Commands to control UPS */
{ "load.off.delay", 0, 0,
"UPS.PowerSummary.DelayBeforeShutdown", NULL, DEFAULT_OFFDELAY,
HU_TYPE_CMD, NULL },
{ "load.on.delay", 0, 0,
"UPS.PowerSummary.DelayBeforeStartup", NULL, DEFAULT_ONDELAY,
HU_TYPE_CMD, NULL },
So there's a few things I am trying to figure out:
1) Where are the commands that I said the UPS had (via HU_TYPE_CMD, I
thought) when I use upscmd?
2) Why does the usbhid-ups automatically add those 4 commands to all usb
subtype drivers....can it really know that those 4 commands are supported?
Along those lines, am I supposed to support those 4 commands?
3) Finally...what is the usefulness of shutdown.stayoff? It tells the UPS
to shut off its load and not to turn it back on when the power comes back. If
so...how does the UPS ever know to turn that load back on? You would have to
hook a different PC to the UPS and run nut just to send the "load.on"
command?
Sincerely,
Rob Groner
Software Engineer
RTD Embedded Technologies, Inc.
ISO9001 and AS9100 Certified
Ph: 814-234-8087
www.rtd.com<http://www.rtd.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150320/f702a15c/attachment.html>
Hi Rob I still have an unset draft answer to your previous mail... but you seem to have progressed... 2015-03-20 16:32 GMT+01:00 Rob Groner <rgroner at rtd.com>:> I?m doing testing of the UPS-side code, including being able to tell the > UPS to shutdown and then come back up after a while (if power has returned). > > > > I?m trying to use upscmd so that I don?t have to do an actual shutdown, > but when I have it list the commands for my UPS, I just see 4 commands, and > they?re not the ones I thought I had specified. > > > > load.on > > load.off > > shutdown.return > > shutdown.stayoff > > > > I looked in the usbhid-ups file, and I see where, if it finds > load.on.delay or load.off.delay, then it adds the 4 commands shown above. > Now, load.on.delay and load.off.delay are the only two commands I **want** > to support. So I put them in my hid2nut table: > > > > /* Commands to control UPS */ > > { "load.off.delay", 0, 0, "UPS.PowerSummary.DelayBeforeShutdown", NULL, > DEFAULT_OFFDELAY, HU_TYPE_CMD, NULL }, > > { "load.on.delay", 0, 0, "UPS.PowerSummary.DelayBeforeStartup", NULL, > DEFAULT_ONDELAY, HU_TYPE_CMD, NULL }, > > > > So there?s a few things I am trying to figure out: > > 1) Where are the commands that I said the UPS had (via HU_TYPE_CMD, > I thought) when I use upscmd? >these should be there. as per the code pointed in (2) below, the above 4 commands are only created if either "load.off.delay", "load.on.delay" or both exists... practically, you may have identified an issue. Could you please check if "usbhid-ups -D ..." does list the above HID data (UPS.PowerSummary.DelayBeforeShutdown &DelayBeforeStartup) The only case I see is that the base data are missing, since we don't check if these HID path actually exists... please report back so that we can fix the code if needed. 2) Why does the usbhid-ups automatically add those 4 commands to all> usb subtype drivers?.can it really know that those 4 commands are > supported? Along those lines, am I supposed to support those 4 commands? > > answer here:https://github.com/networkupstools/nut/blob/master/drivers/usbhid-ups.c#L1002> 3) Finally?what is the usefulness of shutdown.stayoff? It tells the > UPS to shut off its load and not to turn it back on when the power comes > back. If so?how does the UPS ever know to turn that load back on? You > would have to hook a different PC to the UPS and run nut just to send the > ?load.on? command? > > that's a use case and an option.Some users prefer the default "turn on when AC is back", some others prefer not. cheers, Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150320/9b01dfbe/attachment.html>
>>I still have an unset draft answer to your previous mail... but you seem to have progressed...Heh?that?s been known to happen. ? I have the luxury of relatively un-interrupted development on this project, so it goes a lot faster now. Hopefully that lasts?>>>Could you please check if "usbhid-ups -D ..." does list the above HID data (UPS.PowerSummary.DelayBeforeShutdown &DelayBeforeStartup) >>>The only case I see is that the base data are missing, since we don't check if these HID path actually exists...Ah, bingo I think. It sees the two paths, but gives me a ?broken pipe? when trying to retrieve the reports. I don?t have reports implemented for those two commands because?well, they should only exist one way, there is nothing to read from them. I?ll put in a dummy report for them and see if that makes it all better. On a side note?I have them implemented in the USB Report descriptor as a Feature, which I know is R/W. I tried making them Input and Output, and I seem to remember each time, it still came back with ?broken pipe? as though it were trying to get the value of that particular data item. Is one of those types (Feature, Input, Output) actually correct for these commands?>>>answer here: >>>https://github.com/networkupstools/nut/blob/master/drivers/usbhid-ups.c#L1002I found it in the code, but I still didn?t understand. I get it now?it just calls my delayed command but with a delay of 0. That?s good to know?I?ll have to take that value into account, I think I had just been checking that the delay *wasn?t* zero before.>>>3) Finally?what is the usefulness of shutdown.stayoff? It tells the UPS to shut off its load and not to turn it back on when the power comes back. If so?how does the UPS ever know to turn that load back on? You would have to hook a different PC to the UPS and run nut just to send the ?load.on? command?Ok, I kind of get that it?s a use-case or optional feature, and I might implement that. I had up to now just figured they would configure their PC BIOS to handle the power-on event. But I still have to ask?how does the UPS ever know to turn its load on again? When the UPS itself is power cycled (again)? Thanks much for the help Arno Sincerely, Rob Groner Software Engineer RTD Embedded Technologies, Inc. ISO9001 and AS9100 Certified Ph: 814-234-8087 www.rtd.com<http://www.rtd.com/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150320/0e38c4fb/attachment.html>
Ok, that?s what it was?I added a dummy report handler for those two report IDs,
and now there?s no broken pipe, and both the .delay commands show up for upscmd.
Excellent! I so far can?t actually set the command due to an ERR ACCESS-DENIED,
but I?ll probably be able to figure that out (other than just going all-root).
Sincerely,
Rob Groner
Software Engineer
RTD Embedded Technologies, Inc.
ISO9001 and AS9100 Certified
Ph: 814-234-8087
www.rtd.com<http://www.rtd.com/>
From: aquette.dev at gmail.com [mailto:aquette.dev at gmail.com] On Behalf Of
Arnaud Quette
Sent: Friday, March 20, 2015 2:15 PM
To: Rob Groner
Cc: nut-upsdev at lists.alioth.debian.org
Subject: Re: [Nut-upsdev] UPS commands
Hi Rob
I still have an unset draft answer to your previous mail... but you seem to have
progressed...
2015-03-20 16:32 GMT+01:00 Rob Groner <rgroner at rtd.com<mailto:rgroner
at rtd.com>>:
I?m doing testing of the UPS-side code, including being able to tell the UPS to
shutdown and then come back up after a while (if power has returned).
I?m trying to use upscmd so that I don?t have to do an actual shutdown, but when
I have it list the commands for my UPS, I just see 4 commands, and they?re not
the ones I thought I had specified.
load.on
load.off
shutdown.return
shutdown.stayoff
I looked in the usbhid-ups file, and I see where, if it finds load.on.delay or
load.off.delay, then it adds the 4 commands shown above. Now, load.on.delay and
load.off.delay are the only two commands I *want* to support. So I put them in
my hid2nut table:
/* Commands to control UPS */
{ "load.off.delay", 0, 0,
"UPS.PowerSummary.DelayBeforeShutdown", NULL, DEFAULT_OFFDELAY,
HU_TYPE_CMD, NULL },
{ "load.on.delay", 0, 0,
"UPS.PowerSummary.DelayBeforeStartup", NULL, DEFAULT_ONDELAY,
HU_TYPE_CMD, NULL },
So there?s a few things I am trying to figure out:
1) Where are the commands that I said the UPS had (via HU_TYPE_CMD, I
thought) when I use upscmd?
these should be there.
as per the code pointed in (2) below, the above 4 commands are only created if
either "load.off.delay", "load.on.delay" or both exists...
practically, you may have identified an issue.
Could you please check if "usbhid-ups -D ..." does list the above HID
data (UPS.PowerSummary.DelayBeforeShutdown &DelayBeforeStartup)
The only case I see is that the base data are missing, since we don't check
if these HID path actually exists...
please report back so that we can fix the code if needed.
2) Why does the usbhid-ups automatically add those 4 commands to all usb
subtype drivers?.can it really know that those 4 commands are supported? Along
those lines, am I supposed to support those 4 commands?
answer here:
https://github.com/networkupstools/nut/blob/master/drivers/usbhid-ups.c#L1002
3) Finally?what is the usefulness of shutdown.stayoff? It tells the UPS to
shut off its load and not to turn it back on when the power comes back. If
so?how does the UPS ever know to turn that load back on? You would have to hook
a different PC to the UPS and run nut just to send the ?load.on? command?
that's a use case and an option.
Some users prefer the default "turn on when AC is back", some others
prefer not.
cheers,
Arno
--
Eaton Data Center Automation - Opensource Leader
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150320/fd63e6b7/attachment-0001.html>
On Mar 20, 2015, at 11:32 AM, Rob Groner <rgroner at RTD.com> wrote:> 3) Finally?what is the usefulness of shutdown.stayoff? It tells the UPS to shut off its load and not to turn it back on when the power comes back. If so?how does the UPS ever know to turn that load back on? You would have to hook a different PC to the UPS and run nut just to send the ?load.on? command?If the goal is just to perform a clean shutdown, and the power might cycle a few more times before coming back completely, then shutdown.stayoff might make more sense. A human could come along and manually power it back on. I suspect a lot of people who want to maximize uptime would want the UPS to wait a bit for the battery to charge ("battery.charge.restart" -> "Minimum battery level for UPS restart after power-off") before powering the load back on. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150321/40aaa9fd/attachment.html>
I'm probably spending WAY too much time on this question, but....
If the goal is just to perform a clean shutdown, and the power might cycle a few
more times before coming back completely, then shutdown.stayoff might make more
sense. A human could come along and manually power it back on.
...by plugging the PC into a new power source? Because the UPS outlet would be
shut off, so hitting the power button on the PC won't do anything. I'm
not aware of buttons on a UPS that tells it to turn its outlet back on, but then
my own UPSes have always been fairly dumb power units. Perhaps the newer
smarter ones allow for easy turning on and off of the outlet via physical
console? In that case, I can see the usefulness of .stayoff.
I suspect a lot of people who want to maximize uptime would want the UPS to wait
a bit for the battery to charge ("battery.charge.restart" ->
"Minimum battery level for UPS restart after power-off") before
powering the load back on.
Ah, that's a good idea. Something new to implement today!
Sincerely,
Rob Groner
Software Engineer
RTD Embedded Technologies, Inc.
ISO9001 and AS9100 Certified
Ph: 814-234-8087
www.rtd.com<http://www.rtd.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150323/a7a96364/attachment.html>