Support for Liebert Corp PowerSure PST UPS #2271
Labels
impacts-release-2.8.1
Issues reported against NUT release 2.8.1 (maybe vanilla or with minor packaging tweaks)
liebert
USB non-zero interface numbers
Most UPSes serve USB interactions on interface 0 which is default. Recent "composite devices" differ
USB
Milestone
Comments
|
|
|
This looks like it has a chance to be covered by However, product ID 0x0002 is not currently known in the driver sources. This has two implications:
|
jimklimov
added a commit
to jimklimov/nut
that referenced
this issue
Jan 19, 2024
…kupstools#2271] Signed-off-by: Jim Klimov <[email protected]>
|
I've proposed an exploratory fix in PR #2272 - you can try to build that codebase per wiki instructions linked earlier, using this for the initial git checkout: |
|
Jim, Thanks for your prompt reply. I will see if I can get some testing done this weekend. |
jimklimov
added a commit
to jimklimov/nut
that referenced
this issue
Jan 20, 2024
…rs/belkin-hid.c [networkupstools#2271] Signed-off-by: Jim Klimov <[email protected]>
jimklimov
added
USB
liebert
impacts-release-2.8.1
|
Cheers, do we have any lucky progress here? :) |
|
I am trying to follow the directions for installing the test on the raspian
system. Trying is the optimum word.
…On Mon, Jan 22, 2024 at 3:39 AM Jim Klimov ***@***.***> wrote:
Cheers, do we have any lucky progress here? :)
—
Reply to this email directly, view it on GitHub
<#2271 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGUJRAUDMRLA4RVWTGWKUPTYPYQTZAVCNFSM6AAAAABCB6HNXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBTGQ4TONJWGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Well... typically you |
|
"WARNING: Some error has occurred while processing 'nut-scanner' command-line I did the "Replacing a systemd deployment" section. |
|
And did you pass any arguments to Also, try After the |
|
Gentle bump? :) Note I've updated the previous post with a few more ideas... |
|
For what it's worth, I think I have the same unit here (a Vertiv PSI5 unit). It reports the same info from lsusb. Unfortunately, I don't have a great way to build from source, as everything's running in docker containers. I'll be down to test once the product ID patch gets merged and the docker images get updated, though. |
|
@electroflame : just in case, are your NUT containers the HomeAssistant plugin? If yes, see our Wiki for community hints about building one. Hope that helps. Also, is a NUT container useful (e.g. to shut down its host and bring down the UPS in the end)? |
|
I'm not using the HomeAssistant plugin, although that's an idea. My plan was just to run NUT in a container and let all of the clients connect to it that way. It just helps keep everything separate on my end, and I've got a dashboard to let me know if services (i.e. containers) crash or stop responding. I've done a little more by trying to set the Setting Is there anything else that might help here? |
|
Following a discussion from another thread, just as a guess - check if |
|
Hm, no dice on changing the driver. They complain about needing a subdriver, although the HID driver correctly detects the Belkin subdriver. I'm going to spin up a VM and see if the Vertiv PowerAssist software can detect the UPS correctly. |
|
In that case, I'd suggest checking in the host system whether NUT drivers behave better, using a custom build or maybe by |
|
My container was privileged, but it made no difference either way. I tried installing NUT on an Ubuntu VM and had similar issues. Mainly that lsusb sees the device, but NUT and nut-scanner do not. So I tried installing it on a Raspberry Pi 4, outside of any Docker/virtualization layer, and I have the same result. lsusb sees the USB device (with the name and vendor ID, etc.) but NUT doesn't. So as a last-ditch effort, as I was seriously questioning whether the actual UPS was malfunctioning, I hooked it up to my main Mac to check if macOS sees it as a battery. It does! So macOS reads it as a UPS, so the device isn't malfunctioning, but it doesn't really help me as NUT still can't see it, and the Mac is too far away to use the UPS via USB for more than a test (and it wouldn't be networked anyway). Any other ideas to debug this a bit further? Thanks for the help so far! |
|
Well, Starting with NUT v2.8.1 (or master) you should be able to pass a Try Belkin/Liebert; also maybe Phoenixtec/Liebert or MGE as likely related variants. |
|
Hm, no dice. I decided to try apcupsd and see if that worked (even though this isn't an APC unit) and to my surprise it does actually read about half of the data off the UPS, including the status and battery (which honestly are the most important). It doesn't get Voltage or anything, though. I wonder if this is just sending malformed data. I might just have to stick with apcupsd until the vendor/product IDs update, and see if nut-scanner can see it then. |
|
Just a quick update here: I bit the bullet and set up a fresh install of Raspberry Pi OS (Bookworm) on a Raspberry Pi 4 and booted into that, installing a fresh version of NUT. As an aside, there may still be issues with NUT and newer Pis or Pi OS. There's permission issues with a fresh install of each (the kernel might be grabbing the USB?) but setting up a udev rule and running upsmon as root seems to fix that. Unfortunately, I didn't get much farther than with the VMs. With I think this is about the limit of what I can do debugging-wise, unfortunately. I'm out of ideas. |
|
From indications in the issues so far, different Pi models may have had different quality USB chips. There were many reports about issues with Pi3 (maybe owing more to platform popularity than HW quality, though) which subsided around Pi4 and on the rise with Pi5. Take with a grain of salt - I have no 100% conclusions here. Regarding a fresh install - which NUT version was there? Packaged (and 2.8.1?) or one you've built from Git master or the exploratory fix in PR #2272? (I guess building AND installing only the latter would get around the permission option problem, as this is the only NUT source which "knows" the new ID.) Did you try with the |
|
I tried the package in the repository first (2.8.0 -ish, I think). Then I wiped it again and built 2.8.1 (but I forgot to try your PR). It takes a while to build on a Raspberry Pi 4, so I didn't do it again (I have to have the Pi up and running during the day, so I can only take it down to test during a short window). Things get way more complicated to debug when I build from source (and increases the odds of me doing something wrong), so I might just have to wait for 2.8.1 to make it into the normal Debian/Raspberry repositories. Again, with the |
|
Well, name/model/etc. were the basics per USB HID, so the interesting part is if it pulls the actual UPS power device info :) If you followed the Wiki article (and config prereqs that it references), you would have |
|
I'm going to wipe the SD card back to a fresh install and try building from your PR fork. I'll see if I can get any more data out of it that way and let you know. |
|
Okay, some good news. After compiling again, running Next, running It definitely sees more info, but still doesn't have anything usable from the UPS. I'll try the subdrivers next, but I wanted to post this in case you see anything immediately wrong. |
|
Here are the results from the subdrivers you recommended earlier (neither worked): Phoenixtec/Liebert MGE |
|
For kicks, can you try adding a |
|
Sure, I hope I did it right.
Unfortunately, still no extra UPS data. |
|
Interestingly, this log made me realize that this might be an HID index issue. Here's lsusb: The second descriptor seems to be the one with Interrupt support, so I'm guessing that might actually be the UPS values. I saw two issues #1840 and #2149 that might apply. The log seems to imply that the driver is checking all of the HIDs, but I'm not sure -- maybe I'm getting bit by the multiple HID issue here? |
|
Interesting idea... There are some devices and drivers using a non-zero interface, etc. IIRC Arduino-based experiments were much of the recent context on this, and the different numbers became driver config fields (with no exposure yet via config files, I think). Maybe an id-based tweak could help in upsdrv_init() or similar... Can you experiment on that? |
|
Unfortunately I think this is about as far as I can take it. My experience with C is very, very limited, and a Raspberry Pi is super slow to work with. If this ends up as a config value I'll be glad to give it a test, but I don't think I can devote the time to noodling around in a language I'm not relatively confident in (especially as it's a driver connected to a powered device). Thanks for the nudges so far, I appreciate it! I hope this gets worked out one day, but unfortunately I don't think I can be the one to do it. |
jimklimov
added
the
USB non-zero interface numbers
|
Hello, can you please check if #2331 helps? Follow https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests with this branch for the build: |
|
Sure, I've got a bit too much on my plate this week, but I can try and get this tested next week. Any chance you can outline what flags you need me to use in the driver command? |
|
Similar to this, I guess: #1840 (comment) |
|
I've got a confirmation there, so maybe would just release this change once CI is happy with syntax nuances :D and then it would be part of NUT |
|
Ah, nice! I'll definitely try to get to this next week, whether it's on |
|
Relevant PRs were merged to |
|
Just wanted to follow up on this. I recompiled from
And running the actual driver: Success! It looks like only the battery and status info is found (apcupsd gets the load status as well, so there may be room for improvement here). For kicks I tried Phoenixtec/Liebert as well, and got a bit more data out of it (MGE reported similar data): So it might be possible to get more data out of it, but I don't know enough about NUT to interpret the logs fully. Let me know if you want some more data, but otherwise the work you did seems to work like a charm -- thank you! |
|
Thanks! The With |
|
I am in the US, so 60Hz should be correct. The output voltage at zero is incorrect, I think (unless it's off by some decimals and its rounding down) as the machine I'm typing this on is on the UPS. Unless that's for battery output? The actual output load/current power draw should be around 6% of the unit's max power, looking at the UPS's display. |
|
I was able to get the below with this change. I was very hacky with diff --git a/drivers/belkin-hid.c b/drivers/belkin-hid.c
index 686dc9261..21f3c9729 100644
--- a/drivers/belkin-hid.c
+++ b/drivers/belkin-hid.c
@@ -183,7 +183,11 @@ static const char *liebert_config_voltage_fun(double value)
static const char *liebert_line_voltage_fun(double value)
{
if( value < 1 ) {
- if( fabs(value - 1e-7) < 1e-9 ) {
+ if( fabs(value - 1e-3) < 1e-3 ) {
+ liebert_line_voltage_mult = 1e5;
+ upsdebugx(2, "Input/OutputVoltage = %g -> assuming correction factor = %g",
+ value, liebert_line_voltage_mult);
+ } else if( fabs(value - 1e-7) < 1e-9 ) {
liebert_line_voltage_mult = 1e7;
upsdebugx(2, "Input/OutputVoltage = %g -> assuming correction factor = %g",
value, liebert_line_voltage_mult);
@@ -480,6 +484,17 @@ static hid_info_t belkin_hid2nut[] = {
{ "battery.voltage", 0, 0, "UPS.PowerSummary.Voltage", NULL, "%s", 0, liebert_line_voltage_info },
{ "battery.voltage.nominal", 0, 0, "UPS.PowerSummary.ConfigVoltage", NULL, "%s", HU_FLAG_STATIC, liebert_config_voltage_info },
{ "ups.load", 0, 0, "UPS.Output.PercentLoad", NULL, "%.0f", 0, NULL },
+ /* Liebert PSI5 */
+ { "input.voltage.nominal", 0, 0, "UPS.Flow.ConfigVoltage", NULL, "%.0f", 0, NULL },
+ { "input.frequency", 0, 0, "UPS.PowerConverter.Input.Frequency", NULL, "%s", 0, divide_by_100_conversion },
+ { "input.voltage", 0, 0, "UPS.PowerConverter.Input.Voltage", NULL, "%s", 0, liebert_line_voltage_info },
+ { "output.voltage.nominal", 0, 0, "UPS.Flow.ConfigVoltage", NULL, "%.0f", 0, NULL },
+ { "output.frequency", 0, 0, "UPS.PowerConverter.Output.Frequency", NULL, "%s", 0, divide_by_100_conversion },
+ { "output.voltage", 0, 0, "UPS.PowerConverter.Output.Voltage", NULL, "%s", 0, liebert_line_voltage_info },
+ { "ups.load", 0, 0, "UPS.OutletSystem.Outlet.PercentLoad", NULL, "%.0f", 0, NULL },
+ { "battery.voltage", 0, 0, "UPS.BatterySystem.Battery.Voltage", NULL, "%s", 0, liebert_line_voltage_info },
+ { "battery.voltage.nominal", 0, 0, "UPS.BatterySystem.Battery.ConfigVoltage", NULL, "%.0f", 0, NULL },
+ { "battery.capacity", 0, 0, "UPS.Flow.ConfigApparentPower", NULL, "%.0f", 0, NULL },
/* status */
{ "BOOL", 0, 0, "UPS.PowerSummary.Discharging", NULL, NULL, HU_FLAG_QUICK_POLL, liebert_discharging_info }, /* might not need to be liebert_* version */
{ "BOOL", 0, 0, "UPS.PowerSummary.Charging", NULL, NULL, HU_FLAG_QUICK_POLL, liebert_charging_info },
diff --git a/drivers/usbhid-ups.c b/drivers/usbhid-ups.c
index 4775d38fe..6481092c6 100644
--- a/drivers/usbhid-ups.c
+++ b/drivers/usbhid-ups.c
@@ -553,6 +553,22 @@ info_lkp_t divide_by_10_conversion[] = {
{ 0, NULL, divide_by_10_conversion_fun, NULL }
};
+/* returns statically allocated string - must not use it again before
+ done with result! */
+static const char *divide_by_100_conversion_fun(double value)
+{
+ static char buf[20];
+
+ snprintf(buf, sizeof(buf), "%0.1f", value * 0.01);
+
+ return buf;
+}
+
+/* FIXME? Do we need an inverse "nuf()" here? */
+info_lkp_t divide_by_100_conversion[] = {
+ { 0, NULL, divide_by_100_conversion_fun, NULL }
+};
+
/* returns statically allocated string - must not use it again before
done with result! */
static const char *kelvin_celsius_conversion_fun(double value)
diff --git a/drivers/usbhid-ups.h b/drivers/usbhid-ups.h
index 2e8a3fced..8bc1f94f2 100644
--- a/drivers/usbhid-ups.h
+++ b/drivers/usbhid-ups.h
@@ -114,6 +114,7 @@ extern info_lkp_t date_conversion[];
extern info_lkp_t hex_conversion[];
extern info_lkp_t stringid_conversion[];
extern info_lkp_t divide_by_10_conversion[];
+extern info_lkp_t divide_by_100_conversion[];
extern info_lkp_t kelvin_celsius_conversion[];
/* ---------------------------------------------------------------------- */
|
|
Thanks for the suggested fixes. Actually does not look as "bad" as you made believe :) One thing that looks like it needs more attention is the ordering of Also, for whatever reason the original code went with two orders of magnitude in the difference, e.g. I think this needs a bit more investigation in |
|
@jrjparks : would you please care to open a pull request with this change (and revise my earlier comment, if it does make sense or not)? |
|
Yeah I can make one this weekend |
This was referenced Mar 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Need help getting driver support for this unit:
Supposedly has kernel support: https://linux-hardware.org/?id=usb:10af-0002
The text was updated successfully, but these errors were encountered: