Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Arnaud Quette]

Hi Manuel,

2017-06-14 15:16 GMT+02:00 Manuel Wolfshant <wo...@nobugconsulting.ro>:

> Hello
>
>
>
> On 06/14/2017 03:32 PM, Arnaud Quette wrote:
>
>
>
> On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wo...@nobugconsulting.ro>
> wrote:
>
>> >
>>> >If that matters, the OS is a fully updated CentOS 6.9 and this
>>> (latest stable ) version of nut was packaged by me. The problem appears on
>>> any of the USB ports ( well, I tried the 2 in front and one in the back of
>>> the server ).
>>> >
>>> > lsusb -v reports:
>>> ...
>>> >  wDescriptorLength 549
>>> >  Warning: incomplete report descriptor
>>> >  Report Descriptor: (length is 9)
>>> >Item(Main  ): (null), data=none
>>>
>>> Because both NUT and lsusb are having trouble retrieving the HID Report
>>> Descriptor, I think the problem is at a lower level: probably between the
>>> UPS, the kernel, and the USB HCI. The archives have a number of unresolved
>>> emails about the 5E and "broken pipe" errors.
>>>
>>> Probably worth checking with Eaton, too.
>>>
>>
>> Charles is right in both the fact that the issue is (or at least seems to
>> be) upstream to NUT, and also that it's worth checking with "Eaton"
>>
>>
>> I've approached "them" ( apparently my request for supported landed
>> at after-sales support/Romania ) as soon as Charles replied. Unfortunately
>> the "dialogue" rather stalls, they seem to have a policy to not send more
>> than one email every 3 days. Leaving aside that after telling them that I
>> am using an *USB *unit (and providing USB-related logs ) they wanted to
>> know if I was using *SNMP*.
>>
>
> no comments ;)
>
>  still no reply from them ...
>

is the guy you contacted Paul Henri?


>
>
>> Could you please tell me your kernel
>>
>> [root@belgrade ~]# uname -r
>> 2.6.32-696.3.1.el6.x86_64
>>
>
> that may be part of the issue... long time I've not tried the 2.x series,
> not sure how it goes nowadays.
> btw, any interesting "usb" messages from your syslog?
> also, would you be able to test with a 3.x or 4.x, at least to see if that
> improves / solves the issue?
>
> It's a bit tricky. I tried to use the kernel-lt package from the elrepo
> repository ( incidentally I am also part of the elrepo team but I am in
> charge with other packages, not the kernels ) and failed miserably. For
> reasons unknown to me ( and not logged ) the system failed to boot and a
> colleague from that office had to manually make it use the stock CentOS
> kernel ( typing what I was dictating to him over the phone .. )
> Due to a complete lack of logs, I have absolutely no idea what happened
> and since the machine is critical for the activity there, I am a bit
> reluctant to try again
>
>
>
> Would you also be able to test some github code?
>> We have the libusb-1.0 branch that provides both libusb 1.0 support
>> (interesting to test to see if the problem still happens) along with few
>> other improvements (though these should not help for your issue):
>> https://github.com/networkupstools/nut/tree/libusb-1.0
>>
>> I can and I will test ( tomorrow, probably ).
>>
>
> I just packaged and tested it ( see below some comments, not important for
> my issue here )
> Unfortunately there is no change in the output:
>
> [root@belgrade ~]#u root -x explore -x vendorid="0463" -a eaton
> Network UPS Tools - Generic HID driver 0.42 (2.7.4.1)
> USB communication driver (libusb 0.1) 0.33
>0.00 [D1] debug level is '4'
>0.012088 [D1] upsdrv_initups...
>8.248213 [D2] Checking device (0463/) (002/004)
>9.249069 [D2] - VendorID: 0463
>9.249094 [D2] - ProductID: 
>9.249129 [D2] - Manufacturer: unknown
>9.249135 [D2] - Product: unknown
>9.249140 [D2] - Serial Number: unknown
>9.249145 [D2] - Bus: 002
>9.249151 [D2] - Device release number: 0001
>9.249156 [D2] Trying to match device
>9.249199 [D2] Device matches
>9.249209 [D2] failed to claim USB device: could not claim interface
> 0: Device or resource busy
>9.249373 [D2] detached kernel driver from USB
> device...
>9.249394 [D3] nut_usb_set_altinterface: skipped
> usb_set_altinterface(udev, 0)
>9.249991 [D2] Unable to get HID descriptor (error sending control
> message: Broken pipe)
>9.250002 [D3] HID descriptor length (method 1)
&g

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Arnaud Quette]

2017-06-13 17:49 GMT+02:00 Manuel Wolfshant <wo...@nobugconsulting.ro>:

> On 06/13/2017 05:48 PM, Arnaud Quette wrote:
>
> Hi Manuel
>
>
> Hi Arno
>
>
Hi Manuel

>
>
> 2017-06-07 14:40 GMT+02:00 Charles Lepple <clep...@gmail.com>:
>
>> On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wo...@nobugconsulting.ro>
>> wrote:
>> >
>> >If that matters, the OS is a fully updated CentOS 6.9 and this
>> (latest stable ) version of nut was packaged by me. The problem appears on
>> any of the USB ports ( well, I tried the 2 in front and one in the back of
>> the server ).
>> >
>> > lsusb -v reports:
>> ...
>> >  wDescriptorLength 549
>> >  Warning: incomplete report descriptor
>> >  Report Descriptor: (length is 9)
>> >Item(Main  ): (null), data=none
>>
>> Because both NUT and lsusb are having trouble retrieving the HID Report
>> Descriptor, I think the problem is at a lower level: probably between the
>> UPS, the kernel, and the USB HCI. The archives have a number of unresolved
>> emails about the 5E and "broken pipe" errors.
>>
>> Probably worth checking with Eaton, too.
>>
>
> Charles is right in both the fact that the issue is (or at least seems to
> be) upstream to NUT, and also that it's worth checking with "Eaton"
>
>
> I've approached "them" ( apparently my request for supported landed at
> after-sales support/Romania ) as soon as Charles replied. Unfortunately the
> "dialogue" rather stalls, they seem to have a policy to not send more than
> one email every 3 days. Leaving aside that after telling them that I am
> using an *USB *unit (and providing USB-related logs ) they wanted to know
> if I was using *SNMP*.
>

no comments ;)

>
> Could you please tell me your kernel
>
> [root@belgrade ~]# uname -r
> 2.6.32-696.3.1.el6.x86_64
>

that may be part of the issue... long time I've not tried the 2.x series,
not sure how it goes nowadays.
btw, any interesting "usb" messages from your syslog?
also, would you be able to test with a 3.x or 4.x, at least to see if that
improves / solves the issue?


>
> and libusb (0.1) version?
>
> [root@belgrade ~]# rpm -qa libusb
> libusb-0.1.12-23.el6.x86_64
>
>
>
> Would you also be able to test some github code?
> We have the libusb-1.0 branch that provides both libusb 1.0 support
> (interesting to test to see if the problem still happens) along with few
> other improvements (though these should not help for your issue):
> https://github.com/networkupstools/nut/tree/libusb-1.0
>
> I can and I will test ( tomorrow, probably ).
>
>
> Don't hesitate if you need more guidance for trying this branch.
>
> Do you happen to know how can I find the version of firmware run by the
> UPS, in _my_ conditions ( remote + the previously mentioned errors) ?
>

don't bother too much, in the end, such request only get an answer once it
has reached me ;)


> The guys who contacted me from Eaton did not reply yet to my email sent
> yesterday.
>

that requires the driver to be running, then it's published as ups.firmware.
as per my upsc output above (in my case): ups.firmware: 02.06.0019


>
> FYI, I've just made a test with the same unit, on a Debian jessie (kernel
> 3.16.43-2, libusb 0.1.12-25) both with 2.7.4 and the latest git master, and
> it works fine:
>
> battery.charge: 62
> battery.runtime: 2725
> battery.type: PbAc
> device.mfr: EATON
> device.model: 5E 1500i
> device.type: ups
> driver.name: usbhid-ups
> [...]
>
> I was expecting it to work fine, given https://risc-a-day.blogspot.
> ro/2014/09/getting-my-ups-to-work-with-linux.html ( before the purchase I
> assumed the units to be similar, modulo the maximum power )
>

you shouldn't be that far...


>
> cheers,
> Arno
>
> thanks a lot. I will come back with more data once I test the github code
> ( yes, I know, everybody hates this kind of threats :) )
>

looking forward to get news so ;)

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] Unable to use nut-2.7.4 with Eaton 5E1500I USB

[Arnaud Quette]

Hi Manuel

2017-06-07 14:40 GMT+02:00 Charles Lepple :

> On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant 
> wrote:
> >
> >If that matters, the OS is a fully updated CentOS 6.9 and this
> (latest stable ) version of nut was packaged by me. The problem appears on
> any of the USB ports ( well, I tried the 2 in front and one in the back of
> the server ).
> >
> > lsusb -v reports:
> ...
> >  wDescriptorLength 549
> >  Warning: incomplete report descriptor
> >  Report Descriptor: (length is 9)
> >Item(Main  ): (null), data=none
>
> Because both NUT and lsusb are having trouble retrieving the HID Report
> Descriptor, I think the problem is at a lower level: probably between the
> UPS, the kernel, and the USB HCI. The archives have a number of unresolved
> emails about the 5E and "broken pipe" errors.
>
> Probably worth checking with Eaton, too.
>

Charles is right in both the fact that the issue is (or at least seems to
be) upstream to NUT, and also that it's worth checking with "Eaton"

Could you please tell me your kernel and libusb (0.1) version?

Would you also be able to test some github code?
We have the libusb-1.0 branch that provides both libusb 1.0 support
(interesting to test to see if the problem still happens) along with few
other improvements (though these should not help for your issue):
https://github.com/networkupstools/nut/tree/libusb-1.0

Don't hesitate if you need more guidance for trying this branch.

FYI, I've just made a test with the same unit, on a Debian jessie (kernel
3.16.43-2, libusb 0.1.12-25) both with 2.7.4 and the latest git master, and
it works fine:

battery.charge: 62
battery.runtime: 2725
battery.type: PbAc
device.mfr: EATON
device.model: 5E 1500i
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4.1
driver.version.data: MGE HID 1.42
driver.version.internal: 0.42
input.voltage: 240.0
outlet.1.status: on
outlet.desc: Main Outlet
outlet.id: 1
outlet.switchable: no
output.frequency: 49.9
output.frequency.nominal: 50
output.voltage: 241.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 02.06.0019
ups.load: 0
ups.mfr: EATON
ups.model: 5E 1500i
ups.power.nominal: 1500
ups.productid: 
ups.start.battery: yes
ups.status: OL
ups.timer.shutdown: -1
ups.vendorid: 0463

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error

[Arnaud Quette]

2017-04-04 15:37 GMT+02:00 Jon Bendtsen <jon.bendt...@jonix.dk>:

> On 04/04/17 15.19, Arnaud Quette wrote:
>
>>
>>
> [cuuut]
>
> there is a Github issue: https://github.com/networkupstools/nut/issues/415
>> + a branch with the implementation:
>> https://github.com/networkupstools/nut/tree/upsmon_alarm
>>
>> For now:
>> - upsmon can react on the ALARM notify type, as with other events, and
>> WALL+SYSLOG+EXEC...
>> - I've also fixed the CGI to expose the ALARM flag, which was not done.
>>
>> A possible improvement would be to send the content of ups.alarm, but that
>> requires more thinking and time.
>> And the current implementation already points at this data.
>>
>> @Jon: would you be able to test this branch and ack? (including the
>> "covers (or
>> not) my needs...)
>>
>
> yeah, I can do that, but I'd prefer to wait a few days and test with a
> machine that does nothing else and with NUT software that my main servers
> does not rely on.
>
> I've just ordered a new Eaton 5SC 1500i as a replacement because it is
> listed as very well supported. Once it gets here I'll get the broken UPS
> free and I'll install the NUT software on a test machine.
>

Hi Jon,

thanks for your feedback, and for selecting Eaton for your new UPS.
Keep me updated of your tests results.

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error

[Arnaud Quette]

2017-04-04 14:18 GMT+02:00 Jon Bendtsen <jon.bendt...@jonix.dk>:

> On 04/04/17 14.10, Roger Price wrote:
>
>> On Tue, 4 Apr 2017, Arnaud Quette wrote:
>>
>>
> [cut]
>
> Hi Arnaud, It seems to me that, looking out into the future, there are
>> three
>> things upsmon needs:
>>
>> 1. A fall-through  of "UNKNOWN" so that all status changes,
>> no
>> matter how wierd, can be caught.  Such a catch-all  would
>> also have
>> caught the "ALARM" from the old battery.
>>
>> 2. A UPS specific option in the NOTIFYFLAG and NOTIFYMSG declarations as
>> already
>> provided by the AT declaration in upssched.conf.  This would make it
>> possible to
>> have messages and action specific to a UPS, in a multi-UPS configuration.
>>
>> I would like to be able to specify
>>
>>NOTIFYMSG myups@localhost  ONBATT "%s: local UPS on battery"
>>NOTIFYMSG bigups@serverONBATT "%s: Server room alert: UPS on
>> battery"
>>
>>NOTIFYFLAG myups@localhost ONBATT SYSLOG+EXEC+WALL
>>NOTIFYFLAG heartbeat@localhost ONBATT SYSLOG+EXEC
>>
>> 3. A  "ALARM" as you propose.
>>
>
> good ideas
>

there is a Github issue: https://github.com/networkupstools/nut/issues/415
+ a branch with the implementation:
https://github.com/networkupstools/nut/tree/upsmon_alarm

For now:
- upsmon can react on the ALARM notify type, as with other events, and
WALL+SYSLOG+EXEC...
- I've also fixed the CGI to expose the ALARM flag, which was not done.

A possible improvement would be to send the content of ups.alarm, but that
requires more thinking and time.
And the current implementation already points at this data.

@Jon: would you be able to test this branch and ack? (including the "covers
(or not) my needs...)

thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] Is a timer a file?

[Arnaud Quette]

Hi Roger,

2017-03-28 15:07 GMT+02:00 Roger Price <ro...@rogerprice.org>:

> Hi Arnaud,
>
> On Wed, 22 Mar 2017, Arnaud Quette wrote:
>
>   The technique is very general and is to send SIGUSR1/SIGUSR2 to the
>> upsd daemon.  SIGUSR1 and SIGUSR2 are events just like ONBATT and ONLINE.
>>   The patch runs successfully on my opensuse 13.2 box, and solves my
>> problem. In upssched.conf I now have declarations such as
>>
>>  AT SIGUSR1 * CANCEL-TIMER shutdown-timer
>>
>>   Will my patches be included in NUT?
>>
>> I've quickly checked your 2 patches.  The solution seems to me not broad
>> enough for injecting upstream. This works nice for a single device / UPS
>> setup, but would not make it when there are more devices, as I get it.
>>
>
> True, I use SIGUSR1 and SIGUSR2 which do not allow a payload such as a UPS
> unit name.  That would require SIGQUEUE, which accepts integers and
> pointers to other values (such as UPS unit names), but a Bash script can
> only send integers with SIGQUEUE.  Sending pointers to UPS unit names would
> require a new C program.  This would be a good programming exercise, but
> no-one has asked for such a facility in NUT.
>
> I suspect that only a small percentage of NUT users use upssched timers.
>
> At first sight, I would more see something injecting into the PIPEFN fifo,
>> i.e. acting the same way upsmon would when calling upssched with the
>> upsname and the triggering event.
>> I think that this can be solved more easily with tools like socat or nc,
>> sending the command directly to the pipe. For example, to cancel the timer
>> "shutdown-timer" from the upssched-cmd script, you would:
>>
>>echo "CANCEL shutdown-timer" | socat -
>> UNIX-CLIENT:/var/run/nut/upssched.pipe
>>
>
> What a hack! :-) Sure, it is possible to do clever things with such tools,
> but I wanted something that used the .conf files to express the
> configuration.
>
> I also considered using a dummy UPS with a .dev script written and erased
> as needed by a Bash script.
>
> Please tell me back if such solution would make it for you.
>>
>
> For the moment I will stick with my SIGUSR patches.
>
> I also realize that the distributed sample configuration and scripts do
>> not fully match the doc. I'll make another round of update for this, still
>> on the same branch.
>>
>
> I would warmly welcome your help to complete the documentation, both with
>> part of your patches that make sense,
>>
>
> I think the user documentation would benefit from an explanation that
> there are two possible approaches to NUT configuration: Simple/optimistic,
> without timers, and pessimistic with timers.  And then a complete, fully
> worked example of the NUT setup for the simplest usage based on OB and LB
> (no timers).  The example on my website covers the pessimistic (with
> timers) approach only.
>
> along with the above solution if it's good too.
>>
>
> I would not recommend putting a technique based on socat/nc/netcat in the
> NUT user documentation, but perhaps under a heading such as "Debugging" it
> would be worth having it in the Developer Guide.
>

would you be kind enough to complete the ticket on Github, so that we track
and address this after 2.7.5?
https://github.com/networkupstools/nut/issues/293

I'm intending to finally release it soon, and to have more doc improvement
for the next release.
And your help is definitely welcome!

thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] upsd/upsc, LISTEN and hostname resolution in master/slave

[Arnaud Quette]

2017-03-29 12:32 GMT+02:00 Arnaud Quette <arnaud.que...@gmail.com>:

>
>
> 2017-03-29 5:49 GMT+02:00 Spike <sp...@drba.org>:
> (...)
>
>> Is this really the desired behavior? I can certainly work with it, but it
>> seems it'd be nice if it could work with dns resolution (at least client
>> side, the LISTEN statement I guess it's ok), but maybe I'm missing some
>> good reason why this would cause other issues.
>>
>
> this is indeed undocumented (will fix it after this mail and a quick
> lunch), but that works
>

I've clarified a bit:
https://github.com/networkupstools/nut/commit/e83780337183d5369f892891df08775198231fe0

I'm interested in some feedback on whether this clarifies enough or not...

thanks and cheers,
Arno
--
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] upsd/upsc, LISTEN and hostname resolution in master/slave

[Arnaud Quette]

2017-03-29 5:49 GMT+02:00 Spike :

> Hi,
>

Hi again Spike ;)

I've been setting up a few Eatons 1500 USB in master/slave mode and run
> into what I'm thinking is a hostname resolution problem.
>
> Basically, to avoid hardcoding ips, I'd love to be able to add a LISTEN on
> the lan's ip which has hostname, let's say, server1.local .
>
> If I set up upsd.conf such as LISTEN server1.local 3493 what I end up with
> is upsd listening on 127.0.0.1 . I'm guessing it gets this value from
> /etc/hosts which overrides server1.local dns resolution.
>

probably /etc/hosts indeed.
however, server1 should resolve to a non local IP@, so that one should work
(need DNS resolution, possibly through DHCP bridging)

So basically if I want it to listen on anything other than localhost I need
> to hardcode an ip in upsd.conf or add a line to /etc/hosts, which is not
> quite convenient if the computer gets its ip from dhcp.
>

no
simply add 1 or more LISTEN lines, with the DNS resolvable names (if DHCP
served)


> What's more, it seems that upsc does the same thing, so if I have a line
> such as:
> MONITOR eaton@server1.local ... that will fail if I specified the
> external ip. However this will succeed from the slave, because there's no
> server1.local in /etc/hosts I'm guessing so the name resolves to the same
> ip in the LISTEN.
>

upsd serves the data to the rest of the world, i.e. all NUT clients,
including upsc / upsrw / upscmd / upsmon
so the LISTEN line(s) impacts all these


> Is this really the desired behavior? I can certainly work with it, but it
> seems it'd be nice if it could work with dns resolution (at least client
> side, the LISTEN statement I guess it's ok), but maybe I'm missing some
> good reason why this would cause other issues.
>

this is indeed undocumented (will fix it after this mail and a quick
lunch), but that works

LISTEN myhostname.domain1
LISTEN myhostname.domain2

We once had ACL (ACCEPT / REJECT) to refine the job, but that's really a
firewall job ;)

So another approach is to "LISTEN 0.0.0.0" (i.e. everything) and use your
firewall to restrict INPUT interfaces.

Hope it helps,
cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] Eaton 1500 USB constant disconnections

[Arnaud Quette]

Hi Spike

2017-03-29 5:38 GMT+02:00 Spike <sp...@drba.org>:

> Arno, thanks for taking the time to write back and no worries about lag,
> we're all busy and I'm grateful there is a community to interact with to
> begin with.
>
> You're right - the problem went away once I actually configured nut. I
> guess I was too "cautious" and when I saw the errors I thought something
> was wrong with the usb connection and didn't try to get nut going assuming
> it'd failed. Eventually debugging through systemd/udev I realized it was
> indeed the device initiating a connection and found out about the pong from
> the UPS.
>

thanks for the confirmation.

thanks again and maybe worthwhile to have this documented somewhere,  not
> sure, maybe the ML archive will work for that.
>

the mail archive is indeed here for that.

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

best,
>
> Spike
>
> On Tue, Mar 28, 2017 at 2:46 AM Arnaud Quette <arnaud.que...@gmail.com>
> wrote:
>
>>
>> 2017-03-11 4:55 GMT+01:00 Spike <sp...@drba.org>:
>>
>> Hi,
>>
>>
>> Hi Spike,
>>
>> sorry for the lag in answering, I was collecting the needed information.
>>
>> I have a eaton 1500 that connects to an Ubuntu Xenial box via USB. The
>> UPS works, however exactly *ever 5 minutes* it disconnects and reconnects
>> and I see this in syslog:
>>
>> Mar 10 19:50:32 spike kernel: usb 4-5: USB disconnect, device number 103
>> Mar 10 19:50:33 spike kernel: usb 4-5: new low-speed USB device number
>> 104 using ohci-pci
>> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device found,
>> idVendor=0463, idProduct=
>> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device strings: Mfr=1,
>> Product=2, SerialNumber=4
>> Mar 10 19:50:34 spike kernel: usb 4-5: Product: Ellipse PRO
>> Mar 10 19:50:34 spike kernel: usb 4-5: Manufacturer: EATON
>> Mar 10 19:50:34 spike kernel: usb 4-5: SerialNumber: P344G46HW9
>> Mar 10 19:50:38 spike kernel: hid-generic 0003:0463:.1221:
>> hiddev0,hidraw2: USB HID v1.10 Device [EATON Ellipse PRO] on
>> usb-:00:12.0-5/input0
>>
>> does anybody have any clue why that's happening? besides spamming the
>> logs I'm afraid that it may not reconnect at some point and/or fail when
>> it's actually needed.
>>
>>
>> this is a workaround implemented to avoid, under some specific
>> conditions, a freeze of the USB communication.
>> As far as I've been told, when there is an actual SW communication (such
>> as with NUT) with requests and replies in the 5mn timeframe, this should
>> not occur.
>>
>> Could you please:
>> - confirm back that there is indeed a SW communication setup (NUT or
>> UPower for example),
>> - send me back the upsc output for this unit, including the serial number
>> and firmware revision
>>
>> thanks and regards,
>> Arno
>>
>>
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Eaton 1500 USB constant disconnections

[Arnaud Quette]

2017-03-11 4:55 GMT+01:00 Spike :

> Hi,
>

Hi Spike,

sorry for the lag in answering, I was collecting the needed information.

I have a eaton 1500 that connects to an Ubuntu Xenial box via USB. The UPS
> works, however exactly *ever 5 minutes* it disconnects and reconnects and I
> see this in syslog:
>
> Mar 10 19:50:32 spike kernel: usb 4-5: USB disconnect, device number 103
> Mar 10 19:50:33 spike kernel: usb 4-5: new low-speed USB device number 104
> using ohci-pci
> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device found,
> idVendor=0463, idProduct=
> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device strings: Mfr=1,
> Product=2, SerialNumber=4
> Mar 10 19:50:34 spike kernel: usb 4-5: Product: Ellipse PRO
> Mar 10 19:50:34 spike kernel: usb 4-5: Manufacturer: EATON
> Mar 10 19:50:34 spike kernel: usb 4-5: SerialNumber: P344G46HW9
> Mar 10 19:50:38 spike kernel: hid-generic 0003:0463:.1221:
> hiddev0,hidraw2: USB HID v1.10 Device [EATON Ellipse PRO] on
> usb-:00:12.0-5/input0
>
> does anybody have any clue why that's happening? besides spamming the logs
> I'm afraid that it may not reconnect at some point and/or fail when it's
> actually needed.
>

this is a workaround implemented to avoid, under some specific conditions,
a freeze of the USB communication.
As far as I've been told, when there is an actual SW communication (such as
with NUT) with requests and replies in the 5mn timeframe, this should not
occur.

Could you please:
- confirm back that there is indeed a SW communication setup (NUT or UPower
for example),
- send me back the upsc output for this unit, including the serial number
and firmware revision

thanks and regards,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] Fatal EEPROM fault!

[Arnaud Quette]

2017-03-27 13:47 GMT+02:00 Sonic <sonicsm...@gmail.com>:

> On Mon, Mar 27, 2017 at 3:04 AM, Arnaud Quette <arnaud.que...@gmail.com>
> wrote:
> > as per confirmation from Eaton support team, and looking at the link
> above,
> > the latest FW is "02.12.0025".
>
> Hi Arno,
>

Hi Chris,

According to that link, unless I'm missing something, as the 5P2200RT
> is a 2U sized unit (2 rack spaces) the proper firmware should be
> "03.00.". Firmware "02.12.0025" is listed for 1U sized units.
>

ah, true, sorry. I got confused by the French filter, which only displays
the 1U units (up to 1550)
so indeed, the latest version for your unit is "03.00.".
sorry for the confusion!

> This FW upgrade may fix the EEPROM fault too, but it's not yet confirmed.
>
> > Please update me if you go through this upgrade.
>
> I certainly will - but it's quite problematic as there are no Windows
> systems in the server room. It's a bit unfathomable that in 2017 a
> manufacturer doesn't fully support such critical functions from a 'nix
> box.
>

fully shared feeling.
It's still a chicken and egg thing, where users like you have to report to
support / sales representatives this need for Linux FW upgrade, so that
such things can be considered for the development / release roadmaps.

thanks for your support and understanding,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] Fatal EEPROM fault!

[Arnaud Quette]

Hi Chris

2017-03-23 16:58 GMT+01:00 Sonic :

> On Thu, Mar 23, 2017 at 11:26 AM, Gene Heskett 
> wrote:
> > Have you the file to be used to update the EEPROM with?
>
> Eaton shows a firmware file:
> https://powerquality.eaton.com/Support/Software-Drivers/
> Downloads/5P-UPS-firmware.asp
>
> However I'm not sure if it is for the questionable EEPROM and if so
> maybe it is downlevel from the current reported firmware.
> upsc shows:
> ups.firmware: 04
>
> and the file is apparently:
> V03.00.
>
> Chris
> 
>

as per confirmation from Eaton support team, and looking at the link above,
the latest FW is "02.12.0025".

This FW upgrade may fix the EEPROM fault too, but it's not yet confirmed.

Please update me if you go through this upgrade.

Thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] Fatal EEPROM fault!

[Arnaud Quette]

2017-03-23 16:26 GMT+01:00 Gene Heskett :

> On Thursday 23 March 2017 09:29:55 Sonic wrote:
>
> > Hello,
> >
> > Sorry if any of this is obvious - I'm new to NUT.
> >
> > NUT via upsc is displaying (edited for length):
> >
> > device.model: Eaton 5P 2200
> > device.type: ups
> > driver.name: usbhid-ups
> > ups.alarm: Fatal EEPROM fault!
> > ups.status: ALARM OL CHRG
> > ups.test.interval: 604800
> > ups.test.result: Done and passed
> > driver.version: 2.7.2
> > driver.version.data: MGE HID 1.33
> > driver.version.internal: 0.38
> >
> > Is this possibly a firmware or configuration issue?
> >
> > Does NUT report the firmware version (it's not jumping out at me in
> > the upsc output)?
> >
> > Can NUT upgrade the firmware on this device? Eaton only seems to have
> > instructions for a Windows box.
> >
> > Thank you,
> >
> > Chris
> >
> Linux has a dfu-util, device firmware updater. But I've no clue if eaton
> would allow access to do that via its USB interface.  This is obviously
> independent from Nut.
>
> Have you the file to be used to update the EEPROM with?
>
> Here is its help screen, mat or may not be usefull.
> Usage: dfu-util [options] ...
>   -h --help Print this help message
>   -V --version  Print the version number
>   -v --verbose  Print verbose debug statements
>   -l --list List the currently attached DFU capable
> USB devices
>   -d --device vendor:productSpecify Vendor/Product ID of DFU device
>   -p --path bus-port. ... .port Specify path to DFU device
>   -c --cfg config_nrSpecify the Configuration of DFU device
>   -i --intf intf_nr Specify the DFU Interface number
>   -a --alt alt  Specify the Altsetting of the DFU Interface
> by name or by number
>   -t --transfer-sizeSpecify the number of bytes per USB
> Transfer
>   -U --upload file  Read firmware from device into 
>   -D --download fileWrite firmware from  into device
>   -R --resetIssue USB Reset signalling once we're
> finished
>   -s --dfuse-address addressST DfuSe mode, specify target address for
> raw file download or upload. Not
> applicable for
> DfuSe file (.dfu) downloads
>
>
Hi Gene,

thanks for this info, I was not aware of the DFU USB class.
sadly, this doesn't apply here since the FW upgrade on Eaton units use a
specific proprietary approach, which works for serial, USB and network...

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] Fatal EEPROM fault!

[Arnaud Quette]

2017-03-23 14:29 GMT+01:00 Sonic :

> Hello
>

Hi Chris


> Sorry if any of this is obvious - I'm new to NUT.
>
> NUT via upsc is displaying (edited for length):
>
> device.model: Eaton 5P 2200
> device.type: ups
> driver.name: usbhid-ups
> ups.alarm: Fatal EEPROM fault!
> ups.status: ALARM OL CHRG
> ups.test.interval: 604800
> ups.test.result: Done and passed
> driver.version: 2.7.2
> driver.version.data: MGE HID 1.33
> driver.version.internal: 0.38
>
> Is this possibly a firmware or configuration issue?
>

not sure, first time that I actually see that


> Does NUT report the firmware version (it's not jumping out at me in
> the upsc output)?
>

the upsc output you have is more than limited, probably due to the EEPROM
issue (update: just realized that you truncated the output ; pleased send
in a complete listing).
you should have something like that:
http://networkupstools.org/ddl/Eaton/5P_650.html
the field you're looking for is "ups.firmware" (for ex 02.08.0016 in the
above dump)

Can NUT upgrade the firmware on this device? Eaton only seems to have
> instructions for a Windows box.
>

indeed, confirmed. Though we have code for other platforms, it's internal
only (/me still fighting to open more things...)

For now, I'm checking with our support and HW team to provide you with a
solution.
Have you done anything special or had anything special with the unit (can
help a lot to troubleshoot)?

Thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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 ESV+ and Power Trim

[Arnaud Quette]

Hi David,

2017-03-21 20:06 GMT+01:00 David Baker <da...@baker.im>:

> Hi,
>
>
> Thanks for checking in – I managed to re-compile it but was getting the
> same error – I then had other things to do so didn’t get further in my
> investigation.
>

same error being "Can't chdir to /var/state/ups: No such file or directory"?
if so, ensure that you use Charles' provided "configure" directives, and
then make && make install.


> I’m going to delete the installation and the re-make / install it to see
> if that sorts it.
>
>
>
> I’ll let you know how I get on!
>

thanks,

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


> Dave
>
>
>
> *From:* Arnaud Quette [mailto:aquette@gmail.com]
> *Sent:* 21 March 2017 15:10
> *To:* Charles Lepple
> *Cc:* David Baker; NUT Users
> *Subject:* Re: [Nut-upsuser] MGE ESV+ and Power Trim
>
>
>
>
>
>
>
> 2017-03-12 4:02 GMT+01:00 Charles Lepple <clep...@gmail.com>:
>
> On Sat, Mar 11, 2017 at 7:15 PM, David Baker <da...@baker.im> wrote:
> > Hi Arnaud & Charles,
> >
>
>
>
> Hi Dave,
>
> any news on your side from this venerable ESV+?
>
>
>
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Is a timer a file?

[Arnaud Quette]

Hi Roger

2017-03-21 19:34 GMT+01:00 Roger Price <ro...@rogerprice.org>:

> On Tue, 21 Mar 2017, Arnaud Quette wrote:
>
> Hi Roger,
>>
>> reviving this discussion, since we have a Github ticket for 2.7.5:
>> https://github.com/networkupstools/nut/issues/293
>>
> ...
>
>> I've made some additions to clarify things on the timer, and complete the
>> script:
>> https://github.com/networkupstools/nut/compare/upssched-doc?expand=1
>>
>
> Hi Arnaud, Your change to the documentation clears up what I had
> mis-understood.  The new text makes it clear that the upssched timers are
> an in-memory device, and that they can only be turned on and off with
> upssched.conf declarations such as
>
> AT ONBATT * START-TIMER onbattwarn 30
> AT ONLINE * CANCEL-TIMER onbattwarn
>

thanks for your confirmation. I'll check to merge that PR.


>   Is there some other way of forcing routine cancel_timer from a
>> script or a configuration file?
>>
>> this is the last point to address, but I'd need to better understand
>> prior to potentially taking action:
>> theoretically, each event that triggers a timer (like ONBATT) has a
>> counterpart to cancel it (like ONLINE).
>> Ex (from the doc):
>> AT ONBATT * START-TIMER onbattwarn 30
>> AT ONLINE * CANCEL-TIMER onbattwarn
>>
>> So is there any use case we're missing here?
>>
>
> My use case was for a UPS unit which gave transient stupid status changes
> such as "OL DISCHARG CHARG LB" when the battery was 100% charged.  It was
> an old MGE unit which has since died.
>
> When the stupid status change occured, the LB began a system shutdown.  To
> overcome this unwanted stutdown, I wanted to start a 5 second timer, and
> when this ran out, upssched-cmd would review the situation, and decide if a
> shutdown was really needed.  If it was not needed, I had to cancel the
> system-shutdown timer.  I mistakenly assumed that such a timer was a file,
> and that it was sufficient to erase the file.
>
> To solve the problem of cancelling an arbitrary timer from a script such
> as upssched-cmd, I submitted a proposal to nut-upsdev:
>
>[Nut-upsdev] Proposal for technique to stop a timer at any moment
> https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007202.html
>
> and a set of patches :
>
> https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007203.html
> https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007204.html
>
> The technique is very general and is to send SIGUSR1/SIGUSR2 to the upsd
> daemon.  SIGUSR1 and SIGUSR2 are events just like ONBATT and ONLINE. The
> patch runs successfully on my opensuse 13.2 box, and solves my problem. In
> upssched.conf I now have declarations such as
>
>AT SIGUSR1 * CANCEL-TIMER shutdown-timer
>
> Will my patches be included in NUT?
>

Thanks for sharing your use case, and the rationales behind.
First, the base point is to be able to cancel a timer anytime, from a
command-line, which makes sense (as an extension, the opposite may also be
true, to start a timer lively, without the event coming from upsmon).

I've quickly checked your 2 patches.
The solution seems to me not broad enough for injecting upstream. This
works nice for a single device / UPS setup, but would not make it when
there are more devices, as I get it.

At first sight, I would more see something injecting into the PIPEFN fifo,
i.e. acting the same way upsmon would when calling upssched with the
upsname and the triggering event.
I think that this can be solved more easily with tools like socat or nc,
sending the command directly to the pipe.
For example, to cancel the timer "shutdown-timer" from the upssched-cmd
script, you would:

   echo "CANCEL shutdown-timer" | socat -
UNIX-CLIENT:/var/run/nut/upssched.pipe

Please tell me back if such solution would make it for you.

I also realize that the distributed sample configuration and scripts do not
fully match the doc.
I'll make another round of update for this, still on the same branch.
I would warmly welcome your help to complete the documentation, both with
part of your patches that make sense, along with the above solution if it's
good too.

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] Is a timer a file?

[Arnaud Quette]

Hi Roger,

reviving this discussion, since we have a Github ticket for 2.7.5:
https://github.com/networkupstools/nut/issues/293

2016-06-05 12:34 GMT+02:00 Roger Price :

> On Sat, 4 Jun 2016, Charles Lepple wrote:
>
> On Jun 3, 2016, at 6:48 AM, Roger Price  wrote:
>>
>>> ... the timer.  I don't see it in /var/lib/ups where the locate tool
>>> finds upsd.pid, and I don't see it in /run or /var/run where I see
>>> upsmon.pid.
>>>
>>> ... it seems that the timers are only stored in memory. See
>> checktimers(): https://github.com/networkupst
>> ools/nut/blob/master/clients/upssched.c#L129
>>
>
> Hello Charles, thanks for the link.  If timers are only stored in memory
> then the example given at http://networkupstools.org/doc
> s/user-manual.chunked/ar01s07.html chapter 7.2 is wrong.  It is not
> possible to turn off a timer with rm as shown in
>
> #! /bin/sh
> case $1 in
> ...
> ups-back-on-power)
> /bin/rm -f /some/path/ups-on-battery
> ;;
> ...
> esac
>
> This would explain the problem I have with a current script.
>

I've made some additions to clarify things on the timer, and complete the
script:
https://github.com/networkupstools/nut/compare/upssched-doc?expand=1


> Is there some other way of forcing routine cancel_timer from a script or a
> configuration file?
>

this is the last point to address, but I'd need to better understand prior
to potentially taking action:
theoretically, each event that triggers a timer (like ONBATT) has a
counterpart to cancel it (like ONLINE).
Ex (from the doc):
AT ONBATT * START-TIMER onbattwarn 30
AT ONLINE * CANCEL-TIMER onbattwarn

So is there any use case we're missing here?

Thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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 ESV+ and Power Trim

[Arnaud Quette]

2017-03-12 4:02 GMT+01:00 Charles Lepple :

> On Sat, Mar 11, 2017 at 7:15 PM, David Baker  wrote:
> > Hi Arnaud & Charles,
> >
>

Hi Dave,

any news on your side from this venerable ESV+?

-- Arno

> You’ll have to forgive my low level of Linux Understanding here….
> >
> >
> >
> > I downloaded the source files, modified the appropriate driver file,
> > re-compiled it (all of this was a lot of research and learning!)
> >
> >
> >
> > When I use the new driver I get –
> >
> >
> >
> > Network UPS Tools - UPS driver controller 2.7.2
> >
> > Network UPS Tools - MGE UPS SYSTEMS/U-Talk driver 0.93 (2.7.4.1)
> >
> > Can't chdir to /var/state/ups: No such file or directory
> >
> > Driver failed to start (exit status=1)
>
> To match the Raspbian build, I think the configure parameters should
> look like this:
>
> ./configure --build=arm-linux-gnueabihf --prefix=
> --includedir=/usr/include \
>--mandir=/usr/share/man --infodir="\${prefix}/share/info"
> --sysconfdir=/etc/nut \
>--localstatedir=/var --libexecdir="\${prefix}/lib/nut"
> --enable-maintainer-mode \
>--libdir=\${prefix}/lib/arm-linux-gnueabihf --with-ssl --with-nss
> --with-cgi --with-dev \
>--enable-static --with-statepath=/var/run/nut
> --with-altpidpath=/var/run/nut \
>--with-drvpath=/lib/nut --with-cgipath=/usr/lib/cgi-bin/nut \
>--with-htmlpath=/usr/share/nut/www --with-pidpath=/var/run/nut
> --datadir=/usr/share/nut \
>--with-pkgconfig-dir=/usr/lib/arm-linux-gnueabihf/pkgconfig \
>--with-user=nut --with-group=nut --with-udev-dir=/lib/udev \
>--with-systemdsystemunitdir=/lib/systemd/system
>
> Source: https://buildd.debian.org/status/fetch.php?pkg=nut=
> armhf=2.7.4-4=1475019180=0
> (so if the paths are slightly different, it's because the log is from
> stock Debian vs. Raspbian)
>
> You might not need all of those options for just one driver, but it
> should save some trial-and-error to just copy-and-paste everything,
> then rebuild.
>
> > The new .h file reads as this –
> >
> >
> >
> > /* Output page */
> >
> > { "output.voltage", 0, 0, "Lv", "%05.1f", VOLT, TRUE },
> >
> > { "output.voltage.nominal", ST_FLAG_RW | ST_FLAG_STRING, 5, "Lv
> ?",
> > "%05.1f", VOLT, TRUE },
> >
> > { "output.current", 0, 0, "Lc", "%05.1f", AMPERE, TRUE },
> >
> >
> >
> > If I copy the old driver back, it works fine – so I’m guessing I’ve got
> > something wrong with the compile or syntax!
>
> The .h file looks good, as far as I can tell.
>
> > Welcome your thoughts – the ESV22+ was a beast I came across which didn’t
> > work – I managed to pick up some replacement batteries and it’s now
> > protecting a load of audio and comms equipment in a charitable community
> > centre in Northern Romania!
>
> Always good to hear about equipment being saved from the dump, and put
> to good use!
>
___
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 ESV+ and Power Trim

[Arnaud Quette]

Hi David and Charles

Le 3 mars 2017 2:35 PM, "Charles Lepple"  a écrit :

> On Mar 3, 2017, at 8:21 AM, Charles Lepple  wrote:
> >
> > On Mar 2, 2017, at 3:38 PM, David Baker  wrote:
> >>
> >> I’ve read the documentation, and it would appear that this can be set
> by the U-Talk protocol (page 34 of http://networkupstools.org/pro
> tocols/mge/9261zwfa.pdf) but I can’t seem to figure out how to send the
> device the command, or manage to terminal into the unit (once disabling NUT
> services) and send the command.
> >>
> >> I think the command would be Lv 24000.
> >>
> > In theory, you could change the following line:
> >
> > https://github.com/networkupstools/nut/blob/v2.7.4/drivers/
> mge-utalk.h#L220
> >
> > from "{ "output.voltage", 0, 0, "Lv", "%05.1f", VOLT, TRUE },"
> >
> > to "{ "output.voltage", ST_FLAG_RW | ST_FLAG_STRING, 5, "Lv", "%05.1f",
> VOLT, TRUE },"
> >
> > This would allow you to use the "upsrw" command to set the voltage (with
> appropriate scaling).
> >
> > Do you have a development environment set up for the Raspberry Pi?
>
> Sorry, I think I read the protocol document too quickly.
>
> Is it maybe "Iv 24000" (inverter voltage)? It doesn't look like the
> current driver reads or writes the inverter settings.
>
> Arnaud, do you have any additional insight on the difference between
> setting output voltage and inverter voltage?



It's a long time since I've not dive into the UTalk code and devices. The
last time was more than a decade ago.Happy to see some ESV+ alive :)

Then, even reading the spec, I'm not sure what was the exact difference
between Lv and Iv, at least for a small UPS like ESV+.

So you can add the following line after "output.voltage in mge-utalk.h:

"{ "output.voltage.nominal", ST_FLAG_RW | ST_FLAG_STRING, 5, "Lv ?",
"%05.1f", VOLT, TRUE },"

By adding the above, you'll be able to have the nominal output voltage
reading and report (Lv ?) and to use upsrw to set nominal output voltage
(Lv 24000).
Please tell us back if the above works fine for you, so that we can update
the driver.
Otherwise, simply test by replacing the "Lv ?" with "Iv ?".

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

Re: [Nut-upsuser] EATON 9SX not display battery.charge

[Arnaud Quette]

Privet Yaroslav,

all my apologies for the eternity taken to answer.

2014-12-30 18:22 GMT+01:00 Charles Lepple :

> On Dec 29, 2014, at 10:03 AM, Ярослав Бабаянц  wrote:
>
> Any news?
>
> Send dubug with explore one more time
> in attach
>
>
> Unless I am mistaken, there is no new information in the latest debug
> output.
>
> One odd thing in the HID dump is that DesignCapacity appears twice, with
> very different values:
>
> Path: UPS.BatterySystem.Battery.*DesignCapacity*, ReportID: 0x23, Offset:
> 0, Size: 32, Value: 18000
> ...
> Path: UPS.PowerSummary.CapacityGranularity1, ReportID: 0x0c, Offset: 0,
> Size: 8, Value: 1
> Path: UPS.PowerSummary.CapacityMode, ReportID: 0x0c, Offset: 8, Size: 8,
> Value: 2
> Path: UPS.PowerSummary.*DesignCapacity*, ReportID: 0x0c, Offset: 16,
> Size: 8, Value: 100
> Path: UPS.PowerSummary.FullChargeCapacity, ReportID: 0x0c, Offset: 24,
> Size: 8, Value: 100
>
> (These are both 'Type: Feature'.)
>
> From pdcv10.pdf, UPS.BatterySystem.Battery.DesignCapacity should be in
> CapacityMode units, and CapacityMode==2 is %. But since CapacityMode is in
> UPS.PowerSummary, maybe it refers to UPS.PowerSummary.DesignCapacity instead.
> The 18000 might be mAh or mWh.
>
> It is also possible that one of UPS.PowerSummary.DesignCapacity
> or UPS.PowerSummary.FullChargeCapacity was intended to
> be RemainingCapacity. You can verify this by forcing the UPS onto battery
> power until the front panel displays a charge lower than 100%.
>
> I do not see any items which are likely to be runtime.
>

Charles' audit is fully right.

After some more review and local testing:
- would you be able to test with the latest NUT revision (2.7.4)? Note that
it's not mandatory, since no change here should be impacting your issue.
- the firmware revision is bad (ups.firmware: 9SX5Ki)
- I've tested locally with a 9SX (ups.firmware: 02.17.0040, previous
official FW) and the needed data is present
(UPS.PowerSummary.RemainingCapacity).
- I'm convinced that your issue comes from an outdated FW.
would you be able to upgrade the firmware of your unit?
If so, everything is available here (for Windows only though): h
ttp://powerquality.eaton.com/Support/Software-Drivers/Downloads/9SX-UPS-firmware.asp

I hope the above information will help you in solving your issue.

Best regards,
Arnaud
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
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] IBM 5396-1Kx ups nearly recognised.

[Arnaud Quette]

Quick additional feedback:

2016-06-08 15:01 GMT+02:00 Arnaud Quette <arnaud.que...@gmail.com>:

> Hi Andy,
>
> trying to catch my late here and there, keep in mind that my below
> comments may be missing things...
>
> 2016-04-24 23:30 GMT+02:00 Andy R <spinner+nutl...@delphinidae.org.uk>:
>
>> On 17/04/2016 21:49, Charles Lepple wrote:
>>
>>> On Apr 16, 2016, at 9:08 PM, Andy R - (NUT-List)
>>> <spinner+nutl...@delphinidae.org.uk> wrote:
>>>
>>>>
>>>> It looks like you were right. I've tried building both the patch
>>>> against the stable 2.7.4 source and using the latest source tarball
>>>> you've just created. The builds both went fine and seem to run as
>>>> they should. The Arch source build scripts are pretty clear to
>>>> manipulate at least.
>>>>
>>>
>>> If there are any URLs that you found particularly helpful for getting
>>> started with that, let me know. These sorts of test scenarios pop up
>>> every now and then.
>>>
>>> The udev rules work fine now, and  upsc/upscmd both return
>>>> promising looking responses. I can't actively test switching the
>>>> UPS right now as it's a bit late here for alarms to go off, however
>>>> if there is anything more to try then please let me know.
>>>>
>>>> I have attached a copy of the upsc/upscmd responses to querying the
>>>> UPS, and the debug output of usbhid-ups from the new build in case
>>>> there are any anomolies that stand out.
>>>>
>>>
>>> It's going to be a little while before I can get back to this, but
>>> maybe one of the other NUT developers can help. One thing I did not
>>> do is try to map this to an equivalent Eaton model[*]. There might be
>>> additional features or fixes if someone knows the exact equivalent.
>>>
>>> [*]:
>>> https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c#L89
>>>
>>>  This part looks weird, but maybe I am not used to seeing the status
>>> of a larger UPS: "ups.status: OL CHRG OFF" (maybe
>>> "battery.charger.status: floating" means float charging, rather than
>>> resting.)
>>>
>>
> yup, nothing but normal.
> OL is simply that the input power is fine.
> OFF means that the UPS doesn't power its output.
>
> the CHRG flag should however not be published since ABM (advanced battery
> monitoring, publication of charger specific info into
> battery.charger.status) is enabled:
>
> https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt#L356
> https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt#L393
>
> and crunchy tech details here:
> https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c#L135
>
>
>
>>
>>> If it really is off, then ups.load, ups.power and output.voltage seem
>>> reasonable. Otherwise, we might have an issue with scaling the
>>> values. (That sort of error is not common on MGE/Eaton units, but you
>>> never know.)
>>>
>>
> indeed ;)
>
>
>>
>>> My personal recommendation is to do as much shutdown testing as you
>>> can before hooking up critical loads. It looks like
>>> "outlet.1.autoswitch.charge.low: 0" is off, so that should simplify
>>> testing. Also, try a battery test to see what messages you get in
>>> syslog. There are some procedures listed in the NUT User Manual for
>>> how to test shutdowns without accidentally cutting power if things
>>> are not configured correctly.
>>>
>>>
>> Hi,
>>
>> Just thought I'd send an interim followup to this, as I haven't
>> forgotten it, just been a little busy.
>>
>> Firstly you were exactly right about the charging status. The ups does a
>> base fast charge to get the battery up to speed at 90% or so, then a
>> slow float charge from 90% to full where it then rests the battery and
>> disconnects the charging circuit. I recall it then just giving a plain
>> "OL OFF" message there then.
>>
>> I've not had any luck in testing it for power handling as the batteries
>> are toasted. Unplugging it at idle load (PC was plugged direct to the
>> wall with just usb to the UPS) caused it to fall flat on its face with
>> an instant shutdown. Plugging back in went back to the "can't power-up
>> due to not having enough battery to complete the self-testing" that I
>> had when I first got the unit. New batteries on order now.
>

Re: [Nut-upsuser] IBM 5396-1Kx ups nearly recognised.

[Arnaud Quette]

Hi Andy,

trying to catch my late here and there, keep in mind that my below comments
may be missing things...

2016-04-24 23:30 GMT+02:00 Andy R :

> On 17/04/2016 21:49, Charles Lepple wrote:
>
>> On Apr 16, 2016, at 9:08 PM, Andy R - (NUT-List)
>>  wrote:
>>
>>>
>>> It looks like you were right. I've tried building both the patch
>>> against the stable 2.7.4 source and using the latest source tarball
>>> you've just created. The builds both went fine and seem to run as
>>> they should. The Arch source build scripts are pretty clear to
>>> manipulate at least.
>>>
>>
>> If there are any URLs that you found particularly helpful for getting
>> started with that, let me know. These sorts of test scenarios pop up
>> every now and then.
>>
>> The udev rules work fine now, and  upsc/upscmd both return
>>> promising looking responses. I can't actively test switching the
>>> UPS right now as it's a bit late here for alarms to go off, however
>>> if there is anything more to try then please let me know.
>>>
>>> I have attached a copy of the upsc/upscmd responses to querying the
>>> UPS, and the debug output of usbhid-ups from the new build in case
>>> there are any anomolies that stand out.
>>>
>>
>> It's going to be a little while before I can get back to this, but
>> maybe one of the other NUT developers can help. One thing I did not
>> do is try to map this to an equivalent Eaton model[*]. There might be
>> additional features or fixes if someone knows the exact equivalent.
>>
>> [*]:
>> https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c#L89
>>
>>  This part looks weird, but maybe I am not used to seeing the status
>> of a larger UPS: "ups.status: OL CHRG OFF" (maybe
>> "battery.charger.status: floating" means float charging, rather than
>> resting.)
>>
>
yup, nothing but normal.
OL is simply that the input power is fine.
OFF means that the UPS doesn't power its output.

the CHRG flag should however not be published since ABM (advanced battery
monitoring, publication of charger specific info into
battery.charger.status) is enabled:

https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt#L356
https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt#L393

and crunchy tech details here:
https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c#L135



>
>> If it really is off, then ups.load, ups.power and output.voltage seem
>> reasonable. Otherwise, we might have an issue with scaling the
>> values. (That sort of error is not common on MGE/Eaton units, but you
>> never know.)
>>
>
indeed ;)


>
>> My personal recommendation is to do as much shutdown testing as you
>> can before hooking up critical loads. It looks like
>> "outlet.1.autoswitch.charge.low: 0" is off, so that should simplify
>> testing. Also, try a battery test to see what messages you get in
>> syslog. There are some procedures listed in the NUT User Manual for
>> how to test shutdowns without accidentally cutting power if things
>> are not configured correctly.
>>
>>
> Hi,
>
> Just thought I'd send an interim followup to this, as I haven't
> forgotten it, just been a little busy.
>
> Firstly you were exactly right about the charging status. The ups does a
> base fast charge to get the battery up to speed at 90% or so, then a
> slow float charge from 90% to full where it then rests the battery and
> disconnects the charging circuit. I recall it then just giving a plain
> "OL OFF" message there then.
>
> I've not had any luck in testing it for power handling as the batteries
> are toasted. Unplugging it at idle load (PC was plugged direct to the
> wall with just usb to the UPS) caused it to fall flat on its face with
> an instant shutdown. Plugging back in went back to the "can't power-up
> due to not having enough battery to complete the self-testing" that I
> had when I first got the unit. New batteries on order now.
>

good. PbAc battery generally lives ~4 years.
It then depends on the operating temperature, and the power quality...


> The actual control software seems to be operating ok. Having got a
> simple configuration running it operates as expected with "upsmon -c
> fsd". The machine stops, and the UPS is triggered to go to standby and
> then restart when power comes back, well it comes straight back after 10
> seconds as the power never goes away in the test.
>

indeed, default behavior (10 sec after the power comes back)


> I've also tripped over a libc-2.23 issue that may or may not be either
> something due to the build used by arch, systemd or something in libc
> itself. But if you try to set SHUTDOWNCMD to the old reboot/shutdown
> commands that have been trampled and swallowed by systemd then you get a
> libc segfault. Using 'systemctl shutdown' as the SHUTDOWNCMD does work
> ok though. Someone else on arch has already posted a bug to systemd
> (https://github.com/systemd/systemd/issues/2796)
>
>
I'm 

[Nut-upsuser] Network UPS Tools version 2.7.4 released

[Arnaud Quette]

Network UPS Tools version 2.7.4 has been released:
http://www.networkupstools.org

Direct access:
- Download: http://www.networkupstools.org/source/2.7/nut-2.7.4.tar.gz
- News: http://www.networkupstools.org/source/2.7/new-2.7.4.txt
- ChangeLog: http://www.networkupstools.org/source/2.7/ChangeLog


Deserved thanks to Daniele and Charles for their continuous work on NUT.

Arno & the NUT team
-- 
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] Call to funding NUT infrastructure

[Arnaud Quette]

Hi Greg and NUT supporters

2015-07-04 8:35 GMT+02:00 Greg Vickers daehe...@iinet.net.au:

  Hi Arnaud,

 You are an officer and a gentleman, very helpful on the email lists when
 time permits, and I am very happy to support the NUT infrastructure!  I
 hope that my donation makes the hosting easier to run for a while!


thanks for your kind words and support, along with the few others that have
donated to support this effort.
I'm back from 2 weeks of vacations, hence my silence. But I'll follow-up on
this subject, and will provide an update.

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



 Cheers,
 Greg

 On 3/07/2015 2:49 am, Arnaud Quette wrote:

  Dear NUT Community,

  It's not something you've been used to from me, but...
  I've been funding the NUT infrastructure on my own for many years now.

  I'm currently in a situation that is a bit hard, financially speaking.
  I've recently renewed the networkupstools.org domain name.
  But now comes the server in itself (BaseInstance Cloud slice on Gandi).

  It's not that many bucks a year, but already too much currently.
 Life push all of us to some priority.
 I could be asking Eaton obviously, but would prefer for now that we keep
 the community approach only.
 I would also like to expand a bit the resources to relaunch a
 demo.networkupstools.org for example, which means a bit more money (btw,
 any idea beside demo.n.o is welcome...).

  So, I would welcome any and all donation through my paypal account (
 arnaud.que...@gmail.com).

  Thanks and cheers,
  Arno
  --
  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] Network UPS Tools version 2.7.3 released

[Arnaud Quette]

Hi Dan

2015-04-22 13:03 GMT+02:00 Dan Craciun dany.crac...@gmail.com:

  Congratulations!

 You might want to modify the date on the homepage. Right now it says:

 April 16, *2014*: NUT 2.7.3 released


Thanks for pointing that, not a thorough enough review.
I've just fixed it.

cheers,
Arno



 On 4/22/2015 12:44 PM, Arnaud Quette wrote:
  Network UPS Tools version 2.7.3 has been released:
 http://www.networkupstools.org

 Direct access:
 - Download: http://www.networkupstools.org/source/2.7/nut-2.7.3.tar.gz
 - News: http://www.networkupstools.org/source/2.7/new-2.7.3.txt
 - ChangeLog: http://www.networkupstools.org/source/2.7/ChangeLog

  Please note that, with this release, the Device Dumps Library is now
 available online:
 http://www.networkupstools.org/ddl/

  Deserved thanks to Daniele and Charles

 Arno  the NUT team

___
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

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

[Arnaud Quette]

Hi Panagiotis

2015-04-06 9:13 GMT+02:00 Panagiotis Kritikakos 
panagiotis.kritika...@nikitec.gr:

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

[Arnaud Quette]

Hello Panagiotis

2015-04-03 14:28 GMT+02:00 Panagiotis Kritikakos 
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 newmge-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.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

[Arnaud Quette]

Hello Panagiotis

2015-04-01 16:28 GMT+02:00 Panagiotis Kritikakos 
panagiotis.kritika...@nikitec.gr:

 Hello all,

 OS name: FreeNAS 9.3
 NUT version: 2.7.2
 NUT installed method: Bundled with FreenNAS 9.3
 Device: EATON 5SC 1000 (http://powerquality.eaton.
 com/Products-services/Backup-Power-UPS/5SC.aspx?cx=5
 wtredirect=www.eaton.com/5SCGUID=B81251A4-F34E-4373-94B3-B4FB3D0CBCA8)

 Problem description:

 This was originally reported as bug to FreeNAS (https://bugs.freenas.org/
 issues/8049#change-41087) and was asked to post this upstream, so here it
 goes.

 The issue with the driver has been seen in FreeNAS 9.3-STABLE. While the
 serial connection with the UPS (Eaton 5 5SC Serial with mge-shut driver) is
 working initially, almost after every reboot, the driver is failing with
 the message UPS failed - Driver not connected. This was not the case with
 FreeNAS 9.2 and NUT 2.7.1.

 Additional information:

 ~# /usr/local/libexec/nut/mge-shut -DD -a ups-filesrv01
 Network UPS Tools - Generic HID driver 0.38 (2.7.2)
 SHUT communication driver 0.84
 Warning: This is an experimental driver.
 Some features may not function correctly.

0.00 debug level is '2'
0.000901 upsdrv_initups...
0.000911 libshut_open: using port /dev/cuau0
0.001034 entering shut_synchronise()
0.037281 Communication with UPS established
0.037289 entering shut_get_descriptor(n 01, 18)
0.120208 shut_wait_ack(): ACK received
0.371873 shut_wait_ack(): ACK received
9.504230 shut_wait_ack(): Nothing received
9.589858 shut_wait_ack(): ACK received
9.742965 shut_wait_ack(): Nothing received
9.867744 shut_wait_ack(): ACK received
9.971912 - VendorID: 0463
9.971919 - ProductID: 
9.971923 - Manufacturer: Eaton
9.971926 - Product: unknown
9.971929 - Serial Number: unknown
9.971932 - Bus: serial
9.971935 Device matches
9.971939 entering shut_get_descriptor(n 21, 9)
   13.027594 shut_wait_ack(): Nothing received
   16.028593 shut_wait_ack(): Nothing received
   16.055659 shut_wait_ack(): Nothing received
   16.055670 Max tries reached while waiting for ACK, still getting
 errors
   16.055674 entering shut_synchronise()
   16.197941 Unable to get HID descriptor ()
   16.197949 No matching HID UPS found

 Thank you in advance!


The only diff I see between shut in 2.7.1 and 2.7.2 is the following:

--- ../nut-2.7.1/drivers/libshut.c2013-10-02 14:16:42.0 +0200
+++ drivers/libshut.c2014-02-25 16:39:34.0 +0100
@@ -312,7 +312,7 @@
 /* FIXME: add variable baudrate detection */
 *upsfd = ser_open(device_path);
 ser_set_speed(*upsfd, device_path, B2400);
-setline(*upsfd, 0);
+setline(*upsfd, 1);

 /* initialise communication */
 if (!shut_synchronise(*upsfd))


This is tied to the PnP feature, and was reverted with the following commit:
https://github.com/networkupstools/nut/commit/75b0ce8b952d7c55880f7a019ba61ec05b45e6a7

Never had time to get the complete consideration on this, so I'm still
lacking visibility.
it's still unclear to me why it does not work for you. Is FreeNAS linux
based or BSD?
I've just tested a pristine 2.7.2 on Debian Jessie + 5SC700, and it works
fine.

would you be able to test a patch or a git branch?

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] SSL only working in DEBUG mode

[Arnaud Quette]

Hey mister M'

A first huge thanks for taking care of this,  and so late in the night. I
know that it's not easy...

(sent from my S3... please excuse my brevity)
Le 25 mars 2015 18:49, Emilien Kia kiae@gmail.com a écrit :



 2015-03-21 17:06 GMT+01:00 Melkor Lord melkor.l...@gmail.com:


 On Fri, Mar 20, 2015 at 4:40 PM, Emilien Kia kiae@gmail.com wrote:

 Some precisions:

 we are not alone, some projects had similar problem:
http://bugs.bitlbee.org/bitlbee/ticket/785
 And the problem is really coming from NSS initialization. Discussion
about the issue here :
http://osdir.com/ml/mozilla.crypto/2002-08/msg00016.html


 Wow! Congratulations on finding the source of the problem, I bet this
wasn't easy!


 You have done the hardest job. Once you isolate the problem occurs only
when running as a deamon and not in debug mode, searching for a problem is
easier.
 Moreover we have done so many tests on this feature that it is really
surprising we didn't detect this problem before.
 But when we look more precisely at DVT linked by Charles, we can see we
did test only in direct mode, not in deamonized mode.



 I'm glad to see that NUT isn't faulty :-)


 There is a workaround to use NSS with fork but it is more setting a
flag to share some resources (primarily sockets) but must (re)initialize
NSS library on all children.

 AFAIK why we initialize NSS library before becoming user and forking is
to be able to access and read certificates and keys which is readable only
by root and should not be readable in userland. This behavior is this
because it was the behavior used when using OpenSSL. Modifying this
behavior implies to modify key/certificate storage and acces right policy.


 Well, NUT uses a dedicated unpriviledged user to run (nut in my case)
so why not initialize the SSL stuff after forking?

 Before forking, just check that the SSL cert/key files belong to the
same user as the user which started upsd and throw an error message to
the logs if it's not the case to warn the user. Then it's your decision
whether to disable SSL usage and continue or refuse upsd execution if
conditions are not met.


 I will look to do something like that.



 If it's convenient, make this part NSS dependent with the usual #ifdef
spaghetti :-) to avoid influence on the OpenSSL code.


 What I will do is to move ssl initializing after usering and forking,
than add key file right checking where ssl was initialized before (before
forking).
 As keys should be owned by nut user, this would not be a problem.
 And moving this code, independently of SSL implementation (OpenSSL or
NSS) should work. And will not add more code implementation dependent.

 Charles, Arnaud ? Ok with that ?

Works for me at first, but I'll see once yiu push the PR and we have some
tests validating the behavior in daemon mode, including some reload with
added certs (will that work?!)

Thanks again *a lot* and cheers
Arno
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] netvision-mib driver

[Arnaud Quette]

Hi Henning,

note that I've cc'ed the NUT users list for info.

2015-02-04 13:47 GMT+01:00 Henning Fehrmann henning.fehrm...@aei.mpg.de:

 Hi Arnaud,

 the best to process the value would be to have the MIB definition for
 upsAlarmOnBattery, as for example:
 [1]
 https://github.com/networkupstools/nut/blob/master/drivers/eaton-mib.c#L108

 Yea, I looked into netvision-mib.c but I was afraid that patching it
 would break more than it helps. We still can try it ..

 
 You should request these info to Socomec, or better, ask them to send
 the
 updated Netvision MIB (v6) to the project (or /me) for publishing on
 NUT
 protocols library:
 [2]http://www.networkupstools.org/ups-protocols.html

 I attach the Netvision MIB I got recently from the Socomec side.


thx. I will publish it along with the 2.7.3 release.

in light of this:
- it's a kinda-boolean (0/1, ok/not ok)
- I've committed the fix
https://github.com/networkupstools/nut/commit/4552d14162086a280445efc5331a8e6ad7b1c3a4


 
 Last question: would you be able to test a patch or a github branch
 (i.e.
 needs recompilation)?

 Yes, we can do it and we can grant you access, or both, as you wish.


please be my guest and test the result ;)



 I'm in the process of releasing 2.7.3, so that would be the best to
 have
 your patch in and tested...

 We'll watch for new pushes.

 Thank you and cheers,
 Henning



cheers,
Arno
--
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

[Nut-upsuser] Network UPS Tools version 2.7.2 released

[Arnaud Quette]

Network UPS Tools version 2.7.2 has been released:
http://www.networkupstools.org/

This is a second interim release, part of the testing series.

Direct access:
- Download: 
http://www.networkupstools.http://www.networkupstools.org/source/2.7/nut-2.7.2.tar.gz
org/source/2.7/nut-2.7.2.tar.http://www.networkupstools.org/source/2.7/nut-2.7.2.tar.gz
gz http://www.networkupstools.org/source/2.7/nut-2.7.2.tar.gz
- News: 
http://www.networkupstools.http://www.networkupstools.org/source/2.7/new-2.7.2.txt
org/source/2.7/new-2.7.2.txthttp://www.networkupstools.org/source/2.7/new-2.7.2.txt
- ChangeLog: 
http://www.networkupstools.http://www.networkupstools.org/source/2.7/ChangeLog
org/source/2.7/ChangeLoghttp://www.networkupstools.org/source/2.7/ChangeLog

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

Re: [Nut-upsuser] snmp-ups sends status OL OB on HP R3000 UPS with AF465A management card [UPDATE]

[Arnaud Quette]

Philippe, Ivan,

please see https://github.com/networkupstools/nut/issues/118
and send back your data.

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

Re: [Nut-upsuser] Arch Linux and Tripp Lite web snmp card issues.

[Arnaud Quette]

2014-02-25 12:58 GMT+01:00 Charles Lepple clep...@gmail.com:

 On Feb 24, 2014, at 11:48 PM, Jason R Begley wrote:

0.073855 load_mib2nut: trying classic method with 'delta_ups' mib
0.073878 Entering nut_snmp_get_str()
0.073899 nut_snmp_get((null))
0.073918 nut_snmp_walk((null))

 Arnaud,

 The gen-snmp-subdriver.sh script is setting mib2nut[i]-oid_auto_check to
 NULL for new drivers (with no instructions on what to use in place of
 NULL). However, this seems to be only used with the classic method for
 detecting an UPS.

 Is the intent to phase out the classic method, or should we just add an
 explicit NULL check in load_mib2nut()?

 The full stack trace is below:

  Program received signal SIGSEGV, Segmentation fault.
  0xb7da9470 in __strchr_sse2_bsf () from /usr/lib/libc.so.6
  (gdb) bt
  #0  0xb7da9470 in __strchr_sse2_bsf () from /usr/lib/libc.so.6
  #1  0xb7f05758 in snmp_parse_oid () from /usr/lib/libnetsnmp.so.30
  #2  0x0804afd8 in nut_snmp_walk ()
  #3  0x0804b261 in nut_snmp_get ()
  #4  0x0804bab6 in nut_snmp_get_str ()
  #5  0x0804be7b in load_mib2nut ()
  #6  0x0804bfd2 in upsdrv_initups ()
  #7  0x08049fb4 in main (


Hi Charles,

gen-snmp-subdriver.sh simply hasn't done its job, for some reasons.
well, 1 clear is that's it not a completed effort... at all
but, still IIRC, it should have produced at least a bit more

@Jason: how have you called the script?
could you please also send an archive including:
- the results of the adapted commands on #L73, #L74
https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-snmp-subdriver.sh
- your mib file

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

Re: [Nut-upsuser] NetVision 6.0 MIB

[Arnaud Quette]

2014-02-12 10:13 GMT+01:00 hamid.na...@coop.no:

 Arnaud,



 I see your name all over when I look for Netvision MIB. Thought maybe you
 can help me. I want the MIB for our UPS (SOCOMEC) with NetVision 6.0



 I appreciate your help in advanceJ

 Regards

 Hamid Nabil




Hello Hamid,

the procedure describing how to do the ground work (needed from you) can be
found here:
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#snmp-subdrivers

we will then be able to help in completing and merging the result.

cheers,
Arno
-- 
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] Add general UPS SNMP agent as a nut client

[Arnaud Quette]

2014-02-16 8:31 GMT+01:00 a...@i100.no:

 Hi


Hi Alf,


 One idea I've had for some time, but unfortunately not had time to
 implement, is to add a general SNMP agent, which will work with all UPSes
 supported by nut.
 The idea is to have the SNMP agent use the nut API to fetch values from
 the UPS.
 So the SNMP agent will be similar to the upsc utility.

 Whenever the SNMP agent is queried for information, it will use the nut
 API to get hold of the data.
 We will just need to take for example the Eaton MIB file, and map each
 SNMP OID to the corresponding value as exposed by upsc.

 The background for wanting this, is that I am using a Eaton ConnectUPS-BD
 WEB/SNMP card, and exposing the data as SNMP, and using OpenNms, I out of
 the box get nice graphing of voltage levels and power usage.
 I really like that functionality and graphing.
 The setup is working fine by me, but by implementing such a SNMP agent,
 every user of nut could get the same functionality, and would not be
 requiring special hardware for doing so.
 OpenNms can easliy generate graphs etc based on the SNMP MIB file that is
 part of nut for Eaton UPSes. I think Cacti and other such tools should also
 be easy to set up.

 I've written a bit about my setup here :

 http://www.kanonbra.com/index.php/projects/snmpnms/27-monitoring-eaton-9130-ups-in-opennms

 The question is really if other people would also like to have SNMP
 monitoring support for their UPSes ?
 Adding support for SNMP traps might be harder, but I noticed some email
 one the mailing list today that there is already ideas for adding SNMP
 traps generally.


Reviving a bit the archives (clouds of dust floating around...)
Here is my first and now 10 years old attempt:
http://old.networkupstools.org/server-projects/
Native C and Net SNMP libs...

And more recently: https://github.com/luizluca/nut-snmpagent
Ruby this time, from Luiz Angelo Daros de Luca.

That made me realize that it's still not referenced on the NUT Related
Projects page.
(yup Charles, yet another unshared thing...)
This last point is now fixed:

and the website updated, with a news entry.

All my apologies to the author, Luiz!
If you're still open and motivated in working with me on this topic, I've
finally gone through this 2 years time-warp... and hopefully back.

cheers,
Arnaud
-- 
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

[Nut-upsuser] Formalizing the end of the relationship with Eaton

[Arnaud Quette]

Dear NUT users,

The relationship with Eaton was in need of clarification for a long time,
which happened over the past weeks.This is now officially noted on the NUT
side, through moving Eaton from the Main supporter to Supporting UPS
manufacturer, rewording the content and putting a big warning [1].

Quoting these main changes:

Eaton, has been the main NUT supporter in the past, between 2007 and 2011,
continuing MGE UPS SYSTEMS efforts.
...
The situation has evolved, and since 2011 Eaton does not support NUT
anymore.
This may still evolve in the future.
But for now, please do not consider anymore that buying Eaton products will
provide you with official support from Eaton, or a better level of device
support in NUT.

Considering that I'm still an Eaton employee, this blurry situation was one
of the main factors that kept me away from NUT for the past couple of years.
Not the only one, but I'm working on these points one after another.

You can expect to see me slowly starting to bother you all again in a soon
future ;)

Cheers,
Arnaud
--
[1] http://www.networkupstools.org/acknowledgements.html#Eaton
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Update to the NUT Team members

[Arnaud Quette]

Dear NUT users and developers,

Frédéric Bohe, NUT Senior developer, who has worked with us as an Eaton
contractor from 2009 to 2013, is now retired.
Thanks for all the hard work on the Windows port, nut-scanner, Unix
packaging, support, ... Fred.
We will miss you!

At the same time, Daniele Pezzini has devoted a lot of time and energy over
the past months (and years even).
Daniele deserve the NUT Senior developer title, which he kindly accepted.
Please join me in welcoming and thanking him.

I've just updated these information on the NUT website [1].

Cheers,
Arnaud
--
[1] http://www.networkupstools.org/acknowledgements.html
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Emne: Eaton Powerware 5110 - some stats not reported

[Arnaud Quette]

2014-02-13 6:55 GMT+01:00 Alf Høgemark a...@i100.no:

 Hi


Hi Alf,


 On
 http://nutwiki.kanonbra.com/wiki/Category:Eaton_Powerware_5110


cool thing!
But duplicating the NUT Device Dumps Library [1].
The DDL can also serve both users and developers purposes, by providing
these dumps as .dev files (usable with dummy-ups).
I'm looking for someone to help me completing this effort: would you be
interested in?
It would mostly be collecting dumps posted on the lists and the web, and
calling users to massively send theirs...

This however made me realize that it's still not referenced on the web and
in the docs.

Cheers,
Arnaud
--
[1] http://www.networkupstools.org/devdumps/
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Formalizing the end of the relationship with Eaton

[Arnaud Quette]

2014-02-15 11:31 GMT+01:00 Greg Vickers daehe...@iinet.net.au:

  On 15/02/14 19:56, Arnaud Quette wrote:

Dear NUT users,

  The relationship with Eaton was in need of clarification for a long time,
 which happened over the past weeks.This is now officially noted on the NUT
 side, through moving Eaton from the Main supporter to Supporting UPS
 manufacturer, rewording the content and putting a big warning [1].

 Quoting these main changes:

 Eaton, has been the main NUT supporter in the past, between 2007 and
 2011, continuing MGE UPS SYSTEMS efforts.
 ...
 The situation has evolved, and since 2011 Eaton does not support NUT
 anymore.
 This may still evolve in the future.
 But for now, please do not consider anymore that buying Eaton products
 will provide you with official support from Eaton, or a better level of
 device support in NUT.

  Considering that I'm still an Eaton employee, this blurry situation was
 one of the main factors that kept me away from NUT for the past couple of
 years.
  Not the only one, but I'm working on these points one after another.

 You can expect to see me slowly starting to bother you all again in a soon
 future ;)


 Aw, you never bothered :)


thanks, too kind Greg ;)


 Thanks for the clarification, I've been unaware of that particular
 situation.


not that many people were...


 You must be relieved that this situation is becoming a bit clearer, and
 hopefully gives you the ability to pursue what you want to do!


as told, I've still to work out other points (the NUT Foundation being #1
now).
but it already freed me a bit of soul to relaunch a few things.

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

Re: [Nut-upsuser] Request for advice about NUTdrivers/bcmxcp

[Arnaud Quette]

2013/11/18 Vladimir Nesterenko nesterenko...@gmail.com



 -- Forwarded message --
 From: Vladimir Nesterenko nesterenko...@gmail.com
 Date: 2013/11/13
 Subject: Request for advice about NUTdrivers/bcmxcp
 To: Arnaud Quette arnaudque...@eaton.com


 Hello.
 I am using this driver on openSUSE 12.3 with EATON Powerware 5110 the
 basic functions work fine, but there is a need to solve two problems:
 1. There is a need to shut down or block the sound when running on
 battery. This device has this feature when used by Eaton LanSafe v.6 on
 Windows. In other UPS drivers this feature is available through the command
 beeper.toggle. Is there any chance of getting this command in driver
 bcmxcp(bcmxcp_usb)?
 2. The default settings execute system shutdown by the event low battery
 (LB), but I need to turn off when the level of charge remaining 30%. If to
 you not difficult, tell me how this can be implemented.

 P.S. I would be very grateful if you can give any advice or technical
 information for upgrading this driver.


Hello Vladimir,

sorry for the late in answering, but the NUT Community could told you that
I've not really been present nor reactive over the past year...
that said, here are base answers to your questions:
1. there have been recent updates from Alf Høgemark, along with some others.
We are currently working hard to release 2.7.1, which will ship these
improvements.
2. http://www.networkupstools.org/docs/user-manual.chunked/ar01s07.html

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

Re: [Nut-upsuser] [HCL] Eaton 5S1500LCD supported by usbhid-ups

[Arnaud Quette]

2013/9/10 Matt Ivie matt.i...@bonntran.com

 Device Manufacturer: Eaton
 Device Name: 5S1500LCD
 --
 upsc output:

 battery.charge: 100
 battery.charge.low: 20
 battery.runtime: 3515
 battery.type: PbAc
 device.mfr: EATON
 device.model: Ellipse PRO 1500
 device.serial: 00
 device.type: ups
 driver.name: usbhid-ups
 driver.parameter.pollfreq: 30
 driver.parameter.pollinterval: 2
 driver.parameter.port: auto
 driver.parameter.vendorid: 0463
 driver.version: 2.6.4
 driver.version.data: MGE HID 1.31
 driver.version.internal: 0.37
 input.frequency: 60.0
 input.transfer.high: 138
 input.transfer.low: 93
 input.voltage: 121.0
 input.voltage.extended: no
 outlet.1.desc: PowerShare Outlet 1
 outlet.1.id: 2
 outlet.1.status: on
 outlet.1.switchable: no
 outlet.2.desc: PowerShare Outlet 2
 outlet.2.id: 3
 outlet.2.status: on
 outlet.2.switchable: no
 outlet.desc: Main Outlet
 outlet.id: 1
 outlet.switchable: no
 output.frequency: 60.0
 output.frequency.nominal: 60
 output.voltage: 121.0
 output.voltage.nominal: 115
 ups.beeper.status: enabled
 ups.delay.shutdown: 20
 ups.delay.start: 30
 ups.firmware: 01.04.0012
 ups.load: 3
 ups.mfr: EATON
 ups.model: Ellipse PRO 1500
 ups.power: 55
 ups.power.nominal: 1500
 ups.productid: 
 ups.realpower: 31
 ups.serial: 00
 ups.status: OL CHRG
 ups.timer.shutdown: 0
 ups.timer.start: 0
 ups.vendorid: 0463

 ---
 Tested shutdown sequence and the computer powers down, then the UPS
 shuts down. UPS powers back on and all devices that are supposed to turn
 on do. Everything appears to be working as expected.
 ---
 Link to description: http://powerquality.eaton.com/5S1500LCD.aspx?CX=3


Hello Matt,

thanks for your report!
I've just committed a patch to add 5S to the HCL:
https://github.com/networkupstools/nut/commit/06a4a6614fdaf546b4a4047126564ab4568bc4de

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

Re: [Nut-upsuser] Not receiving real data from a Eaton E series DX 1000H UPS

[Arnaud Quette]

2013/4/18 Pladi Computers Ltd. pl...@lovechnet.com

  UPS:
 http://www.eaton.com/Eaton/ESeriesUPS/DXUPS/index.htm?wtredirect=www.eaton.com/DXUPS

 I have the same problem on two different computers. The first one is
 running Ubuntu 12.10 i386 , the second one is running Debian  6.0 x64. Both
 of them are updated. I tried using different serial cable but the result is
 the same.
 The connection to the ups using Windows 7 and Winpower is working fine on
 the computer I tested.

 The nut version on the Debian pc is 2.4.3-1.1squeeze2 and on the Ubuntu
 one is 2.6.3-1ubuntu2. Both of them are installed from the repositories.

 I tried adding pollinterval=20 to ups.conf, MAXAGE 25 to upsd.conf
 and DEADTIME 25 to upsmon.conf but I still get stale errors in syslog
 and null information about all the stats.

 #ups.conf
 [ups0]
 driver = mge-utalk
 port = /dev/ttyS0
 pollinterval = 20

 The logs are in the attached file.


mge-utalk was fixed in the development branch, but was not yet released.
You can download from github either the tree or just the patch:
https://github.com/networkupstools/nut/commit/9257cc0b68b8bdb65f97b7a15fc3b8d947dfaee8

cheers,
Arnaud
-- 
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] NOTIFYCMD and SHUTDOWNCMD do not work until Nut is restarted

[Arnaud Quette]

2013/4/16 Julien Métairie ruli...@ruliane.net

 Hello,


  Message original 
 Sujet: Re: [Nut-upsuser] NOTIFYCMD and SHUTDOWNCMD do not work until Nut
 is restarted
 De : Julien Métairie ruli...@ruliane.net
 Pour : NUT Users 
 nut-upsuser@lists.alioth.**debian.orgnut-upsuser@lists.alioth.debian.org
 
 Date : 12/04/2013 18:28


  Hi,

  Message original 
 Sujet: Re: [Nut-upsuser] NOTIFYCMD and SHUTDOWNCMD do not work until Nut
 is restarted
 De : Arnaud Quette aquette@gmail.com
 Pour : Julien Métairie ruli...@ruliane.net
 Copie à : NUT Users 
 nut-upsuser@lists.alioth.**debian.orgnut-upsuser@lists.alioth.debian.org
 
 Date : 11/04/2013 22:33

  bonjour Julien

 2013/4/11 Julien Métairie ruli...@ruliane.net
 mailto:ruli...@ruliane.net

 Hi everybody,

 I installed and configured Nut 2.4.3 on Debian Squeeze, using
 package. It monitors an MGE Pulsar 1500 UPS in standalone mode.

 Here are parts of upsmon.conf :
 SHUTDOWNCMD /bin/bash /root/extinction.sh  /var/log/ups/ups.log
 21
 NOTIFYCMD /bin/bash /usr/sbin/alerte.sh
 [...]
 NOTIFYFLAG ONBATT   SYSLOG+EXEC

 At startup, driver, upsd and upsmon start but when I pull off the
 line, a message is appended to syslog but no script is executed, nor
 SHUTDOWNCMD is called. To make things better, I must restart Nut :
 invoke-rc.d nut restart

 Trying to understand this behavior, i noticed the following lines in
 syslog at computer startup, pasted there[1] for convenience :

 usb 3-1: New USB device found, idVendor=0463, idProduct=
 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4
 usb 3-1: Product: Pulsar
 usb 3-1: Manufacturer: MGE UPS SYSTEMS
 usb 3-1: SerialNumber: 1Y3H34201
 usb 3-1: configuration #1 chosen from 1 choice
 [...]

 /build/buildd-linux-2.6_2.6.__**32-48squeeze1-i386-F95osd/__**
 linux-2.6-2.6.32/debian/build/**__source_i386_none/drivers/**
 hid/__usbhid/hid-core.c:

 usb_submit_urb(ctrl) failed
 generic-usb 0003:0463:.0001: timeout initializing reports
 generic-usb 0003:0463:.0001: hiddev0,hidraw0: USB HID v1.10
 Device [MGE UPS SYSTEMS Pulsar] on usb-:00:0a.1-1/input0
 usbcore: registered new interface driver usbhid
 usbhid: v2.6:USB HID core driver

 May the failure be linked to my issue ? What can I do to make Nut
 work as soon as my computer boots up ?


 maybe.
 can you reproduce this easily?
 if so, what the result of upsc devname:
 1) just after the boot?
 2) then, when you've pulled the line?

 Arnaud
 cheers,
 --
 NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
 Debian Developer - http://www.debian.org
 Free Software Developer - http://arnaud.quette.fr


 I can reproduce it ; here [1] is the output :
 At startup :

 ruliane@physrv01:~$ upsc onduleur
 battery.capacity: 9.00
 battery.charge: 100
 battery.charge.low: 50
 battery.charge.restart: 0
 battery.energysave: yes
 battery.protection: yes
 battery.runtime: 1962
 battery.type: PbAc
 device.mfr: MGE UPS SYSTEMS
 device.model: Pulsar 1500
 device.serial: 1Y3H34201
 device.type: ups
 driver.name: usbhid-ups
 driver.parameter.pollfreq: 30
 driver.parameter.pollinterval: 2
 driver.parameter.port: /dev/usb/hiddev0
 driver.version: 2.4.3
 driver.version.data: MGE HID 1.18
 driver.version.internal: 0.34
 input.bypass.current: 0.00
 input.bypass.voltage: 232.0
 input.frequency: 49.0
 input.frequency.nominal: 50
 input.voltage: 232.0
 input.voltage.nominal: 230
 outlet.1.autoswitch.charge.**low: 0
 outlet.1.delay.shutdown: 2592000
 outlet.1.delay.start: 3
 outlet.1.desc: PowerShare Outlet 1
 outlet.1.id: 1
 outlet.1.status: on
 outlet.1.switchable: yes
 outlet.2.autoswitch.charge.**low: 0
 outlet.2.delay.shutdown: 2592000
 outlet.2.delay.start: 6
 outlet.2.desc: PowerShare Outlet 2
 outlet.2.id: 2
 outlet.2.status: on
 outlet.2.switchable: yes
 outlet.desc: Main Outlet
 outlet.id: 0
 outlet.switchable: yes
 output.current: 1.30
 output.frequency: 49.0
 output.frequency.nominal: 50
 output.powerfactor: 0.76
 output.voltage: 41216.0
 output.voltage.nominal: 230
 ups.beeper.status: enabled
 ups.delay.shutdown: 20
 ups.delay.start: 30
 ups.firmware: 01
 ups.load: 19
 ups.load.high: 102
 ups.mfr: MGE UPS SYSTEMS
 ups.model: Pulsar 1500
 ups.power: 294
 ups.power.nominal: 1500
 ups.productid: 
 ups.realpower: 223
 ups.realpower.nominal: 1350
 ups.serial: 1Y3H34201
 ups.start.auto: yes
 ups.start.battery: no
 ups.start.reboot: yes
 ups.status: OL CHRG
 ups.test.interval: 604800
 ups.test.result: Done and passed
 ups.timer.shutdown: -1
 ups.timer.start: -1
 ups.type: online
 ups.vendorid: 0463

 [Unplugged]

 ruliane@physrv01:~$ upsc onduleur
 battery.capacity: 9.00
 battery.charge: 99
 battery.charge.low: 50
 battery.charge.restart: 0
 battery.energysave: yes
 battery.protection: yes
 battery.runtime: 2033
 battery.type: PbAc
 device.mfr: MGE UPS SYSTEMS
 device.model: Pulsar 1500

Re: [Nut-upsuser] snmp definitions problem

[Arnaud Quette]

2013/4/3 ramazan firin ramazan_fi...@hotmail.com

 Hi,

 İ have a necron snmp ups.

 nut-scanner cant find it. i tried to add with these definition but it
 fails..

 [test5-ups]
   driver = snmp-ups
 port = 10.9.40.19
   community = asdf12
 desc =test


 i run driver with debugging , result is ,

 root@upsviewer-debian:/usr/local/ups/bin# ./snmp-ups -DDD -a test5-ups
 Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5)
0.00 send_to_all: SETINFO driver.parameter.port 10.9.40.196
0.43 debug level is '7'
0.000490 SNMP UPS driver : entering upsdrv_initups()
0.000501 SNMP UPS driver : entering nut_snmp_init(snmp-ups)
0.001679 SNMP UPS driver : entering load_mib2nut(auto)
0.001691 trying the new match_sysoid() method
0.001696 Entering nut_snmp_get_str()
0.001706 nut_snmp_get(.1.3.6.1.2.1.1.2.0)
6.008128 Can't get sysOID value
6.008150 load_mib2nut: trying classic method with 'apcc' mib
6.008157 Entering nut_snmp_get_str()
6.008169 nut_snmp_get(.1.3.6.1.4.1.318.1.1.1.1.1.1.0)
   12.014585 load_mib2nut: trying classic method with 'mge' mib
   12.014609 Entering nut_snmp_get_str()
   12.014617 nut_snmp_get(.1.3.6.1.4.1.705.1.1.1.0)
   18.021015 load_mib2nut: trying classic method with 'netvision' mib
   18.021039 Entering nut_snmp_get_str()
   18.021047 nut_snmp_get(.1.3.6.1.4.1.4555.1.1.1.1.1.1.0)
   24.027518 load_mib2nut: trying classic method with 'pw' mib
   24.027540 Entering nut_snmp_get_str()
   24.027549 nut_snmp_get(1.3.6.1.4.1.534.1.1.2.0)
   30.033923 load_mib2nut: trying classic method with 'aphel_genesisII' mib
   30.033946 Entering nut_snmp_get_str()
   30.033954 nut_snmp_get(.1.3.6.1.4.1.17373.3.1.1.0)
   36.040390 load_mib2nut: trying classic method with 'aphel_revelation'
 mib
   36.040413 Entering nut_snmp_get_str()
   36.040427 nut_snmp_get(.1.3.6.1.4.1.534.6.6.6.1.1.12.0)
   42.046845 load_mib2nut: trying classic method with 'eaton_epdu' mib
   42.046869 Entering nut_snmp_get_str()
   42.046877 nut_snmp_get(.1.3.6.1.4.1.534.6.6.7.1.2.1.2.0)
   48.053299 load_mib2nut: trying classic method with 'pulizzi_switched1'
 mib
   48.053322 Entering nut_snmp_get_str()
   48.053330 nut_snmp_get(.1.3.6.1.4.1.20677.1)
   54.059725 load_mib2nut: trying classic method with 'pulizzi_switched2'
 mib
   54.059748 Entering nut_snmp_get_str()
   54.059757 nut_snmp_get(.1.3.6.1.4.1.20677.1)
   60.066200 load_mib2nut: trying classic method with 'raritan' mib
   60.066224 Entering nut_snmp_get_str()
   60.066232 nut_snmp_get(.1.3.6.1.4.1.13742.1.1.12.0)
   66.072623 load_mib2nut: trying classic method with 'baytech' mib
   66.072645 Entering nut_snmp_get_str()
   66.072654 nut_snmp_get(.1.3.6.1.4.1.4779.1.3.5.2.1.24.1)
   72.079055 load_mib2nut: trying classic method with 'cpqpower' mib
   72.079076 Entering nut_snmp_get_str()
   72.079084 nut_snmp_get(.1.3.6.1.4.1.232.165.3.1.1.0)
   78.085473 load_mib2nut: trying classic method with 'bestpower' mib
   78.085496 Entering nut_snmp_get_str()
   78.085504 nut_snmp_get(.1.3.6.1.4.1.2947.1.1.2.0)
   84.091922 load_mib2nut: trying classic method with 'cyberpower' mib
   84.091945 Entering nut_snmp_get_str()
   84.091953 nut_snmp_get(.1.3.6.1.4.1.3808.1.1.1.1.1.1.0)
   90.098338 load_mib2nut: trying classic method with 'ietf' mib
   90.098361 Entering nut_snmp_get_str()
   90.098370 nut_snmp_get(1.3.6.1.2.1.33.1.1.1.0)
   96.104771 No supported device detected
 root@upsviewer-debian:/usr/local/ups/bin#



 i ask to manufacturer about mibs, they send me information like that,

   0 upsBaseIdentModel .1.3.6.1.4.1.935.1.1.1.1.1.1  1
 upsSmartIdentFirmwareRevision .1.3.6.1.4.1.935.1.1.1.1.2.1  2
 upsThreePhaseRatingRectifierVoltage .1.3.6.1.4.1.935.1.1.1.8.8.1  3
 upsThreePhaseRatingRectifierFrequency .1.3.6.1.4.1.935.1.1.1.8.8.2  4
 upsThreePhaseRatingBypassVoltage .1.3.6.1.4.1.935.1.1.1.8.8.3  5
 upsThreePhaseRatingBypassFrequency .1.3.6.1.4.1.935.1.1.1.8.8.4  6
 upsThreePhaseRatingOutputVoltage .1.3.6.1.4.1.935.1.1.1.8.8.5  7
 upsThreePhaseRatingOutputFrequency .1.3.6.1.4.1.935.1.1.1.8.8.6  8
 upsThreePhaseRatingBatteryVoltage .1.3.6.1.4.1.935.1.1.1.8.8.7  9
 upsThreePhaseInputVoltageR/upsThreePhaseInputVoltageS/upsThreePhaseInputVoltageT
 .1.3.6.1.4.1.935.1.1.1.8.2.2/.1.3.6.1.4.1.935.1.1.1.8.2.3/.1.3.6.1.4.1.935.1.1.1.8.2.4
 10
 upsThreePhaseBypssSourceVoltageR/upsThreePhaseBypssSourceVoltageS/upsThreePhaseBypssSourceVoltageT
 .1.3.6.1.4.1.935.1.1.1.8.4.2/.1.3.6.1.4.1.935.1.1.1.8.4.3/.1.3.6.1.4.1.935.1.1.1.8.4.4
 11
 upsThreePhaseOutputVoltageR/upsThreePhaseOutputVoltageS/upsThreePhaseOutputVoltageT
 .1.3.6.1.4.1.935.1.1.1.8.3.2/.1.3.6.1.4.1.935.1.1.1.8.3.3/.1.3.6.1.4.1.935.1.1.1.8.3.4
 12
 upsThreePhaseOutputLoadPercentageR/upsThreePhaseOutputLoadPercentageS/upsThreePhaseOutputLoadPercentageT
 .1.3.6.1.4.1.935.1.1.1.8.3.5/.1.3.6.1.4.1.935.1.1.1.8.3.6/.1.3.6.1.4.1.935.1.1.1.8.3.7
 13 upsThreePhaseBatteryVoltage .1.3.6.1.4.1.935.1.1.1.8.1.1  14
 upsThreePhaseBatteryCapacityPercentage 

Re: [Nut-upsuser] NOTIFYCMD and SHUTDOWNCMD do not work until Nut is restarted

[Arnaud Quette]

bonjour Julien

2013/4/11 Julien Métairie ruli...@ruliane.net

 Hi everybody,

 I installed and configured Nut 2.4.3 on Debian Squeeze, using package. It
 monitors an MGE Pulsar 1500 UPS in standalone mode.

 Here are parts of upsmon.conf :
 SHUTDOWNCMD /bin/bash /root/extinction.sh  /var/log/ups/ups.log 21
 NOTIFYCMD /bin/bash /usr/sbin/alerte.sh
 [...]
 NOTIFYFLAG ONBATT   SYSLOG+EXEC

 At startup, driver, upsd and upsmon start but when I pull off the line, a
 message is appended to syslog but no script is executed, nor SHUTDOWNCMD is
 called. To make things better, I must restart Nut :
 invoke-rc.d nut restart

 Trying to understand this behavior, i noticed the following lines in
 syslog at computer startup, pasted there[1] for convenience :

 usb 3-1: New USB device found, idVendor=0463, idProduct=
 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4
 usb 3-1: Product: Pulsar
 usb 3-1: Manufacturer: MGE UPS SYSTEMS
 usb 3-1: SerialNumber: 1Y3H34201
 usb 3-1: configuration #1 chosen from 1 choice
 [...]
 /build/buildd-linux-2.6_2.6.**32-48squeeze1-i386-F95osd/**
 linux-2.6-2.6.32/debian/build/**source_i386_none/drivers/hid/**usbhid/hid-core.c:
 usb_submit_urb(ctrl) failed
 generic-usb 0003:0463:.0001: timeout initializing reports
 generic-usb 0003:0463:.0001: hiddev0,hidraw0: USB HID v1.10 Device
 [MGE UPS SYSTEMS Pulsar] on usb-:00:0a.1-1/input0
 usbcore: registered new interface driver usbhid
 usbhid: v2.6:USB HID core driver

 May the failure be linked to my issue ? What can I do to make Nut work as
 soon as my computer boots up ?


maybe.
can you reproduce this easily?
if so, what the result of upsc devname:
1) just after the boot?
2) then, when you've pulled the line?

Arnaud
cheers,
-- 
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] Startproblems - Settings for ups.conf

[Arnaud Quette]

2013/3/7 Charles Lepple clep...@gmail.com

 On Mar 7, 2013, at 6:48 AM, Gregor Burck wrote:

  0.199391 Checking device (06DA/0003) (005/003)
  0.199409 - VendorID: 06da
  0.199415 - ProductID: 0003
  0.199420 - Manufacturer: unknown
  0.199425 - Product: unknown
  0.199430 - Serial Number: unknown
  0.199436 - Bus: 005
  0.199440 Trying to match device
  0.199451 Device matches
  0.199460 failed to claim USB device: could not claim interface 0:
 Operation not permitted


there is a high recurring rate on this issue.
time to improve the situation...


  Any of those configurations should work, but there seems to be a
 permissions problem. This is odd, since there is a udev rule in the Ubuntu
 package on 12.04 which should match this device.


right, but...


 What does 'ls -l /dev/bus/005/003' return? (adjust the 005/003 to match
 the last part of the Checking device line for the UPS)

 You can also see if '/lib/nut/blazer_usb -DDD -u root -a powerwalker1'
 works temporarily.


I've just added the following to the FAQ, which will hopefully solve your
issue:
https://github.com/networkupstools/nut/commit/eb1f01ed6f0e3844d00876b748287976b7c2478a

this may need some improvement though (lsusb + ls -l /dev/bus/XXX/YYY
check, -u root test, ...)!
FAQ would need an overall refresh:
https://github.com/networkupstools/nut/issues/19

cheers,
arno
-- 
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] EATON 5PX with nut 2.6 on ubuntu 12.04

[Arnaud Quette]

2013/3/13 Sabine GOUDARD sabine.goud...@st-etienne.archi.fr


   Hello


Hello Sabine


 I almost managed to make everything work
 my server isn't in prodution because i had some problem on others system
 but last week i come back and i run an update on ubuntu 12.04.1 to 12.04.2
 I don't known if its' the reaseon or if someone has change something but
 scripts no longer work
 I have a message returned 2


could you please point the script or send the faulty command?
the more details, the better...

-- arno

Can you help me because I don't find how to solve this
 thanks
 Best regards
  sabine

 message d'origine-
 De: Sabine GOUDARD sabine.goud...@st-etienne.archi.fr
 A: Arnaud Quette aquette@gmail.com
 Date: Fri, 08 Mar 2013 08:46:19 +0100
 --


 Hello Arnaud
 I almost managed to make everything work
 my server isn't in prodution because i had some problem on others system
 but last week i come back and i run an update on ubuntu 12.04.1 to 12.04.2
 I don't known if its' the reaseon or if someone has change something but
 scripts no longer work
 I have a message returned 2
 Can you help me because I don't find how to solve this
 thanks
 Best regards
  sabine
 Le 13/12/2012 00:15, Arnaud Quette a écrit :


 2012/12/12 Sabine GOUDARD sabine.goud...@st-etienne.archi.fr

 Hello,


 Hello Sabine,


 I have a EATON 5PX with a Network Management Card
 on ubuntu 12.04

 I established a shutdown procedure like described in rogerprice.org
 It works

 I have an event mail on onbatt then another on onbattdelay1 then the
 upsmon -c fsd order on onbattedelay2

 When onbattdelay2 is finished, my server execute auto logout and
 shutdown proceeding
 then my ups shutdown too but when ?


 please read the section Limitation in snmp-ups:
 http://www.networkupstools.org/docs/man/snmp-ups.html

 though the 2 first sentences are not true anymore (I've implemented
 snmp-ups shutdown in 2.6.4), the last one is still very true!
 the best for you is to send an upscmd ... shutdown.return, before
 upsmon -c fsd on onbattedelay2

 My second question is
 I don't find the battery.charge.low parameter on this ups


 SNMP OID is not present with the MGE MIB.
 you can try mib= with pw or ietf in your ups.conf, and check which
 one provide the more data...


 my third question
 When electric power come back, ups restart, my server restart
 but the driver isn't connceted
 I have this message :Can't connect to UPS (snmp-ups-MYUPS) : no such
 file or directory
 If I restart nut service, it's ok
 What can I do to avoid this problem ?


 I don't recall the exact init script in 12.04, but /etc/init.d/nut-server
 should have a Required-Start: ... $network ...
 this implies low level networking (ethernet card; may imply PCMCIA
 running)
 but I can't guarantee that you SNMP agent is already reachable.
 you can delay (or wait for agent availability) in various manners.
 the more simple is probably to decrease NUT startup priority...


 and finally, last question
 When electric power come back, ups is started, my server is started
 how can I execute for example a wake on lan or a reboot for some
 computer which isn't connect on the ups


 again, various manners, and not especially tied to nut.
 I would recommend  calling wakeonlan or whatever ssh ... command in
 /etc/rc.local

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



 --

 *
 **Sabine Goudard*
 Service Informatique et Multimédia
 Tél : 04 77 42 37 20

 *Ecole Nationale Supérieure d’Architecture de Saint-Étienne*
 1, rue Buisson BP 94
 42003 Saint-Étienne Cedex 1
 Tél. : 04 77 42 35 42
 Fax : 04 77 42 35 40
 http://www.st-etienne.archi.fr

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

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

Re: [Nut-upsuser] Smart1500LCD USB and usbhid-ups

[Arnaud Quette]

2012/12/13 Steve Salier steve.sal...@gmail.com

 Arnaud,


Hi Steve,

Many thanks - I modified the conf file as you indicated - which seems to
 have solved the issue. Does this look ok?
  Dec 12 18:47:31 nas6 notifier: Network UPS Tools - Generic HID driver
 0.37 (2.6.5)
  Dec 12 18:47:31 nas6 notifier: USB communication driver 0.31
  Dec 12 18:47:32 nas6 notifier: Network UPS Tools - UPS driver controller
 2.6.5
  Dec 12 18:47:32 nas6 notifier: Starting nut.
  Dec 12 18:47:32 nas6 notifier: fopen /var/db/nut/upsd.pid: No such file
 or directory
  Dec 12 18:47:32 nas6 notifier: listening on 127.0.0.1 port 3493
  Dec 12 18:47:32 nas6 notifier: Connected to UPS [ups]: usbhid-ups-ups
  Dec 12 18:47:32 nas6 notifier: nut_upsmon not running? (check
 /var/db/nut/upsmon.pid).
  Dec 12 18:47:32 nas6 notifier: Starting nut_upsmon.
  Dec 12 18:47:32 nas6 notifier: kill: No such process
  Dec 12 18:47:32 nas6 notifier: UPS: ups (master) (power value 1)
  Dec 12 18:47:32 nas6 notifier: nut_upslog not running? (check
 /var/db/nut/upslog.pid).
  Dec 12 18:47:32 nas6 notifier: Starting nut_upslog.


it's indeed working!
I've thus added this ProductID 0x3016 to usbhid-ups (commit r3827)

Merci!


welcome.
thanks for your report!

Arnaud
-- 
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] EATON 5PX with nut 2.6 on ubuntu 12.04

[Arnaud Quette]

2012/12/12 Sabine GOUDARD sabine.goud...@st-etienne.archi.fr

 Hello,


Hello Sabine,


 I have a EATON 5PX with a Network Management Card
 on ubuntu 12.04

 I established a shutdown procedure like described in rogerprice.org
 It works

 I have an event mail on onbatt then another on onbattdelay1 then the
 upsmon -c fsd order on onbattedelay2

 When onbattdelay2 is finished, my server execute auto logout and
 shutdown proceeding
 then my ups shutdown too but when ?


please read the section Limitation in snmp-ups:
http://www.networkupstools.org/docs/man/snmp-ups.html

though the 2 first sentences are not true anymore (I've implemented
snmp-ups shutdown in 2.6.4), the last one is still very true!
the best for you is to send an upscmd ... shutdown.return, before upsmon
-c fsd on onbattedelay2

My second question is
 I don't find the battery.charge.low parameter on this ups


SNMP OID is not present with the MGE MIB.
you can try mib= with pw or ietf in your ups.conf, and check which
one provide the more data...


 my third question
 When electric power come back, ups restart, my server restart
 but the driver isn't connceted
 I have this message :Can't connect to UPS (snmp-ups-MYUPS) : no such file
 or directory
 If I restart nut service, it's ok
 What can I do to avoid this problem ?


I don't recall the exact init script in 12.04, but /etc/init.d/nut-server
should have a Required-Start: ... $network ...
this implies low level networking (ethernet card; may imply PCMCIA
running)
but I can't guarantee that you SNMP agent is already reachable.
you can delay (or wait for agent availability) in various manners.
the more simple is probably to decrease NUT startup priority...


 and finally, last question
 When electric power come back, ups is started, my server is started
 how can I execute for example a wake on lan or a reboot for some
 computer which isn't connect on the ups


again, various manners, and not especially tied to nut.
I would recommend  calling wakeonlan or whatever ssh ... command in
/etc/rc.local

cheers,
Arno
-- 
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] Smart1500LCD USB and usbhid-ups

[Arnaud Quette]

2012/12/11 Steve Salier steve.sal...@gmail.com


 Greetings all,


Hi Steve,


 Anyone have a clue on this behavior (see below) on this behavior with
 FreeNAS-8.3.0-RELEASE-x64 (r12701M) on a TrippLite 1500LCD UPS? NUT version
 is 2.6.5

 Using the following profile: Tripp-Lite ups 2 Smart1500LCD USB (usbhid-ups)

 I get the following:

 Dec 10 21:40:12 nas6 kernel: uhid0: Tripp Lite TRIPP LITE UPS, class 0/0,
 rev 1.10/0.02, addr 2 on usbus1
 Dec 10 21:40:12 nas6 notifier: Will not 'restart' nut because nut_enable
 is NO.
 Dec 10 21:40:12 nas6 notifier: Will not 'restart' nut_upsmon because
 nut_upsmon_enable is NO.
 Dec 10 21:40:12 nas6 notifier: Will not 'restart' nut_upslog because
 nut_upslog_enable is NO.
 Dec 10 21:40:20 nas6 notifier: nut not running? (check
 /var/db/nut/upsd.pid).
 Dec 10 21:40:20 nas6 notifier: nut_upsmon not running? (check
 /var/db/nut/upsmon.pid).
 Dec 10 21:40:20 nas6 notifier: nut_upslog not running? (check
 /var/db/nut/upslog.pid).
 Dec 10 21:40:21 nas6 notifier: nut not running? (check
 /var/db/nut/upsd.pid).
 Dec 10 21:40:21 nas6 notifier: This TrippLite? device (09ae:3016) is not
 (or perhaps not yet) supported
 Dec 10 21:40:21 nas6 notifier: by usbhid-ups. Please make sure you have an
 up-to-date version of NUT. If
 Dec 10 21:40:21 nas6 notifier: this does not fix the problem, try running
 the driver with the
 Dec 10 21:40:21 nas6 notifier: '-x productid=3016' option. Please report
 your results to the NUT user's
 Dec 10 21:40:21 nas6 notifier: mailing list nut-upsuser@….
 Dec 10 21:40:21 nas6 notifier:
 Dec 10 21:40:21 nas6 notifier: Network UPS Tools - Generic HID driver 0.37
 (2.6.5)
 Dec 10 21:40:21 nas6 notifier: USB communication driver 0.31
 Dec 10 21:40:21 nas6 notifier: No matching HID UPS found
 Dec 10 21:40:21 nas6 notifier: Driver failed to start (exit status=1)
 Dec 10 21:40:21 nas6 notifier: Network UPS Tools - UPS driver controller
 2.6.5
 Dec 10 21:40:21 nas6 root: /usr/local/etc/rc.d/nut: WARNING: failed precmd
 routine for nut
 Dec 10 21:40:21 nas6 notifier: /usr/local/etc/rc.d/nut: WARNING: failed
 precmd routine for nut
 Dec 10 21:40:21 nas6 notifier: nut_upsmon not running? (check
 /var/db/nut/upsmon.pid).
 Dec 10 21:40:21 nas6 notifier: Starting nut_upsmon.
 Dec 10 21:40:21 nas6 notifier: kill: No such process
 Dec 10 21:40:21 nas6 notifier: UPS: UPS1 (master) (power value 1)
 Dec 10 21:40:21 nas6 upsmon[39737]: UPS [UPS1]: connect failed: Connection
 failure: Connection refused
 Dec 10 21:40:21 nas6 upsmon[39737]: Communications with UPS UPS1 lost
 Dec 10 21:40:21 nas6 notifier: nut_upslog not running? (check
 /var/db/nut/upslog.pid).
 Dec 10 21:40:21 nas6 notifier: Starting nut_upslog.
 Dec 10 21:40:21 nas6 notifier: Warning: initial connect failed: Connection
 failure: Connection refused
 Dec 10 21:40:21 nas6 notifier: Stopping nut_upslog.
 Dec 10 21:40:21 nas6 notifier: Stopping nut_upsmon.
 Dec 10 21:40:21 nas6 upsmon[39736]: upsmon parent: read
 Dec 10 21:40:21 nas6 notifier: nut not running? (check
 /var/db/nut/upsd.pid).

 According to latest HCL for NUT, the TrippLite? SmartUPS 1500 is supported:
 http://www.networkupstools.org/stable-hcl.html


 Not sure where the reference the 09ae:3016 model type is coming from.


these are the USB Vendor and Product IDs, that permits usbhid-ups to find
supported devices.

in the present case, this specific product ID 3016 is not currently part of
our list.
we can add it, but the first thing to do is to try if it works ;)

as mentioned in the above log, just add -x productid=3016 or add
productid=3016 in ups.conf, after the port = auto line.

please report back if everything works, so that we can add this to
usbhid-ups.

cheers,
Arnaud
-- 
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-utalk ESV8+ comm problem

[Arnaud Quette]

All,

Martin has just acknowledged that everything is fine.

I've just committed the patch (r3819):
trac.networkupstools.org/projects/nut/changeset/3819

cheers,
Arno

2012/10/26 Arnaud Quette aquette@gmail.com


 2012/10/25 Martin Loyer mar...@martinloyer.fr

  Sorry guys,

 I'm leaving for 10 days tomorrow.

 I let you know on my way back.


 no pb Martin.
 I've created a patch 
 trackerhttps://alioth.debian.org/tracker/index.php?func=detailaid=313882group_id=30602atid=411544as
  a reminder.

 see you when you're back,
 Arnaud
 --
 Network UPS Tools (NUT) 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] bcmxcp_usb can not communicate with Eaton Powerware 5110

[Arnaud Quette]

2012/12/3 Jevgeni Jurtsenko jevgeni...@gmail.com

 Hi Arnaud,


Hi Jevgeni,


 Unfortunately your patch didn't solved the problem for me.


it couldn't, since your issue is upstream to it (i.e, in kernel land)


 I googled about the issue once more while setting the OS second time to
 give logs you asked previously.  Out of the syslog you can see that it is
 being flooded with *usbfs *errors about claiming the device. One of the
 suggestions was the problem with *dwc_otg *driver. However
 my solution was a script, which resets usb and I'm able to get data from
 UPS again.. As I mentioned above that re-plugging the usb cable solved it.
 Problem is not stable ~3 fails out of 5 startups. At the moment I am using
 PW5115

 lsusb -v -d0x06da:0x0002

 Bus 001 Device 004: ID 06da:0002 Phoenixtec Power Co., Ltd UPS
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   1.10
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize0 8
   idVendor   0x06da Phoenixtec Power Co., Ltd
   idProduct  0x0002 UPS
   bcdDevice1.00
   iManufacturer   4
   iProduct   24
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   34
 bNumInterfaces  1
 bConfigurationValue 1
 iConfiguration  0
 bmAttributes 0x80
   (Bus Powered)
 MaxPower   60mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   1
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass  0
   bInterfaceProtocol  0
   iInterface  0
   ** UNRECOGNIZED:  09 21 00 01 00 01 22 00 00
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes3
   Transfer TypeInterrupt
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0008  1x 8 bytes
 bInterval  20
 Device Status: 0x5a08
   (Bus Powered)
 ¤¤¤
 *grep usb /var/log/syslog*
 Nov 25 11:41:51 raspberrypi kernel: [   95.021492] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021531] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021573] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021611] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021653] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021693] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021733] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021774] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021815] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021855] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021897] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021936] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.021976] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 Nov 25 11:41:51 raspberrypi kernel: [   95.022017] usb 1-1.2: usbfs:
 process 1862 (bcmxcp_usb) did not claim interface 0 before use
 ¤¤
 */lib/nut/bcmxcp_usb -D -u root -a ups*
 Network UPS Tools - BCMXCP UPS driver 0.26 (2.6.5)
 USB communication subdriver 0.22
0.00 send_to_all: SETINFO driver.parameter.port auto
0.002520 debug level is '5'
0.019435 entering nutusb_open()
0.037846 device 004 opened successfully
0.039967 Can't claim POWERWARE USB interface: could not claim
 interface 0: Device or resource busy
0.041162 Can't reset POWERWARE USB endpoint: could not clear/halt
 ep 129: Device or resource busy
0.041965 device 004 opened successfully
0.042690 

Re: [Nut-upsuser] setup apc pcnet apc9616

[Arnaud Quette]

Hi,

please keep the traffic on the list!

2012/11/30 Periko Support pheriko.supp...@gmail.com

 On Fri, Nov 30, 2012 at 12:01 PM, Arnaud Quette aquette@gmail.com
 wrote:
 
  2012/11/30 Periko Support pheriko.supp...@gmail.com
 
   Hi friends.
 
  Searching for info about how to setup acp pcnet card on nut?
 
   Any info will be accepted, thanks!!!
 
 
  is it an SNMP card?
  if yes, then use snmp-ups, otherwise, I'll need more info.
  in all case, please report your results.
 
  cheers,
  Arnaud
  --
  NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
  Debian Developer - http://www.debian.org
  Free Software Developer - http://arnaud.quette.fr
 

 The UPS have snmp v1 enable.
 Right now with apcupsd is working but in pfsense I just have NUT them
 I want to know how can I access my ups.
 Any info will be appreciated.
 Thanks!!!


as told, you need the snmp-ups driver.
put something like the following in your ups.conf file:
[myups]
driver = snmp-ups
port = SNMP agent IP address
community = community

for more information on snmp-ups:
http://www.networkupstools.org/docs/man/snmp-ups.html

there is also plenty of docs on NUT configuration for pfsense...

success report is welcome since 9616 us not currently listed in our
supported cards.

cheers,
Arnaud
-- 
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] CyberPower DX600E won't switch up after power

[Arnaud Quette]

2012/12/1 Franck fra...@secretfatty.net

 Date: Mon, 26 Nov 2012 19:34:28 +0100
 From: Arnaud Quette aquette@gmail.com
 To: Franck fra...@secretfatty.net
 Cc: 
 nut-upsuser@lists.alioth.**debian.orgnut-upsuser@lists.alioth.debian.org
 Subject: Re: [Nut-upsuser] CyberPower DX600E won't switch up after power



 right. we need to monitor the UPS while it's shutting down...


 Well I'd like to try that; but I'm 2000km from my UPS and It seems to be
 problematic for me to have the test done.

 But anyway I just got this reply to my quite random inquiry to CyberPower
 (wrong country) support:

 I can only make vague guesses because I have never seen the product you
 have, and I am not familiar with the software you used to generate that
 data.  The following values stand out to me.

 battery.voltage: 4.7

 battery.voltage.nominal: 12

 ups.load: 31

 If I am interpreting them correctly your battery should be at 12 volts,
 but it is only at 4.7 volts?

 And the UPS load is 31%?



 If the battery is at 4.7 volts it will not pass the power on self-test. It
 needs to be somewhere above 10 volts (Perhaps 10.5 or 11)before it will
 pass the self-test and let the ups turn on.



 Other possibilities.

 If you have the computers set to auto start when power is restored, they
 will turn on simultaneously, if there has been a power loss that
 significantly drained the batteries, they will have very little energy when
 the power is restored.  The power on self test checks the CyberPower’s
 ability to run on battery by stopping access to wall power and forcing the
 UPS on to battery power.  If the batteries are very low and the auto
 startup of the computers hits while they are being tested then the load of
 the computers on the weak battery could cause the voltage to drop and the
 self-test would fail.



 One or both of your computers has an Active PFC power supply and your UPS
 is not a sine wave ups. If you are not familiar with this problem, just
 search the internet on the terms “active pfc” and “sine”



 The battery in the UPS could be defective.



 Again.  I do not know the product you are asking about so I can’t provide
 an accurate diagnosis.  I can only suggest possibilities.

 

 So if the guy os right and this might be a battery problem.


hem, ups.load is the load on the UPS output.
what you were looking for is probably battery.charge.

battery.voltage seems indeed wrong, but to me, that's another issue.
yours is with the restart function, that is tied to the USB/HID data I
mentioned before.
monitoring these counting down should help understanding how these actually
behave.

it's true that being 2000kms away doesn't make things easy.
but there each problem has at least 1 solution:
instead of doing a full reboot cycle, we can just monitor for 10 seconds,
and cancel the procedure

- stop NUT after the reboot,
- restart the driver in debug more (/lib/nut/usbhid-ups -D myups)
and upsd (simply type upsd as root) in another term
- then execute upscmd -u ... -p ... myups shutdown.return
CAUTION: wait no more than 10-15 seconds!!! Otherwise, your server will
crash!!!
possibly monitor your unit with upsc
- then execute upscmd -u ... -p ... myups shutdown.cancel (mention -u and
-p to avoid loosing a few seconds!)
-then Ctrl+C in the driver term.
and send back the driver output, in compressed form.
you can then restart everything as usual...

cheers,
Arnaud
-- 
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] Issues with USB connectivity

[Arnaud Quette]

]=21
1.065709 HID descriptor, method 2: (9 bytes) = 09 21 00 01 21 01
 22 03 02
1.065712 HID descriptor length 515
1.068713 Unable to get Report descriptor: Broken pipe


... confirmed here!


1.068735 Checking device (0E0F/0002) (002/003)
1.079553 - VendorID: 0e0f
1.079562 - ProductID: 0002
1.079565 - Manufacturer: unknown
1.079568 - Product: VMware Virtual USB Hub
1.079571 - Serial Number: unknown
1.079574 - Bus: 002
1.079577 Trying to match device
1.079582 Device does not match - skipping
1.079592 No appropriate HID device found
1.079599 No matching HID UPS found

 Regards

 - Simon

 From: Arnaud Quette [mailto:aquette@gmail.com]
 Sent: Thursday, 29 November 2012 4:10 AM
 To: Simon Attwell
 Cc: nut-upsuser@lists.alioth.debian.org
 Subject: Re: [Nut-upsuser] Issues with USB connectivity


 2012/11/28 Charles Lepple clep...@gmail.com
 On Nov 27, 2012, at 9:43 PM, Simon Attwell wrote:

 0.026636 Checking device (051D/0003) (002/002)
 1.037912 - VendorID: 051d
 1.037931 - ProductID: 0003
 Unfortunately, this looks like an APC 5G model. NUT v2.6.5 already has one
 hack to work around their broken HID implementation (the 'interrupt pipe
 disabled' message), but I am not sure that we have uncovered all of the
 quirks yet.


as Charles mentioned here, we may have uncovered a new noncompliance to USB!

what would really help is:
- an USB sniff (using Wireshark) of the communication with APC software.
Please, either point it as an URL (on your website or anything else) or
compressed (the whole mail must be under 40Kb!)
- a test with the latest apcupsd version (development if possible).

Note that you may also contact APC:
the mentioned usbhid-ups quirk was an official request from APC (the only
one to be precise), so quite probably due to a user support request...

cheers,
Arnaud
-- 
Engineering Linux/Unix Expert - Opensource Solutions Lead - Eaton -
http://opensource.eaton.com
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
--
Conseiller Municipal - Saint Bernard du Touvet
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] setup apc pcnet apc9616

[Arnaud Quette]

2012/11/30 Periko Support pheriko.supp...@gmail.com

  Hi friends.

 Searching for info about how to setup acp pcnet card on nut?

  Any info will be accepted, thanks!!!


is it an SNMP card?
if yes, then use snmp-ups, otherwise, I'll need more info.
in all case, please report your results.

cheers,
Arnaud
-- 
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] bcmxcp_usb can not communicate with Eaton Powerware 5110

[Arnaud Quette]

2012/11/29 Jevgeni Jurtsenko jevgeni...@gmail.com

 Hello all,


Hi Jevgeni,


 While repeatedly setting up the system for tests figured out the problem
 in other OS subsystem driver. Problem solved with the script. Thanks again
 for your time


I'm not sure to understand: do you mean that the patch I've provided
(xcp-rcv-loop.diff) has fixed your issue or?

cheers,
Arnaud
-- 
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] NOTIFYCMD

[Arnaud Quette]

2012/11/28 Charles Lepple clep...@gmail.com

 On Nov 27, 2012, at 9:30 AM, lejeczek wrote:

  I'm looking for pager.txt which upsmon.conf mentions of, but could not
 find it anywhere including the sources?


 It has been incorporated into docs/scheduling.txt - I've updated the
 upsmon.conf sample file and man page.

 I haven't used it myself, though.


Note that this text doc. is also available in HTML format, within the user
manual:
http://www.networkupstools.org/docs/user-manual.chunked/ar01s07.html

cheers,
Arnaud
-- 
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] Issues with USB connectivity

[Arnaud Quette]

2012/11/28 Charles Lepple clep...@gmail.com

 On Nov 27, 2012, at 9:43 PM, Simon Attwell wrote:

 0.026636 Checking device (051D/0003) (002/002)
 1.037912 - VendorID: 051d
 1.037931 - ProductID: 0003

 Unfortunately, this looks like an APC 5G model. NUT v2.6.5 already has one
 hack to work around their broken HID implementation (the 'interrupt pipe
 disabled' message), but I am not sure that we have uncovered all of the
 quirks yet.

 What does 'lsusb -v -d 051d:0003' return?


my guess is that it's a local source install (hint: /usr/local/ups/...) and
udev helper file (52-nut-usbups.rules) is not installed.

a validation of this would be to use -u root to test for device
privileges issues:
# ./usbhid-ups -D -u root -a apc1000

if it works, then it's actually a udev issue.
otherwise, you indeed uncovered a new potential issue with APC 5G...

cheers,
Arnaud
-- 
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] driver looking for MAXIM MXE II

[Arnaud Quette]

2012/11/28 Walter O. Dari wlin...@gmail.com

 El 28/11/12 03:00, Kjell Claesson escribió:

  I think Arnaud was referring to the NUT version.
 The blazer_usb have been updated so you would need NUT 2.6.4
 to make it recognise the ups.



 Ops ... sorry!:-(

 Then I'll change the version of nut.

 Thank you very much!


Kjell is fully right: I was indeed referring to NUT 2.6.4 minimum.
sorry for not stating it more clearly, and thanks to Kjell!

cheers,
Arnaud
-- 
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] MEC0003 protocol support

[Arnaud Quette]

2012/11/27 Walshe, John (DCOR) john.wal...@smithsdetection.com

 Hi Arnaud,


Hi John


 

 Thanks for replying.


welcome, but please keep the list cc'ed!


 

 Since I sent the message I tried the UPS on winXP  just to see if the
 upsilon s/w did toggle beeper and shutdown as required. Indeed it did, but
 it didn’t perform any of the battery tests . So with UsbSnoop I tried to
 grab the usb traffic to capture the command stream. Unfortunately that s/w
 doesn’t seem to capture the downstream properly – just the upstream. From
 that however I could see that the reply to the standard query (Q1) command
 conformed to the MEC0002 protocol – so we are not far away.

 We presently have the ups on another PC with XP inside a VM on Debian
 squeeze. We’ll try to capture the downstream from upsilon that does result
 in a shutdown and a beeper toggle.

 If we have luck I’ll send you the details.

 **


ok, thanks.
considering the above, a blazer_usb trace, with debug level 5 (i.e -D)
would be interesting too.

which version of NUT are you using btw?

cheers,
Arno
-- 
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] Kernel crash when using usbhid-ups driver.

[Arnaud Quette]

2012/11/27 Paul Whittaker paul.whitta...@drisq.com

 Hi,


Hi Paul,

I've recently added a UPS (CyberPower CP1300EPFCLCD) to one of our
 servers, and I'm managing it with NUT and the usbhid-ups driver.  I've
 configured it to do what we want, and it all works fine. (upsc displays
 information from upsd correctly, upsmon correctly shuts down both the
 server and the UPS when the battery is low, messages are logged when the
 mains supply to the UPS is cut/restored, and so forth.)

 However, in the week since installing NUT the server has suffered four
 kernel crashes (on stock 64-bit Ubuntu kernels, currently
 3.2.0-33-generic) and has been unable to stay up for longer than 12-36
 hours without crashing hard and requiring manual power cycling; this
 system has never previously crashed.  Googling around the issue brings
 up various things, including
 http://thr3ads.net/nut-upsdev/2011/01/1475908-a-nasty-kernel-oops, which
 make me think this could be an existing issue with the
 kernel/library/USB stack that's being triggered by NUT.  I've tried a
 couple of workarounds (including running the driver with -D), but none
 have prevented these lock-ups.

 I'd like to use NUT with usbhid-ups to manage the UPS, but also
 (obviously) need to keep the server stable.  If there's a way to do
 this, I'd like to; if not, I've got some crash logs that someone might
 perhaps find useful.

 I'm happy to provide more details, but first I'd like to check a few
 basics since I'm new to the list:

  1. Is this the right mailing list to be asking about this?  I can
 imagine the devs would be interested in this, but I'm primarily here as
 a user.


yes

 2. Is the Linux USB subsystem already known to be prone to stability
 issues like this, or am I just having some bad luck on this machine?


we have had very few issue, and yours is the 2nd (kernel crash with
production release, such as Alfred Ganz) iirc.
and your issue is probably different from Alfred's one, at least in the
symptoms.


  3. What's the polite way to supply the list with large attachments,
 such as log extracts (~10kB) and photos of kernel crash screens (~900kB)?


please send the log here, in compressed form.
are the photos taken with a still cam?
please put these on your website (or any other public storage) and point
the link

a dump file would be preferable:
https://help.ubuntu.com/12.04/serverguide/kernel-crash-dump.html

cheers,
Arnaud
-- 
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] Unable to disable beeper on Powercom Imperial IMP-525AP [SOLVED]

[Arnaud Quette]

2012/11/23 Sergey Talchuk tals1...@gmail.com

 Hi Arnaud,


Hi Sergey,

I received several replies from technical support.
 It turned out that according to the UPS serial number it had been
 manufactured in 2012. So, the device should support the ability to disable
 the beeper.
 But still I can not disable the beeper using the latest version of UPSMON
 Plus in Windows:
 http://www.pcm.ru/data/download/public/soft/setup_upsmon_v2.9.rar (don't
 know why; the device was tested on XP/Win7 with different USB cables)
 [WORKAROUND]
 However, beeper can be disabled with the button on the UPS (except when
 the device starts and the battery capacity is 0 the beeper should/will work)
 NUT gets the correct value now:

 $ upsc powercom ups.beeper.status
 disabled

 Thank you,
 Sergey


thanks for this info, it will probably be useful to other NUT Powercom
users.

cheers,
Arnaud
-- 
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

On Thu, Nov 1, 2012 at 3:07 PM, Arnaud Quette aquette@gmail.com wrote:


 2012/10/31 Sergey Talchuk tals1...@gmail.com

 Hi Arnaud,


 Hi Sergey,

 Unfortunately, I did not get an answer from the manufacturer's support.
 However, in the forum I got to know that the ability to disable the
 beeper had been added in 2010 only.
 http://forum.pcm.ru/viewtopic.php?f=4t=12642
 http://forum.pcm.ru/viewtopic.php?f=10t=10376

 So UPS devices which where built after 2010 should support this option.


 thanks for sharing this info with us.
 I assume yours was built before 2010.

 cheers,
 Arnaud
 --
 Network UPS Tools (NUT) 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] cheap UPS for NUT?

[Arnaud Quette]

2012/11/23 Periko Support pheriko.supp...@gmail.com

  Hi guys.


Hi

 My first post, I had see the list of compatible UPS devices, I have
 use APC BackupUPS 550, 450, but does cost +55 bucks, exist other model
 or brand usb/serial that someone have working and a little cheaper
 that APC?

 Thanks!!!


the cheapest units supported by NUT are the ones supported by
blazer_{ser,usb} drivers, and sold by more than 75 manufacturers (this is
only the number of brands supported by NUT though!):
http://www.networkupstools.org/stable-hcl.html

cheers,
Arnaud
-- 
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] CyberPower DX600E won't switch up after power

[Arnaud Quette]

Hi Franck

2012/11/23 Franck fra...@secretfatty.net

 Subject: [Nut-upsuser] CyberPower DX600E won't switch up after power
 is back
 Message-ID: 
 3c530815d1ea602efdfec0d67eb1e**0...@secretfatty.net3c530815d1ea602efdfec0d67eb1e...@secretfatty.net
 
 Content-Type: text/plain; charset=UTF-8; format=flowed

 Hello
 I have an issue with an CyberPower DX600E,
 it doesn't switch up when the power is back; after it has been
 unloaded;
 is it because of one of those variables ?
 regards
 Franck

 #upsc myups
 battery.charge: 100
 battery.charge.low: 10
 battery.charge.warning: 20
 battery.mfr.date: CPS
 battery.runtime: 1380
 battery.runtime.low: 300
 battery.type: PbAcid
 battery.voltage: 4.7
 battery.voltage.nominal: 12
 device.mfr: CPS
 device.model: DX600E
 device.type: ups
 driver.name: usbhid-ups
 driver.parameter.pollfreq: 30
 driver.parameter.pollinterval: 2
 driver.parameter.port: auto
 driver.version: 2.4.3
 driver.version.data: CyberPower HID 0.3
 driver.version.internal: 0.34
 input.transfer.high: 0
 input.transfer.low: 0
 input.voltage: 230.0
 input.voltage.nominal: 230
 output.voltage: 238.0
 ups.beeper.status: enabled
 ups.delay.shutdown: 20
 ups.delay.start: 30
 ups.load: 31
 ups.mfr: CPS
 ups.model: DX600E
 ups.productid: 0501
 ups.realpower.nominal: 360
 ups.status: OL
 ups.timer.shutdown: -60
 ups.timer.start: 0
 ups.vendorid: 0764



 Am i suppose to run a shutdown.return command ?

 Does it make sense to do it in the script triggering (for example when
 receiving low battery ?


depending on your exact OS / distros, this should be handled by NUT
initscripts and probably the halt one.
what is yours?

some generic info on how shutdown works with NUT:
http://www.networkupstools.org/docs/user-manual.chunked/ar01s06.html#Shutdown_design

cheers,
Arnaud
-- 
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] MEC0003 protocol support

[Arnaud Quette]

2012/11/21 Walshe, John (DCOR) john.wal...@smithsdetection.com

 Hi Folks,

 I’m trying to use a ZIGOR Danubio 2000 ups with NUT on Debian squeeze
 (AMD64).

 OS/NUT are all the latest official release (as of last week) with NUT
 installed from packages.

 ** **

 As the usb descriptor presents MEC (and the Fry’s electronics) I chose to
 use the blazer_usb driver.

 ** **

 All appears to work well excepting that the UPS does not appear to accept
 the shutdown instcmd to turn off the ups outputs at the end of the shutdown
 process. The UPS remains on until the batteries completely drain and it has
 to turn off to protect itself.

 Apart from that, reporting, messaging, shutdown process etc  all works
 well.

 ** **

 ** **

 On shutdown I can see 

 instcmd: command [shutdown.stop] handled

 instcmd: command [shutdown.return] handled

 Shutting down in 30 seconds

 Waiting for UPS to cut power.

 Will now halt.

 ** **

 The PC turns off put UPS stays running until batteries run out.

 ** **

 So I can see that the driver issues the command and thinks that it is
 “handled”. Looking at it with higher debug level I can see that the driver
 reports a “USB no ACK” to these instcmds. Checking the USB with wireshark
 shows that this text string originated in the UPS, ie it is a text string
 returned in response to the instcmds.

 ** **

 Looking closer at the USB descriptor it presents MEC0003 rather than the
 MEC0002 that I see all over the fora.

 ** **

 So it would appear that there is a new variety of MEC protocol. 

 Has anyone else seen this?

 Is there any work ongoing with this MEC0003 protocol?

 What can I do to help this cause? (bear in mind I’m a Linux newbie – but
 with good backup J )


could you please send back a driver output, debug level 5 (i.e -D),
including a shutdown.return command sent from upscmd.
note that, for this test, you should remove your system from the UPS, or
send directly a shutdown.stop afterward.

I'm also interested in the wireshark snoop.

cheers,
Arnaud
-- 
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] CyberPower DX600E won't switch up after power

[Arnaud Quette]

2012/11/26 Franck fra...@secretfatty.net

 On 2012-11-26 18:39, Arnaud Quette wrote:

 Hi Franck

 2012/11/23 Franck fra...@secretfatty.net [3]

  Subject: [Nut-upsuser] CyberPower DX600E wont switch up after

 power
 is back
 Message-ID: 
 3c530815d1ea602efdfec0d67eb1e**0...@secretfatty.net3c530815d1ea602efdfec0d67eb1e...@secretfatty.net
 [1]

 Content-Type: text/plain; charset=UTF-8; format=flowed

 Hello
 I have an issue with an CyberPower DX600E,
 it doesnt switch up when the power is back; after it has been

 unloaded;
 is it because of one of those variables ?
 regards
 Franck

 #upsc myups
 battery.charge: 100
 battery.charge.low: 10
 battery.charge.warning: 20
 battery.mfr.date: CPS
 battery.runtime: 1380
 battery.runtime.low: 300
 battery.type: PbAcid
 battery.voltage: 4.7
 battery.voltage.nominal: 12
 device.mfr: CPS
 device.model: DX600E
 device.type: ups
 driver.name [2]: usbhid-ups

 driver.parameter.pollfreq: 30
 driver.parameter.pollinterval: 2
 driver.parameter.port: auto
 driver.version: 2.4.3
 driver.version.data: CyberPower HID 0.3
 driver.version.internal: 0.34
 input.transfer.high: 0
 input.transfer.low: 0
 input.voltage: 230.0
 input.voltage.nominal: 230
 output.voltage: 238.0
 ups.beeper.status: enabled
 ups.delay.shutdown: 20
 ups.delay.start: 30
 ups.load: 31
 ups.mfr: CPS
 ups.model: DX600E
 ups.productid: 0501
 ups.realpower.nominal: 360
 ups.status: OL
 ups.timer.shutdown: -60
 ups.timer.start: 0
 ups.vendorid: 0764


 Am i suppose to run a shutdown.return command ?

 Does it make sense to do it in the script triggering (for example
 when receiving low battery ?


 depending on your exact OS / distros, this should be handled by NUT
 initscripts and probably the halt one.
  what is yours?


 Thanks for your reply Arnaud;
 I have a debian squeeze.


looking again at your upsc output, I suspect more an issue with the UPS
than with Squeeze.

a good test would be to:
- remove your PC from the UPS,
- stop NUT after the reboot,
- restart the driver in debug more (/lib/nut/usbhid-ups -D myups) and
upsd (simply type upsd) in another term
- then execute upscmd -u ... -p ... myups shutdown.return
- leave it half a minute, then Ctrl+C in the driver term.
and send back the driver output, in compressed form.
you can then restart everything as usual...

I'd like to see how the data behind ups.timer.shutdown and
ups.timer.start behave.

cheers,
Arnaud
-- 
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] APC UPS: replacement battery always triggers shutdown

[Arnaud Quette]

Michal, Kastus, Jack,

I have a similar request sitting in the Features requests for years:
https://alioth.debian.org/tracker/index.php?func=detailaid=304645group_id=30602atid=411545
http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-June/000938.html

would you please unite your efforts and bring a patch for NUT FAQ (or the
driver(s))?

thanks a lot!
Arnaud
-- 
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

2012/11/11 Kastus Shchuka ks-...@tprfct.net

 On Sun, Nov 11, 2012 at 07:21:35AM -0800, JS wrote:
  I followed this procedure (charging the battery fully, letting it drain
 off a token load while UPS is grounded on a surge protector) but it did not
 help.
 
  Perhaps I missed something running this procedure; if anyone has
 suggestions for solving this they'd be greatly appreciated.

 I've been in the same situation after replacing the battery in SC620I
 model.

 Then I found
 http://old.nabble.com/SmartUPS-and-new-battery-td20678966.html
 and followed the procedure:

 1. Shutdown the apcupsd daemon.
 2. Run apctest
 3. Choose option 6 to enter terminal mode
 4. Enter Y (UPS should respond SM)
 5. Enter 1 (one, not el; wait 4 seconds)
 6. Enter 1 (one, not el; UPS should respond PROG)
 7. Enter 0 (zero, not oh; UPS should respond with current constant)
 8. Enter + (plus) or - (minus) to increment/decrement the value
 9. Enter R to reprogram constant value (UPS should respond Bye)
 10. Enter Y (UPS should respond SM)
 11. Enter 0 (zero, not oh; UPS should respond with the new constant)
 12. Enter Esc to exit terminal mode
 13. Choose option 7 to exit apctest.

 The value to store in the register 0 differs by the model. There is a table
 posted in the middle of the thread. I hope your model is listed there.
 If you cannot find your model, you may want to try experimenting with
 different
 values.

 In my case, after updating register 0, my UPS is back to 42 min runtime.

 Hope this helps.

 Kastus


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

Re: [Nut-upsuser] CyberPower DX600E won't switch up after power

[Arnaud Quette]

2012/11/26 Franck fra...@secretfatty.net

 On 2012-11-26 19:34, Arnaud Quette wrote:

 2012/11/26 Franck fra...@secretfatty.net [4]

  On 2012-11-26 18:39, Arnaud Quette wrote:

  Hi Franck

 2012/11/23 Franck fra...@secretfatty.net [3] [3]

  Subject: [Nut-upsuser] CyberPower DX600E wont switch up after

 power
 is back
 Message-ID: 
 3c530815d1ea602efdfec0d67eb1e**0...@secretfatty.net3c530815d1ea602efdfec0d67eb1e...@secretfatty.net
 [1]
 [1]

 Content-Type: text/plain; charset=UTF-8; format=flowed

 Hello
 I have an issue with an CyberPower DX600E,
 it doesnt switch up when the power is back; after it has been

 unloaded;
 is it because of one of those variables ?
 regards
 Franck

 #upsc myups
 battery.charge: 100
 battery.charge.low: 10
 battery.charge.warning: 20
 battery.mfr.date: CPS
 battery.runtime: 1380
 battery.runtime.low: 300
 battery.type: PbAcid
 battery.voltage: 4.7
 battery.voltage.nominal: 12
 device.mfr: CPS
 device.model: DX600E
 device.type: ups
 driver.name [2] [2]: usbhid-ups


 driver.parameter.pollfreq: 30
 driver.parameter.pollinterval: 2
 driver.parameter.port: auto
 driver.version: 2.4.3
 driver.version.data: CyberPower HID 0.3
 driver.version.internal: 0.34
 input.transfer.high: 0
 input.transfer.low: 0
 input.voltage: 230.0
 input.voltage.nominal: 230
 output.voltage: 238.0
 ups.beeper.status: enabled
 ups.delay.shutdown: 20
 ups.delay.start: 30
 ups.load: 31
 ups.mfr: CPS
 ups.model: DX600E
 ups.productid: 0501
 ups.realpower.nominal: 360
 ups.status: OL
 ups.timer.shutdown: -60
 ups.timer.start: 0
 ups.vendorid: 0764


 Am i suppose to run a shutdown.return command ?

 Does it make sense to do it in the script triggering (for
 example
 when receiving low battery ?


 depending on your exact OS / distros, this should be handled by
 NUT
 initscripts and probably the halt one.
  what is yours?


 Thanks for your reply Arnaud;
 I have a debian squeeze.


 looking again at your upsc output, I suspect more an issue with the
 UPS than with Squeeze.

 a good test would be to:
 - remove your PC from the UPS,


 Just to check I understood well:
 You mean I would plug the PC directly to the power source, and connect the
 UPS with the PC only using the USB ?


right. we need to monitor the UPS while it's shutting down...


  - stop NUT after the reboot,
 - restart the driver in debug more (/lib/nut/usbhid-ups -D myups)
 and upsd (simply type upsd) in another term
  - then execute upscmd -u ... -p ... myups shutdown.return
 - leave it half a minute, then Ctrl+C in the driver term.
 and send back the driver output, in compressed form.
 you can then restart everything as usual...

 Id like to see how the data behind ups.timer.shutdown and
 ups.timer.start behave.



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

Re: [Nut-upsuser] driver looking for MAXIM MXE II

[Arnaud Quette]

You will need at least 2.6.4 for this unit, but it's really blazer_usb.

Cheers,
Arnaud
(sent from my S3... please excuse my brevity)
Le 23 nov. 2012 09:40, Walter O. Dari wlin...@gmail.com a écrit :

 Results:

 wodari@svrsw2:/usr/local/**MonitorSoftware$ lsusb
 Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 002: ID 06da:0201 Phoenixtec Power Co., Ltd
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


 1
 --**--**
 
 ups.conf

 [maxim]
 driver = blazer_usb
 port = auto
 desc = SW servers


 wodari@svrsw2:~$ /sbin/upsdrvctl start
 Network UPS Tools - UPS driver controller 2.4.3
 Network UPS Tools - Megatec/Q1 protocol USB driver 0.03 (2.4.3)
 No supported devices found. Please check your device availability with
 'lsusb'
 and make sure you have an up-to-date version of NUT. If this does not help,
 try running the driver with at least 'subdriver', 'vendorid' and
 'productid'
 options specified. Please refer to the man page for details about these
 options
 (man 8 blazer).

 Driver failed to start (exit status=1)
 --**--**
 

 2
 --**--**
 
 ups.conf

 [maxim]
 driver = megatec_usb
 port = auto
 desc = SW servers


 wodari@svrsw2:~$ /sbin/upsdrvctl start
 Network UPS Tools - UPS driver controller 2.4.3
 Network UPS Tools - Megatec protocol driver 1.6 (2.4.3)
 Serial-over-USB transport layer 0.10
 No supported devices found. Please check your device availability with
 'lsusb'
 and make sure you have an up-to-date version of NUT. If this does not help,
 try running the driver with at least 'vendorid' and 'subdriver' options
 specified. Please refer to the man page for details about these options
 (man 8 megatec_usb).
 Please report your results to the NUT user's mailing list
 nut-upsuser@lists.alioth.**debian.orgnut-upsuser@lists.alioth.debian.org
 .

 Driver failed to start (exit status=1)
 --**--**
 

 3
 --**--**
 
 ups.conf

 [maxim]
 driver = bcmxcp_usb
 port = auto
 desc = SW servers


 wodari@svrsw2:~$ /sbin/upsdrvctl start
 Network UPS Tools - UPS driver controller 2.4.3
 Network UPS Tools - BCMXCP UPS driver 0.23 (2.4.3)
 USB communication subdriver 0.18
 Can't open POWERWARE USB device, retrying ...
 Can't open POWERWARE USB device, retrying ...
 Can't open POWERWARE USB device, retrying ...
 --**--**
 

 4
 --**--**
 
 ups.conf

 [maxim]
 driver = tripplite_usb
 port = auto
 desc = SW servers


 wodari@svrsw2:~$ /sbin/upsdrvctl start
 Network UPS Tools - UPS driver controller 2.4.3
 Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.4.3)
 Warning: This is an experimental driver.
 Some features may not function correctly.

 No matching USB/HID UPS found
 Driver failed to start (exit status=1)
 --**--**
 


 More info...

 I'm use Debian Squeeze

 wodari@svrsw2:~$ uname -a
 Linux svrsw2 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64
 GNU/Linux

 wodari@svrsw2:~$ upsrw maxim
 Can't connect: Connection failure: Connection refused

 wodari@svrsw2:~$ upscmd -l maxim
 Error: Connection failure: Connection refused



 Walter




 El 23/11/12 04:18, Arnaud Quette escribió:

 HolÃ

 Try blazer_usb. Please report back if everything is working as per
 http://www.networkupstools.**org/stable-hcl.html#footnoteshttp://www.networkupstools.org/stable-hcl.html#footnotes

 Cheers
 Arnaud
 (sent from my S3... please excuse my brevity)

 Le 21 nov. 2012 23:13, Walter O. Dari wlin...@gmail.com
 mailto:wlin...@gmail.com a écrit :

 Hello:

 I have a UPS model MXE II MAXIM brand online, 3500VA 2100W.
 Connects to the PC by a USB 2.0 port.
 I wanted to use nut, but this brand is not on the list of nut drivers.

 lsusb returns:

 ...
 Bus 003 Device 003: ID 06DA: 0201 Phoenixtec Power Co., Ltd
 ...

 I did not find this manufacturer in the driver list.

 Anyone know if you can have compatibility with other make and model
 of UPS.

 With what driver it could start testing?

 Greetings and thanks,
 Walter

 (original Spanish text translated by Google)


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

Re: [Nut-upsuser] driver looking for MAXIM MXE II

[Arnaud Quette]

Holà

Try blazer_usb. Please report back if everything is working as per
http://www.networkupstools.org/stable-hcl.html#footnotes

Cheers
Arnaud
(sent from my S3... please excuse my brevity)
Le 21 nov. 2012 23:13, Walter O. Dari wlin...@gmail.com a écrit :

 Hello:

 I have a UPS model MXE II MAXIM brand online, 3500VA 2100W.
 Connects to the PC by a USB 2.0 port.
 I wanted to use nut, but this brand is not on the list of nut drivers.

 lsusb returns:

 ...
 Bus 003 Device 003: ID 06DA: 0201 Phoenixtec Power Co., Ltd
 ...

 I did not find this manufacturer in the driver list.

 Anyone know if you can have compatibility with other make and model of UPS.

 With what driver it could start testing?

 Greetings and thanks,
 Walter

 (original Spanish text translated by Google)

 __**_
 Nut-upsuser mailing list
 Nut-upsuser@lists.alioth.**debian.orgNut-upsuser@lists.alioth.debian.org
 http://lists.alioth.debian.**org/cgi-bin/mailman/listinfo/**nut-upsuserhttp://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

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

Re: [Nut-upsuser] PowerCom BNT-600AP on ubuntu 12.04.1 AMD64

[Arnaud Quette]

2012/11/13 Tosoa elsif...@gmail.com

 Hello people,


I use a BNT-600AP from PowerCom, and on driver loading (nut service start)
 the UPS goes off so I cannot use nut as service as the computer goes off
 with the UPS.

 When the computer is not using the UPS, but still connected, I see that
 the UPS goes off for a very short time, does battery check and goes on
 again.

 I don't know how to deal with this issue as I cannot use my UPS with nut.


could you please provide back:
- the content of your ups.conf file
- the output of the driver using (don't power your PC with this UPS!):
$ /path/to/driver -D -a upsname

cheers,
Arnaud
-- 
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] GE LP Series?

[Arnaud Quette]

Hi Roy,

Try using blazer_ser or blazer_usb.

Cheers,
Arnaud
(sent from my S3... please excuse my brevity)
Le 14 nov. 2012 11:23, Roy Sigurd Karlsbakk r...@karlsbakk.net a écrit :

 Hi all

 We have a 100kVA GE LP Series UPS. I can't find this series in the HCL,
 but other GE UPSes are listed. Would it be possible to somehow use NUT with
 this UPS?

 --
 Vennlige hilsener / Best regards

 roy
 --
 Roy Sigurd Karlsbakk
 (+47) 98013356
 r...@karlsbakk.net
 http://blogg.karlsbakk.net/
 GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
 --
 I all pedagogikk er det essensielt at pensum presenteres intelligibelt.
 Det er et elementært imperativ for alle pedagoger å unngå eksessiv
 anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller
 eksisterer adekvate og relevante synonymer på norsk.

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

Re: [Nut-upsuser] manufactor listing

[Arnaud Quette]

2012/11/13 Marco Jackobs jack...@macle.de

 Hello,


Hello

first, please subscribe to the NUT users mailing for further discussions:
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

i have a question about http://www.networkupstools.org.

 The Grafenthal GmbH is manufacture of UPS Systems.
 Is it possible Grafenthal listing as a manufacture in the categorie for
 Uninterruptible Power Supply?

 Our Website:
 www.grafenthal.com


the procedure is to test your units with NUT and report success using the
following directions:
http://www.networkupstools.org/stable-hcl.html#footnotes

Best regards,
Arnaud Quette
-- 
Network UPS Tools (NUT) 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] bcmxcp_usb can not communicate with Eaton Powerware 5110

[Arnaud Quette]

2012/11/1 Jevgeni Jurtsenko jevgeni...@gmail.com

 Hello all,

  Sorry for delay. I've been away for a while. Back to testing. I've tried
 regular version 2.6.5-1 and patched. Main thing is that both versions work
 until I reboot the OS, after that starting the nut fails with messages
 below. To make it run again I've to re-plug the usb cable. Hard-resetting
 the ups doesn't help either. Considering the fact to remotely monitor the
 devices it is quite inconvenient. Suppose there is I power fault and ups is
 drained out of power then the system won't come back online after power is
 restored. I've tried searching for a working way to model the usb cable
 re-plug on OS level with no luck.  Any help would be appreciated.

 Linux raspberrypi 3.2.27+ #160 PREEMPT Mon Sep 17 23:18:42 BST 2012 armv6l
 GNU/Linux

 *Version 2.6.5-1*
 USB communication subdriver 0.21
0.00 debug level is '5'
0.008920 entering nutusb_open()
0.013091 device 004 opened successfully
0.015893 Can't claim POWERWARE USB interface: could not claim
 interface 0: Device or resource busy
0.018484 Can't reset POWERWARE USB endpoint: could not clear/halt
 ep 129: Device or resource busy
0.020807 device 004 opened successfully
0.021753 Can't claim POWERWARE USB interface: could not claim
 interface 0: Device or resource busy
0.022617 Can't reset POWERWARE USB endpoint: could not clear/halt
 ep 129: Device or resource busy
0.023750 device 004 opened successfully
0.024928 Can't claim POWERWARE USB interface: could not claim
 interface 0: Device or resource busy
0.026070 Can't reset POWERWARE USB endpoint: could not clear/halt
 ep 129: Device or resource busy
0.029099 device 004 opened successfully
0.029412 Can't claim POWERWARE USB interface: could not claim
 interface 0: Device or resource busy
0.029714 Can't reset POWERWARE USB endpoint: could not clear/halt
 ep 129: Device or resource busy
0.030193 send_to_all: SETINFO device.type ups
0.031387 send_to_all: SETINFO driver.version 2.6.4
0.031855 send_to_all: SETINFO driver.version.internal 0.26
0.032720 send_to_all: SETINFO driver.name bcmxcp_usb
0.033757 send_read_command: (4 bytes) = ab 01 31 23
0.034906 entering get_answer(31)
0.035409 get_answer: (0 bytes) =
0.036298 send_read_command: (4 bytes) = ab 01 31 23
0.039485 entering get_answer(31)
0.040038 get_answer: (0 bytes) =
0.040289 send_read_command: (4 bytes) = ab 01 31 23
0.041718 entering get_answer(31)
0.042514 get_answer: (0 bytes) =
0.043435 send_read_command: (4 bytes) = ab 01 31 23
0.045095 entering get_answer(31)
0.045885 get_answer: (0 bytes) =
0.046158 send_read_command: (4 bytes) = ab 01 31 23
0.050026 entering get_answer(31)
0.050552 get_answer: (0 bytes) =
0.050785 Communications with UPS lost: Error executing command
0.051043 Could not communicate with the ups: Device or resource busy
0.051271 CLOSING

 *Patched version*
 2.225863 = usb_interrupt_read -16
2.226680 = packet_loop (0, 0)
2.227534 = bytes_read (0)
2.227857 = usb_interrupt_read -16
2.228667 = packet_loop (0, 0)
2.229701 = bytes_read (0)
2.230028 = usb_interrupt_read -16
2.230809 = packet_loop (0, 0)
2.233160 = bytes_read (0)
2.234230 = usb_interrupt_read -16
2.234546 = packet_loop (0, 0)
2.234763 = bytes_read (0)
2.235573 = usb_interrupt_read -16
2.236373 = packet_loop (0, 0)
2.237285 = bytes_read (0)
2.237620 = usb_interrupt_read -16
2.238418 = packet_loop (0, 0)
2.239706 = bytes_read (0)


strange that a reboot causes this kind of issues!
is this stable (i.e, reproduced upon each reboot)?

I would need the following, after a reboot (i.e, reproducing the above
issue):
- lsusb -v -d0x0592:0x0002
- grep usb /var/log/syslog
- full trace, debug level 5, of the patched driver
- ps -efl | grep bcm

@Greg  Massimo: do you have the same behavior?

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] Tripp-Lite INTERNET525U

[Arnaud Quette]

2012/11/8 Kris Jordan nut...@sagebrushnetworks.com

 Arnaud Quette wrote, On 11/8/2012 2:34 PM:

 2012/11/8 Kris Jordan nut...@sagebrushnetworks.com mailto:nut.kj@**
 sagebrushnetworks.com nut...@sagebrushnetworks.com


 Kris Jordan wrote, On 10/25/2012 11:30 AM:

 I wouldn't mind learning a bit about the USB capture stuff. I have
 SniffUSB installed on a Windows XP VM. I think SniffUSB is the
 latest *free* Windows USB sniff program available, built on other
 people's work. Seems to work fine when I tested it with the 3S 550.

 So I can do some captures of the Tripp-Lite 550 if that setup will do.

 Otherwise, the WinXP virtualbox, linux usbmon + ?wireshark? setup
 will be some time later when I get a test machine setup with
 Centos6 or the current Fedora release.


 I've found wireshark to be a very convenient tool for capturing and
 analyzing USB frames too.
 (valid comment for our 3S discussion ;)
 I can't say for USB on Windows though, but iirc it produces similar
 results to the Linux one...


 An example is attached to my 3S 550 thread for the beeper.


sorry, I meant a wireshark USB snoop.
though the Sniff USB contains everything, it's processing will take me more
time than I can currently devote.
the wireshark one will have a chance to fit in...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] Tripp-Lite INTERNET525U

[Arnaud Quette]

2012/11/8 Kris Jordan nut...@sagebrushnetworks.com

 Kris Jordan wrote, On 10/25/2012 11:30 AM:

  Charles Lepple wrote, On 10/25/2012 4:18 AM:

 On Thu, Oct 25, 2012 at 2:47 AM, Kris Jordan
 nut...@sagebrushnetworks.com wrote:

 I assume some kind of USB debugging will need to be done? And can that
 be
 easily done (software-wise) on Windows 7 Pro x64?

 I don't have a convenient Linux test system at hand for the moment,
 though I
 do have a few VM's (assuming the extra layers don't get in the way).

 Unfortunately, it sounds like our usual suggestions for Windows tools
 won't work:

 http://libusb.6.n5.nabble.com/**Working-preferably-free-USB-**
 sniffer-for-Windows-7-x64-**td8754.htmlhttp://libusb.6.n5.nabble.com/Working-preferably-free-USB-sniffer-for-Windows-7-x64-td8754.html

 It is easiest to have Windows in a VM, and do the USB capture from a
 Linux host running the virtual machine manager (VirtualBox, VMWare,
 Qemu, etc.)


 I also have a Windows XP VM. So I could use the old Windows tools.


 I wouldn't mind learning a bit about the USB capture stuff. I have
 SniffUSB installed on a Windows XP VM. I think SniffUSB is the latest
 *free* Windows USB sniff program available, built on other people's work.
 Seems to work fine when I tested it with the 3S 550.

 So I can do some captures of the Tripp-Lite 550 if that setup will do.

 Otherwise, the WinXP virtualbox, linux usbmon + ?wireshark? setup will be
 some time later when I get a test machine setup with Centos6 or the current
 Fedora release.


I've found wireshark to be a very convenient tool for capturing and
analyzing USB frames too.
(valid comment for our 3S discussion ;)
I can't say for USB on Windows though, but iirc it produces similar results
to the Linux one...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] NUT v2.6.4 with HP AF401A won't start

[Arnaud Quette]

2012/10/31 Pratt Chris chris.pr...@comptel.com

  Hi Arnaud.

 **


Hi Chris,


 I think you’ve cracked it.  The following terminal output shows the
 package and also shows that when I start it from /usr/local/ups/bin it
 doesn’t crash.


nice, I've committed the patch to the trunk (NUT development version),
r3769:
http://trac.networkupstools.org/projects/nut/changeset/3769


 **

 [root@ups-monitor bin]# rpm -q nut

 nut-2.6.4-1.el6.x86_64

 [root@ups-monitor bin]# which upsdrvctl

 /sbin/upsdrvctl

 [root@ups-monitor bin]# pwd

 /usr/local/ups/bin

 [root@ups-monitor bin]# ./upsdrvctl start

 Network UPS Tools - UPS driver controller 2.6.5

 Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5)

 Detected HP R12000/3UPS on host 192.168.0.89 (mib: cpqpower 1.5)

 [UPS-HP01] snmp_ups_walk: data stale for ups.L1.realpower

 [UPS-HP01] snmp_ups_walk: data stale for ups.L2.realpower

 [UPS-HP01] snmp_ups_walk: data stale for ups.L3.realpower

 [root@ups-monitor bin]#

 ** **

 I’ve uninstalled the package and re-run make install just to be sure and
 it starts up fine with upsdrvctl start, with the following message in
 /var/log/messages.

 Oct 30 09:20:25 ups-monitor snmp-ups[32252]: Startup successful

 ** **

 Now it’s on to finishing the configuration and setting up the clients.


beware of 1 thing: the main difference with a source install, as you did
lastly, and a native package (RPM) is the system/shutdown integration.

the init.d / systemd script will look for binaries (upsd, drivers, ...), in
the known path, not /usr/local/ups/{bin,sbin}...

so you may want to keep your original rpm and overwrite snmp-ups with the
new one.
thus, uninstall first the current install and reconfigure using the
following:

./configure --program-prefix= --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info --with-all --with-nss
--with-libltdl --without-hal --with-cgi --datadir=/usr/share/nut
--with-user=nut --with-group=dialout --with-statepath=/var/run/nut
--with-pidpath=/var/run/nut --with-altpidpath=/var/run/nut
--sysconfdir=/etc/ups --with-cgipath=/var/www/nut-cgi-bin
--with-drvpath=/sbin --with-systemdsystemunitdir=/usr/lib/systemd/system
--disable-static --with-udev-dir=/lib/udev

the above is a trimmed version of the one provided by Michal Hlavinka.
but you may want or need to trim it a bit more...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] Unable to disable beeper on Powercom Imperial IMP-525AP

[Arnaud Quette]

2012/10/31 Sergey Talchuk tals1...@gmail.com

 Hi Arnaud,


Hi Sergey,

Unfortunately, I did not get an answer from the manufacturer's support.
 However, in the forum I got to know that the ability to disable the beeper
 had been added in 2010 only.
 http://forum.pcm.ru/viewtopic.php?f=4t=12642
 http://forum.pcm.ru/viewtopic.php?f=10t=10376

 So UPS devices which where built after 2010 should support this option.


thanks for sharing this info with us.
I assume yours was built before 2010.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] Eaton 3S550

[Arnaud Quette]

2012/10/25 Kris Jordan nut...@sagebrushnetworks.com

 Arnaud Quette wrote, On 10/24/2012 3:33 PM:



 I always test. Beeper still beeps while on-battery. Using Eaton's
 software, it can disable the alarm just fine. I re-enabled the
 alarm before I ran the above command. My previously attached logs
 included me running every command including upsc.


 quite frankly, I'm puzzled.
 I would need to test on an actual device... and currently, I can't!
 that would be worth, with the below (depending on your answer) to contact
 the official Eaton support.


 For being a problem just for NUT, it sounds like Eaton would not care
 much. I have no need to re-enable it once I got it disabled, so I'm fine.


the point is that there is a bug in NUT, and I dislike when I don't
understand.
I've tracked it, for later processing:
https://alioth.debian.org/tracker/index.php?func=detailaid=313884group_id=30602atid=411542


  The two values are linked, as long as you use a valid value for
 low or high, the other value will also change.

 But, there is one that doesn't work, a low value of 75.

 low-high:
 84-142 (red light)
 96-138 (both lights)
 75-144 (green light)

 upsrw -u admin -p password -s input.transfer.high=138 ups
 Result: 84-142 -- 96-138

 upsrw -u admin -p password -s input.transfer.low=75 ups
 Result: 96-138 -- 84-142

 upsrw -u admin -p password -s input.transfer.low=96 ups
 Result: 84-142 -- 96-138

 I've tested it a bunch of times, low=75 is the only one giving me
 troubles. The other way to get 75-144 is to use high=144, which
 works fine.


 strange! the trace shows no error, but the value is indeed not changed.
 and this works with the windows SW?


 Yes, and I  just doubled-checked to be sure. Perhaps it only sends the
 high value. So there might be a firmware bug for setting the low value.

I have my work-around and it's documented in my notes for this UPS. Unless
 Eaton changes their stance about NUT, it sounds like there is nothing worth
 contacting them about. However, I have told them about the sleep issue I
 was having since that happens no matter what.


it's good that you have a work-around, but I'll definitely want to fix that
one too.
this one is indirectly tracked through the above bug ticket.

Don't worry about the lag, and thank you for the hard work (and more)!


thanks.
for the sake of completion, part of the more, I'm also local councilor and
leaving in the mountain.
we just got our first snows of the year this week-end. 20 cm is not that
much, but already making an overhead of work...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] NUT 2.6.3, openSUSE 12.2 : UPS unit not switched off: Fixed

[Arnaud Quette]

Hi Roger,

note that I'm cc'ing Stanislav (maintainer of the NUT packages in Suse).
thanks for Kris Jordan for the support interim too ;)

2012/10/28 Roger Price ro...@rogerprice.org

 On Fri, 26 Oct 2012, Kris Jordan wrote:

 Did you install NUT from a package? Note, 2.6.5 is the current
 version and 2.6.4 had fixed a vulnerability.


 I'm using the nut 2.6.3 package included in the openSUSE 12.2 distribution.

  Check that your distribution's shutdown script is running 'upsdrvctl
 shutdown' in the presence of the killpower file
 (POWERDOWNFLAG).


 Summary: looks like an openSUSE bug, simple fix available.

 OpenSUSE 12.2 has a script /usr/sbin/rcupsd for starting and stopping the
 upsd service. This is a link to script /etc/init.d/upsd which contains:

 powerdown)
 ## Special command: Instruct UPS to shutdown.
 sync 
 if grep -q '^\[' $UPS_CONFIG ; then
 echo -n Instructing UPS to powerdown 
 $UPSDRVCTL_BIN shutdown /dev/null 21 || rc_failed
 rc_check
 else
 echo No local UPS defined, skipping powerdown 
 fi
 rc_status -v
 ;;
 try-powerdown)
 ## Special command: Instruct UPS to shutdown, if halt is running
 ## or variable UPSD_POWERDOWN_CONDITION is set and power is
 failing.
 ## Otherwise silently quit.
 ##
 if test $RUNLEVEL = 0 -o -n $UPSD_POWERDOWN_CONDITION ; then
 if test -n $POWERDOWNFLAG -a -f $POWERDOWNFLAG ; then
 exec $0 powerdown
 fi
 fi
 ;;

 where  UPSDRVCTL_BIN=/usr/lib/ups/**driver/upsdrvctl

 In addition, file /etc/sysconfig/shutdown contains the configuration
 parameter

   # Hook during system shutdown to run extra command
   HALT_POWERDOWN_INSERT=/etc/**init.d/upsd try-powerdown

 but when upsd try-powerdown is called it fails silently because $RUNLEVEL
 and $UPSD_POWERDOWN_CONDITION are empty.  upsd powerdown is never called.

 I changed the configuration parameter to 
 HALT_POWERDOWN_INSERT=/etc/**init.d/upsd
 powerdown, reran command SuSEconfig, and tried again but there was no
 change.  However typing the command /etc/init.d/upsd powerdown does shut
 down the UPS unit.

 OpenSUSE 12.2 has fully embraced systemctl and systemd: I tried grepping
 around in the /lib/systemd shutdown specifications, but I cannot find any
 reference to /etc/init.d/upsd powerdown.  This is beginning to look like a
 bug in openSUSE 12.2 which I will report in their forums.

 Here is a fix: There is a file /etc/init.d/halt.local which is currently
 empty:

  # /etc/init.d/halt.local
  # script with local commands to be executed from init on system shutdown
  # Here you should add things, that should happen directly before shuting
  # down.

 I added the lines

  # RP 2012-10-28 Turn off the UPS unit.
  # Needed for automatic system restart when wall power returns.
  UPSDRVCTL_BIN=/usr/lib/ups/**driver/upsdrvctl
  echo `date -I` `date +%T` $0 calls $UPSDRVCTL_BIN shutdown 
 /var/log/halt.local
  $UPSDRVCTL_BIN shutdown

 I pulled the plug from the wall and witnessed a server shutdown followed
 10 seconds later by a UPS shutdown.  Pushing the plug back into the wall
 got the system running again.


I just saw that you (Roger) had a parallel discussion on Suse forums,
possibly leading toward some systemd integration issue...

maybe Stan can shed some light on this.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] NUT v2.6.4 with HP AF401A won't start

[Arnaud Quette]

2012/10/29 Pratt Chris chris.pr...@comptel.com

  Hi Arnaud.

 **


Hi Chris,


 I’ve run the commands you suggested but it actually didn’t crash.  I let
 it run for about 10 minutes and it was obviously repeating the same
 messages so I broke it with Ctrl-C.

 ** **

 I’ve attached the terminal output (shortened to meet the file  size limit)
 and at the end it shows the message from trying to start it with upsdrvctl
 and the message in /var/log/messages.


just to be sure to understand since the end of the traces seems to be
melted:
- the driver doesn't crash when using /usr/local/ups/bin/snmp-ups -D ...
- the driver crashes when using upsdrvctl start

is upsdrvctl also located in /usr/local/bin or do you have another one
installed (RPM)?
could you please check using rpm -q nut?

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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-utalk ESV8+ comm problem

[Arnaud Quette]

2012/10/25 Martin Loyer mar...@martinloyer.fr

  Sorry guys,

 I'm leaving for 10 days tomorrow.

 I let you know on my way back.


no pb Martin.
I've created a patch
trackerhttps://alioth.debian.org/tracker/index.php?func=detailaid=313882group_id=30602atid=411544as
a reminder.

see you when you're back,
Arnaud
-- 
Network UPS Tools (NUT) 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-utalk ESV8+ comm problem

[Arnaud Quette]

2012/10/21 Ivo Karabojkov karaboj...@kit.bg

  Hi, Arnaud!


Hi Ivo,

As my ESV8+ woprks now I produced two debug outputs - before and after
 applying the patch.


both outputs shows that everything is fine, which is not fully satisfactory
to me.


 In the next few days I'll do my best to send outputs with Pulsar ES11 and
 EL.
 I remember with the original (non-patched) driver ES11  didn't work well
 and driver issued messages could not get multtiplier table, using raw
 readings.


I've seen your further post. the msg you mention is nothing but normal.
what is (was) not is the behavior your unit had previously, and the fact
that the driver was not recovering.
I suspect that it was in echo mode. i.e, the unit once only received a
single Z

the patch can only improve the situation, since it's back near to the
previous implementation (at least for the ZZ), and more complying to the
UTalk spec (WRT timing).

that said, I would still like to hear from Martin and his ESV8 (not a +).

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] NUT v2.6.4 with HP AF401A won't start

[Arnaud Quette]

2012/10/22 Pratt Chris chris.pr...@comptel.com

  Hi Arnaud.


Hi Chris

I’ve applied the patch but it still crashes.  I started from scratch and
 did the following:

 **


strange! at least, it runs (a few seconds) longer... hem.
this seems related to another issue here.

I would need a gdb backtrace to shed some light.
can you install gdb, if needed, and run as root:
$ gdb /path/to/snmp-ups

then enter snmp-ups params:
(gdb) run -D -a UPS-HP01

once snmp-ups crashes, type bt in gdb, i.e:
(gdb) bt

and send me back the output.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] Eaton 3S550

[Arnaud Quette]

2012/10/19 Kris Jordan nut...@sagebrushnetworks.com

 Arnaud Quette wrote, On 10/18/2012 11:39 AM:

  Hi Kris,

 as told in a separate mail on the list, I will there be acting as an
 individual, since Eaton current stance is to not allow me to support NUT
 users nor to do my NUT leader tasks on my working hours for a few weeks now!


 I must have missed that message.


it was in a separate user discussions:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2012-October/008011.html


 I saw something about the hosting change, but I saw no reason why.


because of the same kind of reasons mentioned in the above mail:
people tended to interpret Eaton logo presence as if Eaton was sponsoring
NUT, which was somehow true at some point in the past.
but that's not the case currently, and for some time now.
and this forces me to assume more and more things on my personal time. and
I can tell you that I've many other caps to assume.
which also explains the lag you see in my answers...

that's probably a bit egoist, but giving my *personal* credits to Eaton is
not something I want to do anymore!
and I can tell you that I've poured thousands of hours of my personal time
in this project, for the past decade, along with money...

Part of my reason to go Eaton was because of their support for Open Source
 and NUT (or at least I thought because they were hosting).


however, note that Eaton is still the only manufacturer supporting NUT!
but this support level has slowly been decreasing over the time, and is
limited to the windows port and few more things currently.

I'm still hoping that we're reaching the end of a night, and that the day
is coming after.
but I won't  be hoping for much more time...

that said, back to your issue


  the current Eaton support is limited to Frederic's work on the Windows
 port, and Vaclav integration works (clock_gettime and monotonic).

 2012/10/13 Kris Jordan nut...@sagebrushnetworks.com mailto:nut.kj@**
 sagebrushnetworks.com nut...@sagebrushnetworks.com


 Kris Jordan wrote, On 10/10/2012 11:00 PM:

 Windows 7 Pro x64

 Eaton 3S550 (brand new, battery mfg 8/15/2012)
 NUT 2.6.5-3


 Pretty much done testing this UPS on Windows. I couldn't disable
 the beeper using NUT, and even after doing so successfully with
 the Solution-Pac, it still says enabled (in NUT). Though I thank
 Eaton for not using an obnoxious (loud) beeper.


 is it actually enabled? i.e, when unplugging the power cord, does it beep
 or not?
 I would like to see a driver debug trace (level 5) when calling 'upscmd
 ... beeper.off'.


 upscmd -u admin -p password ups beeper.off

 I always test. Beeper still beeps while on-battery. Using Eaton's
 software, it can disable the alarm just fine. I re-enabled the alarm before
 I ran the above command. My previously attached logs included me running
 every command including upsc.


quite frankly, I'm puzzled.
I would need to test on an actual device... and currently, I can't!
that would be worth, with the below (depending on your answer) to contact
the official Eaton support.




 I also get ERR VAR-NOT-SUPPORTED for input.transfer.low/high. This
 is perhaps normal because of the way this UPS sets the value in a
 combined fashion. I did not log this happening. If wanted, I can
 test it more.


 strange, the trace clearly state the variable publication.
 so, yes, I'm interested in both the exact command used (copy/paste) + the
 driver trace excerpt around the upsrw call (grep for 'setvar')


 For whatever reason, I no longer get the ERR message, maybe I kept
 mistyping something.


quite probably


 The two values are linked, as long as you use a valid value for low or
 high, the other value will also change.

But, there is one that doesn't work, a low value of 75.

 low-high:
 84-142 (red light)
 96-138 (both lights)
 75-144 (green light)

 upsrw -u admin -p password -s input.transfer.high=138 ups
 Result: 84-142 -- 96-138

 upsrw -u admin -p password -s input.transfer.low=75 ups
 Result: 96-138 -- 84-142

 upsrw -u admin -p password -s input.transfer.low=96 ups
 Result: 84-142 -- 96-138

 I've tested it a bunch of times, low=75 is the only one giving me
 troubles. The other way to get 75-144 is to use high=144, which works fine.


strange! the trace shows no error, but the value is indeed not changed.
and this works with the windows SW?

the code for input.transfer.* is still a pass-through: NUT only send the
value to the device, without any specific processing or enforcement
(conversely to output.voltage.nominal for example). this is still part of
Eaton TODO list...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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

Re: [Nut-upsuser] mge-utalk ESV8+ comm problem

[Arnaud Quette]

2012/10/19 Ivo Karabojkov karaboj...@kit.bg

  Hi!


Hi Ivo,


 Here is my Debug (-) output of mge-utalk during the malfunction. Do
 you want to capture new one (when it works)?


I would prefer to see the output with the patch I sent.
to apply it, go into the NUT source dir. and:
$ patch -p0  utalk-zz500ms.diff

then make and test as usual.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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-utalk ESV8+ comm problem

[Arnaud Quette]

2012/10/18 Ivo Karabojkov karaboj...@kit.bg

  Hi!


Hi Ivo

Sorry for being away for the last week and thank you all for your time and
 patience!
 Today I tried to collect newer log file than one attached in my first post.
 I used the same HDD with no modifications of config or OS, on the same
 computer with the same interface cable (original MGE, not hand-made). The
 computer is real - not VM to avoid eventual malfunction caused by virtual
 access to RS232 ports.
 It was very odd that the connection to the UPS suddenly started working! I
 am able to read status and perform tests including fsd with 100 % success!
 Before my first try I had UPS repaired. The inverter transistors had to be
 resoldered. This does not impact communication circuits, at least not
 directly.
 The difference today was that since I was away and the device was freshly
 repaired I disconnected its acumulators to avoid eventual damages. Maybe
 this hard reset helped to the UPS controller to start comunicating
 normally? But it worked with Eaton's Windows software!
 I'll test it for at least a week before attaching it to my production
 system. Non-reasonal function or malfunction is really disturbing.
 The unit is old but it is from this low-efficiency generation that
 produces very good sine waveform and does not wear its electronic
 components (ex. capaciotrs) It surely has lead in its soldering compounds
 and is not CFC-free (during production). The large and half-empty heavy
 metal enclosure is also important for unit's reliability. In fact the only
 reason to throw it out would be it's denial to work with NUT on one of my
 FreeBSD servers.

 I would be very glad if I can help testing the driver (and if you still
 willing to).
 I have also access for testing to MGE Pulsar ES 11+ and an EL (i'll
 clarify the exact model tomorrow).
 Both are working without software support. I can test them with NUT.

 Sorry for (maybe) false allarm.


not a false alarm at all, since you had an actual issue!

I'll follow-up in my answer to Martin.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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-utalk ESV8+ comm problem

[Arnaud Quette]

2012/10/19 Martin Loyer mar...@martinloyer.fr

 **

 Dear all,



  Ivo, we really need your implication to solve *your* issue!

  I have an old ESV8 UPS down here, and I did code patching years ago to
 support old model on nut.

 is your ESV8 still working?

  For sure :)
 This UPS is strong! By now, it is 18 years old :O


 made to last until the end of time ;)
 ah, good ol' MGE time.

  But, I got some bad effect, like Debian bug you mentionned on your
 email.

 Would be difficult for me to gain access to an ESV8+, but we can work
 together to test.

 even to me. all this goes back to MGE time, now defunct for 5 years.
 the only things that survived is the Comet and E Series DX (see below)

  I may have access to an old ESV8+. I gave one to a friend of mine, years
 ago.


 that would be nice


  I can make some test, but I need more information. Could you send me
 your
 debug log?

 I think I've found a Comet and a E Series DX (so speaking UTalk) at
 Eaton today.
 this is the kind of things that becomes rare nowadays!

 on the patch side, I'd also like to:
 - add some more inter-char delay, since mge_command() only has 100 ms.
 I've just checked again Utalk spec [1], and we should be at least 500
 ms between commands.
 the point here is that this inter-char delay is not satisfied with
 commands that do not receive an answer (such as Z)

  Interesting. If we are hearing too fast, it's not that good.


 we're *talking* too fast actually ;)


  You're right ! ... I talked to fast ;)


  For specific commands (such as Z), we may just wait and ignore any
 answers (as we did by the past).


 not sure to get your point!? we still ignore the result of mge_command(...
 Z)

  Fore sure :D


 - see the result of Marek's mention, i.e moving the double Z before the
 Si test.

  For sure. I dig on my archives, and found a serial spy log taken on
 Windows between PSP and ESV8.
 Z is send twice, then AX 1, then SI 1.


 yep, with 500 ms inter-commands... I still have access to that code ;)

 By the way, I worked a lot to make support of programmable outlets. By
 now, it is not supported (even for recent UPS, working on usb-hid). I may
 test and patch.

 @Ivo: could you send me your log file?


 @Martin: how do you want to proceed on the UTalk issue?
 I can either provide a (set of) patch(es), or few directions...

 Let's wait Ivo's answer and log files.

I don't think it's necessary.
Ivo mentioned that the situation self unblocked (maybe related to the hard
reset), and most of all that it works on Windows with Eaton SW...

my feeling is that moving the ZZ before the Si test, and forcing an
inter-command delay of 500 ms should do it here.
I've attached a patch. use -p0 from the nut top source dir...

 Then, I'll try to fix it. Then we test it, and validate on severals UPS.
 If OK, I'let you publish patch Arnaud.

 If I have some time, I can work on programmable outlet, with limited
 support to onboard one (no external outlet plugged in daisy chain).

could be nice.
it would also be a good time to it now, since Ivo may also test it on his
units.
I'll check on my side if I can bootstrap a base code...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr


utalk-zz500ms.diff
Description: Binary data
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Blazer_usb Permissions problem: Input/output error

[Arnaud Quette]

Hi Paul,

as told privately, I will there be acting as an individual, since Eaton
current stance is to not allow me to support NUT users nor to do my NUT
leader tasks on my working hours for a few weeks now!

the current Eaton support is limited to Frederic's work on the Windows
port, and Vaclav integration works (clock_gettime and monotonic).

2012/10/15 Paul Barber p...@barbz.com.au

  On 11/10/2012 2:46 PM, Paul Barber wrote:

 Arnaud Quette aquette.dev at gmail.com writes:


  Hi Paul
 2012/8/19 Paul Barber p at barbz.com.au
 Hi all,
 I have an eaton ENV800HA connected for a freebsd 9.0 box with nut 2.6.5

  installed (on the supported list).

  The UPS is connected using the Blazer_USB driver (not sure how to check its

  version).

  When I kick off upsd it detects the UPS no problems and I get all my

  information:

  battery.charge: 100battery.voltage: 13.60battery.voltage.high:

  13.00battery.voltage.low: 10.40battery.voltage.nominal: 12.0device.type: 
 upsdriver.name: blazer_usbdriver.parameter.pollinterval: 
 2driver.parameter.port:
 /dev/ugen1.5driver.version: 2.6.5-Unversioned 
 directorydriver.version.internal:
 0.09input.current.nominal: 3.0input.frequency: 50.2input.frequency.nominal:
 50input.voltage: 245.0input.voltage.fault: 244.5input.voltage.nominal:
 240output.voltage: 245.0ups.beeper.status: enabledups.delay.shutdown:
 30ups.delay.start: 180ups.load: 4ups.productid: 5161ups.status:
 OLups.temperature: 25.0ups.type: offline / line interactiveups.vendorid: 0665

  However after a random amount of time I get the following error:
 blazer_usb[4466]: Permissions problem: Input/output error

 Followed by:
 upsd[4468]: Can't connect to UPS [EatonUPS] (blazer_usb-EatonUPS): No such

  file or directoryupsmon[4566]: Poll UPS [EatonUPS at localhost] failed -
 Driver not connectedupsmon[4566]: Communications with UPS EatonUPS at
 localhost lostupssched-cmd: Communications with the UPS EatonUPS at 
 localhost
 are lostupsmon[4566]: Poll UPS [EatonUPS at localhost] failed - Driver not
 connected

  Ive tried the basics and chmod 777'd the ugen1.5 port (not a problem it if

  works for a while) but worth a shot.

  After doing some reading on here I ran /usr/local/libexec/nut/./blazer_usb -u

  root -DDD -a EatonUPS which on its first run worked for 72 seconds, but 330
 seconds on the second run before ending with:

  327.930857   send: Q1 328.193486   read: (247.0 247.0 247.0 004 50.0 13.6 
 25.0

  1001 329.940841   send: Q1 330.177471   read: (247.0 247.0 247.0 004 50.0
 13.6 25.0 1001 331.950574   send: Q1 332.193457   read: (247.0 247.0 247.0
 004 50.0 13.6 25.0 1001 338.860148   send: Unknown error 338.860204
  Permissions problem: Input/output error

  Ive also found the following message in the log when I start upsd:
 root: Unknown USB device: vendor 0x0665 product 0x5161 bus uhub2



 is this msg different from the one when you initially plug your UPS USB cord?


  Any ideas where to go from here?


 good question!blazer_usb will reconnect upon certain error, like your IO

  one.but the thing is that device permissions must allow that.

  Ie, on Linux, udev is in charge of setting the permissions for NUT on all

  known devices.thus, upon any kind of disconnection/reconnection, NUT will be
 able to establish again the communication.you should dig around
 this...cheers,Arnaud-- Linux / Unix / Opensource Engineering Expert - Eaton - 
 http://opensource.eaton.comNetwork UPS Tools (NUT) Project Leader - 
 http://www.networkupstools.org

  Debian Developer - http://www.debian.orgFree Software Developer -

  http://arnaud.quette.fr

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

  Had a bit more of a play with this and still couldn't make it work.

 Ive tried this now also on openindiana with the latest nut - same issue works
 for 5 minutes then drops out with stale data errors (at the same time as the
 permission errors in BSD).

 Ive played with the polling times out to 30 seconds and this hasn't made a
 difference.

 Also when it does go to stale data it wont also detect again (I had the same
 problems on free bsd)

 For example:
 paul@indy:/opt/nut/bin# ./blazer_usb -u root -DDD -a trust
 Network UPS Tools - Megatec/Q1 protocol USB driver 0.09 (2.6.5)
0.00 debug level is '3'
0.093158 Checking device (0665/5161) (/dev/usb/665.5161/0)
0.100375 - VendorID: 0665
0.100413 - ProductID: 5161
0.100433 - Manufacturer: INNO TECH
0.100455 - Product: USB to Serial
0.100475 - Serial Number: 20100826
0.100493 - Bus: /dev/usb
0.100513 Trying to match device
0.100533 Device matches
0.100601 Trying megatec protocol...
0.101337 send: Q1
0.351941 read: (248.5 248.5 248.5 003 50.0 13.6 25.0 1001
0.352107 Status read in 1 tries
0.352139

Re: [Nut-upsuser] Eaton 3S550

[Arnaud Quette]

Hi Kris,

as told in a separate mail on the list, I will there be acting as an
individual, since Eaton current stance is to not allow me to support NUT
users nor to do my NUT leader tasks on my working hours for a few weeks now!

the current Eaton support is limited to Frederic's work on the Windows
port, and Vaclav integration works (clock_gettime and monotonic).

2012/10/13 Kris Jordan nut...@sagebrushnetworks.com

 Kris Jordan wrote, On 10/10/2012 11:00 PM:

 Windows 7 Pro x64

 Eaton 3S550 (brand new, battery mfg 8/15/2012)
 NUT 2.6.5-3


 Pretty much done testing this UPS on Windows. I couldn't disable the
 beeper using NUT, and even after doing so successfully with the
 Solution-Pac, it still says enabled (in NUT). Though I thank Eaton for not
 using an obnoxious (loud) beeper.


is it actually enabled? i.e, when unplugging the power cord, does it beep
or not?
I would like to see a driver debug trace (level 5) when calling 'upscmd ...
beeper.off'.

I also get ERR VAR-NOT-SUPPORTED for input.transfer.low/high. This is
 perhaps normal because of the way this UPS sets the value in a combined
 fashion. I did not log this happening. If wanted, I can test it more.


strange, the trace clearly state the variable publication.
so, yes, I'm interested in both the exact command used (copy/paste) + the
driver trace excerpt around the upsrw call (grep for 'setvar')

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] SNMP UPS: NETYS RT 1/1 UPS

[Arnaud Quette]

2012/10/15 Ing. Ján jan.ond...@upjs.sk

 Hello,


Hi

thanks for reply. We tested shutdown, but UPS's initial battery capacity is
 0%, after power loss, battery started to charge, capacity is increasing.
 When NUT shuts down my server? When UPS is over 95% of it's capacity? :-)


I'm not sure to completely understand the use case and issue!
could you please elaborate?


 I have also an NetVision-5.01-5.0x-unix.mib file, which doesn't help too.


was it provided with the unit?
could you please send the MIB file, provided with your device, in
compressed form.

a quick search on the net led me to the Delta MIB:
http://www.snmplink.org/cgi-bin/nd/m/Ent/D/Delta%20Electronics%20Group/%5BE.%5D%20Delta%20Electronics,%20Inc.%20-%202254/*25Old3/UPSv4.mib

 When trying to force netvision driver to snmp-ups command, it fails with:


this is a different 'netvision', for Socomec units.


 [root@kvm1 ~]# snmp-ups -a local -x mibs=netvision -D
 Network UPS Tools - Generic SNMP UPS driver 0.66 (2.6.4)
0.00 debug level is '5'
0.000380 SNMP UPS driver : entering upsdrv_initups()
0.000396 SNMP UPS driver : entering nut_snmp_init(snmp-ups)
0.051354 SNMP UPS driver : entering load_mib2nut(netvision)
0.051374 load_mib2nut: trying classic method with 'netvision' mib
0.051383 Entering nut_snmp_get_str()
0.051390 nut_snmp_get(.1.3.6.1.4.1.4555.1.1.1.1.1.1.0)
0.059889 [local] unhandled ASN 0x5 received from
 .1.3.6.1.4.1.4555.1.1.1.1.1.1.0
0.059933 Unknown mibs value: netvision

 I also tested an older version of SNMP interface for this UPS, but looks
 like there are communication problems between UPS and older SNMP interface.
 With this new one I can see actual values over web interface, but not using
 snmp-ups driver.


there is no need to do so.
while your UPS also provide data using a proprietary MIB, it also support
(partially) the IETF MIB, as seen in your first mail.
your unit seems well detected and supported, minus a few things.

your battery.charge is indeed 0 %, but the OID serving it is there, so we
have no way to determine that it's buggy.
on the UPS shutdown, everything is explained here:
http://www.networkupstools.org/docs/user-manual.chunked/ar01s06.html#UPS_shutdown

the conclusion is that, as told by Gregor, your unit should not have any
issue with the shutdown.
but it's true that the support of your unit with the IETF MIB is not fully
optimal.
a better support could come from the proprietary MIB, but I've personally
no time to devote to this currently.
that said, the task is not that hard, even for a non-programmer.
if you to have a run, let me know.
otherwise, drop the following output (in compressed form) on the list, for
potential future processing:
$ snmpwalk -v1 -c XXX 192.168.14.10 .1.3.6.1.4.1.2254.2.4
$ snmpwalk -Os -v1 -c XXX 192.168.14.10 .1.3.6.1.4.1.2254.2.4

the latter will requires the MIB file to actually display the OID string
name.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr


SAL

 On Mon, Oct 15, 2012 at 07:27:30AM +, Friedrich, Gregor wrote:
  Hello
 
  I have the same problem. There are 2  MIBs shipped with the  ups
 (attached). I copied these in /usr/share/netsnmp/mibs folder , but no
 results.
  The general UPS-status (OL...) is supported...  automatic shutdown is
 working in my test system.
 
  Regards Gregor
 
  
   Hello,
  
 I have an NETYS RT 1/1 UPS, which is not fully supported. Starting
 snmp
   driver displays:
  
   [root@kvm1 ~]# snmp-ups -a local
   Network UPS Tools - Generic SNMP UPS driver 0.66 (2.6.4)
   Duplicate driver instance detected! Terminating other driver!
   No matching MIB found for sysOID '.1.3.6.1.4.1.2254.2.4'!
   Please report it to NUT developers, with an 'upsc' output for your
 device.
   Going back to the classic MIB detection method.
   Detected NETYS RT 1/1 UPS on host 192.168.14.10 (mib: ietf 1.4)
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.2.3.0
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.2.6.0
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.3.3.1.4.1
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.3.3.1.5.1
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.4.4.1.4.1
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.5.3.1.3.1
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.5.3.1.4.1
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.5.3.1.5.1
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.6.3.8
   [local] unhandled ASN 0x6 received from 1.3.6.1.2.1.33.1.7.1.0
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.9.6.0
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.9.7.0
   [local] unhandled ASN 0x5 received from 1.3.6.1.2.1.33.1.9.9.0
   [local] unhandled ASN 0x5 received 

Re: [Nut-upsuser] mge-utalk ESV8+ comm problem

[Arnaud Quette]

2012/10/16 Martin Loyer

 Salut Arnaud :D


salut Martin !!
спасение Ivo

Ivo, we really need your implication to solve *your* issue!


  I have an old ESV8 UPS down here, and I did code patching years ago to
 support old model on nut.

 is your ESV8 still working?

 For sure :)
 This UPS is strong! By now, it is 18 years old :O


made to last until the end of time ;)
ah, good ol' MGE time.


  But, I got some bad effect, like Debian bug you mentionned on your email.

 Would be difficult for me to gain access to an ESV8+, but we can work
 together to test.

 even to me. all this goes back to MGE time, now defunct for 5 years.
 the only things that survived is the Comet and E Series DX (see below)

 I may have access to an old ESV8+. I gave one to a friend of mine, years
 ago.


that would be nice



  I can make some test, but I need more information. Could you send me your
 debug log?

 I think I've found a Comet and a E Series DX (so speaking UTalk) at Eaton
 today.
 this is the kind of things that becomes rare nowadays!

 on the patch side, I'd also like to:
 - add some more inter-char delay, since mge_command() only has 100 ms.
 I've just checked again Utalk spec [1], and we should be at least 500
 ms between commands.
 the point here is that this inter-char delay is not satisfied with
 commands that do not receive an answer (such as Z)

 Interesting. If we are hearing too fast, it's not that good.


we're *talking* too fast actually ;)


 For specific commands (such as Z), we may just wait and ignore any answers
 (as we did by the past).


not sure to get your point!? we still ignore the result of mge_command(...
Z)



  - see the result of Marek's mention, i.e moving the double Z before the
 Si test.

 For sure. I dig on my archives, and found a serial spy log taken on
 Windows between PSP and ESV8.
 Z is send twice, then AX 1, then SI 1.


yep, with 500 ms inter-commands... I still have access to that code ;)


 By the way, I worked a lot to make support of programmable outlets. By
 now, it is not supported (even for recent UPS, working on usb-hid). I may
 test and patch.

 @Ivo: could you send me your log file?


@Martin: how do you want to proceed on the UTalk issue?
I can either provide a (set of) patch(es), or few directions...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] NUT v2.6.4 with HP AF401A won't start

[Arnaud Quette]

2012/10/17 Pratt Chris chris.pr...@comptel.com

 Hi Arnaud.


Hi Chris,

first, please keep the traffic on the list, since other people may be
interested in the topic.


 Unfortunately I'm not primarily a developer  (I manage a room full of
 servers) so I don't have the normal array of development tools.  I built
 NUT from the downloaded tarball following the instructions in the
 Installation Guide so If patching means simply amending files I can do that
 and then rebuild and test it, if you let me know what changes need to be
 made.


it's exactly that, not harder.

the patch is attached. please beware that if I've not committed it to the
NUT code repository, it's because of a lack of testing!
so even if my confidence level is good, not all my green lights are lit.

to apply the patch, go into the NUT source directory and use:
$ patch -p0  /path/to/snmp-ups-0outlet.diff

note that it applies fine on 2.6.5.
then just make  make install as previously

I'm interested in a driver debug trace, using:
$ /path/to/snmp-ups -D -a UPS-HP01

If the driver doesn't crash, just Ctrl+C after a couple of minutes.
in all cases, send back the trace in compressed form please.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr


snmp-ups-0outlet.diff
Description: Binary data
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Setting up Apollo Line Interactive UPS on Ubuntu

[Arnaud Quette]

2012/10/18 Mike Raath raa...@gmail.com

 Hi


Hi Mike,


 Having followed this guide:
 http://blog.shadypixel.com/monitoring-a-ups-with-nut-on-debian-or-ubuntu-linux/and
  seeing support for Apollo UPSes mentioned on the compatibility list
 (genericups, type=4) I tried to set up Nut as follows.

 OS: Ubuntu Server 12.04
 Nut: 2.6.3 (I believe - from Ubuntu repos)

 ups.conf:

 [apollo]
 driver = genericups
 upstype = 4
 port = /dev/ttyUSB0


 Problem is that there is no ttyUSB0 device. UPS attaches to machine via
 USB cable, and lsusb indicates that it is a Cypress Semiconductor USB to
 Serial cable.

 $ lsusb
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 004 Device 002: ID 0665:5161 Cypress Semiconductor USB to Serial


try using this in ups.conf:
[apollo]
driver = blazer_usb
port = auto

start the driver using:
$ /lib/nut/blazer_usb -u root -D -a apollo

let the driver run for a couple of minutes, then Ctrl+C, and send back the
output in compressed form.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] Setting up Apollo Line Interactive UPS on Ubuntu

[Arnaud Quette]

2012/10/18 Mike Raath raa...@gmail.com

 Hope I let it run for long enough - compressed output attached.


congrats, you have a working unit.
you can proceed to normal ops, i.e start using 'service nut-server start 
service nut-client start'...

please report back the exact device name, along with the results of the
shutdown testing:
http://www.networkupstools.org/stable-hcl.html#footnotes

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] Setting up Apollo Line Interactive UPS on Ubuntu

[Arnaud Quette]

2012/10/18 Mike Raath raa...@gmail.com

 I did a sudo upsdrvctl start and it appeared to have worked - thank you
 very much!

 However the service commands you mentioned don't appear to be part of the
 nut package:

 $ service nut-server start  service nut-client start
 nut-server: unrecognized service


I was pretty sure I already did the split in this version.
'service nut start' will do it


 I'll post back the reports as requested. Congratulations on this project
 and thanks for helping out so quickly!


I will wait for your report, including the exact device name (I'm
insisting...) to commit an entry in the HCL.

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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] NUT v2.6.4 with HP AF401A won't start

[Arnaud Quette]

2012/10/16 Pratt Chris chris.pr...@comptel.com:
 Hi.

Hi Chris,

  I’m trying to configure NUT to manage a HP R12000/3 3-phase UPS fitted with
 an AF401A management module but it immediately crashes with a segmentation
 fault.

right, we have recently identified a regression WRT outlet handling.
I have a stagging patch for ~2 months, but still no time to test and
complete it.

Would you be able to patch, compile and test on your side?

Best regards,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr

  O/S is CentOS 6.3 64-bit

 NUT built from tarball

 AF401A Firmware version  2.1.3

  Extract from /etc/ups/ups.conf

 [UPS-HP01]

 driver = snmp-ups

 port = 192.168.0.89

 desc =  HP R12000/3 UPS



 Output from starting the driver

 [root@ups-monitor log]# upsdrvctl start

 Network UPS Tools - UPS driver controller 2.6.4

 Network UPS Tools - Generic SNMP UPS driver 0.66 (2.6.4)

 kill: No such process

 Detected HP R12000/3UPS on host 192.168.0.89 (mib: cpqpower 1.5)

 Driver exited abnormally

 [root@ups-monitor log]#



 Extract from /var/log/messages

 Oct 15 15:02:32 ups-monitor kernel: snmp-ups[16840]: segfault at 0 ip
 00354707a98c sp 7fff11f2a8b8 error 4 in
 libc-2.12.so[354700+189000]

 Debug output attached.

 I’ve downloaded the latest mib file (v1.64) from HP’s website but I can’t
 find any way to add it to the source files.  I’ve seen references to the
 mib2nut mapping but, again, no help on how to achieve this.



 Thanks,







 Chris Pratt

 Development Infrastructure Manager

 Comptel Corporation

 69 Suttons Business Park, Sutton Park Avenue, Reading, RG6 1AZ, UK

 T: +44 118 929 4176 | M: +44 7979 854 307 | F: +44 118 929 4001

 chris.pr...@comptel.com

 www.comptel.com






 
 Disclaimer: This message and any attachments thereto are intended solely for
 the addressed recipient(s) and may contain confidential information.
 If you are not the intended recipient, please notify the sender by reply
 e-mail and delete the e-mail (including any attachments thereto) without
 producing, distributing or retaining any copies thereof. Any review,
 dissemination or other use of, or taking of any action in reliance upon,
 this information by persons or entities other than the intended recipient(s)
 is prohibited.
 Thank you.

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

___
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-utalk ESV8+ comm problem

[Arnaud Quette]

2012/10/15 Martin Loyer mar...@martinloyer.fr:
 Dear all,

salut Martin !

happy to see you're still around too ;)

 I have an old ESV8 UPS down here, and I did code patching years ago to
 support old model on nut.

is your ESV8 still working?

 But, I got some bad effect, like Debian bug you mentionned on your email.

 Would be difficult for me to gain access to an ESV8+, but we can work
 together to test.

even to me. all this goes back to MGE time, now defunct for 5 years.
the only things that survived is the Comet and E Series DX (see below)

 I can make some test, but I need more information. Could you send me your
 debug log?

I think I've found a Comet and a E Series DX (so speaking UTalk) at Eaton today.
this is the kind of things that becomes rare nowadays!

on the patch side, I'd also like to:
- add some more inter-char delay, since mge_command() only has 100 ms.
I've just checked again Utalk spec [1], and we should be at least 500
ms between commands.
the point here is that this inter-char delay is not satisfied with
commands that do not receive an answer (such as Z)
- see the result of Marek's mention, i.e moving the double Z before the Si test.

@Ivo: my question still stands: would you be able to test patches and
send me back outputs?

cheers,
Arno
--
[1] http://old.networkupstools.org/protocols/mge/9261zwfa.pdf § 6.1.
Timings (last page)
--
new blog - 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