similar to: [Bug 915985] Re: usbhid-ups regression (APC BE525-RS)

Gentlemen, Please note that what follows pre-dates the latest changes from Arnaud (just thought someone might want to look at these before I can test the latest!). When running newhidups with -D -D -D I saw messages that looked like errors, and it took me a while to understand that they were not really errors. I therefore added two new entries in apc-hid.h, and I modified a couple of diagnistic

Hi all, I have an APC/Smart-UPS 3000 RM that I am trying to connect to nut via the usb port. I have nut running just fine on several other machines using APC ups's via the serial ports but this usb thing is making me crazy. If I do a "/sbin/newhidups -u root -D -a PS1" it recgonizes the ups and dumps a bunch of information like below: (porky pts12) # /sbin/newhidups -u root -D -D

Thanks for the reply. However these two FAQ are unfortunately not describing the situation. - The first issue is that NUT switches off the UPS upon reboot on low battery (not that it dies because of low battery) - The second issue is that the UPS does not recognise being online again (not that the PC does not restart) Sent from my iPhone > On 11 Jun 2019, at 02:03, Charles Lepple <clepple

[adding NBD list] On 4/23/19 2:36 AM, Richard W.M. Jones wrote: > On Mon, Apr 22, 2019 at 07:50:22PM -0500, Eric Blake wrote: >> Previously, we were squashing EOVERFLOW into EINVAL; continue to do so >> at points in the protocol where the client may not be expecting >> EOVERFLOW. > > The protocol spec is unclear on whether EOVERFLOW can be returned in > cases other

On Tue, Apr 23, 2019 at 07:38:41AM -0500, Eric Blake wrote: > [adding NBD list] > > On 4/23/19 2:36 AM, Richard W.M. Jones wrote: > > On Mon, Apr 22, 2019 at 07:50:22PM -0500, Eric Blake wrote: > >> Previously, we were squashing EOVERFLOW into EINVAL; continue to do so > >> at points in the protocol where the client may not be expecting > >> EOVERFLOW.

Gentlemen, I have determined that on my UPS (APC Back-UPS ES 650 FW:818.w1.D USB FW:w1), the variable UPS.PowerSummary.RemainingCapacityLimit is writeable. I am setting this variable to start shutdown a little earlier. Appended is an unconditional patch for apc-hid.h. If, as indicated by the original code, there are APC UPS devices that don't allow setting of this variable, it becomes

On Jun 10, 2019, at 2:32 PM, Marc Finns wrote: > > Hello, I read all FAQ and other sources but I could not find this situation, so I thought of asking the experts. > I successfully configured a Raspberry NUT server to control my UPS that powers several devices (NUC with ESXI VMs, Synology NAS etc). > All works well in principle, but I have the following behaviours that I could not

Hi, I'm trying to generate a skeleton driver with usbhid-ups and gen-usbhid-subdriver but the output seems to be incorrect. Same behavior with stable 2.6.5, so I guess there is something wrong with data coming out of device. I attached the output of usbhid-ups and gen-usbhid-subdriver from the commands: drivers/usbhid-ups -DD -u root -x explore -x vendorid=04d8 -a openups >&

So, going with the proposed initial design, I created a report descriptor to describe the battery. I thought that I'd then see how NUT responded to it. The good news is that the descriptor showed up and all of the paths were correct. Unfortunately, after that, nothing happened...no reports were requested, and it just kept timing out. Is there some minimum amount of functionality I need to

Previously, we were squashing EOVERFLOW into EINVAL; continue to do so at points in the protocol where the client may not be expecting EOVERFLOW. Signed-off-by: Eric Blake <eblake@redhat.com> --- server/protocol.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/server/protocol.c b/server/protocol.c index a52bb56..0a9f73c 100644 --- a/server/protocol.c

I recently purchased a CyberPower CP1500PFCLCD UPS as a replacement UPS for a headless server running Slackware 14.1 with the 3.10.7 kernel. I then downloaded the NUT 2.7.1 tarball on the server and following the directions installed the software. The installation went well and the UPS will shutdown the server using the forced down test and then it powers back up as it should. The

On Mon, Apr 22, 2019 at 07:50:22PM -0500, Eric Blake wrote: > Previously, we were squashing EOVERFLOW into EINVAL; continue to do so > at points in the protocol where the client may not be expecting > EOVERFLOW. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > server/protocol.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) >

You have the device side right. Devices have "UPS.PowerSummary.CapacityMode" (are the next three in %, mAh, or mWh? "UPS.PowerSummary.FullChargeCapacity" "UPS.PowerSummary.RemainingCapacity" "UPS.PowerSummary.RemainingCapacityLimit" "UPS.PowerSummary.WarningCapacityLimit" According to nut-names.txt, NUT has: battery.charge | Battery

Hello, I have been using NUT for a short period of time and have some questions regarding the UPS reboot signal that I can't figure out. Have tried some googling and reading the DOCs but I am struggling to understand how some variables / things are supposed to work, so would appreciate any help with any of the following questions. I am running NUT on standalone mode on a linux machine

Mapping of EOVERFLOW was missed in commit 6f8c8084. Mapping of EOPNOTSUPP is essential for .zero to trigger a fallback to .pwrite, missed in commit 6c0e00e9 (not to mention that it becomes a valid protocol failure once fast zero support is added). There is no Unix.ENOTSUP, or that would get the same treatment per commit abb2b47c. Preserving EROFS and EFBIG is useful because protocol.c

I have not been able to make work nut with my APC RS 500 chears from Uruguay, -- /*-------------------------------------------------*/ "Sin ideales no puede producirse una realidad buena; s?lo teniendo ansias de algo mejor, cabe llegar a ser mejores alg?n d?a." F. Dostoievski /*-------------------------------------------------*/ ___ ___ /\__\ /\__\

I did a test shutdown on a nut controlled UPS and it all went as expected except that when it got to: /usr/local/ups/bin/upsdrvctl shutdown Nothing happened. So the halt script went on and shut down the system. I waited a while but the UPS never turned itself off. Am I doing something wrong, or does this UPS not support this function? Thank you, David Mathog mathog at caltech.edu Manager,

Hi, It's the first time that we want to use an UPS in our labo. We have 1 server, which are running under an old version of opensuse. We would like to use the stable tree of nut on the computer with an APC BACK-UPS RS 1500VA 230V. I have seen on the compatibility page, that this UPS is supported. is there anyone, who uses this UPS with NUT to confirm that ? Thanks a lot, Best regards, GiGGz

On Mar 27, 2018, at 5:47 PM, <p1_p1_p1 at seznam.cz> wrote: > > if somebody has same problem with APC BackUPS (SmartUPS works correctly in same USB) > USE FASTEST USB that U have on board, (if you have USB 2.0 and USB 3.0 onboard use one 3.0 port for UPS), > sounds like nonsense, but it works, just OMG and halelujah for linux usb drivers. According to this, your UPS is using

Hi Patrick, I didn't get further bug reports from you, so I have now listed your device as "supported" by newhidups. Last I saw as of your below message, the driver was working as expected. If there are any future problems, let me know! -- Peter Patrick Nolan wrote: > > Remember me? Back in May we exchanged some messages about my Tripp-Lite > UPS. My boss has gone on