search for: ariwain

...9;s reported. The win software tells very little about the status of the UPS. This time, I added another capture point, a software running inside the vm (usbsniff), in case for some reason commands sent to the ups where missing. Here are the results (the list would hold large messages): http://www.ariwainer.com.ar/varios/ups/2013-12-21-usbmon-fullcycle.log http://www.ariwainer.com.ar/varios/ups/2013-12-21-usbsniff-fullcycle.log http://www.ariwainer.com.ar/varios/ups/2013-12-21-wireshark-fullcycle.pcapng > Also important are the settings in the UPS monitoring software, such as timeouts, or behavio...

On Dec 20, 2013, at 5:31 PM, Ariel Wainer wrote: > Hi, I just bought a cheap UPS and apparently I'm hitting the same issue > that's described here: > http://comments.gmane.org/gmane.comp.monitoring.nut.user/6146 Maybe I'm getting old, but I wish Gmane hadn't gone with such an unreadable layout for their blog format. (Not your fault, I'm just venting. I suppose I

Hi, I just bought a cheap UPS and apparently I'm hitting the same issue that's described here: http://comments.gmane.org/gmane.comp.monitoring.nut.user/6146 Mine is a different brand: "Kanji" which appears to be the argentinian dealler for some generic chinese manufacturer. My model is also 800VA and identified in the same way, so maybe is the same UPS under a different brand:

Dear Chales, Thanks for your quick reply. I have Raspberry with last Kernel [Linux pi1 3.18.6+ #753 PREEMPT Sun Feb 8 14:47:22 GMT 2015 armv6l GNU/Linux] If <upsdrvctl>, <upsd> and <upsmon> are stopped <nutdrv_atcl_usb> Works well without any error as "Device or resource busy". If I run <upsc> command never receive any value from my ups <upsc ups at

On Feb 9, 2015, at 6:48 AM, PERE (yahoo.es) <pererivers at yahoo.es> wrote: > 0.028188 Can't set USB configuration: could not set config 1: Device or resource busy > 0.029246 detached kernel driver from USB device... > 0.030559 USB device [0001:0000] opened > 0.866216 read: (8 bytes) => 03 00 00 00 00 00 00 00 > 0.866413 reply[0] = 0x03

On 21/12/13 21:31, Ariel Wainer wrote: > > Ok, I did this, here is how it went (approximately): > t=0 power on the UPS, with some load. > t=2 min unplug the UPS from mains, alarm goes off. > t=33 min low battery alarm goes off. > t=35 min ups powers down. > Ok, trying to make sense of the capture (again: it's all guessing, I have no experience with usb protocol): Up

On 22/12/13 16:48, Charles Lepple wrote: > > Also, there is an Interrupt Out transfer at #4115/2154 (repeated at #4117) that sends a 0x01 down to the UPS. I assume it turns off at that point, or shortly thereafter? Sorry for the the delay, If I remember correctly, that's what happened. >> It looks simillar to the UPS implementation example from >>

On 27/12/13 00:06, Charles Lepple wrote: > Could you please send the debug output? (if it is more than ~ 30KB > gzipped, just send it directly to me.) I was going to use the debug > output from the earlier thread to generate those C files, but yeah, > there are some additional bits needed. If nothing else, it would be > good to improve the diagnostics for that script. Here's

On 01/01/14 17:33, Charles Lepple wrote: > Disappointing. I will add a note in the man page for that, too. (Maybe > it is only after the UPS is in the low battery state? You mentioned > that it did shut down when you did the capture with the Windows > software.) Yes, but I think it was because the battery was depleted. Let me know if further testing is needed. Cheers!

On 17/01/14 23:47, Charles Lepple wrote: > On Jan 17, 2014, at 6:31 PM, Ariel Wainer wrote: > >> On 17/01/14 01:13, Charles Lepple wrote: >>> >>> The rule in my config was: >>> >>> ATTR{idVendor}=="0001", ATTR{idProduct}=="0000", MODE="664", GROUP="nobody" >>> >>> I have to add OWNER=nobody or

On 17/01/14 01:13, Charles Lepple wrote: > > Good point. I forgot that the permissions errors would happen after the numeric device IDs were matched. > > I just pushed 3c13603. Tested by telling the driver to match a random USB device instead of 0001:0000, and sure enough, when the driver didn't have write access, the unpatched code crashed. Not sure I want to try and send UPS

On 01/01/14 16:12, Charles Lepple wrote: > On Jan 1, 2014, at 1:52 PM, Ariel Wainer wrote: > >> Very strange! It seems like the completly powered down and OK status >> yeild the same reading. The reading didn't change after plugging back in >> the AC. > Well, as strange as that is, I don't think it would be a common case. Ordinarily, the load would be the

On 11/01/14 15:27, Charles Lepple wrote: > On Jan 10, 2014, at 4:46 PM, Ariel Wainer wrote: > >> On 10/01/14 01:53, Charles Lepple wrote: >>> I am curious about why the Interrupt Out packet is sent by the Windows software if it isn't to turn off the UPS. Is it possible to do some more testing with shorter timeouts so that the battery doesn't get depleted? You would

On 10/01/14 01:53, Charles Lepple wrote: > I am curious about why the Interrupt Out packet is sent by the Windows software if it isn't to turn off the UPS. Is it possible to do some more testing with shorter timeouts so that the battery doesn't get depleted? You would need to record the exact time when it shuts down, I think. Sure, I will do the test during the weekend. I'm not

On 31/12/13 21:00, Charles Lepple wrote: > > There is a very proof-of-concept-y driver (nutdrv_atcl_usb) in the atcl branch in GitHub. > > We can probably remove a bunch of the retry loops that it inherited from richcomm_usb. > > There should also be a tarball here fairly soon: > > http://buildbot.networkupstools.org/public/nut/builders/Debian-x64-gcc/builds/115 >

One small comment: When the driver has no permission to access the device, it exits with a segmentation fault, it would be nice to have a more informative error. I'm not really sure if the issue is speciffic to this driver or is it general. I attached the output of an strace with the driver crashing. Best regards. -------------- next part --------------