Re: [Nut-upsuser] RE nut drivers
I've updated to 2.0.4 and changed driver to megatec. It is working too. Old info, showed by fentonups: battery.charge: 100.0 battery.voltage: 28.0 driver.name: fentonups driver.parameter.port: /dev/ttyS0 driver.version: 2.0.3 driver.version.internal: 1.22 input.frequency: 49.9 input.voltage: 221.0 output.voltage: 223.6 ups.load: 032 ups.mfr: FUDEN ups.model: Unknown S163-1000 ups.status: OL TRIM Now it is more verbose :) battery.charge: 100.0 battery.voltage: 28.00 battery.voltage.nominal: 24.0 driver.name: megatec driver.parameter.port: /dev/ttyS0 driver.version: 2.0.4 driver.version.internal: 1.4 input.frequency: 49.9 input.voltage: 219.3 input.voltage.fault: 140.0 input.voltage.maximum: 220.1 input.voltage.minimum: 218.6 output.voltage: 221.8 output.voltage.nominal: 230.0 ups.delay.shutdown: 2 ups.delay.start: 3 ups.load: 30.0 ups.mfr: FUDEN ups.model: S163-1000 9.02A ups.serial: unknown ups.status: OL BOOST ups.temperature: 38.8 It is PowerMan RealSmart 1000 model. I can also try to check PowerMan BackPro model (I have access to machine with it) if it really works with genericups. Arnaud Quette wrote: Hi Kjell, 2006/8/4, Kjell Claesson [EMAIL PROTECTED]: Hi, fre 2006-08-04 klockan 17:24 +0200 skrev Arnaud QUETTE: Hi Alexander, I've UPS named PowerMan RealSmart 1000, it is not listed in compatibility list. I found that it works with fentonups driver and have ups.model Unknown S163-1000. Ithink 1000 is from capacity - I've seen in Internet someone have RealSmart 800 identified S163-800. Also PowerMan have BackPro series - people write it works with genericups, type 4. thanks for these info. About fentonups, you should try the megatec driver, available in 2.0.4, as it will replace fentonups and a bunch of other drivers (get in touch with Carlos about that). @Carlos and Kjell: can you check to update drivers.list as per these info? The info is in the driver.list. thanks for your quick action. Maybe it would be changed to megatec by Carlos. let's wait for feedback from Alexander on how his dev behave with megatec. Arnaud ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] RE nut drivers
Kjell Claesson wrote: Thanks for the info. I change the driver to megatec for the RealSmart 1000 and 800 in the driver.list. Hi. I've checked PowerMan BackPro Plus 1000 with genericups type=4. OL, OB and LB are showed correctly. SD I have not tested. -- Alexander ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Tripp Lite Smart1000LCD driver problem
Peter Selinger wrote: Charles Lepple wrote: On 7/24/06, Phil DeBoest [EMAIL PROTECTED] wrote: HID descriptor retrieved (Reportlen = 459) Unable to get Report descriptor (-75) Phil, This looks a lot like the problem mentioned here: http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-November/000318.html Peter, Do you know where the problem turned out to be in the aforementioned message? If it is a wrong value for desc-wDescriptorLength, we could start a quirks table, and override the descriptor length for that particular UPS (and for some of the APCs, if we are still seeing that problem). -- - Charles Lepple Indeed, the cause of this bug was isolated here: http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-February/000705.html As it turns out, there are two ways of retrieving report 0x21 (the HID descriptor) from the UPS: either by requesting report 0x21 directly, or by requesting report 0x02, which will have a copy of report 0x21 tucked onto its end. Normally, the two ways are supposed to give the same result. However, on some buggy UPS's (notably Tripp Lite, and some APC), only the second method works. lsusb always uses the second method, whereas NUT has always used the first. I have just committed some changes to the development branch that hopefully solve this problem. Now I retrieve the HID descriptor in two different ways, and when in doubt, use the second value (the same as lsusb). I have also made libusb_open() more tolerant in case the actual report descriptor is shorter than expected; so this should no longer fail. Phil, James, Justin, could you test this? Thanks, -- Peter Peter Selinger wrote: Charles Lepple wrote: On 7/24/06, Phil DeBoest [EMAIL PROTECTED] wrote: HID descriptor retrieved (Reportlen = 459) Unable to get Report descriptor (-75) Phil, This looks a lot like the problem mentioned here: http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-November/000318.html Peter, Do you know where the problem turned out to be in the aforementioned message? If it is a wrong value for desc-wDescriptorLength, we could start a quirks table, and override the descriptor length for that particular UPS (and for some of the APCs, if we are still seeing that problem). -- - Charles Lepple Indeed, the cause of this bug was isolated here: http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-February/000705.html As it turns out, there are two ways of retrieving report 0x21 (the HID descriptor) from the UPS: either by requesting report 0x21 directly, or by requesting report 0x02, which will have a copy of report 0x21 tucked onto its end. Normally, the two ways are supposed to give the same result. However, on some buggy UPS's (notably Tripp Lite, and some APC), only the second method works. lsusb always uses the second method, whereas NUT has always used the first. I have just committed some changes to the development branch that hopefully solve this problem. Now I retrieve the HID descriptor in two different ways, and when in doubt, use the second value (the same as lsusb). I have also made libusb_open() more tolerant in case the actual report descriptor is shorter than expected; so this should no longer fail. Phil, James, Justin, could you test this? Thanks, -- Peter Thanks Peter (and Charles)! That seemed to do the trick. The driver now loads and upsd is able to retrieve information from it. Some of the information seems a bit suspect, though. For example, it says the battery voltage is 0, and, even less likely, the output voltage is 177.0. (I'm in the US, so nominal is 120). Surely it wouldn't be indicating peak voltage instead of RMS? Since the computers connected to the UPS continue to function without smoking, I doubt the output voltage is actually that high. The display on the UPS itself indicates everything is normal. Is this likely a parsing issue, or should I investigate further with the UPS itself? I could hook it up to a Windows box, install the software that came with it, and see what it reads. Any other suggestions? Here's the output of upsc: battery.charge: 100 battery.type: PbAc battery.voltage: 0.0 battery.voltage.nominal: 12.0 driver.name: newhidups driver.parameter.port: auto driver.version: 2.1.0 driver.version.data: TrippLite HID 0.1 (experimental) driver.version.internal: 0.30 input.frequency: 59.8 input.voltage: 120.1 input.voltage.nominal: 120 output.frequency.nominal: 60 output.voltage: 177.0 output.voltage.nominal: 120 ups.beeper.status: enabled ups.delay.reboot: 65535 ups.delay.shutdown: 65535 ups.mfr: Tripp Lite ups.model: TRIPP LITE UPS ups.power.nominal: 1000 ups.serial: 692195 A ups.status: OL CHRG Phil Davis Brown is committed to providing Exceptional Client Service. For a review of the supporting principles, go to www.lawiowa.com/about/exceptional To ensure compliance with requirements imposed by the IRS in Circular 230, we inform you that, unless we expressly state
Re: [Nut-upsuser] Tripp Lite Smart1000LCD driver problem
Phil DeBoest wrote: Peter Selinger wrote: I have just committed some changes to the development branch that hopefully solve this problem. Now I retrieve the HID descriptor in two different ways, and when in doubt, use the second value (the same as lsusb). I have also made libusb_open() more tolerant in case the actual report descriptor is shorter than expected; so this should no longer fail. Phil, James, Justin, could you test this? Thanks, -- Peter Thanks Peter (and Charles)! That seemed to do the trick. The driver now loads and upsd is able to retrieve information from it. Some of the information seems a bit suspect, though. For example, it says the battery voltage is 0, and, even less likely, the output voltage is 177.0. (I'm in the US, so nominal is 120). Surely it wouldn't be indicating peak voltage instead of RMS? Since the computers connected to the UPS continue to function without smoking, I doubt the output voltage is actually that high. The display on the UPS itself indicates everything is normal. Is this likely a parsing issue, or should I investigate further with the UPS itself? I could hook it up to a Windows box, install the software that came with it, and see what it reads. Any other suggestions? Here's the output of upsc: battery.charge: 100 battery.type: PbAc battery.voltage: 0.0 battery.voltage.nominal: 12.0 driver.name: newhidups driver.parameter.port: auto driver.version: 2.1.0 driver.version.data: TrippLite HID 0.1 (experimental) driver.version.internal: 0.30 input.frequency: 59.8 input.voltage: 120.1 input.voltage.nominal: 120 output.frequency.nominal: 60 output.voltage: 177.0 output.voltage.nominal: 120 ups.beeper.status: enabled ups.delay.reboot: 65535 ups.delay.shutdown: 65535 ups.mfr: Tripp Lite ups.model: TRIPP LITE UPS ups.power.nominal: 1000 ups.serial: 692195 A ups.status: OL CHRG Phil OK, this is good, now we are getting into fixing small details. I have just committed some changes to the trunk that improve debugging messages and make it easier to get the information I need. Please update to the new version, and then run (as root): drivers/newhidups -DDD -u root [EMAIL PROTECTED] /tmp/logfile After 2 seconds, you can hit CTRL-C. Please send the resulting log file. Note: this is one of the rare times when I actually want to see the output of -DDD. Normally, one should only use -DD on this list, unless specifically requested otherwise. Thanks! -- Peter ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Re: Tripp Lite LCD models w/ NUT
Hi James, thanks for the feedback. The output you get seems generally fine, except for battery.voltage: 0.0 and output.voltage: 164.0; these values are consistent with what Phil DeBoest reported. Upsmon normally executes the shutdown command when you reach the low battery threshold, as decided by the UPS and/or driver. It does so by looking at ups.status, not battery.charge. -- Peter James Pooton wrote: The SVN worked fine for me :) Results below. Just curious, given the data the Tripp Lite LCD UPSs currently return, when does upsmon decide it's time to execute the shutdown command? Is it just when it's on battery alert and finally reaches some internal low threshold of battery.charge? Thanks for all your work... -James [EMAIL PROTECTED] bin]# /usr/local/ups/bin/upsc [EMAIL PROTECTED] battery.charge: 100 battery.type: PbAc battery.voltage: 0.0 battery.voltage.nominal: 24.0 driver.name: newhidups driver.parameter.port: auto driver.version: 2.1.0 driver.version.data: TrippLite HID 0.1 (experimental) driver.version.internal: 0.30 input.frequency: 59.7 input.voltage: 118.8 input.voltage.nominal: 120 output.frequency.nominal: 60 output.voltage: 164.0 output.voltage.nominal: 120 ups.beeper.status: enabled ups.delay.reboot: 65535 ups.delay.shutdown: 65535 ups.mfr: Tripp Lite ups.model: TRIPP LITE UPS ups.power.nominal: 1200 ups.serial: 692199 B ups.status: OL CHRG -James -Original Message- From: Peter Selinger [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 4:40 PM To: James Pooton Subject: Re: Tripp Lite LCD models w/ NUT Hi James, thanks for your message! I think I have fixed this USB report descriptor bug now (as per my previous message). Let me know if it's working! Thanks, -- Peter James Pooton wrote: Hello! Thanks for all your help with NUT! :-) One of your messages on the NUT mailing list saved me today. Just wanted to give you thanks, and an FYI that I took in 6 new Tripp Lite 1500 LCD systems this week and all of them had the USB report descriptor size bug (Unable to get Report descriptor (-75)). I contacted Tripp Lite about it, and the rep took my report but said there were no firmware updates available or in the works that he saw. Someday if you're able to make the workaround part of the source it would be greatly appreciated by those of us with bug ridden UPSs :-) Thanks again! -james ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Re: Tripp Lite LCD models w/ NUT (DETAILS)
James, thanks, this is useful info. Comments below. -- Peter James Pooton wrote: I saw on the list that you were looking for some details. Sorry I'm not part of the list, but here are my results: [EMAIL PROTECTED] bin]# ./newhidups -DDD -u root [EMAIL PROTECTED] Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0) debug level is '3' Checking device (09AE/2005) (004/008) - VendorID: 09ae - ProductID: 2005 - Manufacturer: Tripp Lite - Product: TRIPP LITE UPS - Serial Number: 692199 B - Bus: 004 Trying to match device Device matches failed to claim USB device, trying 2 more time(s)... detaching kernel driver from USB device... trying again to claim USB device... HID descriptor, method 1: (9 bytes) = 09 21 10 01 00 01 22 cb 01 HID descriptor, method 2: (9 bytes) = 09 21 10 01 00 01 22 6a 02 Warning: two different HID descriptors retrieved (Reportlen = 459 vs. 618) Ah, good, my bug fix is working! The driver now notices that the UPS is buggy, and then uses the more likely value, in this case, 618. HID descriptor retrieved (Reportlen = 618) Report descriptor retrieved (Reportlen = 618) Found HID device Report Descriptor size = 618 Report Descriptor: (200 bytes) = 05 84 09 04 a1 01 09 24 a1 02 05 84 85 28 09 fe 75 08 95 01 26 ff 00 15 00 b1 03 85 29 09 ff b1 03 85 2b 09 fd b1 03 09 1a a1 02 09 40 85 30 b1 83 c0 75 08 95 01 26 ff 00 85 11 09 5a b1 82 05 85 95 01 75 08 26 ff 00 15 00 85 2a 09 89 b1 03 85 33 09 2c b1 03 25 64 85 34 09 66 81 a2 85 34 09 66 b1 a2 85 37 09 67 b1 03 05 84 09 02 a1 02 25 01 75 01 85 32 05 84 95 01 09 69 81 a2 09 d0 81 a2 95 03 09 44 09 45 09 4b 81 a2 95 03 81 01 85 32 05 84 75 01 95 01 09 69 b1 a2 05 85 09 d0 b1 a2 95 03 09 44 09 45 09 4b b1 a2 95 03 b1 01 c0 c0 05 84 09 10 a1 02 09 12 a1 02 85 04 09 40 75 10 95 01 27 ff ff 00 I'll have to study this one tomorrow! Detected a UPS: Tripp Lite /TRIPP LITE UPS Using subdriver: TrippLite HID 0.1 (experimental) snip... Report: (3 bytes) = 31 9c 04 Path: UPS.PowerSummary.Voltage, Type: Feature, Value: 156.00 This one is wrong. Probably a miscalculation by the driver. The raw hexadecimal value is 0x049c, which is 1180, which very likely means 118V. I will need to track down the reason the driver reports 156V; perhaps a problem with units. Report: (3 bytes) = 20 0d 01 Path: UPS.BatterySystem.Battery.Voltage, Type: Feature, Value: 269.00 This is equally strange. Here, the reported raw value (269.00) very likely means 26.9V, which would be correct. However, upsc reports battery.voltage: 0.0 What this shows is that the UPS is likely functioning properly; hopefully with a few driver touch-ups, I will be able to coax it into reporting the correct values. Gotta go to bed. More in the next few days... -- Peter ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
