Re: [Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible

[Arnaud Quette via Nut-upsuser]

Le ven. 20 août 2021 à 17:38, Roger Price  a écrit :

> On Fri, 20 Aug 2021, Jim Klimov via Nut-upsuser wrote:
>
> > It is a bit unclear what "or otherwise and Combined date and time
> > representations" means. An example of ISO 8601 date representation (one
> of
> > many offered by the standard) "or otherwise"? Which combined date and
> time
> > would we take - e.g. MMDDTHHMMSSZ (literal T separator and Z for
> "zulu"
> > UTC timezone)? Or with dashes and colons? Or...?
>
> Since we are concerned only with dates, and not time of day, things are a
> little
> simpler.  We follow ISO 8601 clause 5.2.1 Calendar dates, and we don't
> have to
> worry about timezones.  The only real choice is between the format
> MMDD and
> -MM-DD.  Since our dates are intended primarily for humans it seems
> better
> to use the format -MM-DD which has better readability.  It's always
> possible
> to extract the MMDD number if this is eventually needed.
>
> Roger
>
> See also RFC 3339 "Date and Time on the Internet: Timestamps"


 Hi guys,

sorry, I completely missed your mail answers, and only focused on the PR
comments.
So thanks for your feedback.

My original intent was only focused on the battery.date{,.maintenance}.
However, I thought to myself that it could be broadened to all .date
(including ups*).
As mentioned, it's an option. Opaque string format still applies, and *if
possible*, ISO 8601 Calendar date should be used.
As for the time, I'm still in between:
for the base date variables, it's only date without time. There is even a
ups.time to track the device clock.
So even if I amended the PR to include a variation of T, I can
revert it if you prefer.

Thanks and cheers,
Arno
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible

[Arnaud Quette via Nut-upsuser]

Hi all,

I've made a pull request in that sense:
https://github.com/networkupstools/nut/pull/1076

I'll follow-up with applying to some drivers and propose more PRs.

As usual, comments and feedback welcome.

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

Re: [Nut-upsuser] RFC - new proposed variables and clarifications for the battery collection in NUT namespace

[Arnaud Quette via Nut-upsuser]

Le lun. 2 août 2021 à 15:16, Arnaud Quette  a
écrit :

> Hi there,
>
> as discussed on the below Github PRs, I've recently proposed some
> additional variables to deal with battery information in general, and some
> Li-Ion specifics:
>
> * PR https://github.com/networkupstools/nut/pull/1060/files
> ** Add "battery.packs.external": Number of external battery packs
>
> * PR https://github.com/networkupstools/nut/pull/1062/files
> ** Add "battery.voltage.cell.max": Maximum battery voltage seen of the
> Li-ion cell (V)
> ** Add "battery.voltage.cell.min": Minimum battery voltage seen of the
> Li-ion cell (V)
> ** Add "battery.capacity.nominal": Nominal battery capacity (Ah)
> ** Add "battery.status": Health status of the battery (opaque string)
> ** Add "battery.temperature.cell.max": Maximum battery temperature seen of
> the Li-ion cell (degrees C)
> ** Add "battery.temperature.cell.min": Minimum battery temperature seen of
> the Li-ion cell (degrees C)
>
> * PR https://github.com/networkupstools/nut/pull/1063/files
> ** Clarify "battery.date": Battery installation or last change date
> (opaque string)
> ** Add "battery.date.maintenance": Battery next change or maintenance date
> (opaque string)
>
> As usual with RFC for new variables, feedback and comments are warmly
> welcome.
>
> Thanks and cheers
> Arno
>

Hi NUT users,

following a 10 days period after my above announcement, I've considered the
absence of feedback and comments as an implicit approval.
I've hence merged the above PRs, which results in the update of the NUT
variables names and instant commands update:
https://github.com/networkupstools/nut/blob/6d30b8cd190b25cafdbc46f8dc4602fb68692270/docs/nut-names.txt

A special thanks to Roger Price for his support in this updated process!

Thanks and cheers,
Arno
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] [networkupstools/nut] RFC: clarify and complete battery dates (#1063)

[Arnaud Quette via Nut-upsuser]

Le mer. 11 août 2021 à 16:23, Roger Price  a écrit :

> On Wed, 11 Aug 2021, Arnaud Quette wrote:
>
> > Le lun. 9 août 2021 à 15:06, Roger Price  a
> écrit :
> >   If nobody has objected after a week, then I suggest
> >
> > 1) Go ahead with the proposed additions
> > 2) Give us a link to the new docs/nut-names.txt
> >
> > Hi Roger,
> > thanks for your answer!
> >
> > I may be misreading your answer, or misunderstanding the new process, so
> please bear with me.
> > on 1) though I still have the power to merge PRs, I don't consider that
> I'm the right person now to merge these:
> > * PR https://github.com/networkupstools/nut/pull/1060/files
> > * PR https://github.com/networkupstools/nut/pull/1062/files
> > * PR https://github.com/networkupstools/nut/pull/1063/files
> > @Charles Lepple and @Jim Klimov esp. your feedback is welcome
> >
> > on 2) the resulting new docs/nut-names.txt will the the one in git
> master branch, once the above PRs are merged.
> >
> > If agreed, I can proceed with merging these PRs, and link back the
> docs/nut-names.txt in the git master branch.
>
> Bonjour Arnaud, Sorry, I should have been clearer.  The proposed RFC does
> not
> require any modification whatsoever to the NUT development process.
> Nothing
> changes.  Whatever you did before, you go on doing.  However an additional
> effect is that one of the files in the docs directory, nut-names.txt, is a
> Recording Document, and when the development activity changes this file,
> it also
> updates the RFC.
>
> It seems to me that RFCs by their nature are public and changes should be
> publicly documented.  A mailing list announcement is fine.  When I said
>
> > 2) Give us a link to the new docs/nut-names.txt
>
> my idea was that a list reader would be told where the new version could
> be
> seen.  But please do this in whatever way is most convenient to you and to
> the
> development process.
>
> Should the process include an official "Yes we have rough consensus for a
> Recording Document update" from Jim?
>

Hi Roger,

thanks again a lot for your answer and clarifications. And for your help to
the NUT project.
I feel ashamed to be so far from it now :D
Still, I'll go ahead, merge the referenced PRs, and do an announcement here
once done, pointing at the updated nut-names.txt.

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

Re: [Nut-upsuser] [networkupstools/nut] RFC: clarify and complete battery dates (#1063)

[Arnaud Quette via Nut-upsuser]

Le lun. 9 août 2021 à 15:06, Roger Price  a écrit :

> On Mon, 9 Aug 2021, Arnaud Quette wrote:
>
> > small update (replay of #1062): these were announced to the mailing list
> as an RFC for a week, without feedback so far:
> >
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2021-August/012485.html
> >
> > Is a "no answer / objection" considered as a rough consensus? If so, is
> there some time limit attached?
>
> If nobody has objected after a week, then I suggest
>
>   1) Go ahead with the proposed additions
>   2) Give us a link to the new docs/nut-names.txt
>
> One of the big advantages of having NUT project management of the
> Recording
> Document, is that any typos or omissions can be fixed without impacting
> the
> I-D/RFC.
>

Hi Roger,

thanks for your answer!

I may be misreading your answer, or misunderstanding the new process, so
please bear with me.
on 1) though I still have the power to merge PRs, I don't consider that I'm
the right person now to merge these:
* PR https://github.com/networkupstools/nut/pull/1060/files
* PR https://github.com/networkupstools/nut/pull/1062/files
* PR https://github.com/networkupstools/nut/pull/1063/files

@Charles Lepple  and @Jim Klimov
 esp. your feedback is welcome

on 2) the resulting new docs/nut-names.txt will the the one in git master
branch, once the above PRs are merged.

If agreed, I can proceed with merging these PRs, and link back the
docs/nut-names.txt in the git master branch.

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

[Nut-upsuser] RFC - new proposed variables and clarifications for the battery collection in NUT namespace

[Arnaud Quette via Nut-upsuser]

Hi there,

as discussed on the below Github PRs, I've recently proposed some
additional variables to deal with battery information in general, and some
Li-Ion specifics:

* PR https://github.com/networkupstools/nut/pull/1060/files
** Add "battery.packs.external": Number of external battery packs

* PR https://github.com/networkupstools/nut/pull/1062/files
** Add "battery.voltage.cell.max": Maximum battery voltage seen of the
Li-ion cell (V)
** Add "battery.voltage.cell.min": Minimum battery voltage seen of the
Li-ion cell (V)
** Add "battery.capacity.nominal": Nominal battery capacity (Ah)
** Add "battery.status": Health status of the battery (opaque string)
** Add "battery.temperature.cell.max": Maximum battery temperature seen of
the Li-ion cell (degrees C)
** Add "battery.temperature.cell.min": Minimum battery temperature seen of
the Li-ion cell (degrees C)

* PR https://github.com/networkupstools/nut/pull/1063/files
** Clarify "battery.date": Battery installation or last change date (opaque
string)
** Add "battery.date.maintenance": Battery next change or maintenance date
(opaque string)

As usual with RFC for new variables, feedback and comments are warmly
welcome.

Thanks and cheers
Arno
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Bug#964586: O: powerman -- Centralized Power Distribution Unit (PDU) management

[Arnaud Quette]

Package: wnpp
Severity: normal

I intend to orphan the powerman package, since I'm retiring from Debian.

I'm unsure if this software is still useful, considering the
popcorn figures.
So it may be considered for a removal from the archives.

cheers,
Arno

Bug#964585: O: pwrkap -- Energy use monitor and Power Cap enforcement tools - Core

[Arnaud Quette]

Package: wnpp
Severity: normal

I intend to orphan the wmnut package, since I'm retiring from Debian.

I no longer have time to maintain this package.
I'm unsure if this software is still useful, considering the
popcorn figures.
So it may be considered for a removal from the archives.

cheers,
Arno

Bug#964584: Please remove me from the Uploaders

[Arnaud Quette]

Package: pylirc
Severity: normal

I'm in the process of retiring from Debian.
So please remove myself from the Uploaders list.

Thanks and cheers,
Arno

Bug#964583: O: wmnut -- WindowMaker dock app that displays UPS statistics from NUT upsd

[Arnaud Quette]

Package: wnpp
Severity: normal

I intend to orphan the wmnut package, since I'm retiring from Debian.

I no longer have time to maintain this package. This software seems still
useful, though (as the upstream author) I don't intend to update it anymore.

I've uploaded the code to Salsa, and update the control file:

https://salsa.debian.org/debian/wmnut

cheers,
Arno

Re: [Bug 1814314] Re: add nut-scanner to build

[Arnaud Quette]

Hi fellows,

It's always true that I'm more focused on upstream these years, than on
Debian an Ubuntu.
I'll try to make a summary to explain the what and how on this nut-scanner
feature, on the Debian ticket

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814314

Title:
  add nut-scanner to build

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1814314/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Nut-upsdev] NUT namespace: RFC for new variable addition

[Arnaud Quette]

Hi all,

here is another variable addition, related to iPDU, that I'd like to make:
outlet.n.name  | Outlet name (opaque string) | A1

For the sake of completion, we already have "outlet.n.desc" which is more
of a description, as per its name.

At Eaton, we implement:
* outlet.n.name as the physical name of the outlet, related to the group of
the outlet.
For example, the first outlet of the 2nd group (named "B") will be "B1"
* outlet.n.desc as the friendly name of the outlet, which can be changed by
the user.
For example, the first outlet of the 2nd group (named "B") will be "Outlet
B1".
But user may change it to reflect the name of the device powered by this
outlet.

Comments and feedback warmly welcome.
Please however note that I'll be pushing the related commit, since it seem
trivial.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

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-upsdev] NUT namespace: RFC for new variable addition

[Arnaud Quette]

(hmmm, finally hitting the Sent button...)

2017-05-24 13:56 GMT+02:00 Jim Klimov <jimkli...@cos.ru>:

> On May 24, 2017 1:08:09 PM GMT+02:00, Charles Lepple <clep...@gmail.com>
> wrote:
> >On May 24, 2017, at 5:11 AM, Arnaud Quette <arnaud.que...@gmail.com>
> >wrote:
> >>
> >> Hi all,
> >>
> >> here is another one, related to ATS (automatic transfer switch) this
> >time.
> >>
> >> in order to track "dephasing" between input sources (1 and 2), I'd
> >like to add a new variable: "input.phase.shift"
> >>
> >>
> >> Details and implementation can be found on:
> >> https://github.com/networkupstools/nut/pull/433
> >>
> >> Comments and feedback warmly welcome.
> >
> >I don't think "dephasing" is common usage, but "phase shift" should
> >suffice.
> >
> >Also, how does this apply to 3-phase systems? Is it nominally 120
> >degrees?
> >
> >Strange that this has not come up before.
> >___
> >Nut-upsdev mailing list
> >Nut-upsdev@lists.alioth.debian.org
> >http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
>
> It was my impression too. However it seems the 'phase shift' usually
> refers to lag between Amperage and Voltage waves, while this issue is (if I
> get it correctly) about two separate ATS inputs fluctuating on their own
> different clock-offsets. Should be same freq (50 or 60) though, or likely
> assumed so - which might not be guaranteed in real life either ;) On the
> other hand, if the freqs differ, this reported skew degree will vary over
> time (if detected and reported honestly)...
>

Jim is right, this is very tied to ATS. I don't see that applying to 3ph
UPS, since there is only 1 source.
The point for ATS is that a source may be the main, and the other a UPS.
Hence the potential phase shift.
The nominal value is 0

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

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-upsdev] Powercom BNT-2000AP(USB)

[Arnaud Quette]

2017-04-30 13:38 GMT+02:00 Jim Klimov :

> On April 28, 2017 9:11:59 AM GMT+03:00, "Александр Борисович" <
> vtk-al...@mail.ru> wrote:
> >Hello all!
>

privet Alexander


> >Some days ago we received new UPS Powercom BNT-2000AP with USB
> >interface to replace an old staff and I've spent four last days trying
> >to connect it with NUT. I have a FreeBSD 8.4 box with NUT 2.7.2.
> >
> ># dmesg|grep -i powercom
> >ugen0.3:  at usbus0
> >uhid0:  >addr 3> on usbus0
> >uhid0:  >addr 3> on usbus0
> >
> >I know that it's absent in hardware list, but I can't change anything
> >now for nearest 2-3 months. And I don't want to leave server
> >unmanaged.
> >I tried all powercom drivers and all of them were unsuccsessful.
> ># /usr/local/libexec/nut/powercom -a BNT2000 -x type=BNT-other -x
> >port=/dev/ugen0.3 -DDD
> >Network UPS Tools - PowerCom protocol UPS driver 0.14 (2.7.2)
> >   0.00 debug level is '3'
> >   0.000670 tcgetattr(/dev/ugen0.3): Inappropriate ioctl for device
> >I believe that it's right...
> >
> >The "best" results I received with usbhid-ups driver:
> ># /usr/local/libexec/nut/usbhid-ups -a BNT2000 -DDD
> >Network UPS Tools - Generic HID driver 0.38 (2.7.2)
> >USB communication driver 0.32
> >   0.00 debug level is '3'
> >   0.000557 upsdrv_initups...
> >   0.000744 Checking device (0D9F/0004) (/dev/usb//dev/ugen0.3)
> >   0.031233 - VendorID: 0d9f
> >   0.031240 - ProductID: 0004
> >   0.031245 - Manufacturer: unknown
> >   0.031248 - Product: unknown
> >   0.031252 - Serial Number: unknown
> >   0.031256 - Bus: /dev/usb
> >   0.031260 Trying to match device
> >   0.031268 Device matches
> >   0.080235 Unable to get HID descriptor (Unknown error)
> >   0.080248 HID descriptor, method 2: (9 bytes) => 09 21 00 01 00 01 22
> >c6 03
> >   0.080252 HID descriptor length 966
> >   0.090278 Unable to get Report descriptor: Input/output error
> >   0.090299 No appropriate HID device found
> >   0.090306 No matching HID UPS found
> >
> >Someone recommended me to try driver megatec smth like:
> >[ups]
> >driver = megatec_usb
> >port = "/dev/ugen0.2"
> >
> >But there is no driver megatec_usb nither in driver.list no in the
> >hardware list on the site. However, I tried
> >
> ># /usr/local/libexec/nut/blazer_usb -a BNT2000 -x protocol=megatec -DDD
> >Network UPS Tools - Megatec/Q1 protocol USB driver 0.11 (2.7.2)
> >   0.00 debug level is '3'
> >   0.000634 Checking device (0D9F/0004) (/dev/usb//dev/ugen0.3)
> >   0.030633 - VendorID: 0d9f
> >   0.030641 - ProductID: 0004
> >   0.030645 - Manufacturer: unknown
> >   0.030649 - Product: unknown
> >   0.030653 - Serial Number: unknown
> >   0.030657 - Bus: /dev/usb
> >   0.030661 Trying to match device
> >   0.030666 Device does not match - skipping
> >   0.030680 No appropriate HID device found
> >   0.030686 No supported devices found.
> >
> >Can anybody help me? I'm ready to provide any data/information on your
> >request and even to become a tester! :)
> >--
> >Thnx! Alexander
> >___
> >Nut-upsdev mailing list
> >Nut-upsdev@lists.alioth.debian.org
> >http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
>
> Just in case, one thing that stands out in your post is nut-2.7.2. It is
> pretty old, meaning that newer releases or the github master can have more
> HW support. Did you try (or can you build and retry) your experiments with
> this newer code?
>

to complete Jim's answer (you should really try 2.7.4):
* as per NUT HCL, recent Powercom units are supported through USB with
usbhid-ups, so that path is still to be followed
http://networkupstools.org/stable-hcl.html?manufacturer=Powercom

* the actual issue is around "Unable to get Report descriptor: Input/output
error"
I'd be interested in a test in debug level 5 (i.e. -D) to get a bit
more visibility

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] new driver- or vendor-specific variable prefix?

[Arnaud Quette]

Hi Charles

2017-06-07 3:42 GMT+02:00 Charles Lepple :

> Not to pick on anyone in particular, but for the sake of organization, I
> think we might need to address the need for variables beyond the standard
> ones defined here:
>
>http://networkupstools.org/docs/developer-guide.chunked/apas01.html
>
> From http://networkupstools.org/docs/developer-guide.chunked/
> ar01s04.html#_variable_names :
>
> "PLEASE don’t make up new variables and commands just because you can. The
> new dstate functions give us the power to create just about anything, but
> that is a privilege and not a right. Imagine the mess that would happen if
> every developer decided on their own way to represent a common status
> element."
>
> On the other hand, it is useful to expose everything that comes out of the
> stub driver generator to see if it is useful. And for the UPSes where we
> don't have good documentation, well... I'm guilty of this, too:
>
>https://github.com/networkupstools/nut/blob/
> master/drivers/tripplite_usb.c#L613
>
> Any thoughts? Does "ups.debug.*" work? Just "debug.*"? "vendor.XYZ.*"?
>

2nded!

there are 2 different use cases here:
- vendor.xyz would be valid for specific vendor things in production.
however, our approach is that any such things can have a name useful for
others too.
so that would probably limit that point to "opaque" features (I once talked
or at least though of using a vendor.xyz collection to access the ups
internals...)
* ups.debug (or preferably debug.xyz) can be transiently useful to get
visibility on data (through upsc dumps) to finalize a new driver
development or further evolution. That could even be used in conjunction
with a driver generic flag (or maybe -D) to enable or trim out these

Here are the two pull requests that prompted this email:
>
>  * https://github.com/networkupstools/nut/pull/431
>  * https://github.com/networkupstools/nut/pull/440
>

not looked at these thoroughly yet, but #431 tends to expose raw HID data
as nut data.
I'm not in favor of these! Most of these HID data are either used in other
HID subdrivers (thus, references available) or to be considered for
dropping or for the debug.xyz collection...

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

[Nut-upsdev] NUT namespace: RFC for new variable addition

[Arnaud Quette]

Hi all,

here is another one, related to ATS (automatic transfer switch) this time.

in order to track "dephasing" between input sources (1 and 2), I'd like to
add a new variable: "input.phase.shift"


Details and implementation can be found on:
https://github.com/networkupstools/nut/pull/433

Comments and feedback warmly welcome.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Bug#812604: nut-server: usbhid-ups segfaults due to missing USB strings

[Arnaud Quette]

FYI
I've also made a somewhat complementary patch that tries 3 times to get
these string (only once currently elsewhere).
Iirc it's still sitting in the libusb1 branch on github, and it's not yet
merged in the mainline. Would be cool if you could test...

Cheers,
Arno

[Pkg-utopia-maintainers] Bug#861745: Bug#861745: dbus: Make adduser / perl Depends optional

[Arnaud Quette]

2017-05-03 15:23 GMT+02:00 Michael Biebl <bi...@debian.org>:

> Hi Arno
>

Hi Michael

Long time no see, I hope you're doing fine


>
> Am 03.05.2017 um 14:47 schrieb Arnaud Quette:
>
> > we have a project at Eaton related to 42ITy <http://42ity.org>, which
> > produce a Debian derivative for a HW appliance. For storage footprint
> > reason, we've gotten rid of perl. Now, we're adding avahi, which pulls
> > dbus, which pulls perl through the adduser command and Depends.
> >
> > The attached patch moves adduser to Suggests, and use adduser only if
> > available. It otherwise fallback to useradd.
> >
> > Note: there is a small nuance between useradd and adduser: the latter
> tries
> > to use the smallest UID/GID for system users, while the former goes top
> > down from SYS_UID_MAX.
> > As an example, the original dbus postinst ended up with UID/GID 146 on my
> > system, while the modified has 999…
>
> While I understand your incentive, I'm not sure this is the right
> approach. There are a lot of packages requiring adduser. Adding a
> fallback to every one of them doesn't seem right.
>

indeed! I only intended to do a local fix for the specific dbus issue we
have.

Why don't you provide a adduser package in your derivative, which does
> not require perl? It could even be a small shell wrapper around useradd.
>

I was thinking about this, but prefered the more straightforward / less
time consuming focused fix.
I still keep this in mind however, since we (Eaton / 42ITy) intend to
release all our changes / mods / improvements to Debian.
In the long run, we intend to have no diff with Debian, but that can take
some time ;)


> So, from my POV this bug report is a wontfix as I think it's the wrong
> approach. But let's see what Simon, the main dbus maintainer, thinks.
>

makes sense. again, this is more a hotfix for a specific issue / need on
our side.
but it's interesting to get feedback and see if other peoples are facing
the same kind of things...
looking forward Simon's answer

2017-05-03 15:32 GMT+02:00 Michael Biebl <bi...@debian.org>:

>
> Looking again, it seems adduser itself does not actually depend on perl,
> I suppose it only requires perl-base, which is essential.
> Getting rid of perl-base sounds like a lot of work, as packages are free
> to rely on its functionality without having to depend on it. So you'd
> have to check a lot of packages.
>

indeed, adduser depends on perl-base not perl.
Reverse deps on adduser announces 799 packages
that's a lot more than I can handle on the little time I have currently ;)
I'll try to dig the 'adduser-noperl' approach to see if I can get something
out of this.

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
___
Pkg-utopia-maintainers mailing list
Pkg-utopia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers

Bug#861745: [Pkg-utopia-maintainers] Bug#861745: dbus: Make adduser / perl Depends optional

[Arnaud Quette]

2017-05-03 15:23 GMT+02:00 Michael Biebl <bi...@debian.org>:

> Hi Arno
>

Hi Michael

Long time no see, I hope you're doing fine


>
> Am 03.05.2017 um 14:47 schrieb Arnaud Quette:
>
> > we have a project at Eaton related to 42ITy <http://42ity.org>, which
> > produce a Debian derivative for a HW appliance. For storage footprint
> > reason, we've gotten rid of perl. Now, we're adding avahi, which pulls
> > dbus, which pulls perl through the adduser command and Depends.
> >
> > The attached patch moves adduser to Suggests, and use adduser only if
> > available. It otherwise fallback to useradd.
> >
> > Note: there is a small nuance between useradd and adduser: the latter
> tries
> > to use the smallest UID/GID for system users, while the former goes top
> > down from SYS_UID_MAX.
> > As an example, the original dbus postinst ended up with UID/GID 146 on my
> > system, while the modified has 999…
>
> While I understand your incentive, I'm not sure this is the right
> approach. There are a lot of packages requiring adduser. Adding a
> fallback to every one of them doesn't seem right.
>

indeed! I only intended to do a local fix for the specific dbus issue we
have.

Why don't you provide a adduser package in your derivative, which does
> not require perl? It could even be a small shell wrapper around useradd.
>

I was thinking about this, but prefered the more straightforward / less
time consuming focused fix.
I still keep this in mind however, since we (Eaton / 42ITy) intend to
release all our changes / mods / improvements to Debian.
In the long run, we intend to have no diff with Debian, but that can take
some time ;)


> So, from my POV this bug report is a wontfix as I think it's the wrong
> approach. But let's see what Simon, the main dbus maintainer, thinks.
>

makes sense. again, this is more a hotfix for a specific issue / need on
our side.
but it's interesting to get feedback and see if other peoples are facing
the same kind of things...
looking forward Simon's answer

2017-05-03 15:32 GMT+02:00 Michael Biebl <bi...@debian.org>:

>
> Looking again, it seems adduser itself does not actually depend on perl,
> I suppose it only requires perl-base, which is essential.
> Getting rid of perl-base sounds like a lot of work, as packages are free
> to rely on its functionality without having to depend on it. So you'd
> have to check a lot of packages.
>

indeed, adduser depends on perl-base not perl.
Reverse deps on adduser announces 799 packages
that's a lot more than I can handle on the little time I have currently ;)
I'll try to dig the 'adduser-noperl' approach to see if I can get something
out of this.

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

[Pkg-utopia-maintainers] Bug#861745: dbus: Make adduser / perl Depends optional

[Arnaud Quette]

Package: dbus
Severity: wishlist
Tags: patch

Hi,

we have a project at Eaton related to 42ITy , which
produce a Debian derivative for a HW appliance. For storage footprint
reason, we've gotten rid of perl. Now, we're adding avahi, which pulls
dbus, which pulls perl through the adduser command and Depends.

The attached patch moves adduser to Suggests, and use adduser only if
available. It otherwise fallback to useradd.

Note: there is a small nuance between useradd and adduser: the latter tries
to use the smallest UID/GID for system users, while the former goes top
down from SYS_UID_MAX.
As an example, the original dbus postinst ended up with UID/GID 146 on my
system, while the modified has 999…

Thanks for considering its integration,
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


dbus-noperl-adduser.patch
Description: application/mbox
___
Pkg-utopia-maintainers mailing list
Pkg-utopia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers

Bug#861745: dbus: Make adduser / perl Depends optional

[Arnaud Quette]

Package: dbus
Severity: wishlist
Tags: patch

Hi,

we have a project at Eaton related to 42ITy , which
produce a Debian derivative for a HW appliance. For storage footprint
reason, we've gotten rid of perl. Now, we're adding avahi, which pulls
dbus, which pulls perl through the adduser command and Depends.

The attached patch moves adduser to Suggests, and use adduser only if
available. It otherwise fallback to useradd.

Note: there is a small nuance between useradd and adduser: the latter tries
to use the smallest UID/GID for system users, while the former goes top
down from SYS_UID_MAX.
As an example, the original dbus postinst ended up with UID/GID 146 on my
system, while the modified has 999…

Thanks for considering its integration,
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


dbus-noperl-adduser.patch
Description: application/mbox

[Nut-upsdev] NUT namespace: RFC for new variable addition

[Arnaud Quette]

Hi all,

in order to track which phase (L1, L2, L3) feeds a physical outlet groups
on a rack PDU, I'd like to extend the NUT namespace to add a new variable:
outlet.group.n.phase

Details and implementation can be found on:
https://github.com/networkupstools/nut/pull/422

Comments and feedback warmly welcome.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

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

Bug#851015: nut: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

[Arnaud Quette]

Hi Michael,

No idea on the why and not much time to look at it before the week end.
Iirc, dblatex is listed for the manpages generation.

Feel free to upload a fix if you find one.

Thanks and cheers.
Arno

Le 19 janv. 2017 19:57, "Michael Stapelberg"  a
écrit :

> [+aquette, bigon directly]
>
> Are you aware of this issue? This RC bug transitively marked freeradius
> for removal from testing. If you need help, please let me know — I have
> some incentive to look into it in order to keep freeradius in stretch.
>
> Lucas Nussbaum  writes:
>
> > Source: nut
> > Version: 2.7.4-4
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20170111 qa-ftbfs
> > Justification: FTBFS on amd64
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> >
> > Relevant part (hopefully):
> >> make[3]: Entering directory '/<>/docs'
> >> make[3]: Nothing to be done for 'all-am'.
> >> make[3]: Leaving directory '/<>/docs'
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=chunked_format --format=chunked --xsl-file=./chunked.xsl
> user-manual.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=chunked_format --format=chunked --xsl-file=./chunked.xsl
> developer-guide.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=chunked_format --format=chunked --xsl-file=./chunked.xsl
> packager-guide.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=xhtml11_format --format=xhtml --xsl-file=./xhtml.xsl FAQ.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=pdf_format --format=pdf -a docinfo1 user-manual.txt
> >> a2x: WARNING: --destination-dir option is only applicable to HTML based
> outputs
> >> a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/
> asciidoc-dblatex.xsl
> >> Makefile:825: recipe for target 'user-manual.pdf' failed
> >> make[2]: *** [user-manual.pdf] Error 1
> >
> > The full build log is available from:
> >http://aws-logs.debian.net/2017/01/11/nut_2.7.4-4_unstable.log
> >
> > A list of current common problems and possible solutions is available at
> > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
> contribute!
> >
> > About the archive rebuild: The rebuild was done on EC2 VM instances from
> > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> > failed build was retried once to eliminate random failures.
> >
> >
>
> --
> Best regards,
> Michael
>

Bug#851015: nut: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

[Arnaud Quette]

Hi Michael,

No idea on the why and not much time to look at it before the week end.
Iirc, dblatex is listed for the manpages generation.

Feel free to upload a fix if you find one.

Thanks and cheers.
Arno

Le 19 janv. 2017 19:57, "Michael Stapelberg"  a
écrit :

> [+aquette, bigon directly]
>
> Are you aware of this issue? This RC bug transitively marked freeradius
> for removal from testing. If you need help, please let me know — I have
> some incentive to look into it in order to keep freeradius in stretch.
>
> Lucas Nussbaum  writes:
>
> > Source: nut
> > Version: 2.7.4-4
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20170111 qa-ftbfs
> > Justification: FTBFS on amd64
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> >
> > Relevant part (hopefully):
> >> make[3]: Entering directory '/<>/docs'
> >> make[3]: Nothing to be done for 'all-am'.
> >> make[3]: Leaving directory '/<>/docs'
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=chunked_format --format=chunked --xsl-file=./chunked.xsl
> user-manual.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=chunked_format --format=chunked --xsl-file=./chunked.xsl
> developer-guide.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=chunked_format --format=chunked --xsl-file=./chunked.xsl
> packager-guide.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=xhtml11_format --format=xhtml --xsl-file=./xhtml.xsl FAQ.txt
> >> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet"
> --xsltproc-opts "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\""
> --xsltproc-opts "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\""
> --xsltproc-opts "--stringparam nut.nutversion \"2.7.4\"" --attribute
> iconsdir=./images --attribute=badges --attribute=external_title --attribute
> tree_version=2.7 -a toc -a numbered --destination-dir=.
> --attribute=pdf_format --format=pdf -a docinfo1 user-manual.txt
> >> a2x: WARNING: --destination-dir option is only applicable to HTML based
> outputs
> >> a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/
> asciidoc-dblatex.xsl
> >> Makefile:825: recipe for target 'user-manual.pdf' failed
> >> make[2]: *** [user-manual.pdf] Error 1
> >
> > The full build log is available from:
> >http://aws-logs.debian.net/2017/01/11/nut_2.7.4-4_unstable.log
> >
> > A list of current common problems and possible solutions is available at
> > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
> contribute!
> >
> > About the archive rebuild: The rebuild was done on EC2 VM instances from
> > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> > failed build was retried once to eliminate random failures.
> >
> >
>
> --
> Best regards,
> Michael
>

Bug#791625: nut: Can't talk to Eaton 5S

[Arnaud Quette]

2016-12-24 15:23 GMT+01:00 Kurt Roeckx <k...@roeckx.be>:

> On Sat, Dec 24, 2016 at 02:56:53PM +0100, Arnaud Quette wrote:
> > Hi Kurt,
> >
> > are you still facing this issue?
> > As far as I recall, I've tested 5S not long ago (Jessie + NUT 2.7.4), and
> > everything was fine...
>
> As far as I know, it works sometimes. It ussually works when
> they're both just up. But I think the 5S gets confused if you ever
> stop nut.
>
> We also just stopped using the 5S. We've already had 2 of them
> just shut down the power to the server while there was nothing
> wrong with the power and it had power itself. It then indicates
> some internal error. We've replaced them by APCs.
>
> I have no idea if the above 2 issues are related or not.
>
>
Hi Kurt,

thanks for your fast answer.
I've cc'ed myself @work, to push that to the support and validation team,
and check the exact situation.
Sorry for the issues you've encountered, I hope that Eaton will recover
your trust in a soon future.

In the meantime, I wish you a merry Christmas.

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

Bug#791625: nut: Can't talk to Eaton 5S

[Arnaud Quette]

Hi Kurt,

are you still facing this issue?
As far as I recall, I've tested 5S not long ago (Jessie + NUT 2.7.4), and
everything was fine...

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

Accepted wmnut 0.66-1 (source) into unstable

[Arnaud Quette]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 24 Dec 2016 00:18:40 +0100
Source: wmnut
Binary: wmnut
Architecture: source
Version: 0.66-1
Distribution: unstable
Urgency: low
Maintainer: Arnaud Quette <aque...@debian.org>
Changed-By: Arnaud Quette <aque...@debian.org>
Description:
 wmnut  - WindowMaker dock app that displays UPS statistics from NUT's upsd
Changes:
 wmnut (0.66-1) unstable; urgency=low
 .
   * New upstream release
   * debian/rules: add missing dpkg flags
   * debian/control: update Standards-Version to 3.9.8
Checksums-Sha1:
 64e58a651f8a43de2b79ed6c7bdd36619f055abe 1880 wmnut_0.66-1.dsc
 b25d99bb0bf2bd40dc78554b397a7e0bf4c1f843 191253 wmnut_0.66.orig.tar.gz
 14378e36e199f15bc4651d6ee34cb3d18a1154af 3476 wmnut_0.66-1.debian.tar.xz
Checksums-Sha256:
 bf06e0ed700b38aa13707490f6f54df433d98998fd6424747c166bacbeaa40c8 1880 
wmnut_0.66-1.dsc
 42a520739ba8ea8554946672c37f94a56251fc12c08c8b35508d6785f1fd2b1e 191253 
wmnut_0.66.orig.tar.gz
 1944c55481d90f808cfc56314f9d48da8d0416731e5adfed106f66201f635401 3476 
wmnut_0.66-1.debian.tar.xz
Files:
 8983ed641579c83593d6febe0d92c1b8 1880 x11 optional wmnut_0.66-1.dsc
 ffe01b7c46d310c6e5086e976f43a55f 191253 x11 optional wmnut_0.66.orig.tar.gz
 442a345772e6a952a8d4e66d9f0cda93 3476 x11 optional wmnut_0.66-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYXbI5AAoJEKzA5BBVyll2xp8P/RoVUqlqZWoQdmQeZZS59kls
wEzH+rxwwvzj8RMoTqDlIsAjXcMzDCkEWoc4df1+OTKfTN4qO7muUKkGHWo+TTR6
BHqHbfsml6LAQt/Bs/w4ZZkNEYUixScQE0uGFCUqNcEz38t/0V/+v4lauX1CkQqT
DaAyVXOT0eyYEyOnw6Xw/P/5BDPJBsKJqey1cqcwXyjD91Bgx6DirXCnNV7pFT1Q
KRq/ChUoTZwWTgnOrcmoP5/sVCRk+IYyCWf2m9xc8Ay2OFA2l6agdqafoirjJLVe
eMvjjmkQq+F4Am8tmO7OYz0/dk0d2PXRTOS+RCescEOUYL3Tq+0krdb63Vdm/Cnc
ygnMZ21A5JHN1K9oqG+OTcjsxBkzT9LXFmOkogZdpxJ933yG97LGqebmrwTvhJSL
rZ/wJ5ImNJzDZ1ayVHVMwl4aWsZS8hHzhpdIPtU19DUqzdRpppmXZougViyXRs7o
ggCu7JLUJRV/1pReiEuGKA96CHGxW1EorUghmRPZjKXtWTlrXumTjAuEv2h739rs
D58uP24HRD8gwtrEyAUiKF9s5Wvuec8bWI5XzGudkmi1e0OiAWSSSRehXEN1ZJZp
JNVr7f0k19jKbNBRiOCBMnq6+njnQNzL4sMrZAXNKfMthCHP6RdRptrW2GLfqzfz
dExSOi0CawJCvMLwuYqg
=Oh4D
-END PGP SIGNATURE-

Accepted wmnut 0.65-1 (source amd64) into unstable

[Arnaud Quette]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 23 Dec 2016 22:54:52 +0100
Source: wmnut
Binary: wmnut
Architecture: source amd64
Version: 0.65-1
Distribution: unstable
Urgency: low
Maintainer: Arnaud Quette <aque...@debian.org>
Changed-By: Arnaud Quette <aque...@debian.org>
Description:
 wmnut  - WindowMaker dock app that displays UPS statistics from NUT's upsd
Closes: 728002
Changes:
 wmnut (0.65-1) unstable; urgency=low
 .
   * New upstream release (Closes: #728002)
   * debian/copyright: update to comply to copyright format 1.0
   * debian/control
 - update Standards-Version to 3.9.6
 - update Homepage
 - add Vcs-Browser and Vcs-Git fields
   * debian/watch: update URL
   * debian/rules: general update and simplification
Checksums-Sha1:
 83879955a2a75525d1b6a76236b5ec71eb75470d 1880 wmnut_0.65-1.dsc
 5a3c86522c6caccfa3f015cfa814da0f0a0ba75c 191222 wmnut_0.65.orig.tar.gz
 f05c51bb6d03ce81b3c0e5f1d348530f877f20e0 3404 wmnut_0.65-1.debian.tar.xz
 f37dc704efaa9e1e17a389cbcf0583c5eb1a66cc 37734 wmnut_0.65-1_amd64.deb
Checksums-Sha256:
 661f03279875d2cfdc720484561d043ea349c0c69fa9317d6ca0853d131a956c 1880 
wmnut_0.65-1.dsc
 e036f0582afbab210aa72d2324574702f22625ef92681b3b87afa80818ba495b 191222 
wmnut_0.65.orig.tar.gz
 5e90fd1c67723118f204213e59d302a1ae5686fd5b25053fd82fc7b566380345 3404 
wmnut_0.65-1.debian.tar.xz
 766a00cce21f8c4f978479d7ba2adf608f177f3af1123c4e5c308a22262abba6 37734 
wmnut_0.65-1_amd64.deb
Files:
 8b350e8e6c25358bf291a4782256db4d 1880 x11 optional wmnut_0.65-1.dsc
 32cc418c731de3b73d427cd856118e23 191222 x11 optional wmnut_0.65.orig.tar.gz
 26ef75da8cce8e12116771832e47c51a 3404 x11 optional wmnut_0.65-1.debian.tar.xz
 2f16c709e1910d769647c44d082a77b6 37734 x11 optional wmnut_0.65-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYXaecAAoJEKzA5BBVyll2N9cP/izoQ17Dbxda4bNJNQqaU4nQ
pMPgy9kf4gjy3eaDwMCOwBPmXS3lkGr0ha5AmPKBDM/qcJ3Aj9wfNwDQriRAjr0L
uxK76YJ3tjY850zxvtf/ZKLk2LYIXCcAgQtlVvwImyrvarPyel27osSYmZiXZ6AW
QbOEu+BqUFm5QqJM0PhTYcF6W3eRpvRU9C3YEJNVuWt6TtINp2OsdYQ20+RsiHko
uYWNX9LjeVt4I+ulTzG9GjOK4mmmybqN6MMQpTLDr982FPUOOFHN1ZdYNpmyxyUd
MFSu8jYcRTwe1LgBzp9djtkurVL+IfqbkYkR0y2jA+DfHkbFn3Fh0SgPI/Cf8VBR
kHkdtpaeOt1LPjByiamMMO4sIy9OzKCBAzMHCuebi46cyY1V/XePAS3H+IvQfDBc
AOBvqY7qCDSgKlM3LNtBhCtULXCFoftbabBsEIUQjt/q89eLLfvl2NFAidLfA+bE
YfRkgb2MLd8xaOfN5xpRyd0YhBw/8bVaE2l3icnWeYUPJ72acIVrxP7QQ3DpHJxo
qijoqYaeS1nEQjeObgbBZnhQ/OBmi3XSAv4TGe/Lg90GwPTGa6na4wMyaHoyOC6O
VQCQlpE5+cbjFCardoHN15qLub7ryHCqggh9TKsoRXJXu9jIC+W7xLnewelKoIxD
K4LCgAIxvZe+TdRvhySV
=AIY2
-END PGP SIGNATURE-

[Bug 1647088] Re: NUT not work with apc backups with usb through usbhid-ups

[Arnaud Quette]

Hi guys,

this is very possibly a duplicate of #1483615
the error is probably due to an issue retrieving a string, and not handled in 
the driver code.
To confirm, please start the driver in debug mode using (as root):
/lib/nut/usbhid-ups -u nut -DDD -a myups
then
/lib/nut/usbhid-ups -u root -DDD -a myups

if confirmed, this was fixed upstream:
https://github.com/networkupstools/nut/commit/f679a2820e49cbdec4138295de5e8947ee953a8a

However, as mentioned in the other ticket, the above fix has some negative 
impact.
this may in the end be due to another ticket (tied to udev and privileges 
application) logged by Charles Lepple. This privileges issues could lead to the 
string retrieval issue, causing these bugs.

All in all, adding the patch has more benefits than drawbacks

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1647088

Title:
  NUT not work with apc backups with usb through usbhid-ups

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1647088/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Bug#840754: Memory leak in libmagic and failure in magic_load

[Arnaud Quette]

2016-12-02 0:04 GMT+01:00 Christoph Biedl <debian.a...@manchmal.in-ulm.de>:
> Arnaud Quette wrote...
>
>> $ gcc test.c -lmagic
>> valgrind ./a.out
> (...)
>> ==30967== HEAP SUMMARY:
>> ==30967== in use at exit: 48 bytes in 3 blocks
>> ==30967== total heap usage: 28 allocs, 25 frees, 2,179 bytes allocated
> (...)
>
> Hello,
>
> according to my tests this was fixed in file/libmagic 5.29-1 (as in
> sid and stretch):
>
> ==416629== Memcheck, a memory error detector
> ==416629== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==416629== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright 
> info
> ==416629== Command: ./a.out
> ==416629==
> ==416629==
> ==416629== HEAP SUMMARY:
> ==416629== in use at exit: 0 bytes in 0 blocks
> ==416629==   total heap usage: 16 allocs, 16 frees, 1,123 bytes allocated
> ==416629==
> ==416629== All heap blocks were freed -- no leaks are possible
> ==416629==
> ==416629== For counts of detected and suppressed errors, rerun with: -v
> ==416629== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> Please confirm, I'll prepare a fix for jessie then (wheezy is
> appearently not affected).

Hi Christoph,

I confirm that libmagic 5.29-1 (tested on stretch) fixes the issue.

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

Bug#840754: Memory leak in libmagic and failure in magic_load

[Arnaud Quette]

Hi Christoph,

2016-10-17 20:21 GMT+02:00 Christoph Biedl <debian.a...@manchmal.in-ulm.de>:
> tags 840754 confirmed moreinfo
> thanks
>
> Arnaud Quette wrote...
>
>> ==30967== definitely lost: 48 bytes in 1 blocks
>
> Confirmed, can reproduce this from jessie on, not in wheezy though.
>
>> - Redhat has a similar ticket which they solved:
>> https://bugzilla.redhat.com/show_bug.cgi?id=919466
>
> Unfortunately I fail to see the actual fix for this (and I'm also
> somewhat surprised why it never made upstream, but that's a different
> story).
>
> Since you added the patch tag, do you have some details available?

looking closer at the patch I pointed, it's very probably not suitable.
IMHO, it's Debian related, though I've not tested on Redhat nor others.
As per my original report, the issue is with the return value of
get_default_magic(), which is "/etc/magic" instead of the documented
default "/usr/share/misc/magic" (using "MAGIC=/usr/share/misc/magic
valgrind ./a.out" shows no leak).
Not sure how other distros ships the magic.mgc
Another point is that removing (or renaming) /etc/magic also fixes the issue.

I was not able to hunt the bug yet, but here is some details.
- magic.c->magic_getpath return "/etc/magic:/usr/share/misc/magic"
- the processing of /etc/magic goes fine, but the loops then leak when
processing /usr/share/misc/magic
- the leak happen in apprentice.c->apprentice_1() when calling
add_mlist(). Still not sure why, I don't quite get the deeper logic of
this code.

I'll try to dig more and find a suitable patch, but kids vacations are
on the way in the short run...

again, the simple solution, while waiting for fixing the code, may be
to export MAGIC=/usr/share/misc/magic

Do you want me to remove the patch tag, or do you consider the
"export" solution as being a patch?

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - 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

Bug#840754: Memory leak in libmagic and failure in magic_load

[Arnaud Quette]

Package: libmagic1
Version: 1:5.22+15-2+deb8u2
Severity: normal

libmagic suffers from a memory leak, apparently due to magic_load()
not satisfying its contract:0

As per man magic_load:
--
The magic_load() function must be used to load the the colon separated
list of database files passed in as filename, or NULL for the default
database file before any magic queries can performed.

The default database file is named by the MAGIC environment variable.
If that variable is not set, the default database file name is
/usr/share/misc/magic.  magic_load() adds “.mgc” to the database
filename as appropriate.
--

Steps to reproduce:

$ cat test.c
#include 
#include 

int main ()
{ magic_t _magic = magic_open (MAGIC_MIME); int r = magic_load
(_magic, NULL); magic_close (_magic); }

$ gcc test.c -lmagic
valgrind ./a.out
==30967== Memcheck, a memory error detector
==30967== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==30967== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==30967== Command: ./a.out
==30967==
==30967==
==30967== HEAP SUMMARY:
==30967== in use at exit: 48 bytes in 3 blocks
==30967== total heap usage: 28 allocs, 25 frees, 2,179 bytes allocated
==30967==
==30967== LEAK SUMMARY:
==30967== definitely lost: 48 bytes in 1 blocks
==30967== indirectly lost: 0 bytes in 2 blocks
==30967== possibly lost: 0 bytes in 0 blocks
==30967== still reachable: 0 bytes in 0 blocks
==30967== suppressed: 0 bytes in 0 blocks
==30967== Rerun with --leak-check=full to see details of leaked memory
==30967==
==30967== For counts of detected and suppressed errors, rerun with: -v
==30967== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

To fix the above, either:
- use "MAGIC=/usr/share/misc/magic valgrind ./a.out"
- or modify the above test code "magic_load (_magic, "/usr/share/misc/magic")

It turns out the private function get_default_magic() returns
"/etc/magic" instead of the document default "/usr/share/misc/magic",
which in turns generates some lost blocks.

Solution:

Either fix upstream or export the MAGIC environment variable (probably
better / easier considering the code!).

Side notes:
- Reported with details by Michal Vyskocil from the Eaton Opensource Team
- Redhat has a similar ticket which they solved:
https://bugzilla.redhat.com/show_bug.cgi?id=919466

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - 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

Bug#835703: nut: FTBFS: dh_makeshlibs: failing due to earlier errors

[Arnaud Quette]

2016-09-25 12:09 GMT+02:00 Sebastian Harl :

> Hi,
>
> On Sun, Aug 28, 2016 at 12:27:09PM +0200, Lucas Nussbaum wrote:
> > Source: nut
> > Version: 2.7.4-3
> > Severity: serious
>
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
>
> > > dpkg-gensymbols: warning: some new symbols appeared in the symbols
> file: see diff output below
> > > dpkg-gensymbols: warning: some symbols or patterns disappeared in the
> symbols file: see diff output below
> > > dpkg-gensymbols: warning: debian/libnutclient0/DEBIAN/symbols doesn't
> match completely debian/libnutclient0.symbols
> […]
>
> This looks like a rather straight-forward issue, but I'm not into the
> magic of C++ symbol files much ;-) Anyway I can help with this



Hi Sebastian,

please go ahead and NMU if Laurent is also busy.

Thanks for the help,
Arno

Bug#835703: nut: FTBFS: dh_makeshlibs: failing due to earlier errors

[Arnaud Quette]

2016-09-25 12:09 GMT+02:00 Sebastian Harl :

> Hi,
>
> On Sun, Aug 28, 2016 at 12:27:09PM +0200, Lucas Nussbaum wrote:
> > Source: nut
> > Version: 2.7.4-3
> > Severity: serious
>
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
>
> > > dpkg-gensymbols: warning: some new symbols appeared in the symbols
> file: see diff output below
> > > dpkg-gensymbols: warning: some symbols or patterns disappeared in the
> symbols file: see diff output below
> > > dpkg-gensymbols: warning: debian/libnutclient0/DEBIAN/symbols doesn't
> match completely debian/libnutclient0.symbols
> […]
>
> This looks like a rather straight-forward issue, but I'm not into the
> magic of C++ symbol files much ;-) Anyway I can help with this



Hi Sebastian,

please go ahead and NMU if Laurent is also busy.

Thanks for the help,
Arno

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 

Re: [Nut-upsdev] updating the NUT website

[Arnaud Quette]

Hi folks,

Dan is right, and this approach is the best for us to minimize the overhead.
There may however be some points of improvement to give the right
visibility to users, and avoid the confusion of "things being visible on
the website though not yet published as a release".
not much details from my side on this for now, though...

cheers,
Arno


2016-06-07 0:50 GMT+02:00 hyo...@gmail.com :

> hmm..
> In my opinion, since we try to keep the master branch of our main git
> repo (nut) always up-to-date (i.e. we don't do development in a
> separate branch and only merge it back into master when readying a new
> release) and in a working condition, we should not keep the website
> frozen between releases, we should, instead, fetch and publish updates
> when needed: the website will then reflect the status of our
> officially official (albeit not yet part of a set-in-stone release)
> code -- if anyone wants a snapshot of the website at the time of a
> given release, they it can be built from tags.
> (..and, being the personification of laziness, I'd rather prefer to
> avoid any possible conflict that a separate branch could generate when
> merged back into master)
>
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

[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-upsdev] FW: Request for ew device<0x2B2D/0xFFFF> listed into NUT

[Arnaud Quette]

Hi,

I've just processed your request, and I need some more info, as per:
https://github.com/networkupstools/nut/issues/249

thanks and regards,
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

2015-09-01 4:41 GMT+02:00 :

> Resend the mail.
>
>
>
> *发件人:* Zhan, Cindy (詹艳梅)
> *发送时间:* 2015年8月28日 16:19
> *收件人:* nut-upsdev@lists.alioth.debian.org
> *抄送:* Xie, Maggie(谢亚红)
> *主题:* Request for ew device<0x2B2D/0x> listed into NUT
>
>
>
> Dear NUT Developers:
>
>
>
>  We really appreciate for your great job and accomplishment
> in NUT. It’s interesting and fabulous.
>
>
>
> It would be great if our new device can be listed in NUT. Here’s the basic
> information for it:
>
>
>
> Device manufacturer: AEG PS
>
> Device type:  UPS
>
> Connection: USB
>
> VID/PID:  0x2B2D/ 0x
>
> Protocol: HID  (same driver as ‘nut/blob/master/drivers/mghid.c’)
>
> USB Class: HID power device
>
> Shutdown sequence: we have tested it successfully
>
>
>
> Any other information and procedures needed for this action,
> just let us know.
>
> Thank you in advance.
>
>
>
>
>
> Regards
>
> EATON DPQD
>
> ___
> Nut-upsdev mailing list
> Nut-upsdev@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
>



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

Re: UPower: fix build regression

[Arnaud Quette]

Hi Richard,

2015-08-10 12:07 GMT+02:00 Richard Hughes hughsi...@gmail.com:

 On 6 August 2015 at 12:43, Arnaud Quette arnaud.que...@gmail.com wrote:
  Please find attached a patch that fixes a build regression on upower,
  following the removal of dbus build deps.

 Pushed with a small change, thanks.


thanks a lot!

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
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

UPower: fix build regression

[Arnaud Quette]

Please find attached a patch that fixes a build regression on upower,
following the removal of dbus build deps.

Note that there may exist a more optimal way to fix that, according to
UPower evolution plans...

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


0001-Fix-build-regression.patch
Description: application/mbox
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: [Nut-upsdev] [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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] [Nut-upsuser] Nut-2.7.3 gcc-3.3.6

[Arnaud Quette]

2015-07-06 10:40 GMT+02:00 Sergey Talchuk tals1...@gmail.com:

 Dear developers,

 libnutclient has been added as a C++ alternative to libupsclient in 2.7.1.
 As a result I can't compile nut 2.7.3 with gcc-3.3.6. There wasn't such a
 problem with nut-2.6.5.

 Is it possible to add a configuration parameter like
 '-without-libnutclient' to provide better compatibility with older gcc
 versions please (since libnutclient is an alternative to libupsclient)?
 Or maybe use C instead of C++ for libnutclient?

 Unfortunately, is not that easy to upgrade glibc in an embedded system.

 Thank you,
 Sergey


Hello Sergey

thanks for your mail.
I'm adding explicitly Emilien, who may have some additional comments...


I got some complementary questions, to ensure we bring a suitable solution
to your issue:

- which exact system are you running?
- which version of glibc?
- you said that stl is present. Do you have actually the libstdc++-dev
(Debian like) equivalent package / files installed for glibc.
I.e, is there something under /usr/include/c++/3.3.6 and / or
/usr/include/c++/3.3

For the sake of completion, libnutclient is more a developer oriented lib,
more high level and easier to use, and C++ / C usable.
While libupsclient is just the historic internal lib that I once exported
to create the first external NUT client (wmnut, back in 2001) and later
more 3rd party ones...

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

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

[Nut-upsdev] Call to funding NUT infrastructure

[Arnaud Quette]

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] UPower: 95-upower-hid.rules update

[Arnaud Quette]

Hello Bastien,

2015-06-08 15:07 GMT+02:00 Arnaud Quette arnaud.que...@gmail.com:



 2015-06-08 13:06 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Mon, 2015-06-08 at 09:45 +0200, Arnaud Quette wrote:
 
 
  2015-06-04 13:04 GMT+02:00 Bastien Nocera had...@hadess.net:
   On Sat, 2015-05-30 at 18:51 +0200, Arnaud Quette wrote:
   
   
2015-05-29 14:09 GMT+02:00 Bastien Nocera had...@hadess.net:
 On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
  Hi Richard and the list,
 
  you'll find attached a patch for 95-upower-hid.rules, which
   adds:
  - the usbmisc filtering, as added in your repo,
  - more comments, including one that points at your UPower
   repo,
  - 3 new manufacturers (Minibox, iDowell and Powerware)
  - a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2
   PowerCOM
 and 2
  Liebert)

 Could you please split those changes into 3 separate patches?
   
since you already have the usbmisc, I can possibly check to
   split
in 2 commits (1 for the comments, and 1 for the content update).
would that suits you that way?
  
   Sure.
  
  It would also be useful to include a full URL to the NUT Perl
 script
 (to a git repository perhaps), so people don't need to check
   out
 the
 full repo to update it.

as per Charles comments, beside from the perl script, you need
   all
the drivers/*hid.c files to extract the USB info.
the added comment was just to shed light on the fact that it's an
automated data extraction.
I can reword to make it more clear if you want.
  
   Just changing the path to project page URL + the path would be fine
   (that means that somebody unfamiliar with NUT's upstream can
   actually
   find the scripts to update this file).
  
  Prior to pushing the changes in NUT and to generate the patches for
  UPower, does the below header suit you:
 
  # Uninterruptible Power Supplies with USB HID interfaces
  #
  # http://cgit.freedesktop.org/upower/tree/rules/95-upower-hid.rules

 That bit isn't necessary.


 if you don't mind, I would prefer to keep it somewhere, just to remember
 (from a NUT point of view) where the upower repos. (and that file) is.
 so, not necessary, but useful for the NUT side...


  #
  # This file was automatically generated by NUT:
  # https://github.com/networkupstools/nut/
  #
  # To keep up to date, monitor upstream NUT
  #
 https://github.com/networkupstools/nut/commits/master/scripts/upower/95-
  upower-hid.rules
  # or checkout the NUT repository and call 'tools/nut-usbinfo.pl'
 
  Or do you see any other better wording?

 The rest is fine.


 ok, thanks.

 I'll just wait for your ack on the above UPower repos. point, to push the
 remaining commit.


here is the patch, before I completly forgot.
Not that I've removed the pointer to UPower git repository, as you wanted.

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


0001-Fix-HID-rules-header-as-per-discussions.patch
Description: Binary data
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] UPower: 95-upower-hid.rules update

[Arnaud Quette]

Salut Bastien

2015-06-04 13:04 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Sat, 2015-05-30 at 18:51 +0200, Arnaud Quette wrote:
 
 
  2015-05-29 14:09 GMT+02:00 Bastien Nocera had...@hadess.net:
   On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
Hi Richard and the list,
   
you'll find attached a patch for 95-upower-hid.rules, which adds:
- the usbmisc filtering, as added in your repo,
- more comments, including one that points at your UPower repo,
- 3 new manufacturers (Minibox, iDowell and Powerware)
- a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM
   and 2
Liebert)
  
   Could you please split those changes into 3 separate patches?
 
  since you already have the usbmisc, I can possibly check to split
  in 2 commits (1 for the comments, and 1 for the content update).
  would that suits you that way?

 Sure.


please find attached the first patch, addressing the added devices.
I'll send the comments update patch once you ack'ed my previous message.

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


0001-Update-UPower-HID-rules-supported-devices-list.patch
Description: Binary data
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-06-04 13:04 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Sat, 2015-05-30 at 18:51 +0200, Arnaud Quette wrote:
 
 
  2015-05-29 14:09 GMT+02:00 Bastien Nocera had...@hadess.net:
   On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
Hi Richard and the list,
   
you'll find attached a patch for 95-upower-hid.rules, which adds:
- the usbmisc filtering, as added in your repo,
- more comments, including one that points at your UPower repo,
- 3 new manufacturers (Minibox, iDowell and Powerware)
- a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM
   and 2
Liebert)
  
   Could you please split those changes into 3 separate patches?
 
  since you already have the usbmisc, I can possibly check to split
  in 2 commits (1 for the comments, and 1 for the content update).
  would that suits you that way?

 Sure.

It would also be useful to include a full URL to the NUT Perl
   script
   (to a git repository perhaps), so people don't need to check out
   the
   full repo to update it.
  
  as per Charles comments, beside from the perl script, you need all
  the drivers/*hid.c files to extract the USB info.
  the added comment was just to shed light on the fact that it's an
  automated data extraction.
  I can reword to make it more clear if you want.

 Just changing the path to project page URL + the path would be fine
 (that means that somebody unfamiliar with NUT's upstream can actually
 find the scripts to update this file).


Prior to pushing the changes in NUT and to generate the patches for UPower,
does the below header suit you:

# Uninterruptible Power Supplies with USB HID interfaces
#
# http://cgit.freedesktop.org/upower/tree/rules/95-upower-hid.rules
#
# This file was automatically generated by NUT:
# https://github.com/networkupstools/nut/
#
# To keep up to date, monitor upstream NUT
#
https://github.com/networkupstools/nut/commits/master/scripts/upower/95-upower-hid.rules
# or checkout the NUT repository and call 'tools/nut-usbinfo.pl'

Or do you see any other better wording?

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
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: [Nut-upsdev] UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-06-04 13:04 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Sat, 2015-05-30 at 18:51 +0200, Arnaud Quette wrote:
 
 
  2015-05-29 14:09 GMT+02:00 Bastien Nocera had...@hadess.net:
   On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
Hi Richard and the list,
   
you'll find attached a patch for 95-upower-hid.rules, which adds:
- the usbmisc filtering, as added in your repo,
- more comments, including one that points at your UPower repo,
- 3 new manufacturers (Minibox, iDowell and Powerware)
- a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM
   and 2
Liebert)
  
   Could you please split those changes into 3 separate patches?
 
  since you already have the usbmisc, I can possibly check to split
  in 2 commits (1 for the comments, and 1 for the content update).
  would that suits you that way?

 Sure.

It would also be useful to include a full URL to the NUT Perl
   script
   (to a git repository perhaps), so people don't need to check out
   the
   full repo to update it.
  
  as per Charles comments, beside from the perl script, you need all
  the drivers/*hid.c files to extract the USB info.
  the added comment was just to shed light on the fact that it's an
  automated data extraction.
  I can reword to make it more clear if you want.

 Just changing the path to project page URL + the path would be fine
 (that means that somebody unfamiliar with NUT's upstream can actually
 find the scripts to update this file).


Prior to pushing the changes in NUT and to generate the patches for UPower,
does the below header suit you:

# Uninterruptible Power Supplies with USB HID interfaces
#
# http://cgit.freedesktop.org/upower/tree/rules/95-upower-hid.rules
#
# This file was automatically generated by NUT:
# https://github.com/networkupstools/nut/
#
# To keep up to date, monitor upstream NUT
#
https://github.com/networkupstools/nut/commits/master/scripts/upower/95-upower-hid.rules
# or checkout the NUT repository and call 'tools/nut-usbinfo.pl'

Or do you see any other better wording?

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: UPower: 95-upower-hid.rules update

[Arnaud Quette]

Salut Bastien

2015-06-04 13:04 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Sat, 2015-05-30 at 18:51 +0200, Arnaud Quette wrote:
 
 
  2015-05-29 14:09 GMT+02:00 Bastien Nocera had...@hadess.net:
   On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
Hi Richard and the list,
   
you'll find attached a patch for 95-upower-hid.rules, which adds:
- the usbmisc filtering, as added in your repo,
- more comments, including one that points at your UPower repo,
- 3 new manufacturers (Minibox, iDowell and Powerware)
- a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM
   and 2
Liebert)
  
   Could you please split those changes into 3 separate patches?
 
  since you already have the usbmisc, I can possibly check to split
  in 2 commits (1 for the comments, and 1 for the content update).
  would that suits you that way?

 Sure.


please find attached the first patch, addressing the added devices.
I'll send the comments update patch once you ack'ed my previous message.

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


0001-Update-UPower-HID-rules-supported-devices-list.patch
Description: Binary data
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: [Nut-upsdev] UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-06-08 13:09 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Mon, 2015-06-08 at 10:13 +0200, Arnaud Quette wrote:
  -ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Liebert
 
  +ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power Co., Ltd

 I'm guessing this would require changes in NUT, so I should mention I
 don't like that change. Maybe:
 +ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power
 would be better? The names are supposed to be human readable.


though I see your rationales behind that comments, this is not NUT-only,
but also tied to usb.ids and devices USB strings and maintenance / cross
linking info:
https://usb-ids.gowdy.us/read/UD/06da

Note that such change would not make it more human readable, it's just a
truncation ;)
So I'm not in favor of changing this.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-06-08 13:09 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Mon, 2015-06-08 at 10:13 +0200, Arnaud Quette wrote:
  -ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Liebert
 
  +ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power Co., Ltd

 I'm guessing this would require changes in NUT, so I should mention I
 don't like that change. Maybe:
 +ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power
 would be better? The names are supposed to be human readable.


though I see your rationales behind that comments, this is not NUT-only,
but also tied to usb.ids and devices USB strings and maintenance / cross
linking info:
https://usb-ids.gowdy.us/read/UD/06da

Note that such change would not make it more human readable, it's just a
truncation ;)
So I'm not in favor of changing this.

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
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-06-08 14:07 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Mon, 2015-06-08 at 13:21 +0200, Arnaud Quette wrote:
 
 
  2015-06-08 13:09 GMT+02:00 Bastien Nocera had...@hadess.net:
   On Mon, 2015-06-08 at 10:13 +0200, Arnaud Quette wrote:
-ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Liebert
   
+ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power
   Co., Ltd
  
   I'm guessing this would require changes in NUT, so I should mention
   I
   don't like that change. Maybe:
   +ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power
   would be better? The names are supposed to be human readable.
  though I see your rationales behind that comments, this is not NUT
  -only, but also tied to usb.ids and devices USB strings and
  maintenance / cross linking info:
  https://usb-ids.gowdy.us/read/UD/06da
 
  Note that such change would not make it more human readable, it's
  just a truncation ;)
  So I'm not in favor of changing this.

 Actually, shouldn't it say Eaton now:
 http://www.eaton.com/Eaton/OurCompany/NewsEvents/NewsReleases/CT_141334
 ?


well, yes and no (une réponse de Breton as we say in French ;))
same as for MGE | Powerware | Best | Deltec | Sola | ...(very long list of
acquisition).
The difference here, for the sake of completion, is that PTec (short name)
or actually Centralion (same company, but different division) is
manufacturing OEM products, that are then just rebranded by Liebert, Mustek
and numerous other brands, depending on the considered timeframe.


 It's also named simply Phoenixtec in the NUT docs:
 http://www.networkupstools.org/protocols/sola.html


sure, there is still some du cleanup there ;)

Anyway.


so, works for you as is?!
thanks for your understanding.

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
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: [Nut-upsdev] UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-06-08 14:07 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Mon, 2015-06-08 at 13:21 +0200, Arnaud Quette wrote:
 
 
  2015-06-08 13:09 GMT+02:00 Bastien Nocera had...@hadess.net:
   On Mon, 2015-06-08 at 10:13 +0200, Arnaud Quette wrote:
-ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Liebert
   
+ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power
   Co., Ltd
  
   I'm guessing this would require changes in NUT, so I should mention
   I
   don't like that change. Maybe:
   +ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power
   would be better? The names are supposed to be human readable.
  though I see your rationales behind that comments, this is not NUT
  -only, but also tied to usb.ids and devices USB strings and
  maintenance / cross linking info:
  https://usb-ids.gowdy.us/read/UD/06da
 
  Note that such change would not make it more human readable, it's
  just a truncation ;)
  So I'm not in favor of changing this.

 Actually, shouldn't it say Eaton now:
 http://www.eaton.com/Eaton/OurCompany/NewsEvents/NewsReleases/CT_141334
 ?


well, yes and no (une réponse de Breton as we say in French ;))
same as for MGE | Powerware | Best | Deltec | Sola | ...(very long list of
acquisition).
The difference here, for the sake of completion, is that PTec (short name)
or actually Centralion (same company, but different division) is
manufacturing OEM products, that are then just rebranded by Liebert, Mustek
and numerous other brands, depending on the considered timeframe.


 It's also named simply Phoenixtec in the NUT docs:
 http://www.networkupstools.org/protocols/sola.html


sure, there is still some du cleanup there ;)

Anyway.


so, works for you as is?!
thanks for your understanding.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-06-08 13:06 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Mon, 2015-06-08 at 09:45 +0200, Arnaud Quette wrote:
 
 
  2015-06-04 13:04 GMT+02:00 Bastien Nocera had...@hadess.net:
   On Sat, 2015-05-30 at 18:51 +0200, Arnaud Quette wrote:
   
   
2015-05-29 14:09 GMT+02:00 Bastien Nocera had...@hadess.net:
 On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
  Hi Richard and the list,
 
  you'll find attached a patch for 95-upower-hid.rules, which
   adds:
  - the usbmisc filtering, as added in your repo,
  - more comments, including one that points at your UPower
   repo,
  - 3 new manufacturers (Minibox, iDowell and Powerware)
  - a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2
   PowerCOM
 and 2
  Liebert)

 Could you please split those changes into 3 separate patches?
   
since you already have the usbmisc, I can possibly check to
   split
in 2 commits (1 for the comments, and 1 for the content update).
would that suits you that way?
  
   Sure.
  
  It would also be useful to include a full URL to the NUT Perl
 script
 (to a git repository perhaps), so people don't need to check
   out
 the
 full repo to update it.

as per Charles comments, beside from the perl script, you need
   all
the drivers/*hid.c files to extract the USB info.
the added comment was just to shed light on the fact that it's an
automated data extraction.
I can reword to make it more clear if you want.
  
   Just changing the path to project page URL + the path would be fine
   (that means that somebody unfamiliar with NUT's upstream can
   actually
   find the scripts to update this file).
  
  Prior to pushing the changes in NUT and to generate the patches for
  UPower, does the below header suit you:
 
  # Uninterruptible Power Supplies with USB HID interfaces
  #
  # http://cgit.freedesktop.org/upower/tree/rules/95-upower-hid.rules

 That bit isn't necessary.


if you don't mind, I would prefer to keep it somewhere, just to remember
(from a NUT point of view) where the upower repos. (and that file) is.
so, not necessary, but useful for the NUT side...


  #
  # This file was automatically generated by NUT:
  # https://github.com/networkupstools/nut/
  #
  # To keep up to date, monitor upstream NUT
  #
 https://github.com/networkupstools/nut/commits/master/scripts/upower/95-
  upower-hid.rules
  # or checkout the NUT repository and call 'tools/nut-usbinfo.pl'
 
  Or do you see any other better wording?

 The rest is fine.


ok, thanks.

I'll just wait for your ack on the above UPower repos. point, to push the
remaining commit.

thx 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
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: [Nut-upsdev] UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-06-08 13:06 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Mon, 2015-06-08 at 09:45 +0200, Arnaud Quette wrote:
 
 
  2015-06-04 13:04 GMT+02:00 Bastien Nocera had...@hadess.net:
   On Sat, 2015-05-30 at 18:51 +0200, Arnaud Quette wrote:
   
   
2015-05-29 14:09 GMT+02:00 Bastien Nocera had...@hadess.net:
 On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
  Hi Richard and the list,
 
  you'll find attached a patch for 95-upower-hid.rules, which
   adds:
  - the usbmisc filtering, as added in your repo,
  - more comments, including one that points at your UPower
   repo,
  - 3 new manufacturers (Minibox, iDowell and Powerware)
  - a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2
   PowerCOM
 and 2
  Liebert)

 Could you please split those changes into 3 separate patches?
   
since you already have the usbmisc, I can possibly check to
   split
in 2 commits (1 for the comments, and 1 for the content update).
would that suits you that way?
  
   Sure.
  
  It would also be useful to include a full URL to the NUT Perl
 script
 (to a git repository perhaps), so people don't need to check
   out
 the
 full repo to update it.

as per Charles comments, beside from the perl script, you need
   all
the drivers/*hid.c files to extract the USB info.
the added comment was just to shed light on the fact that it's an
automated data extraction.
I can reword to make it more clear if you want.
  
   Just changing the path to project page URL + the path would be fine
   (that means that somebody unfamiliar with NUT's upstream can
   actually
   find the scripts to update this file).
  
  Prior to pushing the changes in NUT and to generate the patches for
  UPower, does the below header suit you:
 
  # Uninterruptible Power Supplies with USB HID interfaces
  #
  # http://cgit.freedesktop.org/upower/tree/rules/95-upower-hid.rules

 That bit isn't necessary.


if you don't mind, I would prefer to keep it somewhere, just to remember
(from a NUT point of view) where the upower repos. (and that file) is.
so, not necessary, but useful for the NUT side...


  #
  # This file was automatically generated by NUT:
  # https://github.com/networkupstools/nut/
  #
  # To keep up to date, monitor upstream NUT
  #
 https://github.com/networkupstools/nut/commits/master/scripts/upower/95-
  upower-hid.rules
  # or checkout the NUT repository and call 'tools/nut-usbinfo.pl'
 
  Or do you see any other better wording?

 The rest is fine.


ok, thanks.

I'll just wait for your ack on the above UPower repos. point, to push the
remaining commit.

thx 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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-05-29 14:09 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
  Hi Richard and the list,
 
  you'll find attached a patch for 95-upower-hid.rules, which adds:
  - the usbmisc filtering, as added in your repo,
  - more comments, including one that points at your UPower repo,
  - 3 new manufacturers (Minibox, iDowell and Powerware)
  - a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM and 2
  Liebert)

 Could you please split those changes into 3 separate patches?


since you already have the usbmisc, I can possibly check to split in 2
commits (1 for the comments, and 1 for the content update).
would that suits you that way?

It would also be useful to include a full URL to the NUT Perl script
 (to a git repository perhaps), so people don't need to check out the
 full repo to update it.


as per Charles comments, beside from the perl script, you need all the
drivers/*hid.c files to extract the USB info.
the added comment was just to shed light on the fact that it's an automated
data extraction.
I can reword to make it more clear if you want.

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
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: [Nut-upsdev] UPower: 95-upower-hid.rules update

[Arnaud Quette]

2015-05-29 14:09 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
  Hi Richard and the list,
 
  you'll find attached a patch for 95-upower-hid.rules, which adds:
  - the usbmisc filtering, as added in your repo,
  - more comments, including one that points at your UPower repo,
  - 3 new manufacturers (Minibox, iDowell and Powerware)
  - a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM and 2
  Liebert)

 Could you please split those changes into 3 separate patches?


since you already have the usbmisc, I can possibly check to split in 2
commits (1 for the comments, and 1 for the content update).
would that suits you that way?

It would also be useful to include a full URL to the NUT Perl script
 (to a git repository perhaps), so people don't need to check out the
 full repo to update it.


as per Charles comments, beside from the perl script, you need all the
drivers/*hid.c files to extract the USB info.
the added comment was just to shed light on the fact that it's an automated
data extraction.
I can reword to make it more clear if you want.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

UPower: 95-upower-hid.rules update

[Arnaud Quette]

Hi Richard and the list,

you'll find attached a patch for 95-upower-hid.rules, which adds:
- the usbmisc filtering, as added in your repo,
- more comments, including one that points at your UPower repo,
- 3 new manufacturers (Minibox, iDowell and Powerware)
- a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM and 2
Liebert)

cheers,
Arnaud
-- 
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
--- upower/rules/95-upower-hid.rules2015-05-29 13:53:23.049748923 +0200
+++ GIThub-NUT/scripts/upower/95-upower-hid.rules   2015-05-29 
13:45:58.097213385 +0200
@@ -1,10 +1,13 @@
 
##
 # Uninterruptible Power Supplies with USB HID interfaces
 #
-# to keep up to date, monitor: 
http://svn.debian.org/wsvn/nut/trunk/scripts/upower/95-upower-hid.rules
+# This file was automatically generated by NUT (nut/tools/nut-usbinfo.pl)
+# to keep up to date, monitor upstream NUT 
https://github.com/networkupstools/nut/commits/master/scripts/upower/95-upower-hid.rules
+# and upstream UPower 
http://cgit.freedesktop.org/upower/tree/rules/95-upower-hid.rules
 
-# only support USB, else ignore
+# newer hiddev are part of the usbmisc class
 SUBSYSTEM==usbmisc, GOTO=up_hid_chkdev
+# only support USB, else ignore
 SUBSYSTEM!=usb, GOTO=up_hid_end
 
 # if usbraw device, ignore
@@ -17,21 +20,31 @@
 ATTRS{idVendor}==03f0, ENV{UPOWER_VENDOR}=Hewlett Packard
 ATTRS{idVendor}==0463, ENV{UPOWER_VENDOR}=Eaton
 ATTRS{idVendor}==047c, ENV{UPOWER_VENDOR}=Dell
+ATTRS{idVendor}==04d8, ENV{UPOWER_VENDOR}=Minibox
 ATTRS{idVendor}==050d, ENV{UPOWER_VENDOR}=Belkin
 ATTRS{idVendor}==051d, ENV{UPOWER_VENDOR}=APC
-ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Liebert
+ATTRS{idVendor}==0592, ENV{UPOWER_VENDOR}=Powerware
+ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power Co., Ltd
+ATTRS{idVendor}==075d, ENV{UPOWER_VENDOR}=iDowell
 ATTRS{idVendor}==0764, ENV{UPOWER_VENDOR}=Cyber Power Systems
 ATTRS{idVendor}==09ae, ENV{UPOWER_VENDOR}=TrippLite
 ATTRS{idVendor}==0d9f, ENV{UPOWER_VENDOR}=PowerCOM
 ATTRS{idVendor}==10af, ENV{UPOWER_VENDOR}=Liebert
 
 # Hewlett Packard
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==0001, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f06, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f08, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f09, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f0a, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe0, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe1, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe2, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe3, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe5, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe6, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe7, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe8, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
 # Eaton
 ATTRS{idVendor}==0463, ATTRS{idProduct}==0001, 
ENV{UPOWER_BATTERY_TYPE}=ups
@@ -40,6 +53,10 @@
 # Dell
 ATTRS{idVendor}==047c, ATTRS{idProduct}==, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
+# Minibox
+ATTRS{idVendor}==04d8, ATTRS{idProduct}==d004, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==04d8, ATTRS{idProduct}==d005, 
ENV{UPOWER_BATTERY_TYPE}=ups
+
 # Belkin
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0375, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0551, 
ENV{UPOWER_BATTERY_TYPE}=ups
@@ -49,15 +66,23 @@
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0910, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0912, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0980, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==050d, ATTRS{idProduct}==0f51, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==050d, ATTRS{idProduct}==1100, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
 # APC
+ATTRS{idVendor}==051d, ATTRS{idProduct}==, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==051d, ATTRS{idProduct}==0002, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==051d, ATTRS{idProduct}==0003, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
-# Liebert
+# Powerware
+ATTRS{idVendor}==0592, ATTRS{idProduct}==0004, 
ENV{UPOWER_BATTERY_TYPE}=ups
+
+# Phoenixtec Power Co., Ltd
 ATTRS{idVendor}==06da, ATTRS{idProduct}==, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
+# iDowell
+ATTRS{idVendor}==075d, ATTRS{idProduct}==0300, 
ENV{UPOWER_BATTERY_TYPE}=ups
+
 # Cyber Power Systems
 ATTRS{idVendor}==0764, ATTRS{idProduct}==0005, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==0764, ATTRS{idProduct}==0501, 

[Nut-upsdev] UPower: 95-upower-hid.rules update

[Arnaud Quette]

Hi Richard and the list,

you'll find attached a patch for 95-upower-hid.rules, which adds:
- the usbmisc filtering, as added in your repo,
- more comments, including one that points at your UPower repo,
- 3 new manufacturers (Minibox, iDowell and Powerware)
- a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM and 2
Liebert)

cheers,
Arnaud
-- 
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
--- upower/rules/95-upower-hid.rules2015-05-29 13:53:23.049748923 +0200
+++ GIThub-NUT/scripts/upower/95-upower-hid.rules   2015-05-29 
13:45:58.097213385 +0200
@@ -1,10 +1,13 @@
 
##
 # Uninterruptible Power Supplies with USB HID interfaces
 #
-# to keep up to date, monitor: 
http://svn.debian.org/wsvn/nut/trunk/scripts/upower/95-upower-hid.rules
+# This file was automatically generated by NUT (nut/tools/nut-usbinfo.pl)
+# to keep up to date, monitor upstream NUT 
https://github.com/networkupstools/nut/commits/master/scripts/upower/95-upower-hid.rules
+# and upstream UPower 
http://cgit.freedesktop.org/upower/tree/rules/95-upower-hid.rules
 
-# only support USB, else ignore
+# newer hiddev are part of the usbmisc class
 SUBSYSTEM==usbmisc, GOTO=up_hid_chkdev
+# only support USB, else ignore
 SUBSYSTEM!=usb, GOTO=up_hid_end
 
 # if usbraw device, ignore
@@ -17,21 +20,31 @@
 ATTRS{idVendor}==03f0, ENV{UPOWER_VENDOR}=Hewlett Packard
 ATTRS{idVendor}==0463, ENV{UPOWER_VENDOR}=Eaton
 ATTRS{idVendor}==047c, ENV{UPOWER_VENDOR}=Dell
+ATTRS{idVendor}==04d8, ENV{UPOWER_VENDOR}=Minibox
 ATTRS{idVendor}==050d, ENV{UPOWER_VENDOR}=Belkin
 ATTRS{idVendor}==051d, ENV{UPOWER_VENDOR}=APC
-ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Liebert
+ATTRS{idVendor}==0592, ENV{UPOWER_VENDOR}=Powerware
+ATTRS{idVendor}==06da, ENV{UPOWER_VENDOR}=Phoenixtec Power Co., Ltd
+ATTRS{idVendor}==075d, ENV{UPOWER_VENDOR}=iDowell
 ATTRS{idVendor}==0764, ENV{UPOWER_VENDOR}=Cyber Power Systems
 ATTRS{idVendor}==09ae, ENV{UPOWER_VENDOR}=TrippLite
 ATTRS{idVendor}==0d9f, ENV{UPOWER_VENDOR}=PowerCOM
 ATTRS{idVendor}==10af, ENV{UPOWER_VENDOR}=Liebert
 
 # Hewlett Packard
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==0001, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f06, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f08, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f09, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f0a, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe0, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe1, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe2, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe3, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe5, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe6, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe7, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1fe8, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
 # Eaton
 ATTRS{idVendor}==0463, ATTRS{idProduct}==0001, 
ENV{UPOWER_BATTERY_TYPE}=ups
@@ -40,6 +53,10 @@
 # Dell
 ATTRS{idVendor}==047c, ATTRS{idProduct}==, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
+# Minibox
+ATTRS{idVendor}==04d8, ATTRS{idProduct}==d004, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==04d8, ATTRS{idProduct}==d005, 
ENV{UPOWER_BATTERY_TYPE}=ups
+
 # Belkin
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0375, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0551, 
ENV{UPOWER_BATTERY_TYPE}=ups
@@ -49,15 +66,23 @@
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0910, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0912, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==050d, ATTRS{idProduct}==0980, 
ENV{UPOWER_BATTERY_TYPE}=ups
+ATTRS{idVendor}==050d, ATTRS{idProduct}==0f51, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==050d, ATTRS{idProduct}==1100, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
 # APC
+ATTRS{idVendor}==051d, ATTRS{idProduct}==, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==051d, ATTRS{idProduct}==0002, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==051d, ATTRS{idProduct}==0003, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
-# Liebert
+# Powerware
+ATTRS{idVendor}==0592, ATTRS{idProduct}==0004, 
ENV{UPOWER_BATTERY_TYPE}=ups
+
+# Phoenixtec Power Co., Ltd
 ATTRS{idVendor}==06da, ATTRS{idProduct}==, 
ENV{UPOWER_BATTERY_TYPE}=ups
 
+# iDowell
+ATTRS{idVendor}==075d, ATTRS{idProduct}==0300, 
ENV{UPOWER_BATTERY_TYPE}=ups
+
 # Cyber Power Systems
 ATTRS{idVendor}==0764, ATTRS{idProduct}==0005, 
ENV{UPOWER_BATTERY_TYPE}=ups
 ATTRS{idVendor}==0764, ATTRS{idProduct}==0501, 

Re: UPower: 95-upower-hid.rules update

[Arnaud Quette]

Hi Bastien,

2015-05-29 14:10 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Fri, 2015-05-29 at 14:09 +0200, Bastien Nocera wrote:
  On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
   Hi Richard and the list,
  
   you'll find attached a patch for 95-upower-hid.rules, which adds:
   - the usbmisc filtering, as added in your repo,
   - more comments, including one that points at your UPower repo,
   - 3 new manufacturers (Minibox, iDowell and Powerware)
   - a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM and
   2
   Liebert)
 
  Could you please split those changes into 3 separate patches?
 
  It would also be useful to include a full URL to the NUT Perl script
  (to a git repository perhaps), so people don't need to check out the
  full repo to update it.

 There's also a few UPS related bugs in:

 https://bugzilla.freedesktop.org/buglist.cgi?component=generallist_id=545920product=upowerresolution=---


23256 https://bugzilla.freedesktop.org/show_bug.cgi?id=23256: not sure,
could be some instability in the UPower / devkit stack. I'll try to check
but no promise, time is missing...
70548 https://bugzilla.freedesktop.org/show_bug.cgi?id=70548: I'll be
checking that one and commenting.


 It would be helpful if you could comment on those (I don't have a UPS
 to test).


would you be interested in getting one?
If so, please contact me back privately, preferably on my @eaton.com
address...

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
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Re: [Nut-upsdev] UPower: 95-upower-hid.rules update

[Arnaud Quette]

Hi Bastien,

2015-05-29 14:10 GMT+02:00 Bastien Nocera had...@hadess.net:

 On Fri, 2015-05-29 at 14:09 +0200, Bastien Nocera wrote:
  On Fri, 2015-05-29 at 13:59 +0200, Arnaud Quette wrote:
   Hi Richard and the list,
  
   you'll find attached a patch for 95-upower-hid.rules, which adds:
   - the usbmisc filtering, as added in your repo,
   - more comments, including one that points at your UPower repo,
   - 3 new manufacturers (Minibox, iDowell and Powerware)
   - a bunch of new devices (7 HP,  1 APC, 1 TrippLite, 2 PowerCOM and
   2
   Liebert)
 
  Could you please split those changes into 3 separate patches?
 
  It would also be useful to include a full URL to the NUT Perl script
  (to a git repository perhaps), so people don't need to check out the
  full repo to update it.

 There's also a few UPS related bugs in:

 https://bugzilla.freedesktop.org/buglist.cgi?component=generallist_id=545920product=upowerresolution=---


23256 https://bugzilla.freedesktop.org/show_bug.cgi?id=23256: not sure,
could be some instability in the UPower / devkit stack. I'll try to check
but no promise, time is missing...
70548 https://bugzilla.freedesktop.org/show_bug.cgi?id=70548: I'll be
checking that one and commenting.


 It would be helpful if you could comment on those (I don't have a UPS
 to test).


would you be interested in getting one?
If so, please contact me back privately, preferably on my @eaton.com
address...

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

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-upsdev] Roadmap to 2.7.3

[Arnaud Quette]

FYI on the added delay


2015-04-16 16:54 GMT+02:00 Arnaud Quette arnaud.que...@gmail.com:




 2015-04-16 14:34 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 16, 2015, at 5:46 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:



 2015-04-15 15:05 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

 Hi Charles,

 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

 cool (bis), I'll check over the day to complete as per my latest merges
 and possibly (if time permits) to publish 2.7.3.


 We should probably add a release checklist to the developer
 documentation, but for now:


 the maintainer guide [1] (not distributed) is more suitable.


 • update version to 2.7.3 in nut/configure.ac

 done

 • create a GPG-signed tag v2.7.3

 done  + a non-signed one (not sure it's worth!)


 Yeah, I guess I meant that we should have a signed tag (v2.7.3) but it
 doesn't need -signed in the name. We only had to do that last time
 because there was already an unsigned v2.7.2 tag.

 • make dist

 done

 • maybe update nut/configure.ac version to 2.7.3.1 or .5?


 not sure to get why .5...


 it's what we did last time :-)


 the history log is also saying so... but still failing to understand the
 jump to .5
 anyway, it's probably too hot here (almost jumped from winter to summer)
 ;)


 My main reason was to create a different name for the tarball in the
 Buildbot snapshot builder. After 2.7.3 is released, I plan to go back to
 the previous way of injecting the Buildbot build number and Git hash into
 the tarball name. (The long filenames in the Java package were preventing
 us from doing this before.)


  so should I really update configure.ac to 2.7.3.1 or?


 Yes, since I don't know how long it will take to reconfigure Buildbot. (I
 would also like to get it to automatically build the website - currently
 that needs to be triggered manually.)


 done to 2.7.3.1


 • push commits and tag

 done

 • update nut/ and ddl/ submodules in nut-website/ (this should update
 the website's version as well)

 WIP, however we should detail the process here:
 either

 - a generic git submodule foreach git pull origin master (I did that one)

 - Vs pulling the matching tags (here 2.7.3 from NUT for ex...), better and 
 more stable

 I suppose we could tag the DDL repository as well.


 done, and will also do for -website
 I've also updated the -website submodules (ddl and nut) using the v2.7.3
 tags




 • add download hashes for tarball


 for hashes and sig:
 make dist-sig
 make dist-hash

  WIP, however access to my Gandi PaaS is underway at Eaton (forgot to
 request that one :-/)
 so a bit more delay in the release publication


 I once started to create a publication script, but... hem can't find it
 back.
 more to resume ;)


 After the new version is tagged, I'll update my Ubuntu PPA.


 cool!
 shouldn't we add it to the Download page?


 It's really more of a temporary solution. Now that our primary Debian
 maintainer is back, all of the packages will be up-to-date, right? /me ducks


 woow, cool, our beloved DD is back?! 8-)
 need a bit more time for that too, slowly ramping up on all (of the many)
 dimensions ;)

 :-)


 access to my hosted PaaS still blocked...


the access to my PaaS hosting NUT is now opened.
While doing a final check, before pushing the release, I realized that I
forgot to rename the link to the previous GPG (1K) key.
I thus had to recreate the 2.7.3 tag, and go again through the release
process.

2.7.3 will be online in a few minutes now...

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Roadmap to 2.7.3

[Arnaud Quette]

2015-04-15 15:05 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

 Hi Charles,

 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

 cool (bis), I'll check over the day to complete as per my latest merges
 and possibly (if time permits) to publish 2.7.3.


 We should probably add a release checklist to the developer
 documentation, but for now:


 the maintainer guide [1] (not distributed) is more suitable.


 • update version to 2.7.3 in nut/configure.ac

 done

 • create a GPG-signed tag v2.7.3

 done  + a non-signed one (not sure it's worth!)

 • make dist

 done

 • maybe update nut/configure.ac version to 2.7.3.1 or .5?


 not sure to get why .5...


 it's what we did last time :-)


the history log is also saying so... but still failing to understand the
jump to .5
anyway, it's probably too hot here (almost jumped from winter to summer) ;)


 My main reason was to create a different name for the tarball in the
 Buildbot snapshot builder. After 2.7.3 is released, I plan to go back to
 the previous way of injecting the Buildbot build number and Git hash into
 the tarball name. (The long filenames in the Java package were preventing
 us from doing this before.)


 so should I really update configure.ac to 2.7.3.1 or?

 • push commits and tag

 done

 • update nut/ and ddl/ submodules in nut-website/ (this should update the
 website's version as well)

 WIP, however we should detail the process here:
either

- a generic git submodule foreach git pull origin master (I did that one)

- Vs pulling the matching tags (here 2.7.3 from NUT for ex...), better
and more stable




 • add download hashes for tarball


 for hashes and sig:
 make dist-sig
 make dist-hash

  WIP, however access to my Gandi PaaS is underway at Eaton (forgot to
request that one :-/)
so a bit more delay in the release publication


 I once started to create a publication script, but... hem can't find it
 back.
 more to resume ;)


 After the new version is tagged, I'll update my Ubuntu PPA.


 cool!
 shouldn't we add it to the Download page?


 It's really more of a temporary solution. Now that our primary Debian
 maintainer is back, all of the packages will be up-to-date, right? /me ducks


woow, cool, our beloved DD is back?! 8-)
need a bit more time for that too, slowly ramping up on all (of the many)
dimensions ;)

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Roadmap to 2.7.3

[Arnaud Quette]

2015-04-16 14:34 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 16, 2015, at 5:46 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:



 2015-04-15 15:05 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

 Hi Charles,

 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

 cool (bis), I'll check over the day to complete as per my latest merges
 and possibly (if time permits) to publish 2.7.3.


 We should probably add a release checklist to the developer
 documentation, but for now:


 the maintainer guide [1] (not distributed) is more suitable.


 • update version to 2.7.3 in nut/configure.ac

 done

 • create a GPG-signed tag v2.7.3

 done  + a non-signed one (not sure it's worth!)


 Yeah, I guess I meant that we should have a signed tag (v2.7.3) but it
 doesn't need -signed in the name. We only had to do that last time
 because there was already an unsigned v2.7.2 tag.

 • make dist

 done

 • maybe update nut/configure.ac version to 2.7.3.1 or .5?


 not sure to get why .5...


 it's what we did last time :-)


 the history log is also saying so... but still failing to understand the
 jump to .5
 anyway, it's probably too hot here (almost jumped from winter to summer) ;)


 My main reason was to create a different name for the tarball in the
 Buildbot snapshot builder. After 2.7.3 is released, I plan to go back to
 the previous way of injecting the Buildbot build number and Git hash into
 the tarball name. (The long filenames in the Java package were preventing
 us from doing this before.)


  so should I really update configure.ac to 2.7.3.1 or?


 Yes, since I don't know how long it will take to reconfigure Buildbot. (I
 would also like to get it to automatically build the website - currently
 that needs to be triggered manually.)


done to 2.7.3.1


 • push commits and tag

 done

 • update nut/ and ddl/ submodules in nut-website/ (this should update the
 website's version as well)

 WIP, however we should detail the process here:
 either

 - a generic git submodule foreach git pull origin master (I did that one)

 - Vs pulling the matching tags (here 2.7.3 from NUT for ex...), better and 
 more stable

 I suppose we could tag the DDL repository as well.


done, and will also do for -website
I've also updated the -website submodules (ddl and nut) using the v2.7.3
tags




 • add download hashes for tarball


 for hashes and sig:
 make dist-sig
 make dist-hash

  WIP, however access to my Gandi PaaS is underway at Eaton (forgot to
 request that one :-/)
 so a bit more delay in the release publication


 I once started to create a publication script, but... hem can't find it
 back.
 more to resume ;)


 After the new version is tagged, I'll update my Ubuntu PPA.


 cool!
 shouldn't we add it to the Download page?


 It's really more of a temporary solution. Now that our primary Debian
 maintainer is back, all of the packages will be up-to-date, right? /me ducks


 woow, cool, our beloved DD is back?! 8-)
 need a bit more time for that too, slowly ramping up on all (of the many)
 dimensions ;)

 :-)


access to my hosted PaaS still blocked...

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Roadmap to 2.7.3

[Arnaud Quette]

Hi Charles,

2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

 cool (bis), I'll check over the day to complete as per my latest merges
 and possibly (if time permits) to publish 2.7.3.


 We should probably add a release checklist to the developer documentation,
 but for now:


the maintainer guide [1] (not distributed) is more suitable.


 • update version to 2.7.3 in nut/configure.ac
 • create a GPG-signed tag v2.7.3
 • make dist
 • maybe update nut/configure.ac version to 2.7.3.1 or .5?


not sure to get why .5...


 • push commits and tag
 • update nut/ and ddl/ submodules in nut-website/ (this should update the
 website's version as well)
 • add download hashes for tarball


for hashes and sig:
make dist-sig
make dist-hash

I once started to create a publication script, but... hem can't find it
back.
more to resume ;)


 After the new version is tagged, I'll update my Ubuntu PPA.


cool!
shouldn't we add it to the Download page?

cheers,
Arno
--
[1]
https://github.com/networkupstools/nut/blob/master/docs/maintainer-guide.txt
-- 
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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Roadmap to 2.7.3

[Arnaud Quette]

Hi Charles,

2015-04-11 21:22 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 8, 2015, at 9:44 AM, Arnaud Quette arnaud.que...@gmail.com wrote:

 - #190: upsd: NSS SSL only working in debug mode = NEED TESTING before
 merging
 Emilien has made a fix and PR  (#199: Initialize SSL after deamonize and
 downgrade to user.)
 The user (Melkor Lord) has ack'ed the fix.
 The fix is indeed trivial but I want to ensure that there is no regression
 for OpenSSL now (though theoretically, there shouldn't be).
 Testing welcome, while waiting to discuss with Emilien to see if he did
 some non-reg testing too.
 Thanks a lot to Emilien for his work on this!


 Just tested Emilien's fix against OpenSSL on Linux Mint 17 - no issues
 there.

 I did notice an issue when trying to test against OpenSSL 1.0.2a on OS X:

 upsd[27047]: Unknown return value from SSL_accept: Resource temporarily
 unavailable

 However, this happens on master as well as the #199 branch, so it is
 technically not a regression. As with the previous bug, it fails safe, and
 does not crop up if SSL is not enabled. I'll file a bug, but I really don't
 want to tackle that until we fix the logging in the SSL code.

 Merged.


cool, thx!
let's see that #202 for 2.7.4.
Note that I've started the tickets triaging for 2.7.4. Feel free to add the
ones you think are worth for it.


 Now, there just remain the Release things, such as NEWS and the like...


 NEWS and UPGRADING should be up to-to-date, except possibly for your
 latest merges. I added UPGRADING notes for the NSS SSL issue.


cool (bis), I'll check over the day to complete as per my latest merges and
possibly (if time permits) to publish 2.7.3.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] CENTOS 6.6 NUT RPM BUILD ISSUES

[Arnaud Quette]

Hey

2015-04-09 1:46 GMT+02:00 Charles Lepple clep...@gmail.com:

 On Apr 8, 2015, at 2:04 PM, Eric Cobb eric_c...@tripplite.com wrote:

 Charles and list,

 If I leave the driver alone it does not eventually start.  It continues to
 report that it is unable to connect.  I have to perform a upsdrvctl stop ;
 upsdrvctl start (I actually just perform a init stop and start so that upsd
 and upsmon both restart) for the driver to actually connect to the ups.

 I have attached an strace of the upsdrvctl start command when it is ran at
 boot time via the init script. I'll let the experts make their assessment
 of what is going wrong.

 Here is the exact line out of the /etc/init.d/ups that i ran (I added -D
 and -u nut on the latest runs, I get the same issue with or without it) Let
 me know if you would like any further symptoms or output.


 start() {
 echo -n $Starting UPS Driver:
 echo UPS DRIVER START  /var/log/upslog
 strace -f -o /var/log/nut/strace.log /usr/sbin/upsdrvctl -D -u nut
 start  /var/log/upslog 21  success || failure
 RETVAL=$?
 Echo

 Eric Cobb
 ekc...@tripplite.com


 The mailing list doesn't accept large attachments, so I attached a gzip'd
 copy of the log in case anyone else wants to take a look.

 It doesn't show timing information, or the content of the URBs, so it is
 hard to tell what the driver is trying to do at any given point.

 I recognize that it is a slight change of the experiment to remove
 upsdrvctl, but could you please start the driver directly in the init
 script with -DDD (path should be in the output of '/usr/sbin/upsdrvctl
 -D'), and redirect that output to a log file? (We had a reason for why
 upsdrvctl does not pass '-D' flags through to the driver, but the reason
 escapes me at the moment.)


simply debugging the driver controller in itself, more than passing the
debug flags to the driver(s)
that said, this point keeps on getting back, on and on.
RFC: we should probably consider for upsdrvctl that -D... is passed to the
driver(s) and -d... for upsdrvctl specifics.
there is no big issue with breaking backward compat here, so if that suits
you all, we can go on implementing that...



 It would also be useful to have the output of dmesg (or at least the
 USB-related subset), in case it has additional information on why
 libusb_get_interrupt() is failing.


2nded, along with your comment that I don't see any difference between
drivers startup process at boot time or later on, WRT to the mentioned
context.
the only point I also see would be some noise (interferences) tied to other
processes looking at USB devices.

Beside from Charles requested test, I would advise you to try increasing
the USB_TIMEOUT value (in usb-common.h) to see if it's just an transient
lack of responsiveness due to some kind of race to access USB devices...

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] On ups.status CHRG/DISCHRG Vs battery.charger.status

[Arnaud Quette]

Hi Charles and the list,


2015-03-30 11:05 GMT+02:00 Arnaud Quette arnaud.que...@gmail.com:

 Hi Charles,


 2015-03-29 0:44 GMT+01:00 Charles Lepple clep...@gmail.com:

 On Mar 25, 2015, at 4:11 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

  1) Keep the legacy CHRG / DISCHRG status bits for ups.status, along
 with the complementary ones for battery.charger.status. And advocate
 (document) for the use of / switch to the latter, that is more suitable for
 publishing such information. All that with an impact on all the NUT driver,
 and a transition period to address that cleanly.

 I prefer this option, for what it's worth. Let's not make ups.status more
 cluttered.


 so do I.
 FYI, the patch I committed for ABM use either one or the other.
 I.e., if ABM support is enabled, status are published on
 battery.charger.status and CHRG/DISCHRG are not pushed to ups.status.
 And conversely if ABM is disabled.


For the sake of completion, I've slightly modified the implementation to
provide backward compatibility.

So, now:
- when ABM is enabled, we both publish the following as per the ABM
information:
* the 5 status bits {charging, discharging, floating, resting, off)
under battery.charger.status
* the 2 historical status bits {CHRG, DISCHRG} under ups.status
- when ABM is disabled, we just publish the 2 historical status bits {CHRG,
DISCHRG} under ups.status, as per UPS.PowerSummary.PresentStatus.{Charging
,Discharging}, as done previously.

I will complete the implementation and related code documentation notes
over the day.
I also plan to create a specific user documentation related to that.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

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-upsdev] Roadmap to 2.7.3

[Arnaud Quette]

Hi Charles and the list

here is an update on 2.7.3

2015-03-20 3:33 GMT+01:00 Charles Lepple clep...@gmail.com:

 On Mar 19, 2015, at 2:00 PM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

 * #158: the branch has been collapsed into one commit, but additional
 documentation (nut-names.txt) is needed:
 https://github.com/networkupstools/nut/commit/00b8c8383a2614fc0bc8df190402b2dc885848a2


 branch updated for nut-names.txt + few minor updates.
 I've also rebased on master, but will need another round (following the 2
 branches pushed below)
 I'm still lagging behind the HW tests, so if you can, let's move on...
 otherwise, I'll do, but not today.
 I'll check whenever possible, but Igor's feedback seems good to me, until
 proven the opposite.


 Arno,

 I saw your commit, but I did not realize it wasn't merged. I think Igor
 has done sufficient testing, so do you want to merge it?


Beside from the known list of tickets for 2.7.3, I had some late additions
tied to Eaton renewed implication in NUT (ABM and Energy Saving, along
with the below ePDU one).
Sorry for the lag and lack of communication Charles... I'm still not in the
optimal zone...


The whole list of remaining things is:

- #197: upsc on ePDU show ups.status only (snmp) = DONE
That one is tricky: as commented, some devices (such as big ePDU) generates
too much info and upsd doesn't keep up in async (default) mode.
For the short run, I've added a *synchronous* flag to address this
exceptional case. That doesn't touch the normal behavior when not used.
Thanks to Daniele for the review and catching my errors :)
Branch (nonblocking_drv) merged.

- #190: upsd: NSS SSL only working in debug mode = NEED TESTING before
merging
Emilien has made a fix and PR  (#199: Initialize SSL after deamonize and
downgrade to user.)
The user (Melkor Lord) has ack'ed the fix.
The fix is indeed trivial but I want to ensure that there is no regression
for OpenSSL now (though theoretically, there shouldn't be).
Testing welcome, while waiting to discuss with Emilien to see if he did
some non-reg testing too.
Thanks a lot to Emilien for his work on this!

- Eaton ABM (Advanced Battery Monitoring): this is something I wanted to
address for ~8 years now. = almost DONE
This is now done in both HID (USB and serial), XCP (USB and serial) and
SNMP.
Eaton XML still remains to be addressed. But I've planned an XML cleanup
ticket for 2.7.4
(#201: Cleanup and complete Eaton XML v3 support / mge-xml code)
I'm still completing a few things, but it's almost good (final commit
pending).

Now, there just remain the Release things, such as NEWS and the like...
I'll be focusing on that now.
So almost good for 2.7.3. The big remainder is still NSS testing WRT
non-reg of OpenSSL.
To me, it's good to go. But considering the previous issue, I want to be
100 % sure this time :)


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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

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-upsdev] New snmp-ups subdriver for Huawei

[Arnaud Quette]

Hi Stuart, Charles and the list,



2015-03-29 14:17 GMT+02:00 Stuart Henderson s...@spacehopper.org:

 On 2015/03/28 20:02, Charles Lepple wrote:
  On Mar 25, 2015, at 9:21 PM, Stuart Henderson s...@spacehopper.org
 wrote:
 
   Hi, the diff inline below adds a new subdriver for snmp-ups to support
   Huawei UPS, based on an observed walk from a UPS5000-E with a few bits
   filled in from the MIBs (copy at http://junkpile.org/HUAWEI_UPS_MIB/).
   Sample output from upsc follows the diff.
 
  Hi Stuart,
 
  Thanks for the patch. It builds cleanly for me, so I have no problems
  merging it.
 
  The only two things that jump out at me could probably be addressed
  with documentation. Is there a low battery alarm? If not, we should
  probably mention somewhere that people will need to either synthesize
  a LB status with one or both of 'override.battery.charge.low' and
  'override.battery.runtime.low'.

 I didn't notice anything that looks like a low battery alarm in the
 Huawei MIB, though it does also return a value in
 UPS-MIB::upsBatteryStatus.0
 so perhaps a LB alarm will be signalled there; I see that in mge-mib.c
 the status appears to be generated from a combination of ietf and private
 MIB but there is a comment FIXME: the below may introduce status
 redundancy,
 that needs to be * adressed by the driver, as for usbhid-ups! so I wasn't
 sure the best approach here.

 Unfortunately it isn't really possible to test low battery in my
 environment,
 I'd need to override the generator autostart/ATS which I don't think I'd
 get approval for (my main aim with this UPS is to use NUT to act as an
 abstraction layer so that it can be monitored alongside a couple of
 more normal UPS, rather than specifically to trigger shutdowns).


first comment:
it would have been great if you used the SNMP subdriver generator [1]
It creates a dump of the whole structure pointed by the sysOID, and help to
track the remaining unimplemented features...


  (Or they can shut down when it first
  transfers to battery, but this sounds like the sort of UPS that would
  keep going for a while.)

 Indeed, it is a bit larger than anything I've dealt with before, you
 may have noticed the battery V in my sample output ;-)

  There also seem to be a few commands in the MIB, but none are
  implemented here. The only ones that people might be expecting are the
  shutdown.reboot and shutdown.stayoff, although I haven't used the SNMP
  driver to see how well those work in general. Not strictly necessary
  to implement, but we should probably take this opportunity to point
  out in the snmp-ups man page that if there are no shutdown.* commands
  listed in the upscmd output, there is a potential for a race condition
  if the power comes back early.

 There's a hwUpsCtrlPowerOff command and a RW hwUpsCtrlPowerOffDelay
 variable, but the mib isn't clear about whether this would be
 shutdown.stayoff or shutdown.return, I'll see if I can find more
 information about this in the manuals.

 I don't see a power-on delay in the vendor mib so I think shutdown.reboot
 may not be possible.

 There is also a battery test command, which would be a bit easier for
 me to test, I'll try and look at that sometime.


also, would be great if you could post (either public/private, but
compressed) or point to the MIB file, for putting on the Protocols page [2]


  Arnaud, as maintainer of snmp-ups, any thoughts here?

 Thanks for the review Charles, and I'd be interested to hear any
 comments from Arnaud.


this version of the SNMP driver is getting too old and not flexible enough.
Keep in mind that there is a rewrite scheduled [3]
However, for now, you may want to have a look at [4]. This implementation
is not perfect, but will give you some ideas.
I still have to find a better way to link and use the commands with the
matching delays.
But it's generally a default behavior of SNMP agent (i.e. first set the
delay, then execute the command)

Thanks for your contribution,
cheers,
Arno
--
[1]
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#snmp-subdrivers
https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-snmp-subdriver.sh
[2] http://www.networkupstools.org/ups-protocols.html
[3] https://github.com/networkupstools/nut/issues/20
[4]
https://github.com/networkupstools/nut/blob/master/drivers/powerware-mib.c#L314
-- 
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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] On ups.status CHRG/DISCHRG Vs battery.charger.status

[Arnaud Quette]

Hi Charles,

2015-03-29 0:44 GMT+01:00 Charles Lepple clep...@gmail.com:

 On Mar 25, 2015, at 4:11 AM, Arnaud Quette arnaud.que...@gmail.com
 wrote:

  1) Keep the legacy CHRG / DISCHRG status bits for ups.status, along with
 the complementary ones for battery.charger.status. And advocate (document)
 for the use of / switch to the latter, that is more suitable for publishing
 such information. All that with an impact on all the NUT driver, and a
 transition period to address that cleanly.

 I prefer this option, for what it's worth. Let's not make ups.status more
 cluttered.


so do I.
FYI, the patch I committed for ABM use either one or the other.
I.e., if ABM support is enabled, status are published on
battery.charger.status and CHRG/DISCHRG are not pushed to ups.status.
And conversely if ABM is disabled.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

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

[Nut-upsdev] On ups.status CHRG/DISCHRG Vs battery.charger.status

[Arnaud Quette]

Hi NUT developers,

part of the 2.7.3 release, we are about to merge the below branch / PR for
the bcmxcp drivers family:
https://github.com/networkupstools/nut/pull/158
https://github.com/networkupstools/nut/tree/pull_158_bcmxcp_rebased

It has introduced the battery.charger.status variable, which is something I
wanted to implement since around 2007.

However, while considering a similar implementation for usbhid-ups, and
thinking a bit more broadly, this new variable tends to collide with the
CHRG / DISCHRG status bits from ups.status, and adding 2 more (floating and
resting).

There, we have 2 options:
1) Keep the legacy CHRG / DISCHRG status bits for ups.status, along with
the complementary ones for battery.charger.status. And advocate (document)
for the use of / switch to the latter, that is more suitable for publishing
such information. All that with an impact on all the NUT driver, and a
transition period to address that cleanly.
2) Add the 2 other status bits (FLOATING and RESTING) for ups.status, still
along with the same new ones for battery.charger.status

I'm personally more in favor of (1), but the long history of NUT makes that
(2) would probably be more suitable. An hybrid approach could also be:
apply (2) (new status bits), and apply the transition of (1).

Feedback and comments warmly welcome.
Going to also push this comment on the PR #158, for the sake of completion.

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-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] UPS commands

[Arnaud Quette]

(sent from my S3... please excuse my brevity)
Le 20 mars 2015 20:02, Rob Groner rgro...@rtd.com a écrit :

 I still have an unset draft answer to your previous mail... but you
seem to have progressed...



 Heh…that’s been known to happen.  J  I have the luxury of relatively
un-interrupted development on this project, so it goes a lot faster now.
Hopefully that lasts…

Hopefully, yes ;)



 Could you please check if usbhid-ups -D ... does list the above HID
data (UPS.PowerSummary.DelayBeforeShutdown DelayBeforeStartup)

 The only case I see is that the base data are missing, since we don't
check if these HID path actually exists...

 Ah, bingo I think.  It sees the two paths, but gives me a “broken pipe”
when trying to retrieve the reports.  I don’t have reports implemented for
those two commands because…well, they should only exist one way, there is
nothing to read from them.  I’ll put in a dummy report for them and see if
that makes it all better.

Not at all!
Grep for these 2 vars in
https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c

You get your answer...
So this is indeed a bug, they should be readable.


 On a side note…I have them implemented in the USB Report descriptor as a
Feature, which I know is R/W.  I tried making them Input and Output, and I
seem to remember each time, it still came back with “broken pipe” as though
it were trying to get the value of that particular data item.  Is one of
those types (Feature, Input, Output) actually correct for these commands?

Feature is for the control pipe, either read or read/write
Notification is for interrupt, similar to snmp traps.
Neither used nor seen pure output but should be conversely similar to
notification...


 answer here:
 
https://github.com/networkupstools/nut/blob/master/drivers/usbhid-ups.c#L1002



 I found it in the code, but I still didn’t understand.  I get it now…it
just calls my delayed command but with a delay of 0.  That’s good to
know…I’ll have to take that value into account, I think I had just been
checking that the delay *wasn’t* zero before.

Just shortcuts to avoid bothering with the immediate versions declaration



 3)  Finally…what is the usefulness of shutdown.stayoff?  It tells
the UPS to shut off its load and not to turn it back on when the power
comes back.  If so…how does the UPS ever know to turn that load back on?
You would have to hook a different PC to the UPS and run nut just to send
the “load.on” command?



 Ok, I kind of get that it’s a use-case or optional feature, and I might
implement that.  I had up to now just figured they would configure their PC
BIOS to handle the power-on event.  But I still have to ask…how does the
UPS ever know to turn its load on again?  When the UPS itself is power
cycled (again)?

Shutdown.return set both offdelay and ondelay.
Search for my previous mails on the topic

 Thanks much for the help Arno

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