similar to: new TSSHARA SOHO II ups

Sorry about the noise guys. Below a significantly improved patch. The main difference is that all calls to usb_get_string_.. have been wrapped in a new function nut_usb_get_string()  that is implemented in libusb.c This was necessary in order to make the bufflen_fix available in libusb.c where usb_get_string() is called in libusb_open() This wrapper function mops up and hides all the work

Peter, I have been doing some more testing and I find that if I modify the libusb.c file to set a report size in libusb_get_report to 16 the error messages go away. This is the code as it currently stands: static int libusb_get_report(usb_dev_handle *udev, int ReportId, unsigned char *raw_buf, int ReportSize ) { int ReportSize_test = 16; unsigned char raw_buf_test[ReportSize_test +

Credit goess to "cppcheck" Signed-off-by: Thomas Jarosch <thomas.jarosch at intra2net.com> --- drivers/usb-common.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb-common.c b/drivers/usb-common.c index e51f3cf..e459872 100644 --- a/drivers/usb-common.c +++ b/drivers/usb-common.c @@ -116,7 +116,7 @@ int USBNewExactMatcher(USBDeviceMatcher_t

Hi Folks, This is my first post on nut-upsdev. I would like to share a small patch to enable support for the Powercool PCRACK 1200VA ups. I found that the UPS uses megatec/krauler protocol but is sensitive to the USB buffer length passed to it in requests via usb_get_string(), and usb_get_string_simple(). If the buflen is greater than 102 then the ups will reply to requests but does not

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()

I recently installed NUT 2.4.3 and found that the USB drivers were logging an insane amount of data to syslog: usbhid-ups | daemon debug | Apr 16 18:29:40 | libusb_get_report: No error usbhid-ups | daemon debug | Apr 16 18:29:40 | libusb_get_report: No error usbhid-ups | daemon debug | Apr 16 18:29:40 | libusb_get_report: No error usbhid-ups | daemon debug | Apr 16 18:29:40 |

Hi Charles, Sorry for the long email, I feel this deserves a fuller explanation. On Wed, Feb 14, 2018 at 10:30:18PM -0500, Charles Lepple wrote: > On Feb 3, 2018, at 7:19 PM, Russell King wrote: > > > > Input and Output reports are used for interrupt endpoints rather than > > control endpoints. HIDGetItemData() only ever requests feature > > report IDs, and

2018-02-27 14:51 GMT+01:00 Jairo Rotava <jairo.rotava at gmail.com>: > Hi, > > I had an issue where after returning the power from a shutdown.return the > ups would do another shutdown.return during the boot, and kept this forever. > After some investigation I found the problem is a bug on the ups - TSSHARA > model, driver nutdrv_qx: every time I shutdown with return, and

Hello, I think that on this file nutdrv_qx_megatec.c the definition for shutdown.stayoff may be wrong. In the file the definition is "S%sR0000\r"m while on the megatec protocol description ( http://networkupstools.org/protocols/megatec.html) the command is just "S%s\r". When I changed it my system was abe to at least stay off, and stopped making an instant power recycling.

Hi, I had an issue where after returning the power from a shutdown.return the ups would do another shutdown.return during the boot, and kept this forever. After some investigation I found the problem is a bug on the ups - TSSHARA model, driver nutdrv_qx: every time I shutdown with return, and reconnect the usb after the power is back it would start another shudown.return cycle. When I used my

Answers bellow. 2018-02-28 1:41 GMT-03:00 Daniele Pezzini <hyouko at gmail.com>: > 2018-02-27 14:51 GMT+01:00 Jairo Rotava <jairo.rotava at gmail.com>: > > Hi, > > > > I had an issue where after returning the power from a shutdown.return the > > ups would do another shutdown.return during the boot, and kept this > forever. > > After some

2018-02-28 21:11 GMT+01:00 Jairo Rotava <jairo.rotava at gmail.com>: > Hello, > > I think that on this file nutdrv_qx_megatec.c the definition for > shutdown.stayoff may be wrong. In the file the definition is "S%sR0000\r"m > while on the megatec protocol description ( > http://networkupstools.org/protocols/megatec.html) the command is just > "S%s\r".

I get the following error on r809 (but it looks like the code change happened here). Does HIDDevice_t need to be defined/changed in one of the headers? if gcc -DHAVE_CONFIG_H -I. -I../../drivers -I../include -I../../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DINET6 -O2 -D_REENTRANT -DNETSNMP_USE_INLINE -Wall -Dlinux -I.

Hi all, I posted originally here last week: https://alioth-lists.debian.net/pipermail/nut-upsuser/2023-October/013461.html Since then, I've been building and testing from source following the instructions a helpful reply in the above thread pointed out. The original problem is I've got one of these arduino HID power devices, as a project for a DIY UPS at home. This arduino is a composite

Earlier this year, I added a patch to my local NUT tree to additionally print the value of usb_strerror() if usb_clear_halt() failed. (Ignore the commented-out goto.) Since these messages are at the LOG_ERR level, should we add usb_strerror() to all of the calls in nut_usb.c? diff --git a/drivers/nut_usb.c b/drivers/nut_usb.c index 494a1fa..4ca2691 100644 --- a/drivers/nut_usb.c +++

Attached is the first 32 seconds of the driver output after applying the patch which fixes the battery scaling problem for this UPS. Matthew Stapleton Email: matthew4196 at gmail.com On 10/08/14 01:27, Charles Lepple wrote: > On Aug 8, 2014, at 9:15 AM, Charles Lepple <clepple at gmail.com> wrote: > >> On Aug 7, 2014, at 10:52 PM, Charles Lepple <clepple at gmail.com>

Thank you for the investigation! I've thought about this in vague terms, i.e. that numbers like this should be configurable, but did not have time to read into USB-related libraries and specs to make any more specific sense of it (and the libusb code is not mine except the recent layers of cleanup). I guess I did not even realize that there is more than the regularly mentioned "interface

Thanks for the quick reply! Ya, I'm new to all this so I didn't know this either, I was vaguely aware of USB composite devices from other projects, but never how it was all enumerated. I dug a bit more on this and I'm convinced the relationship is this: Device ??? Configuration 1 ??? Interface 1 ? ??? Endpoint 1 ? ??? Endpoint 2 ? ??? ... ??? Interface 2

On Feb 3, 2018, at 7:19 PM, Russell King wrote: > > Input and Output reports are used for interrupt endpoints rather than > control endpoints. HIDGetItemData() only ever requests feature > report IDs, and requesting non-feature report IDs as feature IDs may > lead to undesirable results and errors. This one made me scratch my head a bit. I don't think it's unreasonable

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The