similar to: Dynamix 650 VA USB - broken, have rough fix

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

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

Hi, Has anyone had success with the Dynamix 650VA, that uses the USB cable? I can't get megatec_usb to recognize it, I have tried both stable and development versions. Regards Glen Ogilvie

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

Hi to all! Path send by Brian R. Smith with subject "[Nut-upsdev] Dynamix 650 VA USB - broken, have rough fix" really works! Tested with no-name UPS (works with UPSilon 2000 Windows software) and has USB vendorid=0001 productid=0000 Please, add it to the main branch of blazer_usb.c I belive that several users agree this.

Hi James, I'm referring to your post here: http://lists.alioth.debian.org/pipermail/nut-upsuser/2010-September/006201.html Have you got by chance any more info on the Dyamix 1000VA model? I was foolish to buy the USB version because it had a better display on the front. Is there any way to get this to go? I have tried all the USB drivers in NUT (on pfsense 2.0RC1) and none do anything

Hi Volker Kuhlmann and Richard Nelson, As both of you are interested in where I got up to with getting my Dynamix 1000 VA UPS working with Linux, here is the details. It works.. But not too well, as the driver still seems to need some work, and is not in the main nut source as far as I know. It also seems to sometimes not respond when it should. The manufacture has uses the same format as

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

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

Gidday all - I'm a new user to nut. I've got some cheap powerpal UPSs working fairly well. However I also have a new Dynamix UPS-1700D and an old Powercom KIN-1700 something unit that I cannot make work right. The best method I've found is "trial and error" which sounds a bit last-resort. Is there any better way to find out what protocol is used? -- Criggie

Hello, I have been trying to get a TrippLite Internet Office 750 UPS to talk to my Linux PBX for a couple of evenings now and I'm getting nowhere... I tried searching the list archives before posting here (I'm sure I'm not the first one to try to get this going) but they seem to be offline... The UPS is unfortunately USB based but I thought I'd give it a try anyway. Here is

Hi, I've got two Dynamix UPS's, both of which are USB and don't seem to work with NUT yet. Can anyone give me some advise on where I should start with working on getting them working. I can do a little C programming, so happy to give things a go but need some guidance. Brian R. Smith (who also subscribes to this list) has one as well. I've attached the output of lsusb -v and

Hi Jon, your patches are malformed because (presumably) your email client wrapped this lines. Could you please send these as a unified diff ("diff -u"), and send them in attachments, rather than as a copy-and-paste? Thanks, -- Peter Jon Gough wrote: > > Peter, > Here are the files I have worked on. I hope I have diff'd them > correctly. I have not touched the

Hi everybody, If we let the feature running, it appears that the driver gets unbound after a while ( variable from quarter of hour to 6 hours ) and cannot reconnect. This behavior appear with both MGE Ellipse ASR and non-ASR models with connection to an UHCI and OHCI controllers. The USB core is from 2.4.28 kernel. We use nut-2.0.3. Start, powerfail and recovery detections, UPS shutdown work

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

Charles Lepple writes: > still looking for volunteers to test the libusb-1.0 code on FreeBSD and > other systems. On Fedora 27, running commit 2999c95f0: # nut-scanner Cannot load USB library (/usr/lib64/libusb-1.0.so.0.1.0) : /usr/lib64/libusb-1.0.so.0.1.0: undefined symbol: usb_get_string_simple. USB search disabled. There's also a bug in the configure script on 64 bit

NUT developers, just thought I'd share some notes and ideas on using valgrind against the NUT USB drivers on Linux. Stepping back a bit, I wanted to make sure that the tripplite_usb driver* wasn't using any uninitialized memory, or leaking memory over time. valgrind (specifically, the memcheck tool) runs the code in a special dynamic translator that checks every memory access to see if

Ladies and Gentlemen, Running newhidups with -DD shows the following line that starts with "-> String:" occasionally, with no contect that it is related to: ...... Can't find object UPS.Battery.Temperature -> String: PbAc (len = 4/4) Can't find object UPS.Output.PercentLoad ...... However, running newhidups with -DDD, shows the proper context: ...... hu_find_infoval:

On Nov 26, 2017, at 3:15 PM, Sam Varshavchik wrote: > > Charles Lepple writes: > >> still looking for volunteers to test the libusb-1.0 code on FreeBSD and other systems. > > On Fedora 27, running commit 2999c95f0: Thanks for checking this. I should have been more clear in the second email in the thread, but commit 2999c95f0 is on the original "libusb-1.0"

> >> # nut-scanner >> Cannot load USB library (/usr/lib64/libusb-1.0.so.0.1.0) : /usr/lib64/libusb-1.0.so.0.1.0: undefined symbol: usb_get_string_simple. USB search disabled. > > Although I suspect that the USB portion of nut-scanner could probably be replaced with a small shell script that parses the output of lsusb, this shouldn't be too hard to fix. Logged, in case it