Reading UPS variables on Windows without TCP/upsd (direct Named Pipe / local-only access?

[Weruneru]

Hello NUT developers,

I’m using NUT 2.8.4 (Windows snapshot, mingw64) with an Eaton 5SC UPS. The driver is started as:
usbhid-ups.exe -a eaton5sc
and it reports: Listening on named pipe \.\pipe\usbhid-ups-eaton5sc

At the moment I can reliably read values by running upsd bound to localhost (127.0.0.1:3493) and then querying with upsc eaton5sc@127.0.0.1. However, due to security/policy requirements we would like to avoid any TCP interface entirely (even if it’s localhost-only) and instead read the data strictly locally.

Could you please advise on the following:

On Windows, is there an officially supported way to query UPS variables without running upsd, e.g., by talking directly to the driver state via the named pipe?

Is the protocol behind \.\pipe\usbhid-ups- documented and considered stable enough for a custom client (e.g., for exporting to JSON / monitoring)? If yes, where can I find the specification?

Is there a recommended non-TCP “local-only” transport or mode for clients (named pipe / Unix-socket equivalent) that is supported by NUT tools?

My goal is a local readout for monitoring without exposing any network socket. Any guidance on best practices, existing tooling, or build/config options would be greatly appreciated.

Best regards,
Werner

MAINTAINER NOTE: Cross-linking with equivalent mailing thread: https://alioth-lists.debian.net/pipermail/nut-upsdev/2026-March/008210.html

[jimklimov]

Hello, currently the officially supported NUT protocol is TCP-based, with an actual protocol behind it as published in https://www.rfc-editor.org/info/rfc9271 - with authentication, SSL, timeouts, bells and whistles.

• https://github.com/networkupstools/nut/blob/master/docs/net-protocol.txt
• https://networkupstools.org/docs/developer-guide.chunked/net-protocol.html

For chatter between drivers and the locally running data server (which exposes TCP on the other side to further clients - including upsc which can now output JSON, and local or remote upsmon for shutdowns and other reactions to events), there is also a protocol, but it evolves as a private interface between components of the project. So I'd treat it as an implementation detail that can come and go unannounced.

• Fun fact: the "state path" variables in build configuration and docs refer to the older ages, when drivers as standalone programs saved state into text files, and upsd looped to read them. This was not kind to storage I/O, so sockets came along (also allowing for dialog).

For example, in recent releases it was (ab?)used to also have drivers talk to each other (e.g. a new instance to tell the old one to reload configs or exit), and for upsdrvctl to check on the living drivers.

• In POSIX builds, daemons can send signals to each other (e.g. to initiate a reload), although with little fidelity - no arguments, no feedback, potentially a very limited amount of signal numbers may be available. In Windows builds, signals are not a concept at all, at least not in a way that easily maps to POSIX definition - named pipes and similar tricks are the way of inter-process communications instead. So one thing led to another, and some daemons (e.g. drivers and their manager) try/prefer socket dialogs rather than fire-and-forget signals.

It is probably happenstance-stable (as in maybe adding new keywords, not removing old ones, at least over the few past years' time), but with no guarantees to external consumers. There is not even a command to get the version or listing of supported tokens.

• https://github.com/networkupstools/nut/blob/master/docs/sock-protocol.txt
• https://networkupstools.org/docs/developer-guide.chunked/sock-protocol.html

Technically I suppose the longer dialogs have the capability of wedging the drivers (if you begin writing something to the socket and do not break off with end of line or connection closing), which is another reason to not expose it to "random" third-party code.

All in all, I think it could be more flexible and safe to add another socket type support to upsd and libupsclient (and other client bindings) to talk between standard NUT data server and clients over a Unix socket or Named pipe, similarly to how e.g. PgSQL and MySQL permit. Just another transport for same protocol between same programs.

NOTE also that in POSIX builds this is handled by "local Unix sockets", with the nearest equivalent commonplace in Windows being named pipes. I think there were certain differences (e.g. access in Unix/Linux is protected by filesystem permissions), and the NUT for Windows code base is known to not be 100% equivalent to POSIX code base (some spots are stubs and should debug-log as such), so this might pop up in practical works about this. If something bites you, PRs to fix are welcome :)

Pipe/socket names like usbhid-ups-eaton5sc are constructed as <driver name>-<ups.conf section name>.

If you do want to dive into this, coding-wise https://github.com/networkupstools/nut/blob/master/drivers/upsdrvquery.c and https://github.com/networkupstools/nut/blob/master/drivers/upsdrvquery.h may help (the relatively separated client library for low-level socket protocol dialog establishment and tear-down, including TRACKING of sent commands so your client gets the response that it was handled somehow on the other side); you can find ways to use the methods from this file elsewhere in NUT sources.

For scripting and troubleshooting, clients like socat, netcat etc. can be useful (availability depending on the platform, although many are quite portable). In-tree there is a server/sockdebug(.exe) build product, backed by https://github.com/networkupstools/nut/blob/master/server/pipedebug.c (WIN32 source) and https://github.com/networkupstools/nut/blob/master/server/sockdebug.c (POSIX source) with a simple CLI interface to find the <driver name>-<ups.conf section name> connection in the way appropriate for the current platform.

[jimklimov]

As for "guidance on build and tools", see https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests and the linked page with dependencies for different platforms.

For Windows builds, there is semi-native support well-tested with MSYS2 (you can see a concise path from source to product in appveyor.yml), and cross-build from Linux with mingw. These two mingw distributions did slightly differ in availability of third-party libraries and tools (IIRC net-snmp is not packaged and has to be custom-built for one of those).

For developer iteration loops, ci_build.sh offers an easy but "opinionated" way to do ./autogen.sh && ./configure.sh ... && make -j that speeds up at least my daily routine across a dozen OSes when called without arguments (and automates scenarios which CI tests do there, so I can easily try to reproduce failures on build agents).

[jimklimov]

As you asked in e-mail. upsc (and some other simple clients) indeed does not currently support a -D option, maybe will in the future releases. For the time being, all NUT programs with debug logging ability should honour a NUT_DEBUG_LEVEL=... environment variable (practical verbosity numbers dial up to 6).