Nut upsdev - Aug 2017 - NUT namespace: RFC for new variable addition

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170804/2048714e/attachment.html>

On Aug 4, 2017, at 3:00 AM, Arnaud Quette <arnaud.quette at gmail.com>
wrote:
> 
> Comments and feedback warmly welcome.
> Please however note that I'll be pushing the related commit, since it
seem trivial.
It does sound trivial, but do we have that sort of information for other PDUs,
and if not, how should names be represented in a GUI if outlet.n.name isn't
present?

Also, there were some dstate changes a while back, and I didn't fully
understand the need for them. Weren't they related to the volume of updates
for PDUs? Is that more related to the total number of bytes, or number of
variables? Should we be looking at alternate ways to represent updates, since
the outlet names and descriptions will change so infrequently compared to other
variables?

Hi Charles

thanks for your comments first, and sorry for still being missing on the
list.
I'm still caught in the storm of my personal issues, and the overload at
work...

2017-08-04 13:34 GMT+02:00 Charles Lepple <clepple at gmail.com>:
> On Aug 4, 2017, at 3:00 AM, Arnaud Quette <arnaud.quette at
gmail.com> wrote:
> >
> > Comments and feedback warmly welcome.
> > Please however note that I'll be pushing the related commit, since
it
> seem trivial.
>
> It does sound trivial, but do we have that sort of information for other
> PDUs, and if not, how should names be represented in a GUI if
> outlet.n.name isn't present?
>
outlet.n.desc is a good fallback.
I should also probably clarify in the namespace the .desc can be modified
by the user while .name is static, and (potentially) related to some
physical labelling.

> Also, there were some dstate changes a while back, and I didn't fully
> understand the need for them. Weren't they related to the volume of
updates
> for PDUs? Is that more related to the total number of bytes, or number of
> variables? Should we be looking at alternate ways to represent updates,
> since the outlet names and descriptions will change so infrequently
> compared to other variables?

you're probably referring to the "synchronous" option which is
needed not
to flood the unix socket:
https://github.com/networkupstools/nut/commit/924f69c65cbf3b0a6e975d3a1efef06898f97f36
https://github.com/networkupstools/nut/commit/eb64b76cfda5e30c8c1363c5fe72f989d086c9e0

it's really tied to the volume of bytes pushed through the socket.
I never had time to get back on this, but we may be able to overcome this
more cleanly through getsockopt() / setsockopt(). Then the question would
be "which value to set?"

cheers,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170823/b42eaea4/attachment.html>