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

2021-08-24 Thread 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

2021-08-20 Thread 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

2021-08-12 Thread 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)

2021-08-12 Thread 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)

2021-08-11 Thread 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

2021-08-02 Thread 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