[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

[Charles Lepple]

Post by Arnaud Quette
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?

[Arnaud Quette]

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

Post by Arnaud Quette

Post by Arnaud Quette
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.

Post by Arnaud Quette
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

[Arnaud Quette]

Hi all,

here is another variable addition, related to iPDU, that I'd like to make:
outlet.group.n.color | Color of outlet group (hex code) |
#daa520

For the sake of completion, Eaton ePDU outlet groups are identified with a
color code on the device itself:
Loading Image...

Here the first group (A) has a yellow color, and the second group (B) has a
blue color.

This color is provided by the device through its communication protocols
(WiP for SNMP).
And there is a need to provide this information in order to display the
outlets groups with its related color in UI.

Comments and feedback warmly welcome.

cheers,
Arno