similar to: nutdrv-qx powercool 1500VA USB UPS

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

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 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.

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

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?

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.

> 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

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

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

On 22-3-2017 14:37, Charles Lepple wrote: > On Mar 22, 2017, at 9:29 AM, Marc Kessels <marc at kessels.name> wrote: >> Hi Charles, >> >> >> Upsmart version is 1.5, copyright says 2012-2014 > Do you have a direct link? I found UPSmart-DryContact-V3-4.zip and UPSmart-Networking-V2-4.zip via web search, but the dates for the Linux components are ~ 2002. my version

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

The software UPSmart 1.5 is the same as I am using in this thread: http://lists.alioth.debian.org/pipermail/nut-upsdev/2016-November/007248.html (starts in 2016-August) for the powercool 1500VA USB UPS. Have not yet been successful with getting it working with NUT but the symptoms are the same and you may find some of the debug useful from https://github.com/mattwire/powercool-ups If it helps, I

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

Cheers, One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 The gist of it is that "battery.voltage" and "battery.charge" were not always reported correctly with nutdrv-qx driver (might be handled better by blazer drivers though), and the overrides

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

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Cheers, > > One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 > > The gist of it is that "battery.voltage" and "battery.charge" were not always reported

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Cheers, > > One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 > > The gist of it is that "battery.voltage" and "battery.charge" were not always reported

[please use reply-all to include the list on your response] On Jan 23, 2016, at 11:14 AM, Tim Clarke <tim.clarke at manifest.co.uk> wrote: > > 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

On 23/01/16 16:52, Charles Lepple wrote: > [please use reply-all to include the list on your response] > > On Jan 23, 2016, at 11:14 AM, Tim Clarke <tim.clarke at manifest.co.uk> wrote: >> 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

Cheers all, Got an interesting report at https://github.com/networkupstools/nut/issues/2208 about Qx devices that do not respond to NUT unless `upsmart` somehow inits them first (until a re-plug). This behavior is something I've heard of a couple of times, and now there are pcap captures to help smart folks make heads or tails of it and teach `nutdrv_qx` the optionto initialize the UPS