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

Arnaud Quette arnaud.quette at gmail.com
Wed Aug 23 12:44:59 UTC 2017

Hi Charles

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

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:

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?"

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

More information about the Nut-upsdev mailing list