Wrong input voltage reported for APC Back-UPS XS 1400U #1189
Comments
|
Can you please check if it performs better with a build of recent NUT codebase, checked out from master, https://github.com/networkupstools/nut/tree/libusb-1.0 or https://github.com/networkupstools/nut/tree/libusb-1.0+0.1 branch? |
|
I am using a Raspberry Pi 1 for my UPS, compiling takes some time. Using the branch libusb-1.0 and building with and testing with input.voltage is still wrong (but different): Will try with the other branches tomorrow |
|
Same result with branch libusb-1.0+0.1 branch master is compiling now, will report this evening. |
|
OK tried master as well, but still the wrong input.voltage and input.voltage.nominal. Is there anything else I can do to help fix this? |
|
Same for my device Back-UPS XS 950U. I am living in Germany too with 230V. Any news on this issue? |
|
Unfortunately not. I had to switch back to apcupsd to make it work. My setup is now, that I have an old Raspberry Pi with apcupsd monitoring the UPS on the USB-port and provide the UPS info to the local networt. On other systems I use nut with the apcupsd-ups driver having the port pointing to the Pi. |
|
One more idea popped up like in other tickets: can you try following the
developer docs to try generating a usbhid-ups subdriver - there's a script
that effectively walks your device and generates a C file with mapping
table for whatever it finds.
Possibly your device serves the needed data in nodes not mapped (maybe also
scaled) into NUT names, standards are ambiguously implemented by many
market actors; then it would be a matter of adding the lines to your
originally used subdriver source (note: first hit in a walk wins), rebuild,
test - and if that helps - post a PR to update the subdriver.
…On Tue, Nov 23, 2021, 20:41 smainz ***@***.***> wrote:
OK tried *master* as well, but still the wrong input.voltage and
input.voltage.nominal.
Is there anything else I can do to help fix this?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1189 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFBZMDUIIAVF5SAKU5LUNPVAHANCNFSM5IG337SA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
@jimklimov I will try this weekend and scream back on you if I need more advice. Thanks for careing |
|
OK, no luck so far. I created the subdriver using the documented commands: Followed the instructions Placed my driver before the apc-hid already in usbhid-ups.c and rebuilt it. Unfortunally it segfaults when executing What else can I do? Files attached. |
|
Can you see if you can get a meaningful reason for that segfault? maybe
some null pointer or a buffer overflow (e.g. your HID custom name looks
long :))
Something like
gdb --args drivers/usbhid-ups -x ...
and when GDB starts, type "run", and when that fails - "bt" for backtrace.
You may need to embed this into the libtool shell script if
"drivers/usbhid-ups" is one (with binary in ".libs" subdir).
…On Sun, Feb 6, 2022, 17:47 smainz ***@***.***> wrote:
OK, no luck so far. I created the subdriver using the documented commands:
$ drivers/usbhid-ups -DD -u root -x explore -x vendorid=051D \
-x port=auto -s ups 2>&1 | tee apcxs1400.txt
$ cd drivers
$ ../scripts/subdriver/gen-usbhid-subdriver.sh < ../apcxs1400.txt
Followed the instructions
Please enter a name for this driver. Use only letters and numbers. Use
natural (upper- and lowercase) capitalization, e.g., 'Belkin', 'APC'.
Name of subdriver: APCXS1400
Creating apcxs1400-hid.h
Creating apcxs1400-hid.c
Done.
Do not forget to:
* add #include "apcxs1400-hid.h" to drivers/usbhid-ups.c,
* add &apcxs1400_subdriver to drivers/usbhid-ups.c:subdriver_list,
* add apcxs1400-hid.c to USBHID_UPS_SUBDRIVERS in drivers/Makefile.am
* add apcxs1400-hid.h to dist_noinst_HEADERS in drivers/Makefile.am
* "autoreconf" from the top level directory
Placed my driver before the apc-hid already in usbhid-ups.c
and rebuilt it.
Unfortunally it segfaults when executing
Network UPS Tools - Generic HID driver 0.45 (2.7.4-4536-gd46d5153)
USB communication driver (libusb 1.0) 0.42
0.000000 [D1] debug level is '2'
0.009538 [D2] Initializing an USB-connected UPS with library libusb-1.0.24 (API: 0x1000108) (NUT subdriver name='USB communication driver (libusb 1.0)' ver='0.42')
0.013648 [D1] upsdrv_initups (non-SHUT)...
0.057151 [D2] Checking device 1 of 4 (051D/0002)
0.099389 [D2] - VendorID: 051d
0.103395 [D2] - ProductID: 0002
0.105010 [D2] - Manufacturer: American Power Conversion
0.106493 [D2] - Product: Back-UPS XS 1400U FW:926.T1 .I USB FW:T1
0.107006 [D2] - Serial Number: 3B1527X15613
0.107381 [D2] - Bus: 001
0.107748 [D2] - Device: unknown
0.109048 [D2] - Device release number: 0106
0.109443 [D2] Trying to match device
0.110196 [D2] match_function_subdriver (non-SHUT mode): matching a device...
0.111621 [D2] Device matches
0.112020 [D2] Reading first configuration descriptor
0.113502 [D2] Claimed interface 0 successfully
0.116668 [D2] HID descriptor length 1028
0.298714 [D2] Report Descriptor size = 1028
0.299895 Using subdriver: APCXS1400 HID 0.1
Speicherzugriffsfehler
What else can I do?
Files attached.
apcxs1400.txt
<https://github.com/networkupstools/nut/files/8010613/apcxs1400.txt>
apcxs1400-hid.c.txt
<https://github.com/networkupstools/nut/files/8010615/apcxs1400-hid.c.txt>
—
Reply to this email directly, view it on GitHub
<#1189 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFGOHUOOB2T7I3TUO7TUZ2Q35ANCNFSM5IG337SA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Need more help: renamed apcxs1400 to xs, but no change Running on a Raspberry Pi (early model), on buster |
|
OK, found the reason for the segfault. The script creates incorect c code. instead of: it creates Note the missing last line. |
|
But it does not seem to be different from what the apc-hid subdriver does: apcupsd reports: Maybe LINEV is not equal to Input.Voltage? |
|
Maybe... did the generation script find some other mapping lines for
voltage that were not there in original APC subdriver?
Or maybe values are shifted by market (EU/US/...) based on some other
reading, there was recently a discussion of such possibility. Especially if
needing to fit high limits of 260-280V into a byte (ConfigVoltage is 8 bits
in your sample; others claim 16 bits).
…On Sun, Feb 6, 2022, 22:46 smainz ***@***.***> wrote:
But it does not seem to be different from what the apc-hid subdriver does:
64.798816 [D2] Path: UPS.Input.ConfigVoltage, Type: Feature, ReportID: 0x30, Offset: 0, Size: 8, Value: 140
64.808107 [D2] Path: UPS.Input.HighVoltageTransfer, Type: Feature, ReportID: 0x33, Offset: 0, Size: 16, Value: 280
64.814238 [D2] Path: UPS.Input.LowVoltageTransfer, Type: Feature, ReportID: 0x32, Offset: 0, Size: 16, Value: 155
64.819999 [D2] Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x31, Offset: 0, Size: 16, Value: 140
apcupsd reports:
LOTRANS : 155.0 Volts
HITRANS : 280.0 Volts
LINEV : 228.0 Volts
Maybe LINEV is not equal to Input.Voltage?
—
Reply to this email directly, view it on GitHub
<#1189 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFHSWJELTDONTB7TCL3UZ3TZ3ANCNFSM5IG337SA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
This is all the EXPLORE gave me, no additional voltage reading, nor a sign to indicate EU/US/... (I am in the EU). So no hint to a different Voltage definition, nor a value showing something to the 228V apcupsd gives me. In the subdrive i did not change anything, especially i did not remove the 'unmapped.' anywhere. See: Is this something I should have done? |
|
Just in case: the fix-up of faulty HID info was explored in PR #1245 adding a generic hook method that subdrivers may implement for known deficiencies as those surface... |
|
CC @nbriggs : Hi, maybe you can help make sense out of this? I also wonder what the Alas, I'm "just" a maintainer to help things roll along, but not a deep expert in all the nuances... |
|
Hi @jimklimov -- I'll have a look over the next few days. |
|
Tell me, what I can do to help, but it es gtting close to my skill level. I do not know the details of how USB works, not am I into the internals of nut. Compiling and running stuff is ok and some C skills have resist the ravages of time. |
|
Hi @smainz -- nothing specific to do yet, but I expect that seeing the results of running some NUT programs in debug mode will be the most useful once I've had a chance to look at the code. I have a "American Power Conversion Back-UPS RS 1500G", but I'm in the US and that unit is 120VAC only (you'd think that auto voltage sensing would make sense, but I guess the market is large enough they can save cost by selling models specific to the input voltage) |
|
The "EXPLORE" driver doesn't know about any of the vendor-specific usages (as defined for the APC units in in the explore output dump, where ff860060 actually corresponds to "APCStatusFlag" in the original dump that was submitted: |
|
... so the newly generated sub-driver will only make things worse here, and any info that you learn about undecoded fields can be merged back into the apc-specific tables in apc-hid.c -- however, I don't see a path to finding any authoritative documentation unless Schneider Electric/APC is willing to give it up, and I am not hopeful about that. |
|
This is so crazy, apcupsd from 2016 can read the data and nut can not. I am not aware where the guys from apcupsd got their specs from and am too dumb to find it within a few minutes in their code/docs. Is this something which rings a bell on you from src/drivers/usb/usb.c: from example/hid-ups_info.c: |
|
@smainz & @jimklimov -- I've just started to look at the apcupsd code. Regarding why the apcupsd can report the voltage and NUT cannot: I think what I'm seeing is that the apcupsd code (mostly?) ignores the logical minimum/logical maximum information in the report descriptor. So, I've decoded the report descriptor that the UPS sent, and this is the relevant portion of it: Notice for config voltage (report 0x30) and voltage (report 0x31) it has set up the logical min/max range as 75-140. Given that you're operating in a nominal 220-240V region (plus the transfer voltage ranges) that makes no sense. But, since NUT honours the logical min/max values, it will clamp the reported values at 140 if they exceed that. So... the fix_report_descriptor method should be able to help here... I'll look at what this will take. |
|
@smainz -- If your UPS is still under warranty (or you have any kind of support contract) you might consider opening a case with APC/Schneider Electric to get them to fix their firmware so that it reports the "correct" logical range for the input and configured input voltage in the HID report descriptor. I suspect they just forgot to update those limits when they produced the unit for the European market. If people complain, there's a small chance they might fix it. |
|
@smainz Could you try the branch 1189_APC_UPS_wrong_minmax_input_voltage -- if you don't want to recompile the whole thing, copy |
My UPS is out of warranty and I do not have a support contract. In the net I have found a few complaints about the same problem on the same model. Maybe APC has changed the firmware in the mean time. |
|
@andbez, @smainz -- sorry, I messed up and compiled the master branch instead of the fixed branch. New SHA256: % openssl sha256 usbhid-ups |
|
@nbriggs @smainz Tried with the new version and now the Input.Voltage-Value looks better: |
|
Looks promising, thanks @nbriggs for the proposed fix and @andbez & @smainz for testing on short notice!
It's actually "worse" than that: this release date is from "drafting a release" on github, which is independent of the release tag... would be 6 years since that point, soon :( So tying up loose threads in order for 2.7.5 to not be an epic to talk about for eons ;) |
jimklimov
added
the
USB-HID encoding/LogMin/LogMax
I see what you mean, but the longer it is since the last release, the sooner we will see the next one :-) Thank you for your effort. |
|
@flashydave -- quick question if you don't mind: I'm using your fix_report_desc framework to fix the problem smainz reported here for an APC unit, and I noticed that in the CPS code you chose to implement |
|
I agree it is similar to those functions.
I see no reason not to relocate it if has wider use with other UPS
models. I was simply trying to keep the fix local to the driver it
related to and the function itself fell out of the need to call it multiple times. I would have preferred one of the existing funxtions but there were complications over access to parameters at the point where it was called and there were speed/performance issues to consider as mentioned in the HIDDumpTree() comments.
…On 11:39, Fri 11 Feb 22, Nick Briggs wrote:
@flashydave -- quick question if you don't mind: I'm using your fix_report_desc framework to fix the problem smainz reported here for an APC unit, and I noticed that in the CPS code you chose to implement `FindReport()` to find the entry by ReportID and node. I'm wondering (a) if that should be in hidparser.c, along with `FindObject_with_path()` and `FindObject_with_ID()`, and (b) what was the reasoning behind your locating the entry to be fixed based on the ID+node rather than either of the existing methods?
--
Reply to this email directly or view it on GitHub:
#1189 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
@flashydave -- OK. Re. speed & performance: The comments in For the APC case I also need to look at the high voltage transfer threshold, but initially chose to use vs. -- I checked the report descriptor to see that for the APC it sends report ID 0x33 (vs. 16 for your CPS) at an offset of 0 and as a FEATURE. I think I prefer your approach to locating the specific item, but I was a little surprised to find that the headers didn't already have a standard set of definitions for the usage tables based on the USB-IF spec (pdcv11.pdf -- "Universal Serial Bus Usage Tables for HID Power Devices"). There's the array of string to code ( |
|
Agree with your point in general re performance and accessing hardware
but felt also the computational (and programming) effort constructing path objects wasnt worth it. In my case numerics were sufficient to detect the buggy situation reasonably reliably and apply the fix.
I also was surprised a full set of magic numbers had not been defined
but I guess it starts to get complicated if you have to deal with vendor
unique numbers too should those be needed as they might not be
interpreted the same
across manufacturers. I just added the ones I needed. I cant see any
reason not to add more if you need them..
…On 14:13, Fri 11 Feb 22, Nick Briggs wrote:
@flashydave -- OK.
Re. speed & performance: The comments in `HIDDumpTree()` don't apply to our situation -- `HIDDumpTree()` is going to fetch the value from the UPS for each item in the tree, which as they note might take a non-trivial amount of time (especially if the UPS doesn't respond), while we are only inspecting the descriptor array itself and never fetch anything from the UPS, so both `FindReport()` and `FindObject_with_ID()` are O(n) (for n = number of descriptors) and run at memory access speed, once, at startup.
For the APC case I also need to look at the high voltage transfer threshold, but initially chose to use
```
pData=FindObject_with_ID(pDesc_arg, 0x33, 0, ITEM_FEATURE)
```
vs.
```
pData=FindReport(pDesc_arg, 16, (PAGE_POWER_DEVICE<<16)+USAGE_HIGHVOLTAGETRANSFER)
```
-- I checked the report descriptor to see that for the APC it sends report ID 0x33 (vs. 16 for your CPS) at an offset of 0 and as a FEATURE. I think I prefer your approach to locating the specific item, but I was a little surprised to find that the headers didn't already have a standard set of definitions for the usage tables based on the USB-IF spec (pdcv11.pdf -- "Universal Serial Bus Usage Tables for HID Power Devices"). There's the array of string to code (`hid_usage_lkp`) defined in libhid.c, but it just uses the magic numbers rather than constructing them from individual defines (or enum elements -- style choice!) -- looking at what includes what, perhaps hidparser.h (where you put the USAGE_HIGHVOLTAGETRANSFER) would be the right place to put a complete set?
--
Reply to this email directly or view it on GitHub:
#1189 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
@flashydave, @jimklimov -- I have a NUT style question: I've taken the to produce defines for the usages that look like ... since the power device and battery system pages have conflicting field names we need to include the I'm happy either way but it's not my codebase so I'm asking... |
|
I prefer the latter style so that the _ acts more like a heirarchical
separator but I'm sure someone else could suggest an alternative rule.
Its not my code either so I can't say definitively!
…On 11:57, Sat 12 Feb 22, Nick Briggs wrote:
@flashydave, @jimklimov -- I have a NUT style question: I've taken the `rd.conf` file from github.com:abend0c1/hidrdd.git (actually, a very slightly updated version of that for which I've submitted a PR), which incorporates the complete USB-IF usage definitions for power device and battery system pages and processed it with
```
grep -e ^0084 -e ^0085 rd.conf | sed 's/,.*$//;s/ *$//' | sed 's/ /_/g;s/_/ /' | tr '[:lower:]' '[:upper:]' | sed 's/\(0085.... \)/\1USAGE_BAT_/;s/\(0084.... \)/\1USAGE_POW_/;s/\([A-Z_]*\)_PAGE/PAGE_\1/' | awk '{print "#define "$2" 0x"$1}'
```
to produce defines for the usages that look like
```
#define PAGE_POWER_DEVICE 0x0084
#define USAGE_POW_UNDEFINED 0x00840000
#define USAGE_POW_I_NAME 0x00840001
#define USAGE_POW_PRESENT_STATUS 0x00840002
[...]
#define PAGE_BATTERY_SYSTEM 0x0085
#define USAGE_BAT_UNDEFINED 0x00850000
#define USAGE_BAT_SMB_BATTERY_MODE 0x00850001
#define USAGE_BAT_SMB_BATTERY_STATUS 0x00850002
#define USAGE_BAT_SMB_ALARM_WARNING 0x00850003
[...]
```
... since the power device and battery system pages have conflicting field names we need to include the `POW_` or `BAT_` to differentiate, but the real style question is: underscores in the variable part of the field names or not? -- that is `USAGE_BAT_SMB_BATTERY_MODE` or `USAGE_BAT_SMBBATTERYMODE`?
I'm happy either way but it's not my codebase so I'm asking...
--
Reply to this email directly or view it on GitHub:
#1189 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
I like underscores as more readable, especially where we can't have CamelCase etc. Maybe follow precedent of nut-ddl structured names with two underscores between tokens? like USAGE__BAT__SMB_BATTERY_STATUS ? |
|
Thats starting to get messy. Not only does it become irksome to type
(especially for those using command line type editors) and reduces the
amount of code that can seen on any guven size of screen. For example
my recent contributions were all developed using ssh from my phone!
…On 02:51, Sun 13 Feb 22, Jim Klimov wrote:
I like underscores as more readable, especially where we can't have CamelCase etc. Maybe follow precedent of nut-ddl structured names with two underscores between tokens? like USAGE__BAT__SMB_BATTERY_STATUS ?
--
Reply to this email directly or view it on GitHub:
#1189 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
Well then, given a small dictionary of prefixes to juggle, single
underscores can be good and not ambiguous... at least, it's sure better to
get fixes delivered than to bikeshed over this :-)
…On Sun, Feb 13, 2022, 12:17 flashydave ***@***.***> wrote:
Thats starting to get messy. Not only does it become irksome to type
(especially for those using command line type editors) and reduces the
amount of code that can seen on any guven size of screen. For example
my recent contributions were all developed using ssh from my phone!
On 02:51, Sun 13 Feb 22, Jim Klimov wrote:
> I like underscores as more readable, especially where we can't have
CamelCase etc. Maybe follow precedent of nut-ddl structured names with two
underscores between tokens? like USAGE__BAT__SMB_BATTERY_STATUS ?
>
> --
> Reply to this email directly or view it on GitHub:
>
#1189 (comment)
> You are receiving this because you were mentioned.
>
> Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub
<#1189 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFCAVNIQKN53KKSAJSDU26HNRANCNFSM5IG337SA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I agree!
…On 11:43, Sun 13 Feb 22, Jim Klimov wrote:
Well then, given a small dictionary of prefixes to juggle, single
underscores can be good and not ambiguous... at least, it's sure better to
get fixes delivered than to bikeshed over this :-)
On Sun, Feb 13, 2022, 12:17 flashydave ***@***.***> wrote:
> Thats starting to get messy. Not only does it become irksome to type
> (especially for those using command line type editors) and reduces the
> amount of code that can seen on any guven size of screen. For example
> my recent contributions were all developed using ssh from my phone!
>
> On 02:51, Sun 13 Feb 22, Jim Klimov wrote:
> > I like underscores as more readable, especially where we can't have
> CamelCase etc. Maybe follow precedent of nut-ddl structured names with two
> underscores between tokens? like USAGE__BAT__SMB_BATTERY_STATUS ?
> >
> > --
> > Reply to this email directly or view it on GitHub:
> >
> #1189 (comment)
> > You are receiving this because you were mentioned.
> >
> > Message ID: ***@***.***>
>
> —
> Reply to this email directly, view it on GitHub
> <#1189 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAMPTFCAVNIQKN53KKSAJSDU26HNRANCNFSM5IG337SA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
--
Reply to this email directly or view it on GitHub:
#1189 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
OK... I've (force) pushed a revised version of 1189_APC_UPS_wrong_minmax_input_voltage with all the changes and stored a new version of usbhid-ups for x86_64 (SHA256(usbhid-ups)= 17d3420fc892f1cd8fb3d5e4c3b766708890725b76dbfe90ea8a6ddaaa27d495) on http://nhbriggs.users.sonic.net/usbhid-ups if @smainz and/or @andbez want to re-test on their APC units. |
|
@nbriggs Is it enough for you when I run this commit on my Pi or do you need x86_64 too? The later means, i have to move cabinets. Pi is compiling now, you will have feedback later this evening. |
|
Here is: Looks good. Thank you |
|
Here is: ;-) root@omv:~# ./usbhid-ups -a ups -u root -DDD 2>&1 0.185032 Using subdriver: APC HID 0.97 0.329770 [D1] Path: UPS.Input.Voltage, Type: Fea ture, ReportID: 0x31, Offset: 0, Size: 16, Value: 236 @nbriggs Thank you for providing the binary file. |
|
Thanks @smainz and @andbez for testing. I re-read my code and realized there's one more minor change to make having to do with when it reports ("Report Descriptor Fixed") that it did (or did not) find the problem. That probably only requires someone visually inspect the change, though. Famous last words and all that... |
|
Updated again with bumped driver version number and check as mentioned above. |
|
Thanks all for reporting, fixing and testing! Will follow up on the posted PR :)
|
|
Do you need another test or do you trust in you famous last words? |
|
If you'd be happy to just eyeball the last change in source rather than build/test it that would be enough for me. Can't speak to anyone else's wishes. |
|
OK, checked it and it looks good. Did not check the constants though. |
|
@smainz -- thank you, though the code style is from @flashydave so thanks to him. |
I am trying to set up nut fpr my APC Back-UPS XS 1400U formerly used with apcupsd.
Got almost all working, but nut us reporting wrong input voltage:
These values are defiitly wrong:
I am in Germany and we have 230V. apcupsd reports the correct values.
OS: Raspbian GNU/Linux 10 (buster)
nut version 2.7.4 aken from the official raspbian repositories
Maybe this helps to analyze:
The text was updated successfully, but these errors were encountered: