similar to: Patch to support Powercool PCRACK-1200VA

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

Like Glen Ogilvie, I got a newer Dynamix 650 VA with USB connection, and was having trouble getting NUT to communicate with it. This appears to be the UPS that megatec_usb was built for - Vendor: 0x0001, Product: 0x0000, uses Megatec's software, has USB chip attached to internal serial lines, and has terrible USB implementation with fake HID tables. But megatec_usb would consistently fail.

On Dec 17, 2011, at 3:53 AM, Arnaud Quette wrote: > Author: aquette > Date: Sat Dec 17 08:53:41 2011 > New Revision: 3363 > URL: http://trac.networkupstools.org/projects/nut/changeset/3363 > > Log: > Try to fix language ID support for USB units from LDLC, Dynamix and no names in blazer_usb (reworked patch, from Brian R. Smith and Aur?lien Grenotton) ... > + if

I have recently purchased a powercool 1500VA UPS (this one: https://www.cclonline.com/product/106782/PC-1500VA/UPS-Battery-Backup/Powercool-Smart-UPS-1500VA-3-x-UK-Plug-3-x-IEC-RJ45-x-2-USB-LCD-Display/UPS0171/?gclid=Cj0KEQjw3ZS-BRD1xu3qw8uS2s4BEiQA2bcfMwMPzsshzLqNK3E8NoAKQ6PPWRW589_zkYZ5YZDInb4aAuqK8P8HAQ ). It comes with software for windows/linux called UPSmart1.5 which connects and monitors

Further analysis it looks like the status string matches the q1 subdriver but a lowercase "f" is sent to request it instead of "Q1\r". What do you think? ---------- Forwarded message ---------- From: "Matthew Wire" <devel at mrwire.co.uk> Date: 30 Aug 2016 22:51 Subject: powercool 1500VA USB UPS To: <nut-upsuser at lists.alioth.debian.org> Cc: I have

Hi Charles, I've added 3 more files to github. https://github.com/mattwire/powercool-ups/blob/master/wireshark-UPSmart-startup.pcapng - captures startup of UPSmart software and continues for about 5 minutes. https://github.com/mattwire/powercool-ups/blob/master/wireshark-UPSmart-ups_off-on.pcapng - UPSmart software is running, UPS is OFF. UPS is switched on and connects to software.

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()

> On Oct 10, 2016, at 4:29 PM, Matthew Wire <mjw at mjwconsult.co.uk> wrote: > > Here is the complete log for two minutes from startup. thank you compressed to fit on the mailing list. > > On 9 October 2016 at 23:41, hyouko at gmail.com <hyouko at gmail.com> wrote: > > 12.243069 send: Q1 > > 12.243087 command index: 0x03 > > 12.249983 read: (47

Wow just seen this screenshot. I did not know it did that. Is this the port is ask for? Can I go to it's webpage and some port to see this type screen? -Raymond Day On 11/3/2016 6:39 PM, Matthew Wire wrote: > https://github.com/mattwire/powercool-ups/blob/master/UPSmart_connected.png > - is a screenshot of the UPSmart software when connected (shows some > values from UPS).

> Everything looks fine apart from ups.beeper.status always shows enabled > even if the status bit fom the ups has changed state. Probably because the driver updates the beeper status only every 'pollfreq' (default 30) seconds, so it may have missed the change. > After more testing the indexes work as follows > > 0x0a = load.on / cancel.shutdown.stayoff /

Hi, it does communicate using the fabula subdriver but I don't get any of the values parsed. If I execute: ./nutdrv_qx -a powercool -DDDDD -x subdriver=fabula -x vendorid=0001 -x productid=0000 I get the following returned: 12.242991 upsdrv_updateinfo... 12.243047 Quick update... 12.243069 send: Q1 12.243087 command index: 0x03 12.249983 read: (47 bytes) => 28 30 30 30 2e 30 20

-------------------------------------------------- From: <hyouko at gmail.com> Sent: Tuesday, July 08, 2014 12:16 AM To: "Hill" <hill at fermot.com.pl> Cc: "Charles Lepple" <clepple at gmail.com>; <nut-upsuser at lists.alioth.debian.org> Subject: Re: [Nut-upsuser] Lupus 500 MEC0003 Problems >> Everything looks fine apart from ups.beeper.status

Centos 6.7 Linux man8.m1.manifest.co.uk 2.6.32-573.12.1.el6.i686 #1 SMP Tue Dec 15 18:25:17 UTC 2015 i686 i686 i386 GNU/Linux Installed: nut.i686 2.6.5-2.el6 @epel nut-cgi.i686 2.6.5-2.el6 @epel nut-client.i686 2.6.5-2.el6 @epel I'm struggling to control an

Thanks for the log - apparently we always get valid (apart from 0.191312) but empty replies, not only for index 0x03, but also for the other queried index (0x0c). I've re-looked at the logs you posted on GitHub, but I don't see anything exotic going on there. Maybe we're missing some sort of handshaking or the like: can you post the whole captures/logs, right from when you plug the

Hi, (please let me know if there is a better place to submit bugs) I run a FreeBSD box with stack-protector enabled, which raises a problem in the upsdrv_initups() function of the newhidups.c module; the regex_array variable is sized one item too small. Regards, Herve Masson <<<< void upsdrv_initups(void) { int i; #ifndef SHUT_MODE /*! * SHUT is only supported by

Strict C99 compilers do not support implicit function declarations or implicit ints, so something like the patch below is needed. Thanks, Florian diff --git a/configure.ac b/configure.ac index 4f68e98a..b5c7a582 100644 --- a/configure.ac +++ b/configure.ac @@ -173,6 +173,9 @@ AC_RUN_IFELSE([AC_LANG_SOURCE([[ #include <fcntl.h> #include <sys/types.h> #include <sys/wait.h>

Thanks again for the logs. Now... let's assume those interrupts are needed to get valid values... well, we can't do exactly the same thing, but let's start from this one: https://github.com/zykh/nut/tree/nutdrv_qx_fabula-zero Please, test nutdrv_qx (with subdriver 'fabula') from that branch and post the output of it running with debug-level of 5.

Matthew, I've looked briefly at the files you uploaded to GitHub and it seems to me that the device is like something that should work with the 'fabula' USB subdriver (and 'megatec' protocol): what are the issues you are experiencing and that prevent the driver to work?

In the past there have been discussions about adding a switch to rsync to preserve the atime on files being copied by rsync. I needed this function for a project I'm working on and decided to invent it. I've attached the diffs. Note that this has the limitations describe in previous emails, namely that preserving atime causes ctime to not be preserved. *** Patch follows *** ***

On Wed, Aug 31, 2016 at 4:19 AM, Matthew Wire <mjw at mjwconsult.co.uk> wrote: > Further analysis it looks like the status string matches the q1 subdriver > but a lowercase "f" is sent to request it instead of "Q1\r". What do you > think? It is certainly possible - there is no comprehensive protocol guide for all these variants. I was hoping we would hear from