Re: [Nut-upsdev] Cyber Power LE1000DG UPS

[Charles Lepple via Nut-upsdev]

On Jan 13, 2024, at 6:28 PM, Justin Choponis  wrote:
> 
> I have a Cyber Power LE1000DG UPS I got from Best Buy this weekend. I plan to 
> use it with a TrueNAS scale system, and it is connected via USB. Vendor link: 
> https://www.cyberpowersystems.com/product/ups/battery-backup/le1000dg/.
>  
> TrueNAS has you pick a UPS driver. I could not find any “LE” related models 
> on https://networkupstools.org/stable-hcl.html (which is the list TrueNAS 
> uses). Per your guidance on that page, I tried one that I hoped was 
> compatible: “Cyber Power Systems ups 2 Value 800E USB (usbhid-ups)”. Every 
> Cyber Power system with USB on the list there seems to use usbhid-ups anyway 
> – so perhaps picking any of them is reasonable?

Picking anything that maps to usbhid-ups does seem reasonable, though it's 
possible that they pass additional options for certain models (I think FreeNAS 
does this). I don't know of any that are needed for CPS, though.

>  I can have the TrueNAS system power down when power is lost and the UPS runs 
> on battery, but I see occasional messages about communications being lost 
> with the UPS (saying “Statistics could not be recovered”). I also see 
> statistics being gathered in other alert messages (like it is working fine).

No mention of stability issues for LE825G: 
https://alioth-lists.debian.net/pipermail/nut-upsdev/2013-November/006563.html 
(but I don't know different the DG and G models differ)

It is probably worth skimming some of the issues here to see whether there is 
any wisdom applicable to your case: 
https://github.com/networkupstools/nut/issues?q=+label%3A%22CyberPower+%28CPS%29%22+label%3A%22Connection+stability+issues%22

Different versions of the underlying OS and NUT might handle things 
differently, but I don't think I have run across this particular issue (my CPS 
UPS is currently on a Mac, so I don't see connect/disconnect logs). The usual 
hardware suggestions are to swap out the USB cable, and try a powered USB hub.

-- 
Charles Lepple
clepple@gmail

> _
> Nut-upsdev mailing list
> Nut-upsdev@alioth-lists.debian.net 
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] RunTimeToEmpty is in minutes or seconds?

[Charles Lepple via Nut-upsdev]

On Jan 2, 2024, at 1:49 PM, Kelly Byrd  wrote:
> 
> My question for you all is what units ups.powersummary.runtimetoempty is 
> supposed to be in? This doc from USB.org: 
> https://www.usb.org/sites/default/files/hut1_4.pdf (Section 31.2) says 
> minutes,

Do you mean the Power Device Class documentation?

I agree that the description on p.37 of 
https://usb.org/sites/default/files/pdcv11.pdf says minutes, but the last 
reference to RunTimeToEmpty on p.57 is embedded in a descriptor that specifies 
the units to be seconds. I think most manufacturers end up reporting seconds, 
since the descriptors tend to look fairly similar to the spec.

> Is this just a case where real world UPS' are using seconds so we're stuck 
> with it now?

That, and the fact that that the HID protocol uses a lot of base SI units.

> I guess it's being pedantic, but IMO trying to measure a UPS remaining 
> runtime with accuracy is sort of silly. I noticed this because I'm cobbling 
> together a personal project that has absurd capacity for the load, somewhere 
> around 2-3 days from a fully charged battery and I'm using NUT's Arduino 
> driver to report things.

To be honest, this is exactly the sort of thing that the Physical and Logical 
units are meant to address. You can keep the internal time-remaining counter in 
whatever format makes sense in the firmware, and specify some Logical units to 
map that back to seconds so you aren't sending 32-bit numbers for something 
with a really small range.

I'm pretty sure there is one UPS where the shutdown timer settings are kept in 
minutes, and the NUT drivers expose seconds because the vendor specified a 
Physical-to-Logical factor of 60.

- Charles
___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Minutemen UPS Driver

[Charles Lepple via Nut-upsdev]

I think the problem is that there were some communication errors, as noted 
here: https://github.com/networkupstools/nut/issues/555

I would want to test thoroughly before relying on it for automated shutdowns.

-- 
Charles Lepple
clepple@gmail

> On Dec 14, 2023, at 8:35 AM, Jim Klimov via Nut-upsdev 
>  wrote:
> 
> That's MinutemAn and such a key word exists in usbhid-ups subdriver 
> tripplite-hid :)
> 
> 
> Specifically, the "PRO RT 2U" series is among the few mentioned by name:
> 
> $ git grep -i minuteman
> NEWS.adoc:   * add Delta Minuteman UPS VID/PID [PR #1230, issues #555 and 
> #1227]
> drivers/tripplite-hid.c:/* Delta/Minuteman */
> drivers/tripplite-hid.c:/* Delta/Minuteman Enterprise Plus E1500RM2U 
> */
> drivers/tripplite-hid.c:/* Delta/Minuteman PRO1500RT2U */
> 
> 
>   Oddly, it seems nobody posted it to neither HCL nor DDL so far...
> 
> Hope this helps,
> Jim Klimov
> 
> 
> On Thu, Dec 14, 2023 at 1:08 PM James Parascand via Nut-upsdev 
>  > wrote:
>> I am wondering if there is a way to have Nut Server monitor a Minutemen UPS.
>> 
>> https://minutemanups.com/uninterruptible-power-supply/pro-rt2u-line-interactive-uninterruptible-power-supply/
>> 
>> Thanks
>> James
>> ___
>> Nut-upsdev mailing list
>> Nut-upsdev@alioth-lists.debian.net 
>> 
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
> ___
> Nut-upsdev mailing list
> Nut-upsdev@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Can we just import apcupsd code?

[Charles Lepple via Nut-upsdev]

On Jan 4, 2023, at 5:02 PM, Ted Mittelstaedt via Nut-upsdev 
 wrote:
> 
> But instead of that NUT elected to write a shim that spawns apcuspd.  
> 
Technically, it doesn't launch apcupsd, the driver connects to an existing 
apcupsd instance. And the shim (apcupsd-ups) was contributed by a user.

Let's stick to the facts, rather than attempting to guess at motives.
___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Compatibility question

[Charles Lepple via Nut-upsdev]

On Jul 17, 2022, at 4:09 PM, Al M via Nut-upsdev 
 wrote:
> 
> Should this APC UPS be compatible with NUT? Could not find it on the 
> compatible list.
> 
> This description from Amazon:
> APC UPS Battery Backup and Surge Protector, 600VA Backup Battery Power 
> Supply, BE600M1 Back-UPS

It would probably work well enough to get some debug output from the usbhid-ups 
driver, if it doesn't work out of the box.

I'm basing this off of the user manual linked from what seems to be the 
appropriate product page:

https://www.apc.com/shop/tt/en/products/APC-Back-UPS-600VA-120V-1-USB-charging-port-7-NEMA-outlets-2-surge-/P-BE600M1

"Note: PowerChute is only compatible with a Windows operating system. If you 
are using Mac OSX, use the native shutdown feature to protect your system. See 
the documentation provided with your computer."

What the OS X comment implies is that the UPS is compatible with USB HID PDC 
(Power Device Class), which both macOS and NUT usbhid-ups implement. However, 
this doesn't guarantee full NUT compatibility, and it doesn't indicate which 
readings you would be able to get with NUT (versus PowerChute, which apparently 
uses another protocol on top of USB HID).

TL;DR make sure the UPS comes with a good return policy.

> ___
> Nut-upsdev mailing list
> Nut-upsdev@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev


___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] a few build nits

[Charles Lepple via Nut-upsdev]

On Mar 31, 2022, at 9:18 AM, Greg Troxel wrote:
> 
> I see your point about distcheck.  I tend to build tarballs from source
> to then use in pkgsrc (not that I publish those tarballs and packages),
> to be able to debug the combination of upstream and pkgsrc to be ready
> for a release.   I can certainly just flip my script to the light version.
> 
mostly for the archives (sounds like Greg has a solution), this page talks 
about the difference between "make distcheck" and "make distcheck-light" in NUT:

https://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building

- C
___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] On retiring some terminology

[Charles Lepple via Nut-upsdev]

On Mar 12, 2022, at 11:51 AM, Ted Mittelstaedt via Nut-upsdev 
 wrote:
> 
> 11 post over the last year on this topic.  Lots of effort expended on a WOKE 
> problem far more than effort expended on real issues that actually affect 
> code functionality.  My condolences.
> 
Ted, this project doesn't need yet another a Monday morning quarterback. Not 
sure how you're counting those 11 posts (remember, this request originally came 
in through GitHub, and the initial poster made a very level-headed request for 
synonyms in the configuration), but no matter, Jim has admirably worked this 
change in among hundreds of other more substantial commits.

Constructive criticism is welcome, including offering ideas on where to expend 
developer energy in the future for better impact. Uninformed comparisons to 
other projects after work has been undertaken are not useful. You have provided 
contrarian advice before on these lists, and I wouldn't be surprised if you 
saved some people the trouble of doing things the hard way. But that's very 
different than offering an eyeroll literally a year after the discussion 
started.

- Charles


___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Cross-compiling for OpenWRT on Debian - neon libraries error

[Charles Lepple via Nut-upsdev]

On Sep 16, 2021, at 6:30 AM, Seb Belcher via Nut-upsdev 
 wrote:
> 
> Bit of a noob question I'm sure but would appreciate the help.  The nut 
> package maintained for OpenWRT does not include the netxml drivers that I 
> need for my UPS, so I'm embarking on something a little outside my comfort 
> zone and trying to cross-compile from source.  The build system is Debian. 
> 
> I've got quite far, and was able to cross-compile nut with default options 
> but adding the --with-neon is breaking it.  I've installed the neon dev 
> libraries on the build system and they seem to be detected during the 
> configure stage
> ...
> checking for libneon version via pkg-config (0.25.0 minimum required)... 
> 0.30.2 found
> checking for libneon cflags... -I/usr/include/neon
> checking for libneon ldflags... -lneon
> ...
> but then it quits with an error. 
> configure: error: "neon libraries not found, required for neon based XML/HTTP 
> driver"
> 
> I've verified the neon header files are in /usr/include/neon beyond that, I'm 
> at a loss.  Any help would be appreciated.  Thanks. 
> 
It's been a little while since I last used a cross-compiler, so maybe I am 
rusty on terminology. It sounds like you are building on a Debian system, but 
targeting OpenWRT - are they both the same architecture? (e.g. Debian on MIPS, 
and a WRT54G MIPS-based router)

If not, I would expect that your path for libneon would be a little longer, 
with the target architecture/OS included in there somewhere. (The include files 
might work across similar architectures, but the libraries are definitely going 
to have to match the target architecture/OS.)

For instance, you might need to install libneon into the Buildroot staging_dir 
if you are following these instructions:

https://openwrt.org/docs/guide-developer/crosscompile

then follow their recommendations on setting LDFLAGS (which should probably 
show up in NUT's ./configure output).
___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Does Cyberpower BR1000ELCD work?

[Charles Lepple via Nut-upsdev]

On Dec 28, 2020, at 10:01 AM, Mike Ricketts wrote:
> 
> Hi
> 
> I am considering buying a Cyberpower BR1000ELCD UPS.
> 
> https://www.cyberpower.com/uk/en/product/series/brics_lcd
> 
> It does not appear on the HCL, but other Cyberpower USB models do.
> 
> The specs claim it has a HID-compliant USB interface (although who knows how 
> "compliant" that is...)
> 
> I've found that https://github.com/networkupstools/nut/issues/552 was opened 
> to add it to the HCL, but it hasn't been added.  Does anyone know if it was 
> not added because it doesn't work, or just that nobody got around to it?

I think that issue is the only information we have on that UPS, so I'd say it 
just fell through the cracks.

Be sure to check out some of the other issues tagged "CyberPower (CPS)" for 
background on which stats and settings are expected to work. In particular, 
some of the transfer voltages might not work as well as in the vendor software, 
and I don't recall whether these models store those settings in EEPROM (or if 
the software is responsible for re-applying them). I keep thinking "we should 
fix these HID-descriptor related bugs" but that's a big job that only fixes 
things for a few UPSes, and we've had broader tasks like keeping up with libusb 
changes (0.1 vs 1.0) and getting a release out the door.

https://github.com/networkupstools/nut/labels/CyberPower%20%28CPS%29

The good news is that the OL/OB status is generally not affected by voltage 
scaling issues.

> If it is thought to work, I'm happy to do whatever testing is needed to get 
> it added to the HCL - just don't want to buy it and then find it is known to 
> not work for some reason.

Nothing too magical about the HCL - since it is best-effort, and vendors can 
change the innards of an UPS while keeping the name, it can really only be a 
rough guide. For a single UPS, your best hedge against unexpected 
incompatibility might be a good return policy. If you are thinking about a 
larger purchase, I would want to contact a vendor sales rep and mention that 
you want to use the UPSes with third-party software like NUT, since they often 
have their own UPS monitoring software, and very few companies do compatibility 
testing with NUT.

That said, if it works, or if it doesn't, we can still collect that 
information. We're trying to keep this all on open mailing lists and GitHub 
issues to make it easy for others to find. Guidance for testing is at the 
bottom of the HCL page: https://networkupstools.org/stable-hcl.html#footnotes

> -- 
> Mike
> 
> 
> ___
> Nut-upsdev mailing list
> Nut-upsdev@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev


___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev