[Nut-upsuser] [UPS on Serial vs. USB] USB slow to update, serial instant.
When I disconnect my UPS from the wall, I have to wait 15-30 seconds before the USB drier 'polls' this information and tells me that the UPS is on battery power (via knutclient or syslog via nut): [EMAIL PROTECTED] POWER ALERT on Fri Jan 26 12:49:29 EST 2007 With a serial connection, I would get the alerts IMMEDIATELY (0.5-1 seconds) after disconnecting the UPS. My new machine does not have a serial port built-in, only a serial header, and of course does not come with an included cable, so I chose to use USB. My question is, how do I change the polling time that nut uses to poll the device to match that of the serial port? The reason I'd like to is I am not going to see any power alerts for unless there is a power outage for longer than 15-30 seconds. I've checked the FAQ on this, do I have to change the 'MAXAGE' parameter to force more frequent updates? Justin. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Meaning of ups.delay.*
Hi all! As I'm currently porting the HP PowerTrust driver from nut-1.4.3, I have a question regarding ups.delay.*. The PTs can delay the Shutdown/Restart and Kill commands by an arbitrary number of seconds, i.e. they wait for n seconds and then shutdown or kill. The delay for the restart after the shutdown can't be changed. Which of the ups.delay.* variables correspond to these values? Regards, Jakob Haufe ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] [UPS on Serial vs. USB] USB slow to update, serial instant.
When I disconnect my UPS from the wall, I have to wait 15-30 seconds before the USB drier 'polls' this information and tells me that the UPS is on battery power (via knutclient or syslog via nut): [EMAIL PROTECTED] POWER ALERT on Fri Jan 26 12:49:29 EST 2007 With a serial connection, I would get the alerts IMMEDIATELY (0.5-1 seconds) after disconnecting the UPS. My new machine does not have a serial port built-in, only a serial header, and of course does not come with an included cable, so I chose to use USB. Which serial driver have you been using so far? Most serial drivers will poll the UPS every two seconds for status updates. So on average, you'll see status changes in about half that time, which equals about one second. So far the number of UPSes that issue alerts on line status changes is limited and hence we don't have that many drivers that use this feature. But generally speaking, what you're seeing is normal for a driver that uses the serial interface. My question is, how do I change the polling time that nut uses to poll the device to match that of the serial port? That depends on the driver you're using. If you're using the newhidups driver (which will be renamed usbhid-ups in the next release), there is probably not much you can do about this. Many USB protocols are *very* verbose and don't allow polling the status every two seconds. Therefore, the newhidups has a build in mechanism to only do a full status update every 30 seconds (if memory serves). If you're using another driver, you could try the 'pollinterval' parameter (see 'man 5 ups.conf' for a description after verifying that the man page of the driver does not mention it). The reason I'd like to is I am not going to see any power alerts for unless there is a power outage for longer than 15-30 seconds. Use a less verbose (serial) driver in that case. There is probably nothing else we can do for you right now. A driver that uses a more intelligent mechanism to read status changes more frequently is planned, but so far we have no schedule for its release (not even for an experimental/trial version, don't ask). I've checked the FAQ on this, do I have to change the 'MAXAGE' parameter to force more frequent updates? No. The MAXAGE parameter only determines when to declare a driver stale. If we don't hear anything from a driver for this many seconds, it is declared stale. This has nothing to do with the polling interval. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Meaning of ups.delay.*
As I'm currently porting the HP PowerTrust driver from nut-1.4.3, I have a question regarding ups.delay.*. The PTs can delay the Shutdown/Restart and Kill commands by an arbitrary number of seconds, i.e. they wait for n seconds and then shutdown or kill. The delay for the restart after the shutdown can't be changed. Which of the ups.delay.* variables correspond to these values? See my answer on the development list [EMAIL PROTECTED] Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] [UPS on Serial vs. USB] USB slow to update,
If you are using newhidups/usbhid-ups, the option -x pollfreq=value can be used to set the polling frequency (or put pollfreq=value into ups.conf). The default is 30 seconds. -- Peter Justin Piszcz wrote: When I disconnect my UPS from the wall, I have to wait 15-30 seconds before the USB drier 'polls' this information and tells me that the UPS is on battery power (via knutclient or syslog via nut): [EMAIL PROTECTED] POWER ALERT on Fri Jan 26 12:49:29 EST 2007 With a serial connection, I would get the alerts IMMEDIATELY (0.5-1 seconds) after disconnecting the UPS. My new machine does not have a serial port built-in, only a serial header, and of course does not come with an included cable, so I chose to use USB. My question is, how do I change the polling time that nut uses to poll the device to match that of the serial port? The reason I'd like to is I am not going to see any power alerts for unless there is a power outage for longer than 15-30 seconds. I've checked the FAQ on this, do I have to change the 'MAXAGE' parameter to force more frequent updates? Justin. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] no longer stale when disconnected with 2.0.5
If I understood Markus correctly, the problem is not that the data goes stale (it should do that when disconnecting the UPS communications line), but that it goes unstale immediately afterwards (even when the UPS is still disconnected). This shouldn't really happen. Maybe some debugging is needed. Markus: the function that decides whether your UPS is stale or not is server/sstate.c:sstate_dead(). Perhaps you can insert some debugging statements to figure out what this function returns and why. -- Peter Arjen de Korte wrote: After reconnect the ups, the communication is ok and nut works until I disconnect again. Which version of NUT are you using? I tired also different values for pollinterval. Which values? Did you also change the MAXAGE value for upsd? We want to shutdown the server, if the ups is disconnected from the ser= ver (e.g. if the ups is defect). You can do this by means of a script that is called by NOTIFYCMD (see 'ma= n 5 upsmon.conf') or through upssched (see 'man 8 upssched'), which is more flexible. Best regards, Arjen --=20 Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] [UPS on Serial vs. USB] USB slow to update,
On Sat, 27 Jan 2007, Peter Selinger wrote: If you are using newhidups/usbhid-ups, the option -x pollfreq=value can be used to set the polling frequency (or put pollfreq=value into ups.conf). The default is 30 seconds. -- Peter Justin Piszcz wrote: When I disconnect my UPS from the wall, I have to wait 15-30 seconds before the USB drier 'polls' this information and tells me that the UPS is on battery power (via knutclient or syslog via nut): [EMAIL PROTECTED] POWER ALERT on Fri Jan 26 12:49:29 EST 2007 With a serial connection, I would get the alerts IMMEDIATELY (0.5-1 seconds) after disconnecting the UPS. My new machine does not have a serial port built-in, only a serial header, and of course does not come with an included cable, so I chose to use USB. My question is, how do I change the polling time that nut uses to poll the device to match that of the serial port? The reason I'd like to is I am not going to see any power alerts for unless there is a power outage for longer than 15-30 seconds. I've checked the FAQ on this, do I have to change the 'MAXAGE' parameter to force more frequent updates? Justin. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser Very nice-this fixed the issue, thank you! Justin. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] [UPS on Serial vs. USB] USB slow to update, serial instant.
On 1/27/07, Arjen de Korte [EMAIL PROTECTED] wrote: That depends on the driver you're using. If you're using the newhidups driver (which will be renamed usbhid-ups in the next release), there is probably not much you can do about this. Many USB protocols are *very* verbose and don't allow polling the status every two seconds. Therefore, the newhidups has a build in mechanism to only do a full status update every 30 seconds (if memory serves). Unfortunately, a quick glance at this code seems to indicate that even if the UPS sends a notification on the interrupt in pipe, NUT will only check for that every time it does a full status update. I think this has something to do with not wanting to spam the system logs with timeout messages, though. -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] no longer stale when disconnected with 2.0.5
Peter Selinger wrote: If I understood Markus correctly, the problem is not that the data goes stale (it should do that when disconnecting the UPS communications line), but that it goes unstale immediately afterwards (even when the UPS is still disconnected). That's entirely possible if he's using a version older than 2.0.4. That's why I asked him which version he's using. This shouldn't really happen. Maybe some debugging is needed. Maybe, but in that case I would still like to know the version, in order to interpret the output in the right way. We've applied some bugfixes in this aspect, especially in the code that decides whether a UPS is stale or not. Markus: the function that decides whether your UPS is stale or not is server/sstate.c:sstate_dead(). Perhaps you can insert some debugging statements to figure out what this function returns and why. If sstate_dead() is the problem, I'm almost certain that Markus is using something older than 2.0.4. In that case he'd better update to something newer. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] [UPS on Serial vs. USB] USB slow to update, serial instant.
On Sat, 27 Jan 2007, Arjen de Korte wrote: When I disconnect my UPS from the wall, I have to wait 15-30 seconds before the USB drier 'polls' this information and tells me that the UPS is on battery power (via knutclient or syslog via nut): [EMAIL PROTECTED] POWER ALERT on Fri Jan 26 12:49:29 EST 2007 With a serial connection, I would get the alerts IMMEDIATELY (0.5-1 seconds) after disconnecting the UPS. My new machine does not have a serial port built-in, only a serial header, and of course does not come with an included cable, so I chose to use USB. Which serial driver have you been using so far? Most serial drivers will poll the UPS every two seconds for status updates. So on average, you'll see status changes in about half that time, which equals about one second. So far the number of UPSes that issue alerts on line status changes is limited and hence we don't have that many drivers that use this feature. But generally speaking, what you're seeing is normal for a driver that uses the serial interface. My question is, how do I change the polling time that nut uses to poll the device to match that of the serial port? That depends on the driver you're using. If you're using the newhidups driver (which will be renamed usbhid-ups in the next release), there is probably not much you can do about this. Many USB protocols are *very* verbose and don't allow polling the status every two seconds. Therefore, the newhidups has a build in mechanism to only do a full status update every 30 seconds (if memory serves). If you're using another driver, you could try the 'pollinterval' parameter (see 'man 5 ups.conf' for a description after verifying that the man page of the driver does not mention it). The reason I'd like to is I am not going to see any power alerts for unless there is a power outage for longer than 15-30 seconds. Use a less verbose (serial) driver in that case. There is probably nothing else we can do for you right now. A driver that uses a more intelligent mechanism to read status changes more frequently is planned, but so far we have no schedule for its release (not even for an experimental/trial version, don't ask). I've checked the FAQ on this, do I have to change the 'MAXAGE' parameter to force more frequent updates? No. The MAXAGE parameter only determines when to declare a driver stale. If we don't hear anything from a driver for this many seconds, it is declared stale. This has nothing to do with the polling interval. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 Thank you for the detailed explanation! As posted by another user, this is the variable that fixes the issue: pollfreq = 5 Set to five second updates, works great, thanks all! Before: # Serial port: #[belkin] #driver = belkinunv #port = /dev/ttyS0 #desc = Belkin UPS 1200 VA After: # USB: [belkin] driver = newhidups port = auto desc = Belkin Universal UPS 1200 VA pollfreq = 5 Justin. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] no longer stale when disconnected with 2.0.5
Yes, but he said 2.0.5 in the subject line. -- Peter Arjen de Korte wrote: Peter Selinger wrote: If I understood Markus correctly, the problem is not that the data goes stale (it should do that when disconnecting the UPS communications line), but that it goes unstale immediately afterwards (even when the UPS is still disconnected). That's entirely possible if he's using a version older than 2.0.4. That's why I asked him which version he's using. This shouldn't really happen. Maybe some debugging is needed. Maybe, but in that case I would still like to know the version, in order to interpret the output in the right way. We've applied some bugfixes in this aspect, especially in the code that decides whether a UPS is stale or not. Markus: the function that decides whether your UPS is stale or not is server/sstate.c:sstate_dead(). Perhaps you can insert some debugging statements to figure out what this function returns and why. If sstate_dead() is the problem, I'm almost certain that Markus is using something older than 2.0.4. In that case he'd better update to something newer. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Ablerex 625L USB version
Oooppss. Lets try with less data! Peter, Here is the line that I pruned out. Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0) When I start the driver with /usr/local/ups/bin/upsdrvctl -u nut start I get the following messages Network UPS Tools - UPS driver controller 2.1.0 Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0) Detected a UPS: UIS Ablerex/Ablerex USB Interface 049e Using subdriver: Upsilon HID 0.1 Then I issue /usr/local/ups/sbin/upsd -u nut and get Network UPS Tools upsd 2.1.0 upsd: listening on 0.0.0.0:3493 Connected to UPS [eclipse]: eclipse Then I try to see what is available from the driver with /usr/local/ups/bin/upsc eclipse and get Activepower: 0 Apparentpower: 0 driver.name: usbhid-ups driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.1.0 Shutdown.Delay: 0 Startup.Delay: 0 ups.mfr: UIS Ablerex ups.model: Ablerex USB Interface 049e ups.status: WAIT If I try /usr/local/ups/bin/upsc eclipse battery.voltage I get Error: Variable not supported by UPS Yet battery.voltage is defined in the hid_info_t variable. It looks like only part of the output is being read. But at this point I do not know what to do to get further information from the system. I have modified the stub to have the correct (I hope) labels for at least some of the values that should be returned, but they do not show up when I call the command processor. I seem to be missing something in this process. Not sure what, but I am getting confused about what I should have to do. Regards Jon At 17:20 28/01/2007, Peter Selinger wrote: Hi Jon, I can't figure out which version of NUT you are running, because you have pruned that information from your output. Also, which patches, if any, have you applied? What you are seeing from lsusb is not data from the UPS; it is simply a detailed parsing of the report descriptor. For example, when it says Usage, data= [ 0x40 ] 64 Config Voltage, this simply means that HID usage code 0040 corresponds to the ConfigVoltage item (see e.g. libhid.c, line 1100). The error message (75): Value too large for defined data type may indicate that the UPS is unhappy with the size of the buffer provided by NUT (apparently 13). You can play with this by hacking a larger buffer size. It should be easy to do this in the function libhid.c:refresh_report_buffer(), by setting len to something bigger (or smaller). If the buffer is too small, the device is supposed to fill it with valid data up to the given size, instead of bailing out with an error message. So it seems that the device is at least a little buggy. Similar behavior has been observed in other cheap devices. (In fact, one Belkin UPS that I own seems to have a dual bug: if you give a buffer that is too large, then it will attempt to write random contents from the firmware memory into the buffer, often crashing the device). Alternatively, what would happen if you just ignored the error in libhid.c after the call to get_report? Perhaps the buffer has been filled with partial data in spite of the error message? Just some thoughts. -- Peter Jon Gough wrote: Peter, I have been trying with no luck to get the drivers working. I have done a lsusb -v -d : to get the info from the USB regarding my UPS and it seems to be giving valid data. However, I am now confused with the explore option of the usbhid-ups program as the Report Descriptor is 632 byte long (which is confirmed by the lsusb program). But the lsusb program seems to be reading every other byte not each byte. What are the in between bytes for? I have included the output of the lsusb command below (sorry for the length) and it seems to read the output fine, but the NUT software seems to call libusb and get invalid responses. I notice in the latest output that the length of the data and the length being requested seem different (I put a couple of extra debugging statements in). Using subdriver: EXPLORE HID 0.1 parsing 00860004 parsing Flow hid_lookup_usage: found 84001e parsing FlowID hid_lookup_usage: found 84001f Path depth = 3 0: Usage(00860004) 1: Usage(0084001e) 2: Usage(0084001f) Entering libusb_get_report. ReportSize: 13 typesafe_control_msg: size: 13 Can't retrieve Report 1 (75): Value too large for defined data type Path: 00860004.Flow.FlowID, Type: Feature, ReportID: 0x01, Offset: 0, Size: 4 parsing 00860004 parsing Flow hid_lookup_usage: found 84001e parsing ConfigVoltage hid_lookup_usage: found 840040 Path depth = 3 0: Usage(00860004) 1: Usage(0084001e) 2: Usage(00840040) Entering libusb_get_report. ReportSize: 13 typesafe_control_msg: size: 13 Can't retrieve Report 1 (75): Value too large for defined data type Path: 00860004.Flow.ConfigVoltage, Type: Feature, ReportID: 0x01, Offset: 8, Size: 16 Is this correct, or is there something else that needs looking at? Regards Jon Data from lsusb snip
Re: [Nut-upsuser] Ablerex 625L USB version
Peter, Looking at the data further down it has min and max values. These would seem to make sense for voltage (0 250), frequency (0 60), so is this data coming from the UPS, or is it just something in the system that expects these values? Regards Jon At 17:20 28/01/2007, Peter Selinger wrote: Hi Jon, I can't figure out which version of NUT you are running, because you have pruned that information from your output. Also, which patches, if any, have you applied? What you are seeing from lsusb is not data from the UPS; it is simply a detailed parsing of the report descriptor. For example, when it says Usage, data= [ 0x40 ] 64 Config Voltage, this simply means that HID usage code 0040 corresponds to the ConfigVoltage item (see e.g. libhid.c, line 1100). The error message (75): Value too large for defined data type may indicate that the UPS is unhappy with the size of the buffer provided by NUT (apparently 13). You can play with this by hacking a larger buffer size. It should be easy to do this in the function libhid.c:refresh_report_buffer(), by setting len to something bigger (or smaller). If the buffer is too small, the device is supposed to fill it with valid data up to the given size, instead of bailing out with an error message. So it seems that the device is at least a little buggy. Similar behavior has been observed in other cheap devices. (In fact, one Belkin UPS that I own seems to have a dual bug: if you give a buffer that is too large, then it will attempt to write random contents from the firmware memory into the buffer, often crashing the device). Alternatively, what would happen if you just ignored the error in libhid.c after the call to get_report? Perhaps the buffer has been filled with partial data in spite of the error message? Just some thoughts. -- Peter Jon Gough wrote: Peter, I have been trying with no luck to get the drivers working. I have done a lsusb -v -d : to get the info from the USB regarding my UPS and it seems to be giving valid data. However, I am now confused with the explore option of the usbhid-ups program as the Report Descriptor is 632 byte long (which is confirmed by the lsusb program). But the lsusb program seems to be reading every other byte not each byte. What are the in between bytes for? I have included the output of the lsusb command below (sorry for the length) and it seems to read the output fine, but the NUT software seems to call libusb and get invalid responses. I notice in the latest output that the length of the data and the length being requested seem different (I put a couple of extra debugging statements in). snip Item(Local ): Usage, data= [ 0x40 ] 64 Config Voltage Item(Global): Report Size, data= [ 0x10 ] 16 Item(Global): Report Count, data= [ 0x01 ] 1 Item(Global): Unit, data= [ 0x21 0xd1 0xf0 0x00 ] 15782177 Item(Global): Unit Exponent, data= [ 0x07 ] 7 Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xfa 0x00 ] 250 Item(Main ): Feature, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Local ): Usage, data= [ 0x42 ] 66 Config Frequency Item(Global): Report Size, data= [ 0x10 ] 16 Item(Global): Report Count, data= [ 0x01 ] 1 Item(Global): Unit, data= [ 0x01 0xf0 ] 61441 Item(Global): Unit Exponent, data= [ 0x00 ] 0 Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x3c ] 60 Item(Main ): Feature, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield snip --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 000707-0, 27/01/2007 Tested on: 28/01/2007 5:49:24 PM avast! is copyright (c) 2000-2007 ALWIL Software. http://www.avast.com ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Ablerex 625L USB version
Hi Jon, I can't figure out which version of NUT you are running, because you have pruned that information from your output. Also, which patches, if any, have you applied? What you are seeing from lsusb is not data from the UPS; it is simply a detailed parsing of the report descriptor. For example, when it says Usage, data= [ 0x40 ] 64 Config Voltage, this simply means that HID usage code 0040 corresponds to the ConfigVoltage item (see e.g. libhid.c, line 1100). The error message (75): Value too large for defined data type may indicate that the UPS is unhappy with the size of the buffer provided by NUT (apparently 13). You can play with this by hacking a larger buffer size. It should be easy to do this in the function libhid.c:refresh_report_buffer(), by setting len to something bigger (or smaller). If the buffer is too small, the device is supposed to fill it with valid data up to the given size, instead of bailing out with an error message. So it seems that the device is at least a little buggy. Similar behavior has been observed in other cheap devices. (In fact, one Belkin UPS that I own seems to have a dual bug: if you give a buffer that is too large, then it will attempt to write random contents from the firmware memory into the buffer, often crashing the device). Alternatively, what would happen if you just ignored the error in libhid.c after the call to get_report? Perhaps the buffer has been filled with partial data in spite of the error message? Just some thoughts. -- Peter Jon Gough wrote: Peter, I have been trying with no luck to get the drivers working. I have done a lsusb -v -d : to get the info from the USB regarding my UPS and it seems to be giving valid data. However, I am now confused with the explore option of the usbhid-ups program as the Report Descriptor is 632 byte long (which is confirmed by the lsusb program). But the lsusb program seems to be reading every other byte not each byte. What are the in between bytes for? I have included the output of the lsusb command below (sorry for the length) and it seems to read the output fine, but the NUT software seems to call libusb and get invalid responses. I notice in the latest output that the length of the data and the length being requested seem different (I put a couple of extra debugging statements in). Using subdriver: EXPLORE HID 0.1 parsing 00860004 parsing Flow hid_lookup_usage: found 84001e parsing FlowID hid_lookup_usage: found 84001f Path depth = 3 0: Usage(00860004) 1: Usage(0084001e) 2: Usage(0084001f) Entering libusb_get_report. ReportSize: 13 typesafe_control_msg: size: 13 Can't retrieve Report 1 (75): Value too large for defined data type Path: 00860004.Flow.FlowID, Type: Feature, ReportID: 0x01, Offset: 0, Size: 4 parsing 00860004 parsing Flow hid_lookup_usage: found 84001e parsing ConfigVoltage hid_lookup_usage: found 840040 Path depth = 3 0: Usage(00860004) 1: Usage(0084001e) 2: Usage(00840040) Entering libusb_get_report. ReportSize: 13 typesafe_control_msg: size: 13 Can't retrieve Report 1 (75): Value too large for defined data type Path: 00860004.Flow.ConfigVoltage, Type: Feature, ReportID: 0x01, Offset: 8, Size: 16 Is this correct, or is there something else that needs looking at? Regards Jon Data from lsusb @@@ Bus 001 Device 021: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x idProduct 0x bcdDevice1.00 iManufacturer 1 UIS Ablerex iProduct2 Ablerex USB Interface 049e iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 27 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.00 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 632 Report Descriptor: (length is 632) Item(Global): Usage Page, data= [ 0x86 ] 134
Re: [Nut-upsuser] Ablerex 625L USB version
No, it is all part of the report descriptor. A USB device might define a variable called Voltage, whose units are Volts (and not, for example, millivolts, kilovolts, ...) and which can take values in the range 0...250. At this point, you have not read any actual voltage from the UPS yet. The only thing that has happened is that a certain variable has been declared. For example, the USB code for the physical unit Volt is 0x00F0D121. You see this in the line Item(Global): Unit, data= [ 0x21 0xd1 0xf 0x00 ] 15782177 If you really want to know more about these variable descriptors, you have to read the USB HID Power Device Class specification. It is at http://www.usb.org/developers/devclass_docs under Power. But you don't really have to read this. NUT is already doing a good job parsing the report descriptor. Your problem at this point is that, after the device has declared all the variables, it does not allow you to read their actual contents. -- Peter Jon Gough wrote: Peter, Looking at the data further down it has min and max values. These would seem to make sense for voltage (0 250), frequency (0 60), so is this data coming from the UPS, or is it just something in the system that expects these values? Regards Jon At 17:20 28/01/2007, Peter Selinger wrote: Hi Jon, I can't figure out which version of NUT you are running, because you have pruned that information from your output. Also, which patches, if any, have you applied? What you are seeing from lsusb is not data from the UPS; it is simply a detailed parsing of the report descriptor. For example, when it says Usage, data= [ 0x40 ] 64 Config Voltage, this simply means that HID usage code 0040 corresponds to the ConfigVoltage item (see e.g. libhid.c, line 1100). The error message (75): Value too large for defined data type may indicate that the UPS is unhappy with the size of the buffer provided by NUT (apparently 13). You can play with this by hacking a larger buffer size. It should be easy to do this in the function libhid.c:refresh_report_buffer(), by setting len to something bigger (or smaller). If the buffer is too small, the device is supposed to fill it with valid data up to the given size, instead of bailing out with an error message. So it seems that the device is at least a little buggy. Similar behavior has been observed in other cheap devices. (In fact, one Belkin UPS that I own seems to have a dual bug: if you give a buffer that is too large, then it will attempt to write random contents from the firmware memory into the buffer, often crashing the device). Alternatively, what would happen if you just ignored the error in libhid.c after the call to get_report? Perhaps the buffer has been filled with partial data in spite of the error message? Just some thoughts. -- Peter Jon Gough wrote: Peter, I have been trying with no luck to get the drivers working. I have done a lsusb -v -d : to get the info from the USB regarding my UPS and it seems to be giving valid data. However, I am now confused with the explore option of the usbhid-ups program as the Report Descriptor is 632 byte long (which is confirmed by the lsusb program). But the lsusb program seems to be reading every other byte not each byte. What are the in between bytes for? I have included the output of the lsusb command below (sorry for the length) and it seems to read the output fine, but the NUT software seems to call libusb and get invalid responses. I notice in the latest output that the length of the data and the length being requested seem different (I put a couple of extra debugging statements in). snip Item(Local ): Usage, data= [ 0x40 ] 64 Config Voltage Item(Global): Report Size, data= [ 0x10 ] 16 Item(Global): Report Count, data= [ 0x01 ] 1 Item(Global): Unit, data= [ 0x21 0xd1 0xf 0x00 ] 15782177 Item(Global): Unit Exponent, data= [ 0x07 ] 7 Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xfa 0x00 ] 250 Item(Main ): Feature, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Local ): Usage, data= [ 0x42 ] 66 Config Frequency Item(Global): Report Size, data= [ 0x10 ] 16 Item(Global): Report Count, data= [ 0x01 ] 1 Item(Global): Unit, data= [ 0x01 0xf0 ] 61441 Item(Global): Unit Exponent, data= [ 0x00 ] 0 Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x3c ] 60 Item(Main ): Feature, data= [ 0x02 ] 2
Re: [Nut-upsuser] Ablerex 625L USB version
Peter, I generated a new subdriver using the suggested method of running ./drivers/usbhid-ups - -u nut -x explore -x vendorid= auto /tmp/info followed by pumping this into ./scripts/subdriver/path-to-subdriver.sh Then make all, and make install . I don't get any error messages, I just don't seem to get what I expect, which is some of the details from the UPS. Whilst I do have windows software for this device, I would not know where to start to decode what it is doing so that I could replicate it in the NUT system. Jon At 18:16 28/01/2007, Peter Selinger wrote: Jon Gough wrote: Oooppss. Lets try with less data! Yes, I also had trouble posting to the list because of the size limit. It might help if you could teach your mailer not to repeat the entire message in HTML at the end of each message. Peter, Here is the line that I pruned out. Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0) When I start the driver with /usr/local/ups/bin/upsdrvctl -u nut start I get the following messages Network UPS Tools - UPS driver controller 2.1.0 Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0) Detected a UPS: UIS Ablerex/Ablerex USB Interface 049e Using subdriver: Upsilon HID 0.1 OK, so you are using some patch that I have not seen. There is no Upsilon subdriver in the official NUT sources. Then I issue /usr/local/ups/sbin/upsd -u nut and get Network UPS Tools upsd 2.1.0 upsd: listening on 0.0.0.0:3493 Connected to UPS [eclipse]: eclipse Then I try to see what is available from the driver with /usr/local/ups/bin/upsc eclipse and get Activepower: 0 Apparentpower: 0 driver.name: usbhid-ups driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.1.0 Shutdown.Delay: 0 Startup.Delay: 0 ups.mfr: UIS Ablerex ups.model: Ablerex USB Interface 049e ups.status: WAIT OK, sure, you are getting ahead of the game. There is no point in this unless the driver can first communicate with the UPS. If I try /usr/local/ups/bin/upsc eclipse battery.voltage I get Error: Variable not supported by UPS Yet battery.voltage is defined in the hid_info_t variable. It looks like only part of the output is being read. But at this point I do not know what to do to get further information from the system. I have modified the stub to have the correct (I hope) labels for at least some of the values that should be returned, but they do not show up when I call the command processor. I seem to be missing something in this process. Not sure what, but I am getting confused about what I should have to do. Regards Jon snip --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 000707-0, 27/01/2007 Tested on: 28/01/2007 6:31:45 PM avast! is copyright (c) 2000-2007 ALWIL Software. http://www.avast.com ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
