Roger Price writes:
> On Sun, 2 Jun 2024, Jim Klimov wrote:
>
>> Trying to remember the context: is your book only rendered as a PDF
>> (a "release" of which on GitHub the NUT site currently points to),
>> or are there also HTML renditions to point to this way (to see in a
>> typical browser)?
>
Roger Price writes:
> Hello Jim, I would like to be able to refer to the configuration
> examples without having to point to my own site. But the link at
> https://networkupstools.org/documentation.html points to a github.com
> site which offers the documentation as a download rather than an
>
Jim Klimov writes:
>> "battery voltage is unreasonably high" is a reasonable concept. <...> I
>> would not call it HB, though because that makes it sound parallel to LB,
>> which is about believed remaining capacity, not detection of overcharging
>> failure.
>
> Well, given that a
Jim Klimov via Nut-upsdev writes:
> During discussion at
> https://github.com/networkupstools/nut/pull/2430#discussion_r1592317940 I
> found that while `nut-names.txt` documents the `battery.charge.low` as the
> "Remaining battery level when UPS switches to LB (percent)", there is no
>
Jim Klimov writes:
> Just to clarify: using a different port *is* possible since forever, with
> `LISTEN host port` (as two arguments to the directive); the question was if
> having a way to spell it as one argument as `LISTEN host:port` would solve
> some shortcomings/ease adoption more than
Jim Klimov via Nut-upsdev writes:
> A recent discussion in the issue tracker brought up the idea to allow the
> `LISTEN` keyword to also accept a single "host:port" token (e.g. if there
> is only one argument, with at least one colon, and the last colon is
> followed only by numbers, split it
Jim Klimov via Nut-upsdev writes:
> If you can not get into the (TrueNAS) appliance for larger experiments
> but have a computer or VM (with USB/Serial port pass-through) to spare, it
> may be helpful to build current NUT code base there and test
> support-ability of the device with it, see:
>
Jim Klimov via Nut-upsuser writes:
> A hiccup was reported about validating the tarball signature on some
> systems, so it was reissued from another workstation. Please don't worry :)
Do you mean the signature was re-issued, which is ok, or that the
tarball was re-issued, which is very much
Kelly Byrd writes:
> Thanks for the reply, it looks to me (based on various existing HID-based
> drivers in the NUT source tree) that everyone is just mapping it directly
> with a line like this in a hid_info_t:
> { "battery.runtime", 0, 0, "UPS.PowerSummary.RunTimeToEmpty", NULL,
> "%.0f",
Kelly Byrd writes:
> Looking through a bunch of the code for drivers using HID, It looks like
> everyone is using "ups.powersummary.runtimetoempty" to map to NUT's
> "battery.runtime" variable.
>
> My question for you all is what units ups.powersummary.runtimetoempty is
> supposed to be in? This
Kelly Byrd writes:
> Making progress on this PR. I have question about storing and checking
> state in a subdriver
> HID Power Devices can a "UPS.PowerSummary.CapacityMode" value. According to
> the spec, the values are:
> 0: maH
> 1: mwH
> 2: percent (%)
> 3: Boolean support only (OK or failed)
Kelly Byrd writes:
> Making progress on this PR. I have question about storing and checking
> state in a subdriver
> HID Power Devices can a "UPS.PowerSummary.CapacityMode" value. According to
> the spec, the values are:
> 0: maH
> 1: mwH
> 2: percent (%)
> 3: Boolean support only (OK or failed)
(I have been doing things Other Then Nut for quite a while and had not
updated or tried to build.)
I have updated pkgsrc to 2.8.1 plus the patch sent earlier today.
I installed the package and tested it with a Best Fortress, just
monitoring, but it seems to work fine. (I had previously been
Jim Klimov writes:
> By the way, on the NUT CI farm the libwrap is present on some (though not
> all) systems - covering linux, freebsd, openindiana... and neither
> complained about `sockdebug` :\
>
> What version do you have? Maybe it is some alternate implementation?
Looks like 7.4, as
Jim Klimov writes:
> Thanks, I think it would not hurt to add the variables into the source if
> that helps?
I realized that the package defines --with-dev, which seems obviously
wrong, so I removed that. With that gone, the build no longer includes
sockdebug, so I don't need a patch.
> A bit
I am (belatedly) updating pkgsrc to 2.8.1 (+ bugfix).
(FWIW, I think a 2.8.1.1 or 2.8.2 immediately with the fix is in order.
>From a packaging viewpoint, the effort to update for a release is about
3 minutes plus time to adapt anythhing that has changed. So I'd much
rather have releases more
Also, 2.8.0 is old because 2.8.1 was released 5 days ago. But seriously,
if you want to debug nut, it is best to build nut from the latest source
and turn up debugging. This is not really compatible with AH addon
culture, as I understand it.
___
I stuck in a comment in an issue, but I think we're overdue, picking 6
months as arbitrary.
I just created a snapshot privately. It passes make check on netbsd 9
amd64. I am updating pkgsrc-wip, which involves adjusting a lot of
packages that I believe have been merged (yay!).
I wonder if
I guess the big question is whether variables are under the control of
driver or config or both, and how do we know. It seems best to step
back and assess the semantics and assumptions about what is written
when. Maybe drivers should just write to hw when variable is written.
Or maybe we
Jim Klimov via Nut-upsdev writes:
> While looking at https://github.com/networkupstools/nut/issues/2014
> I understood that I am not sure if currently NUT has a standard way of
> triggering a shutdown based on remaining charge or runtime, if a
> device/driver lacks a `battery.charge.low`
Jim Klimov writes:
> Thanks to everyone for a fruitful discussion, links and ideas.
>
> The result is nearing a merge at
> https://github.com/networkupstools/nut/pull/2013 and seems to not upset CI
> on any platform, including Windows (which behaves funny WRT binding to the
> same host:port as
Jim Klimov via Nut-upsuser writes:
> I've recently found that at least on my test box the `LISTEN *` line had
> only set up an IPv4 `0.0.0.0` listener but not an IPv6 `::0` listener for
> `upsd`.
Interesting. On one system I checked, I have 4 explicit directives for
127.0.0.1, ::1, and the
Jim Klimov via Nut-upsdev writes:
> * https://github.com/networkupstools/nut/issues/1994
> * https://github.com/networkupstools/nut/pull/1995
>
> There are some wrinkles to iron out later (gotta run now), but
> generally I intend to move forward with merging this before long. What
> do you
mateuszx via Nut-upsdev writes:
> At my workplace I have exact UPS config as stated in the subject (APC MGE
> Galaxy 5500 + AP9635CH).
> I have it set up to work with snmp-ups NUT driver.
> Despite many readings from *upsc* command I am not receiving "On Line
> Status" (ups.status OL) nor "On
Jim Klimov via Nut-upsdev writes:
> Nearby there's also a `generic_modbus" name. Wondering if the new driver
> should be (similar to) `generic_gpio`.
sound good.
It would be nice if there were an abstraction layer for various GPIO
access methods, rather than hard-coding linux, even if there is
Jim Klimov writes:
> I don't think there is any particular strategy, at least not one I'd know
> of either :) So it is mostly ad-hoc, to keep smaller verbosity numbers
> reasonably quiet, and sufficient info to see the logic progression at a
> given debug level (e.g. if major milestones of a
I am looking at bestfortress and trying to figure out and fix some
things, which is causing me to try to improve logging first. A few
questions:
0) The developer guide doesn't seem to address any of this, or did I
miss it?
1) It seems upsdebugx prints to stdout instead of syslog if in
Jim Klimov via Nut-upsuser writes:
> The opposite opinion is that programs should be quiet until asked to
> squeak (e.g. by restarting with higher debug verbosity... "that would help
> troubleshooting why the rack went down last week, right!" says the sysadmin
> me).
That's a fair summary but
I maintain unison, which had a vast number of issues, and have whittled
it down to <100. Some are fixed, and some have been closed as:
* requests for support or questions, and not bug reports (by unison
doctrine, should be via user mailinglist instead)
* complaints about packages that
It seems we have crossed the threshold where regular people are better
off with git master vs the most recent formal release. Particularly
because packaging systems package actual releases, that leads to a
release being overdue.
There are infinite things to improve, and 536 open issues. My
My thoughts are:
we have an infinite number of version numbers
it makes sense to, roughly every 6 months to a year, release 2.N+1.0 with
whatever has accumulated after a several-week call for testing, even
if it's not exciting.
2.N.1 etc. can happen if there's something serious and
Jim Klimov via Nut-upsdev writes:
> PR https://github.com/networkupstools/nut/pull/1671 proposes a new
> driver, and adds unreleased pieces of libmodbus to make use of them. I did
> not double-check so far, but allegedly it is from a side branch of the
> project and under GPL.
>
> So I have
Jim Klimov via Nut-upsdev writes:
> https://github.com/networkupstools/nut/issues/1663
>
> https://github.com/networkupstools/nut/issues/1664
>
> Following up from my concerns about (USB) driver restarting with recent
> discussions.
Both of those seem sensible to me.
signature.asc
Sesshoumaru via Nut-upsdev writes:
> The APC units offer a information called “total consumed energy” which
> which is available under OID .1.3.6.1.4.1.318.1.1.1.4.3.6.0 (unit is
> kwhv, value * 100).
>
> As suggested by jimklimov I checked docs/nut-names.txt but found nothing for
> the above
Same syndrome as before, xml validation failure.
git bisect in progress.
___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
Greg Troxel writes:
> I updated git to
>
> bce1d5201679e0dd64a839ceaaf47dc14c3c6a16
>
> and got a build failure in the docs.
>
> The problem seems to be which xmllint says does not follow
> the DTD.
ah, but it is not in upsdrvnut.txt, and maybe a2x created it?
s
I updated git to
bce1d5201679e0dd64a839ceaaf47dc14c3c6a16
and got a build failure in the docs.
The problem seems to be which xmllint says does not follow
the DTD.
I don't see how this can build for anyone else.
Making all in docs
Making all in man
DOC-MAN Generating nut.conf.5
I am taking the tarball I built from rc1 and using it as if released in
pkgsrc. The great news is that it only took me about 15 minutes to
update the package.
I am getting one error:
=> Checking for non-existent script interpreters in ups-nut-2.7.4.1
ERROR: [check-interpreter.mk] The
Jim Klimov via Nut-upsdev writes:
> It is with a [happy] heart that I must proclaim today, that the long
> reign of NUT v2.7.4 is coming to an end. Its anticipated successor of half
> a dozen years, release-in-waiting NUT v2.7.5 has also quietly expired, and
> [won't] be sorely missed. They
On 3/31/22 6:15 AM, Jim Klimov wrote:
> As for the man page (re)builds, there might be a better way to handle
> that, but de-facto there are two sets of target lists in
> docs/man/Makefile.am:
> * man5_MANS (more for other numbers, other formats) that would build
> just the pages needed for your
* make check
When I run make check, the good news is that it seems to pass
everything.
But it looks like it is building man pages that maybe should have been
built during the build.
[snip]
Making check in docs
Making check in man
make check-local
PASSED man-source sanity check
I had a failed build recently, traced to an old nutscan-usb.h. Digging
in, I am pretty sure I had done an objdir build earlier, and found a
bunch of files showed by "git status --ignored". There were the usual
things created by autogen.sh and a bunch of e.g Makefile.in. That's all
ok.
I also
Greg Troxel writes:
> * libusb1/0 both
>
> ../../drivers/dummy-ups.c:349:44: warning: passing argument 4 of
> ‘upscli_list_next’ from incompatible pointer type
> [-Wincompatible-pointer-types]
> cc1: warning: unrecognized command line option ‘-Wno-unknown-warning-opti
Jim Klimov writes:
> Just went online to say that I'd like to release a NUT 2.8.0 (nee 2.7.5)
> soon, or at least an RC1 of that, so another round of community testing
> with current master (and reminders of what missed ideas better get in
> before release) would be great. And saw your
This is a remarkably short list!
* libusb1/0 both
../../drivers/dummy-ups.c:349:44: warning: passing argument 4 of
‘upscli_list_next’ from incompatible pointer type [-Wincompatible-pointer-types]
cc1: warning: unrecognized command line option ‘-Wno-unknown-warning-option’
cc1: warning:
David Niklas writes:
>> I'll change the additional sentence to
>>
>> If the client does not send command STARTTLS to the Attachment Daemon
>> communication continues unencrypted, however an Attachment Daemon may
>> refuse unencrypted communication.
>>
>> How the AD does this is an
Roger Price writes:
> On Mon, 3 Jan 2022, Manuel Wolfshant wrote:
>
>> On 1/3/22 14:17, Roger Price wrote:
>>> I propose adding the following sentence to section 4.2.12:
>>>
>>> If the client does not send command STARTTLS to the Attachment Daemon
>>> communication continues unencrypted.
>>
For background, I'm a longtime nut user and list lurker. I was on a
number of IETF WG mailing lists from 1995 to say about 2015, and
attended some IETF meetings from 1995 to around 1999.
Roger Price writes:
> I have received a comment asking me to add XML encoded responses from
> the server
Jim Klimov writes:
> Just in case, regarding the spin-off topic of Python scripting: note there
> is a sort of binding in NUT sources, as used in GUI app etc.
>
> I am not sure what practical state it is in, e.g. if it may need more
> attention for NUT data points and concepts added in recent
Rob Crittenden writes:
> On 12/1/21 09:52, Edgar Fuß via Nut-upsdev wrote:
>>> I wrote python code, not yet published, that compares to "OL".
>> That will already break in the "OL RB" (online, replace battery) case.
>
> Or in my case currently:
>
> ups.status: ALARM OL RB
Thanks to both of you
Tom Li writes:
> There seems to be a misunderstanding here. The original proposal doesn't
> change ups.status=OL at all. Instead, it merely appends an additional
> keyword "ECO" after "OL", i.e. ups.status="OL ECO". Since ups.status
> is already a space-separated list of keywords [1]. It
Jim Klimov via Nut-upsdev writes:
>> The basic standardization items needed are:
>
>1. A ups.status flag for ECO mode, currently there's no standard. I
>looked around the codebase and found many drivers already use the flag OL
>ECO, so I think we could settle on that.
> - But
By way of introduction:
I work on pkgsrc, used on NetBSD, illumos/smartos/etc., and also lots of
others (mac, FreeBSD, AIX, Linux).
I've been running nut for a long time, on 2 NetBSD systems with a Best
Power Fortress 660. (That was a great UPS to buy in 1995, and with
new batteries
53 matches
Mail list logo
