On Sep 8, 2016, at 10:05 AM, Vassilis Virvilis wrote:
> Now that's a problem. I am not sure that I can find
>
> 1) the original software
> 2) a (physical) windows machine in the vicinity of the UPS
>
> I will give it a try but for now looks like a dead end. I have 3 of these
> UPS. Two of them h
Thank you VERY much, Roger, for your detailed explanations. I'm going to choose
to heed your warning.
> On Thu, 8 Sep 2016, Jeff Bowman wrote:
>
> > 1. CLI error: I get an error when running ‘upsdrvctl start’: “Can't
> > claim USB device [051d:0003]: libusb0-dll:err [claim_interface] could not
>
On 09/08/2016 10:46 AM, Roger Price wrote:
>
> Pessimist: Whenever OB is received, start timers to shut down the
> server after a short interval. Expect wall power to return and then
> fail again. Hope that the battery will recover enough between failures
> for the next shutdown. This is for peop
On Thu, 8 Sep 2016, Jeff Bowman wrote:
I’ve been able to get the latest Windows port installed on my Hyper-V 2012 R2
instance and start the service.
But as I’m an absolute beginner I’m not sure how to proceed further. I’ve
browsed the archives, but discussions here tend to assume at least an
> You could also try adding "-x usb_set_altinterface" to the command line
> (or adding it to ups.conf). The lsusb output implies that the only valid
> setting is 0 (bAlternateSetting), but it might need to be set explicitly.
I checked with -x usb_set_altinterface and it says
nut_usb_set_altin
I've been able to get the latest Windows port installed on my Hyper-V 2012 R2
instance and start the service.
But as I'm an absolute beginner I'm not sure how to proceed further. I've
browsed the archives, but discussions here tend to assume at least an
intermediate level of understanding; thus
On Sep 8, 2016, at 9:25 AM, Vassilis Virvilis wrote:
>
> + failed to claim USB device: could not claim interface 0: Device or
> resource busy
> + detached kernel driver from USB device...
> nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0)
> HID descriptor, method 1: (9 bytes) =>
[snip hex dump analysis]
>
> It is possible that the blazer_usb driver initialization has put the UPS
> into a bad state. If you can schedule some downtime, you might want to try
> usbhid-ups again after powering the UPS down completely and unplugging it
> for a little while. (Often, a few seconds
On Sep 8, 2016, at 8:14 AM, Vassilis Virvilis wrote:
>
> Hi again,
>
> Thanks for the prompt reply.
>
> Just for the record i am running debian unstable/sid with nut 2.7.4-3
>
Thanks, that is useful.
> 0.447725refresh_report_buffer: expected 13 bytes, but got 8 instead
This is the firs
Hi again,
Thanks for the prompt reply.
Just for the record i am running debian unstable/sid with nut 2.7.4-3
# dpkg -l 'nut*' | grep ^ii
ii nut 2.7.4-3 all network UPS tools
- metapackage
ii nut-client2.7.4-3 amd64network UPS too
On Sep 8, 2016, at 4:26 AM, Vassilis Virvilis wrote:
>
> The 1000 (bcdUSB 1.00) works with blazer_usb while the 1500 (bcdUSB 1.10)
> doesn't.
>
>From the lsusb descriptor output, the 1500 seems to implement the HID Power
>Device Class (PDC) spec - so it might be possible to adapt usbhid-ups to
Hi,
I have two ups (Turbo-X 1000SD, Turbo-X 1500SD). The both report
themselves as
# lsusb
Bus 008 Device 002: ID 0001: Fry's Electronics
The are produced by MEC and report MEC0002 as product (although the
working one report it in dmesg but not in lsusb)
The 1000 (bcdUSB 1.00) works with bl
12 matches
Mail list logo
