Re: [Nut-upsuser] LiebertPSP
On May 9, 2012, at 11:27 AM, Arnaud Quette wrote: this thread has just popped again, but on the Debian side this time: http://bugs.debian.org/671444 what's exactly the situation of fixes WRT issues? the last mail I have on this thread is attached below... Attached is a patch corresponding to the following branch: https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor At this point, it is probably safe to merge. It does not, however, change the subdriver to liebert-hid. -- Charles Lepple clepple@gmail LiebertPSP-2012-05-09.diff Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Jan 14, 2012, at 7:38 AM, Tim Gould wrote: Shutdown test was successful, including a slave client. They both shut down cleanly starting at 38% as configured below. Excellent! Only issue was that as it hit this threshold, it also reported Replace Battery (ups.status had RB) , and upsmon[3265]: UPS shed@localhost battery needs to be replaced appeared in syslog. We would need that portion of the debug log to confirm what is being sent back from the UPS, but if it works the rest of the time, it might just be a spurious battery status bit. I would think that wouldn't be updated by the UPS except after a deep discharge test, but it's hard to say. After the systems were powered on and mains restored, this went away. If ups.load is supposed to be Watts then according to my power meter it probably needs an extra zero at the end. ups.load should be percent rated capacity. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
Shutdown test was successful, including a slave client. They both shut down cleanly starting at 38% as configured below. Only issue was that as it hit this threshold, it also reported Replace Battery (ups.status had RB) , and upsmon[3265]: UPS shed@localhost battery needs to be replaced appeared in syslog. After the systems were powered on and mains restored, this went away. If ups.load is supposed to be Watts then according to my power meter it probably needs an extra zero at the end. Thanks, Tim. On 21/11/2011, at 3:19 , Charles Lepple wrote: On Nov 19, 2011, at 5:23 PM, Tim Gould wrote: On 17/11/2011, at 15:24 , Charles Lepple wrote: LiebertPSP-scalefactor-004a.patch battery.charge: 100 battery.charge.low: 38 battery.charge.warning: 38 battery.type: PbAc battery.voltage: 27.30 battery.voltage.nominal: 24.00 device.mfr: Emerson Network Power device.model: LiebertPSA device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.2-3318M driver.version.data: Belkin HID 0.15 driver.version.internal: 0.35 input.frequency: 50.0 input.voltage: 245.9 output.voltage: 246.0 ups.load: 3 ups.mfr: Emerson Network Power ups.model: LiebertPSA I'm wondering if some of the scale factor logic should be keyed off of the ups.model field. I just noticed that the original thread was about LiebertPSP, but yours says LiebertPSA. Anyway, I can fix the extra zeros in the voltage readings - we shouldn't pretend that we have that much precision :-) Next step would be to do a shutdown test. Since we're not sure that the low battery signal will work yet, I would suggest plugging the computers into another power source, and then plugging the UPS into a power strip or other switchable outlet. (Some UPSes do not accurately measure charge state when unplugged from the wall, since the ground floats in that instance. Power strips should not switch the ground wire.) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Nov 19, 2011, at 5:23 PM, Tim Gould wrote: On 17/11/2011, at 15:24 , Charles Lepple wrote: LiebertPSP-scalefactor-004a.patch battery.charge: 100 battery.charge.low: 38 battery.charge.warning: 38 battery.type: PbAc battery.voltage: 27.30 battery.voltage.nominal: 24.00 device.mfr: Emerson Network Power device.model: LiebertPSA device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.2-3318M driver.version.data: Belkin HID 0.15 driver.version.internal: 0.35 input.frequency: 50.0 input.voltage: 245.9 output.voltage: 246.0 ups.load: 3 ups.mfr: Emerson Network Power ups.model: LiebertPSA I'm wondering if some of the scale factor logic should be keyed off of the ups.model field. I just noticed that the original thread was about LiebertPSP, but yours says LiebertPSA. Anyway, I can fix the extra zeros in the voltage readings - we shouldn't pretend that we have that much precision :-) Next step would be to do a shutdown test. Since we're not sure that the low battery signal will work yet, I would suggest plugging the computers into another power source, and then plugging the UPS into a power strip or other switchable outlet. (Some UPSes do not accurately measure charge state when unplugged from the wall, since the ground floats in that instance. Power strips should not switch the ground wire.) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On 17/11/2011, at 15:24 , Charles Lepple wrote: LiebertPSP-scalefactor-004a.patch battery.charge: 100 battery.charge.low: 38 battery.charge.warning: 38 battery.type: PbAc battery.voltage: 27.30 battery.voltage.nominal: 24.00 device.mfr: Emerson Network Power device.model: LiebertPSA device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.2-3318M driver.version.data: Belkin HID 0.15 driver.version.internal: 0.35 input.frequency: 50.0 input.voltage: 245.9 output.voltage: 246.0 ups.load: 3 ups.mfr: Emerson Network Power ups.model: LiebertPSA ups.productid: 0001 ups.serial: ups.status: OL CHRG ups.vendorid: 10af liebert-004a.txt.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On 12/11/2011, at 0:48 , Charles Lepple wrote: LiebertPSP-scalefactor-003.patch Quite a lot better. Voltage perhaps needs tweaking? Thanks again. battery.charge.low: 38 battery.charge.warning: 38 battery.type: PbAc device.mfr: Emerson Network Power device.model: LiebertPSA device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.2-3318M driver.version.data: Belkin HID 0.14 driver.version.internal: 0.35 input.frequency: 50.0 input.voltage: 2425. output.voltage: 2440. output.voltage.nominal: 24.00 ups.mfr: Emerson Network Power ups.model: LiebertPSA ups.productid: 0001 ups.serial: ups.status: OL CHRG ups.vendorid: 10af liebert-003.txt.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Nov 16, 2011, at 2:58 PM, Tim Gould wrote: On 12/11/2011, at 0:48 , Charles Lepple wrote: LiebertPSP-scalefactor-003.patch Quite a lot better. Voltage perhaps needs tweaking? Thanks again. I think I got a few more variables, too. Can you let it run for about a minute? Right now, it's only showing the Quick update, and it would be interesting to see the Full update cycle. LiebertPSP-scalefactor-004.patch Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Nov 16, 2011, at 10:18 PM, Charles Lepple wrote: On Nov 16, 2011, at 2:58 PM, Tim Gould wrote: On 12/11/2011, at 0:48 , Charles Lepple wrote: LiebertPSP-scalefactor-003.patch Quite a lot better. Voltage perhaps needs tweaking? Thanks again. I think I got a few more variables, too. Can you let it run for about a minute? Right now, it's only showing the Quick update, and it would be interesting to see the Full update cycle. LiebertPSP-scalefactor-004.patch Ignore that patch, and use this one... at least it builds :-) LiebertPSP-scalefactor-004a.patch Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Nov 10, 2011, at 1:36 PM, Tim Gould wrote: Sorry for the extended delay replying. Some improvement: battery.charge.low: 38 battery.charge.warning: 38 battery.type: PbAc device.mfr: Emerson Network Power device.model: LiebertPSA device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.2-3316M driver.version.data: Belkin HID 0.13 driver.version.internal: 0.35 output.voltage.nominal: 24.00 ups.mfr: Emerson Network Power ups.model: LiebertPSA ups.productid: 0001 ups.serial: ups.status: OB ups.vendorid: 10af Ah, I left out PresentStatus in some of the voltage and status paths. The attached patch should add those, and frequency. (again, versus SVN trunk - you can use svn revert to get your tree back to the SVN state before applying the patch.) Also available as commit 61986b7043 on GitHub: https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor LiebertPSP-scalefactor-003.patch Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On 10/10/2011, at 23:20 , Charles Lepple wrote: On Oct 1, 2011, at 6:28 PM, Charles Lepple wrote: On Sep 30, 2011, at 5:51 PM, Tim Gould wrote: ups.status: ALARM OB LB RB It appears that my trick for matching the 1e-7 didn't work because that structure only stores integers, not floating point numbers. Oops. Arnaud: since this scaling issue has come up before, should we look at some sort of generic scale correction system at another layer in usbhid-ups? Unfortunately, I don't have time for a generic fix at the moment, but I figure something is better than nothing. Here's another stab at correcting the ups.status output. Also available via GitHub (commit 48b47b6). The patch is against the SVN trunk. LiebertPSP-scalefactor-002.patch Sorry for the extended delay replying. Some improvement: battery.charge.low: 38 battery.charge.warning: 38 battery.type: PbAc device.mfr: Emerson Network Power device.model: LiebertPSA device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.2-3316M driver.version.data: Belkin HID 0.13 driver.version.internal: 0.35 output.voltage.nominal: 24.00 ups.mfr: Emerson Network Power ups.model: LiebertPSA ups.productid: 0001 ups.serial: ups.status: OB ups.vendorid: 10af -DDD output attached. Thanks, Tim. liebert-002.txt.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Oct 1, 2011, at 6:28 PM, Charles Lepple wrote: On Sep 30, 2011, at 5:51 PM, Tim Gould wrote: ups.status: ALARM OB LB RB It appears that my trick for matching the 1e-7 didn't work because that structure only stores integers, not floating point numbers. Oops. Arnaud: since this scaling issue has come up before, should we look at some sort of generic scale correction system at another layer in usbhid-ups? Unfortunately, I don't have time for a generic fix at the moment, but I figure something is better than nothing. Here's another stab at correcting the ups.status output. Also available via GitHub (commit 48b47b6). The patch is against the SVN trunk. LiebertPSP-scalefactor-002.patch Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
2011/10/2 Charles Lepple clep...@gmail.com: On Sep 30, 2011, at 5:51 PM, Tim Gould wrote: ups.status: ALARM OB LB RB It appears that my trick for matching the 1e-7 didn't work because that structure only stores integers, not floating point numbers. Oops. Arnaud: since this scaling issue has come up before, should we look at some sort of generic scale correction system at another layer in usbhid-ups? that would probably be a better way. though we have to take a lot of care not to make regression here... cheers, Arnaud -- Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Sep 30, 2011, at 5:51 PM, Tim Gould wrote: ups.status: ALARM OB LB RB It appears that my trick for matching the 1e-7 didn't work because that structure only stores integers, not floating point numbers. Oops. Arnaud: since this scaling issue has come up before, should we look at some sort of generic scale correction system at another layer in usbhid-ups? - Charles ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
Tim, one slight ambiguity here: the most sane values for UPS.Output.Voltage and UPS.Input.Voltage would be 242.0 and 242.5 (from the data below), but UPS.PowerSummary.Voltage and UPS.PowerSummary.ConfigVoltage could refer to the line voltage or battery voltage. 0.413040 Report[get]: (3 bytes) = 1d 11 01 0.413075 Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x1d, Offset: 0, Size: 16, Value: 2.73e-06 0.417039 Report[get]: (3 bytes) = 1f 18 00 0.417063 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x1f, Offset: 0, Size: 16, Value: 2.4e-07 [...] 0.425040 Report[get]: (3 bytes) = 2b 74 09 0.425079 Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x2b, Offset: 0, Size: 16, Value: 2.42e-05 0.429059 Report[get]: (2 bytes) = 2c 01 0.429111 Path: UPS.Output.PercentLoad, Type: Feature, ReportID: 0x2c, Offset: 0, Size: 8, Value: 1 0.433037 Report[get]: (3 bytes) = 20 79 09 0.433063 Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x20, Offset: 0, Size: 16, Value: 2.425e-05 0.437037 Report[get]: (3 bytes) = 38 f4 01 0.437063 Path: UPS.Input.Frequency, Type: Feature, ReportID: 0x38, Offset: 0, Size: 16, Value: 500 Do you have access to a box that can run the manufacturer-provided software for this UPS? It should have a list of measured values, and based on the labels, we can figure out what they are referring to. The problem is that if we multiply everything by 1e7, the ConfigVoltage would be 2.4V. Also, the frequency seems to be high by a factor of 10. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
fatal: https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor/info/refs not found: did you run git update-server-info on the server? Using the patch gets me: battery.charge.low: 38 battery.charge.warning: 38 battery.type: PbAc device.mfr: Emerson Network Power device.model: LiebertPSA device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.2-3254M driver.version.data: Belkin HID 0.13 driver.version.internal: 0.35 ups.alarm: Replace battery! ups.mfr: Emerson Network Power ups.model: LiebertPSA ups.productid: 0001 ups.serial: ups.status: ALARM OB LB RB ups.vendorid: 10af I've attached -DDD output. Thanks, Tim. On 28/09/2011, at 22:53 , Charles Lepple wrote: On Sep 27, 2011, at 3:45 PM, Tim Gould wrote: I'll quite happily experiment with this - however if you could give me a short-cut to the relevant part of the code that would be appreciated as no doubt you are way more familiar with it than me. This turned out to be a little more complicated than I thought (I am only vaguely familiar with this code). The attached patch should cover some of the ups.status flags. Can you apply it, and run the driver with -DDD again? I also pushed it to GitHub, so if you want to check out the git-LiebertPSP-scalefactor branch and build from there, that will make future updates easier. https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor I need to look through the code a little more to make sure that we can read the ConfigVoltage before the other values are parsed. If not, there might be a short time at driver startup when the returned values are still uncorrected. (This would have been a lot easier if the different Liebert units had different USB product IDs... see drivers/tripplite-hid.c and search for tripplite_battvolt_fun for the sort of correction we need to do.) LiebertPSP-scalefactor-001.patch liebert-001.txt.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Sep 30, 2011, at 5:51 PM, Tim Gould wrote: fatal: https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor/info/refs not found: did you run git update-server-info on the server? That URL is for their HTML-based Git browser URL - I should have been clearer. I think you would run git clone https://clep...@github.com/clepple/nut.git then check out the git-LiebertPSP-scalefactor branch. BTW, I took that opportunity to rebase my branch, so if anyone else had cloned it before, the history is slightly different. I'll check the rest of the log later. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Sep 27, 2011, at 3:45 PM, Tim Gould wrote: I'll quite happily experiment with this - however if you could give me a short-cut to the relevant part of the code that would be appreciated as no doubt you are way more familiar with it than me. This turned out to be a little more complicated than I thought (I am only vaguely familiar with this code). The attached patch should cover some of the ups.status flags. Can you apply it, and run the driver with -DDD again? I also pushed it to GitHub, so if you want to check out the git-LiebertPSP-scalefactor branch and build from there, that will make future updates easier. https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor I need to look through the code a little more to make sure that we can read the ConfigVoltage before the other values are parsed. If not, there might be a short time at driver startup when the returned values are still uncorrected. (This would have been a lot easier if the different Liebert units had different USB product IDs... see drivers/ tripplite-hid.c and search for tripplite_battvolt_fun for the sort of correction we need to do.) LiebertPSP-scalefactor-001.patch Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
I'll quite happily experiment with this - however if you could give me a short-cut to the relevant part of the code that would be appreciated as no doubt you are way more familiar with it than me. Thanks, Tim. On 25/09/2011, at 7:29 , Charles Lepple wrote: On Sat, Sep 24, 2011 at 5:00 PM, Tim Gould tgo...@reverb.com.au wrote: -DDD output attached. Given that the ConfigVoltage should not change for a given UPS, this should be useful: 0.413040Report[get]: (3 bytes) = 1d 11 01 0.413075Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x1d, Offset: 0, Size: 16, Value: 2.73e-06 0.417039Report[get]: (3 bytes) = 1f 18 00 0.417063Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x1f, Offset: 0, Size: 16, Value: 2.4e-07 0.421044Report[get]: (2 bytes) = 07 0d 0.421080Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, ReportID: 0x07, Offset: 0, Size: 1, Value: 1e-07 0.421096Report[buf]: (2 bytes) = 07 0d If you multiply those values by 1e7, they should all be right. It looks like a misplaced exponent in the HID descriptor. -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
Apologies for resurrecting an old thread and likely poor formatting - I wasn't subscribed to the list at the time and have copied it out of the archives (http://lists.alioth.debian.org/pipermail/nut-upsuser/2010-July/006104.html). I've been unable to locate any further progress on this UPS (Liebert 10af:0001) - a thread from 2009 (http://lists.alioth.debian.org/pipermail/nut-upsdev/2009-November/004252.html) seemed to work for a Liebert PSA 650 model from then, but this 2010 thread seems to have unearthed an incompatible model - I've just purchased two Liebert PSA 1500 which exhibit exactly the same issues as below. I've put some output inline. I've checked out trunk and there seems to be no progress there. I'm happy to help debugging the driver, is there still some way we can progress this? All I get from upsc is: battery.charge.low: 38 battery.charge.warning: 38 battery.type: PbAc device.mfr: Emerson Network Power device.model: LiebertPSA device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.2-3254 driver.version.data: Belkin HID 0.12 driver.version.internal: 0.35 ups.mfr: Emerson Network Power ups.model: LiebertPSA ups.productid: 0001 ups.serial: ups.status: OB ups.vendorid: 10af Many thanks, Tim. Tue Jul 13 19:54:03 UTC 2010 Citeren Michelle Wright michelle.wright op gmail.com: $ sudo /lib/nut/usbhid-ups -DDD -a maxfun Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 [...] 0.341940 Report[get]: (3 bytes) = 1d 8b 00 0.341960 Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x1d, Offset: 0, Size: 16, Value: 0.01 The UPS is reporting a battery voltage of 1 uV here, most likely because Liebert got the exponent of this value wrong. I assume they meant something like 13.9 V, since 00 8B (hex) equals 139 (decimal). We can fix this though, but this will require a dedicated sub driver. I get: 0.413899Report[get]: (3 bytes) = 1d 08 01 0.413920Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x1d, Offset: 0, Size: 16, Value: 0.03 0.345939 Report[get]: (3 bytes) = 1f 0c 00 0.345956 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x1f, Offset: 0, Size: 16, Value: 0.00 Same here. The nominal battery voltage is probably 12 V, but what is reported is 0.12 uV, since 00 0C (hex) equals 12 (decimal). Can be fixed too. 0.417897Report[get]: (3 bytes) = 1f 18 00 0.417916Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x1f, Offset: 0, Size: 16, Value: 0.00 0.350081 Report[buf]: (2 bytes) = 07 0d 0.350095 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 0.350106 Report[buf]: (2 bytes) = 07 0d 0.350120 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 Although I didn't expect otherwise, the UPS is reporting that AC is not present (that's why you see NUT reporting OB instead of OL). Try if these value change to '1.00' if you unplug the mains. I tried this - unfortunately no they do not. I get this with power disconnected: 0.422018 Report[buf]: (2 bytes) = 07 0d 0.422034 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 0.422046 Report[buf]: (2 bytes) = 07 0d 0.422061 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 With the upsd and upsmon running, I get a console message that I'm on battery which stays that way regardless of whether the AC is connected or not. In that case Liebert seems to report the status reversed from what is specified in the HID PDC specifications (which doesn't surprise me at all, given the broken battery voltage reporting). 0.350131 Report[buf]: (2 bytes) = 07 0d 0.350145 Path: UPS.PowerSummary.PresentStatus.BatteryPresent, Type: Feature, ReportID: 0x07, Offset: 3, Size: 1, Value: 0.00 0.350156 Report[buf]: (2 bytes) = 07 0d 0.350170 Path: UPS.PowerSummary.PresentStatus.BatteryPresent, Type: Input, ReportID: 0x07, Offset: 3, Size: 1, Value: 0.00 I assume the UPS contains a battery and that this value is reversed as well. 0.422073 Report[buf]: (2 bytes) = 07 0d 0.422088 Path: UPS.PowerSummary.PresentStatus.BatteryPresent, Type: Feature, ReportID: 0x07, Offset: 3, Size: 1, Value: 0.00 0.422101 Report[buf]: (2 bytes) = 07 0d 0.422116 Path: UPS.PowerSummary.PresentStatus.BatteryPresent, Type: Input, ReportID: 0x07, Offset: 3, Size: 1, Value: 0.00 My UPS contains a battery, yes :) 0.353937 Report[get]: (3 bytes) = 2b
Re: [Nut-upsuser] LiebertPSP
On Sep 24, 2011, at 5:48 AM, Tim Gould wrote: Apologies for resurrecting an old thread and likely poor formatting - I wasn't subscribed to the list at the time and have copied it out of the archives (http://lists.alioth.debian.org/pipermail/nut-upsuser/2010-July/006104.html ). No problem. Thanks for linking to the old threads. I've checked out trunk and there seems to be no progress there. I'm happy to help debugging the driver, is there still some way we can progress this? One difference that isn't as obvious in the latest code is in the debug output. We changed the Value: format from fixed-width to automatic decimal/scientific notation, so we should be able to see if the ACPresent values are truly 0, or just 1e-7 (which would have looked like 0.00). The fun part will be finding a heuristic that determines whether the exponents are wrong. Unfortunately, the two Liebert models have the same USB product/vendor ID pair. Tue Jul 13 19:54:03 UTC 2010 Citeren Michelle Wright michelle.wright op gmail.com: $ sudo /lib/nut/usbhid-ups -DDD -a maxfun Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 Can you stop the original driver, and re-run it as indicated above? Debug level 3 (as shown) should be sufficient. You can add something like | tee /tmp/liebert-`date -I`.txt to log to both the screen and a log file. After the driver gets into the polling loop, press Ctrl-C. Please gzip the log and attach it to your reply. [...] 0.350081 Report[buf]: (2 bytes) = 07 0d 0.350095 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 0.350106 Report[buf]: (2 bytes) = 07 0d 0.350120 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 Although I didn't expect otherwise, the UPS is reporting that AC is not present (that's why you see NUT reporting OB instead of OL). Try if these value change to '1.00' if you unplug the mains. I tried this - unfortunately no they do not. I get this with power disconnected: 0.422018 Report[buf]: (2 bytes) = 07 0d 0.422034 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 0.422046 Report[buf]: (2 bytes) = 07 0d 0.422061 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 With the upsd and upsmon running, I get a console message that I'm on battery which stays that way regardless of whether the AC is connected or not. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
-DDD output attached. On 25/09/2011, at 1:00 , Charles Lepple wrote: Tue Jul 13 19:54:03 UTC 2010 Citeren Michelle Wright michelle.wright op gmail.com: $ sudo /lib/nut/usbhid-ups -DDD -a maxfun Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 Can you stop the original driver, and re-run it as indicated above? Debug level 3 (as shown) should be sufficient. You can add something like | tee /tmp/liebert-`date -I`.txt to log to both the screen and a log file. After the driver gets into the polling loop, press Ctrl-C. Please gzip the log and attach it to your reply. liebert.txt.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
On Sat, Sep 24, 2011 at 5:00 PM, Tim Gould tgo...@reverb.com.au wrote: -DDD output attached. Given that the ConfigVoltage should not change for a given UPS, this should be useful: 0.413040 Report[get]: (3 bytes) = 1d 11 01 0.413075 Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x1d, Offset: 0, Size: 16, Value: 2.73e-06 0.417039 Report[get]: (3 bytes) = 1f 18 00 0.417063 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x1f, Offset: 0, Size: 16, Value: 2.4e-07 0.421044 Report[get]: (2 bytes) = 07 0d 0.421080 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, ReportID: 0x07, Offset: 0, Size: 1, Value: 1e-07 0.421096 Report[buf]: (2 bytes) = 07 0d If you multiply those values by 1e7, they should all be right. It looks like a misplaced exponent in the HID descriptor. -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] LiebertPSP
Citeren Michelle Wright michelle.wri...@gmail.com: $ sudo /lib/nut/usbhid-ups -DDD -a maxfun Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 [...] 0.341940 Report[get]: (3 bytes) = 1d 8b 00 0.341960 Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x1d, Offset: 0, Size: 16, Value: 0.01 The UPS is reporting a battery voltage of 1 uV here, most likely because Liebert got the exponent of this value wrong. I assume they meant something like 13.9 V, since 00 8B (hex) equals 139 (decimal). We can fix this though, but this will require a dedicated subdriver. 0.345939 Report[get]: (3 bytes) = 1f 0c 00 0.345956 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x1f, Offset: 0, Size: 16, Value: 0.00 Same here. The nominal battery voltage is probably 12 V, but what is reported is 0.12 uV, since 00 0C (hex) equals 12 (decimal). Can be fixed too. 0.350081 Report[buf]: (2 bytes) = 07 0d 0.350095 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 0.350106 Report[buf]: (2 bytes) = 07 0d 0.350120 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x07, Offset: 2, Size: 1, Value: 0.00 Although I didn't expect otherwise, the UPS is reporting that AC is not present (that's why you see NUT reporting OB instead of OL). Try if these value change to '1.00' if you unplug the mains. In that case Liebert seems to report the status reversed from what is specified in the HID PDC specifications (which doesn't surprise me at all, given the broken battery voltage reporting). 0.350131 Report[buf]: (2 bytes) = 07 0d 0.350145 Path: UPS.PowerSummary.PresentStatus.BatteryPresent, Type: Feature, ReportID: 0x07, Offset: 3, Size: 1, Value: 0.00 0.350156 Report[buf]: (2 bytes) = 07 0d 0.350170 Path: UPS.PowerSummary.PresentStatus.BatteryPresent, Type: Input, ReportID: 0x07, Offset: 3, Size: 1, Value: 0.00 I assume the UPS contains a battery and that this value is reversed as well. 0.353937 Report[get]: (3 bytes) = 2b 63 09 0.353954 Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x2b, Offset: 0, Size: 16, Value: 0.24 Most likely the same problem as for the battery voltage. It looks more like the output voltage should be 240.3 V, instead of 24.03 uV. 0.361937 Report[get]: (3 bytes) = 20 68 09 0.361954 Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x20, Offset: 0, Size: 16, Value: 0.24 Same here. Input voltage is probably 240.8 V instead of 24.08 uV. 0.365937 Report[get]: (3 bytes) = 38 f5 01 0.365955 Path: UPS.Input.Frequency, Type: Feature, ReportID: 0x38, Offset: 0, Size: 16, Value: 501.00 Something similar here too. The input frequency is probably 50.1 Hz, instead of 501 Hz. 0.630102 upsdrv_updateinfo... 0.881839 libusb_get_interrupt: Connection timed out 0.881854 Got 0 HID objects... 0.881863 Quick update... NUT attempts to read from the interrupt pipeline here, but at this time there are no messages queued. This is normal, nothing to worry about. The good news is that we can probably support this UPS (sort of), provided you're willing to help us finding and fixing all it's quirks. It will require checking out the development version from SVN and frequent compiling from sources. You'd also need to be able to take the UPS out of service from time to time for testing a new version of the driver. Let us know if you are interested in helping getting this device supported. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
