Nut upsuser - Mar 2015 - Problems with NUT 2.7.2 on CentOS 7 and using the Mini-Box OpenUPS

On Mar 17, 2015, at 11:46 AM, Philip Taylor <philip at kelsotowers.co.uk>
wrote:
> Charles,
> 
> Did you get chance to look at the data I sent you, please?
> 
> I?ve done some more work myself and the conclusion I?ve reached is that if
the minibus OpenUPS doesn?t support instant commands, then sending ?upsdrvctl
shutdown? won?t ever work, as it would need to send instant commands!
You are correct; I don't see any HU_TYPE_CMD entries in openups-hid.c. I
latched on to the other error you mentioned (about claiming the device).

The other HID drivers seem to trigger shutdown by writing to the various timers
(e.g. UPS.PowerSummary.DelayBeforeReboot). Your firmware seems to have
UPS.PowerSummary.PresentStatus.ShutdownRequested, which according to the HID PDC
spec, is read/write. I wonder if the firmware responds to this?
> Also from the trace I sent you, it appears that after the ?RunTimeToEmpty?
query, the interface tries to read a Report b1 of size 248 which results in a
broken pipe. Is that correct and what would need to be done to resolve this? Or
is that simply the end of the useful data, after which anything else is
discarded?
A bit of explanation on the debug output: the "Report Descriptor: (739
bytes)" hex dump is the HID representation of the individual reports
available. NUT parses that out, and iterates over all of the "Usage
IDs" (status variables, and settings). The values for the usages are
grouped in Reports, each with a one-byte ID. For instance, the
UPS.PowerSummary.PresentStatus.* usages are all one bit long, and they are
grouped in the 16-bit ReportID 0x40.

Usually, the Usage IDs are unique. For whatever reason, they use the same
ff000001.ff000001 ID for several reports, so I suspect that these reports are
accessed directly by their Report ID, instead of looking up the HID Usage IDs to
find a report ID.

That may mean that there is another protocol to get report 0xB1, for instance -
it might involve writing something to one of the other reports first. At any
rate, 0xff000 is the vendor-specific prefix, so unless Mini-Box has an advanced
programming guide, I am not sure what you could do with that.
> I?m minded to stop spending time on trying to get NUT to shut down the
OpenUPS, or the  and then use the following sequence :
> 
> 1) UPSMON keeps track of data from the OpenUPS - I can see voltages and
currents etc. using ups. And it does notifications properly.
Out of curiosity, which notifications? In the openups_drv_start_onbatt log, the
PresentStatus values look the same as the online log. Or do you mean you got
that from the ignorelb configuration?
> 2) It notifies me when the input power goes off and battery level drops to
a critical % - set in NUT, not the OpenUPS. At (say) 11.3V it flags this as
critical but doesn?t shut anything down.
> 3)When the battery level reaches a defined voltage - say 11.2V - the
OpenUPS toggles the motherboard power switch, which triggers a controlled
shutdown of the system. Initiated by the UPS and communicated on a pair of wires
- not USB which I can?t get to work!
> 4) The OpenUPS closes itself down then (even if the power comes back in the
meantime - there doesn?t seem to be a race issue)
> 5) When input power returns, the hardware is configured to automatically
start.
Good that it doesn't have the race condition.
> This isn?t ideal in my mind as it should be possible using the USB cable
alone and it should be controlled from the server (NUT) but I think it?s be best
the OpenUPS will do.
> 
> Any comments, please? My further searching shows Nicu Pavel of mini-box
asked questions on this forum in 2012 but I don?t see any good answers! And
mini-box so far haven?t replied to me.
I found those threads; that has been the only contact with Mini-Box that I am
aware of.
> Many thanks for any help you can provide.
> 
> Regards, Philip.
> 
> 
> 
>> On 14 Mar 2015, at 11:07, Philip Taylor <philip at
kelsotowers.co.uk> wrote:
>> 
>> Charles,
>> 
>> Thanks again for your help, and sorry I didn?t :cc - noted for the
future!
>> 
>> I?m suspicious that the OpenUPS doesn?t behave properly in a number of
ways, of which the USB traffic is the one of immediate concern. It seems to me
that NUT can read from it but probably not write to it: and the OpenUPS doesn?t
flag ?low battery? conditions correctly either. It does shut itself down at a
battery voltage I can configure (via MS windows) and it does provide a signal
via a cable to the power button that will trigger a linux shutdown - but it
won?t do this via USB. So it?s useable with that work-round but not as intended!
>> 
>> It also reports spurious values - you spotted the 3.9 million seconds!
When on input power, that?s what you get for runtime! A sensible value is passed
when on battery. Whether that matters is questionable. Various other values
aren?t good either, like battery current when running on battery. Again that?s
not too important as battery voltage, output voltage and output current are OK.
>> 
>> Mini-box support and documentation are very poor too - but you can?t
help with that!
>> 
>> I hope you can comment on the attached debug output which you
requested. I?ve provided two - one on battery and the other on input power
(which is 15v for my OpenUPS). (I have higher debug level options available but
you asked for -DDD)
>> 
>> The command I used to start the driver was /usr/sbin/usbhid-ups -DDD -a
openups
>> 
>> Finally, I?d be interested in the additional debug modes for
usbhid-ups. This isn?t a ?production system? currently; it?s my home automation
server and it?s getting rebuilt shortly as I?ve changed tack on a few things and
it needs a clean out anyway! So I will try anything!
>> 
>> Many thanks for your help.
>> 
>> Philip.
>> <openups_drv_start_lineon.gz><openups_drv_start_onbatt.gz>
-- 
Charles Lepple
clepple at gmail

On Mar 17, 2015, at 10:32 PM, Charles Lepple <clepple at gmail.com> wrote:
> A bit of explanation on the debug output: the "Report Descriptor: (739
bytes)" hex dump is the HID representation of the individual reports
available. NUT parses that out, and iterates over all of the "Usage
IDs" (status variables, and settings). The values for the usages are
grouped in Reports, each with a one-byte ID. For instance, the
UPS.PowerSummary.PresentStatus.* usages are all one bit long, and they are
grouped in the 16-bit ReportID 0x40.
For a slightly different take on this, could you please send the output of
'lsusb -vvv -d04d8:', run as root, and with the NUT driver stopped?

Thanks,

-- 
Charles Lepple
clepple at gmail

Should have copied ;(
> Begin forwarded message:
> 
> Subject: Re: [Nut-upsuser] Problems with NUT 2.7.2 on CentOS 7 and using
the Mini-Box OpenUPS
> From: Charles Lepple <clepple at gmail.com>
> Date: 18 March 2015 03:23:29 GMT
> Cc: "nut-upsuser at lists.alioth.debian.org" <nut-upsuser at
lists.alioth.debian.org>
> To: Philip Taylor <philip at kelsotowers.co.uk>
> 
> On Mar 17, 2015, at 10:32 PM, Charles Lepple <clepple at gmail.com>
wrote:
> 
>> A bit of explanation on the debug output: the "Report Descriptor:
(739 bytes)" hex dump is the HID representation of the individual reports
available. NUT parses that out, and iterates over all of the "Usage
IDs" (status variables, and settings). The values for the usages are
grouped in Reports, each with a one-byte ID. For instance, the
UPS.PowerSummary.PresentStatus.* usages are all one bit long, and they are
grouped in the 16-bit ReportID 0x40.
> 
> For a slightly different take on this, could you please send the output of
'lsusb -vvv -d04d8:', run as root, and with the NUT driver stopped?
> 
> Thanks,
> 
> -- 
> Charles Lepple
> clepple at gmail
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150318/8ccb0f0a/attachment-0001.html>

Charles, to your specific points :
> The other HID drivers seem to trigger shutdown by writing to the various
timers (e.g. UPS.PowerSummary.DelayBeforeReboot). Your firmware seems to have
UPS.PowerSummary.PresentStatus.ShutdownRequested, which according to the HID PDC
spec, is read/write. I wonder if the firmware responds to this?
So are you suggesting if I modify openups-hid.c to include this specific command
as an instant command, it may respond? I could give it a try if you confirm
that?s what you mean.
> Out of curiosity, which notifications? In the openups_drv_start_onbatt log,
the PresentStatus values look the same as the online log. Or do you mean you got
that from the ignorelb configuration?
The notifications are : ONLINE ONBATT FSD COMMOK COMMBAD SHUTDOWN (following FSD
from command line). I believe it notified LOWBATT too when I used ignoreLB and
over-rode battery.charge.low. But I?ve never seen the OpenUPS notify LB via USB.
If I use the scenario I proposed I would monitor battery.voltage by polling the
online log.

I?m a little surprised that I seem to be the only person interested in this
issue - as some others were interested in the OPENUPS2, in fact you added it to
the ?supported devices? list fairly recently. I think the inclusion of the
OpenUPS as ?fully supported? in the hardware compatibility list over-states the
capabilities!

Thanks once again., you have been most helpful.

Regards, Philip.
> On 18 Mar 2015, at 02:32, Charles Lepple <clepple at gmail.com>
wrote:
> 
> On Mar 17, 2015, at 11:46 AM, Philip Taylor <philip at kelsotowers.co.uk
<mailto:philip at kelsotowers.co.uk>> wrote:
> 
>> Charles,
>> 
>> Did you get chance to look at the data I sent you, please?
>> 
>> I?ve done some more work myself and the conclusion I?ve reached is that
if the minibus OpenUPS doesn?t support instant commands, then sending ?upsdrvctl
shutdown? won?t ever work, as it would need to send instant commands!
> 
> You are correct; I don't see any HU_TYPE_CMD entries in openups-hid.c.
I latched on to the other error you mentioned (about claiming the device).
> 
> The other HID drivers seem to trigger shutdown by writing to the various
timers (e.g. UPS.PowerSummary.DelayBeforeReboot). Your firmware seems to have
UPS.PowerSummary.PresentStatus.ShutdownRequested, which according to the HID PDC
spec, is read/write. I wonder if the firmware responds to this?
> 
>> Also from the trace I sent you, it appears that after the
?RunTimeToEmpty? query, the interface tries to read a Report b1 of size 248
which results in a broken pipe. Is that correct and what would need to be done
to resolve this? Or is that simply the end of the useful data, after which
anything else is discarded?
> 
> A bit of explanation on the debug output: the "Report Descriptor: (739
bytes)" hex dump is the HID representation of the individual reports
available. NUT parses that out, and iterates over all of the "Usage
IDs" (status variables, and settings). The values for the usages are
grouped in Reports, each with a one-byte ID. For instance, the
UPS.PowerSummary.PresentStatus.* usages are all one bit long, and they are
grouped in the 16-bit ReportID 0x40.
> 
> Usually, the Usage IDs are unique. For whatever reason, they use the same
ff000001.ff000001 ID for several reports, so I suspect that these reports are
accessed directly by their Report ID, instead of looking up the HID Usage IDs to
find a report ID.
> 
> That may mean that there is another protocol to get report 0xB1, for
instance - it might involve writing something to one of the other reports first.
At any rate, 0xff000 is the vendor-specific prefix, so unless Mini-Box has an
advanced programming guide, I am not sure what you could do with that.
> 
>> I?m minded to stop spending time on trying to get NUT to shut down the
OpenUPS, or the  and then use the following sequence :
>> 
>> 1) UPSMON keeps track of data from the OpenUPS - I can see voltages and
currents etc. using ups. And it does notifications properly.
> 
> Out of curiosity, which notifications? In the openups_drv_start_onbatt log,
the PresentStatus values look the same as the online log. Or do you mean you got
that from the ignorelb configuration?
> 
>> 2) It notifies me when the input power goes off and battery level drops
to a critical % - set in NUT, not the OpenUPS. At (say) 11.3V it flags this as
critical but doesn?t shut anything down.
>> 3)When the battery level reaches a defined voltage - say 11.2V - the
OpenUPS toggles the motherboard power switch, which triggers a controlled
shutdown of the system. Initiated by the UPS and communicated on a pair of wires
- not USB which I can?t get to work!
>> 4) The OpenUPS closes itself down then (even if the power comes back in
the meantime - there doesn?t seem to be a race issue)
>> 5) When input power returns, the hardware is configured to
automatically start.
> 
> Good that it doesn't have the race condition.
> 
>> This isn?t ideal in my mind as it should be possible using the USB
cable alone and it should be controlled from the server (NUT) but I think it?s
be best the OpenUPS will do.
>> 
>> Any comments, please? My further searching shows Nicu Pavel of mini-box
asked questions on this forum in 2012 but I don?t see any good answers! And
mini-box so far haven?t replied to me.
> 
> I found those threads; that has been the only contact with Mini-Box that I
am aware of.
> 
>> Many thanks for any help you can provide.
>> 
>> Regards, Philip.
>> 
>> 
>> 
>>> On 14 Mar 2015, at 11:07, Philip Taylor <philip at
kelsotowers.co.uk> wrote:
>>> 
>>> Charles,
>>> 
>>> Thanks again for your help, and sorry I didn?t :cc - noted for the
future!
>>> 
>>> I?m suspicious that the OpenUPS doesn?t behave properly in a number
of ways, of which the USB traffic is the one of immediate concern. It seems to
me that NUT can read from it but probably not write to it: and the OpenUPS
doesn?t flag ?low battery? conditions correctly either. It does shut itself down
at a battery voltage I can configure (via MS windows) and it does provide a
signal via a cable to the power button that will trigger a linux shutdown - but
it won?t do this via USB. So it?s useable with that work-round but not as
intended!
>>> 
>>> It also reports spurious values - you spotted the 3.9 million
seconds! When on input power, that?s what you get for runtime! A sensible value
is passed when on battery. Whether that matters is questionable. Various other
values aren?t good either, like battery current when running on battery. Again
that?s not too important as battery voltage, output voltage and output current
are OK.
>>> 
>>> Mini-box support and documentation are very poor too - but you
can?t help with that!
>>> 
>>> I hope you can comment on the attached debug output which you
requested. I?ve provided two - one on battery and the other on input power
(which is 15v for my OpenUPS). (I have higher debug level options available but
you asked for -DDD)
>>> 
>>> The command I used to start the driver was /usr/sbin/usbhid-ups
-DDD -a openups
>>> 
>>> Finally, I?d be interested in the additional debug modes for
usbhid-ups. This isn?t a ?production system? currently; it?s my home automation
server and it?s getting rebuilt shortly as I?ve changed tack on a few things and
it needs a clean out anyway! So I will try anything!
>>> 
>>> Many thanks for your help.
>>> 
>>> Philip.
>>>
<openups_drv_start_lineon.gz><openups_drv_start_onbatt.gz>
> 
> -- 
> Charles Lepple
> clepple at gmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150318/bb0a48ff/attachment-0001.html>

On Mar 18, 2015, at 3:57 AM, Philip Taylor <philip at kelsotowers.co.uk>
wrote:
> Charles, to your specific points :
> 
>> The other HID drivers seem to trigger shutdown by writing to the
various timers (e.g. UPS.PowerSummary.DelayBeforeReboot). Your firmware seems to
have UPS.PowerSummary.PresentStatus.ShutdownRequested, which according to the
HID PDC spec, is read/write. I wonder if the firmware responds to this?
> 
> So are you suggesting if I modify openups-hid.c to include this specific
command as an instant command, it may respond? I could give it a try if you
confirm that?s what you mean.
It's a thought. Looking further into the code, I'm not sure how well
usbhid-ups will handle writing to a single bit, since the reports are
collections of bytes. And it would depend how the firmware interprets it (if it
is writable at all).
>> Out of curiosity, which notifications? In the openups_drv_start_onbatt
log, the PresentStatus values look the same as the online log. Or do you mean
you got that from the ignorelb configuration?
> 
> The notifications are : ONLINE ONBATT FSD COMMOK COMMBAD SHUTDOWN
(following FSD from command line). I believe it notified LOWBATT too when I used
ignoreLB and over-rode battery.charge.low. But I?ve never seen the OpenUPS
notify LB via USB. If I use the scenario I proposed I would monitor
battery.voltage by polling the online log.
Maybe it took a little while longer to get the ONBATT status; in both of the
logs you sent, ACPresent is 0.01 (more scaling issues, but the code only cares
about zero or nonzero).
> I?m a little surprised that I seem to be the only person interested in this
issue - as some others were interested in the OPENUPS2, in fact you added it to
the ?supported devices? list fairly recently. I think the inclusion of the
OpenUPS as ?fully supported? in the hardware compatibility list over-states the
capabilities!
Well, we did add the openups2 recently, but it was mainly because it requires a
different set of scale values to fix the voltage and current readings.

"Supported" is an overloaded term. I would agree that given what we
know now, the Hardware Compatibility List (HCL) rating of five stars for the
openUPS is a bit optimistic. But that was updated in 2012 when the first patches
came in, and it was more of a tip-o-the-hat to Mini-Box for providing the driver
for NUT.

The idea with the Device Dump Library (DDL) was to provide more quantitative
information as to what people can expect from a given combination of UPS and
NUT:
http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/ddl/Mini-Box.com/OPEN-UPS.html

We might consider adding a warning if the UPS does not support basic commands
such as shutdown, although we can't do that automatically now, since some of
the older dump files simply do not contain the list of commands (even if they
support them) since they were collected from mailing list posts.
> Thanks once again., you have been most helpful.
You're welcome!

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150318/b01b44ed/attachment.html>