Nut upsdev - Jan 2023 - Proposing a "driver.state" entry for nut-names

Hello all,

  While working on possible solutions to the problem of monitoring
identical-looking USB devices (which currently NUT treats as one matched
device which is busy so goodbye), I wanted to separate handling of
"busy"
errors as fatal or optionally-no depending on whether the driver is being
initialized vs. running in the regular loop.

  In the end, the solution for USB init landed elsewhere, but the
driver-state tracking mechanism was made and tested, and can generally help
in field troubleshooting (log reading, etc.) as well as queries with NUT
clients (is driver stalled in updateinfo for too long?..)

  Since this feature also proposes to extend the schema of valid
"nut-names", I bring it up for community discussion. Unless someone is
strongly against it (including the choice of wording for the state names,
though they are arguably "opaque strings" - but if someone would like
to
process them, it makes sense to set some standard/pattern too), I hope to
merge this, say, after the weekend.

  See https://github.com/networkupstools/nut/pull/1771/files for the
proposed changes, and https://github.com/networkupstools/nut/pull/1770 for
"screenshots" including those reports like

   0.000672     [D5] send_to_all: SETINFO driver.state "init.device"
   ...
   0.425455     [D5] send_to_all: SETINFO driver.state "cleanup.exit"

Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230105/3f76965c/attachment.htm>