[Nut-upsuser] NUT and non-APCC UPSs doing calibration runs

2015-04-08 Thread Ben Kamen

I'm looking to buy some new UPSs and am thinking of parting ways with APC to 
explore other brands.

Can anyone suggest another brand that handles doing calibration runs (or maybe 
another brand doesn't need them) that I can automate with NUT?

Thanks,

 -Ben

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] nutdrv_qx hangs after send: QS

2015-04-08 Thread Richard Flint
Hi,

Thanks for all the help. I have a spare pcengines ALIX box lying around and
I am going to repurpose that as a dedicated UPS monitoring system.

Regards,
Richard

On Mon, Apr 6, 2015 at 2:27 PM Charles Lepple  wrote:

> On Apr 6, 2015, at 8:46 AM, Richard Flint  wrote:
>
> Unfortunately this approach isn't going to work.
>
> I've done some further research and it would appear that it is the
> underlying ugen device and not libusb that is failing to honor the timeout.
>
> https://mail-index.netbsd.org/tech-misc/2006/03/17/.html
>
> The person above worked around this by having the device opened in non
> blocking mode using the O_NONBLOCK flag but this required changing libusb.
>
>
> Unfortunately, the ugen drivers in Solaris, NetBSD, FreeBSD, etc. are
> similarly named, but not necessarily the same code. At least with the
> *BSDs, you can inspect the code to see what has changed (and the BSD USB
> support has improved significantly across the board since 2006 when that
> message was posted).
>
> OpenUSB seems to work around the blocking issue by creating a separate
> timeout thread, so I still think there is some hope there.
>
> On the other hand, if that doesn't work, I would consider setting up
> another system dedicated to monitoring the UPS, and setup NUT on Solaris to
> be a client to the other system. Linux on x86_64 is probably the best
> supported OS for NUT and a USB UPS, but others have had success with
> embedded ARM and MIPS Linux systems. I have a Soekris net5501 running
> FreeBSD monitoring the USB UPS in my home "data center" in the basement,
> and it has been very reliable: http://soekris.com/products/net5501.html (also
> available in a rack-mount form factor; I have no connection to Soekris
> other than using their equipment)
>
> --
> Charles Lepple
> clepple@gmail
>
>
>
>
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] mge-shut driver fails almost after every reboot

2015-04-08 Thread Arnaud Quette
Hello Panagiotis

2015-04-08 13:38 GMT+02:00 Panagiotis Kritikakos <
panagiotis.kritika...@nikitec.gr>:

>  Hello Arno,
>
> FreeNAS doesn't come with a compiler and I had to compile with the patch
> on FreebBSD-9.3 and then copy the produced mge-shut. Unfortunately it
> didn't work out. For every try I was getting "Connection Refused" and when
> I tried /usr/local/libexec/nut/mge-shut -D -a  I was always
> getting 'No matching HID UPS found'.
>
> I returned back to the USB connection now which seem to work better.
>

sad to hear that we did not worked out the SHUT issue.
but glad to hear to you have a solution! USB is still the path forward.
anyway, if you one day have time to get back on this, let me know, and
we'll see, if the issue is still opened, how to address that.


> Thank you very much for your help anyway.
>

thanks and cheers,
Arno
-- 
Eaton Data Center Automation - Opensource Leader
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] mge-shut driver fails almost after every reboot

2015-04-08 Thread Panagiotis Kritikakos

Hello Arno,

FreeNAS doesn't come with a compiler and I had to compile with the patch 
on FreebBSD-9.3 and then copy the produced mge-shut. Unfortunately it 
didn't work out. For every try I was getting "Connection Refused" and 
when I tried /usr/local/libexec/nut/mge-shut -D -a  I was 
always getting 'No matching HID UPS found'.


I returned back to the USB connection now which seem to work better.

Thank you very much for your help anyway.

Best regards,
Panagiotis

On 7/4/2015 10:20 πμ, Arnaud Quette wrote:

Hi Panagiotis

2015-04-06 9:13 GMT+02:00 Panagiotis Kritikakos 
>:


Hello Arno,

Can apply the patch directly or should I recompile nut?


not sure to fully understand your comment, but...
this is a source code patch, so you indeed have to apply it to the NUT 
source code (from within the source tree, "patch -p1 < 
../path/to/patch_file), and then recompile (make, at least, or configure).
note that the configure flags should be adapted to your specific 
distro to ensure easier testing.

not sure about FreeNas ones, but that can be found in their package repos.

cheers,
Arno
--
Eaton Data Center Automation - Opensource Leader
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr


On 3/4/2015 5:06 μμ, Arnaud Quette wrote:

Hello Panagiotis

2015-04-03 14:28 GMT+02:00 Panagiotis Kritikakos
mailto:panagiotis.kritika...@nikitec.gr>>:

Hello Arno,

Question: have you also tested oldmge-shut?
Otherwise, that might be interesting to do so and send
back the results of these tests...

Yes, I've tried this as well with worse results
unfortunately. This driver seems to be even more unstable.
When it gets able to set communication with the UPS (which is
not always the case), it usually lost it again after a while.

~# /usr/local/libexec/nut/oldmge-shut -DD -a ups-filesrv01
Network UPS Tools - Eaton / SHUT driver 0.70 (2.7.2)
   0.00 debug level is '2'
   0.000882 entering upsdrv_initups()
   0.001019 entering shut_ups_start()

   0.028445 Communication with UPS established
   0.028457 entering shut_get_descriptor(n 21, 9)
   0.111394 shut_wait_ack(): ACK received
   0.185328 entering shut_get_descriptor(n 01, 18)
   0.273455 shut_wait_ack(): ACK received
   0.423238 Device Descriptor:
bLength:0x12
bDescriptorType: 0x01
bcdUSB: 0x0110
bDeviceClass:   0x00
bDeviceSubClass: 0x00
bDeviceProtocol:0x00
bMaxPacketSize0: 0x08
idVendor:   0x0463
idProduct:  0x
bcdDevice: 0x0100
iManufacturer:  0x01
iProduct:0x02
iSerialNumber:  0x03
bNumConfigurations: 0x01

   0.423251 entering shut_get_descriptor(n 22, 1538)
   0.525087 shut_wait_ack(): ACK received
   9.705471 Unable to get Report Descriptor


It there a possibility to be an issue of the UPS, or the
connection between the serial port of the machine and the UPS?



thanks for the confirmation with oldmge-shut. I'm not astonished
on the results, but was worth a try.

I've double checked the related code difference for mge-shut
between 2.7.1 and 2.7.2.
Again, the only diff I see is the one pointed previously
(setline...).
So, it would be great if you could test this patch (through some
reboots) and report back.

Then, I don't think it's an issue with the device.
There is a long run TODO (mentioned in the header of libshut.c)
that is the baudrate negotiation.
The driver still communicates at 2400bauds, which is not that
much for such verbose units. We could go at least for 9600 on
these units, which is 4 times faster already.
This may cause some slowness and behavior issues as you're
experiencing, under some circumstances.
For example, the test using a 5SC750 on Linux (Debian Jessie)
shows that report descriptor (size 1538) takes ~10 seconds to be
retrieved, which is quite long.
Then, even if this "new"mge-shut is a lot better than the
oldmge-shut, it can still be perfected on the error handling (and
not optimal cases), which you may be hitting.
And finally, the notification handling could also help to poll
less the unit, while being notified of critical status changes.

cheers,
Arno
-- 
Eaton Data Center Automation - Opensource Leader

NUT (Network UPS Tools) Project Leader -
http://www.networkupstools.org
Debian Developer - http://www.debian