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

[Jim Klimov]

Hello all,

  Note: this was also cross-posted to GitHub issue, where I saw this first
and posted the replies: https://github.com/networkupstools/nut/issues/3369

  One notable point brought up by the discussion is the long-dormant idea
about supporting Unix sockets (or Windows named pipes) as a local non-TCP
transport for the NUT networked protocol; posted it to issue tracker as
https://github.com/networkupstools/nut/issues/3370 - I think it is a more
correct way forward than leeching onto the driver-server socket protocol
which is an implementation detail without stability guarantees.

Hope this helps,
Jim Klimov


On Tue, Mar 24, 2026 at 11:56 PM Kantor, Werner via Nut-upsdev <
nut-upsdev at alioth-lists.debian.net> wrote:

> 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 at 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:
>
>    1. 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?
>    2. Is the protocol behind \\.\pipe\usbhid-ups-<upsname> documented and
>    considered stable enough for a custom client (e.g., for exporting to JSON /
>    monitoring)? If yes, where can I find the specification?
>    3. Is there a recommended non-TCP “local-only” transport or mode for
>    clients (named pipe / Unix-socket equivalent) that is supported by NUT
>    tools?
>    4. In my build, upsc.exe does not accept -D/-DD debug options (it
>    reports “unknown option -D”). Is there another way to debug or trace the
>    client request/response protocol?
>
> Our goal is a local readout (e.g., for Zabbix/monitoring) without exposing
> any network socket. Any guidance on best practices, existing tooling, or
> build/config options would be greatly appreciated.
>
>
>
> Best regards,
> Werner
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20260325/2c543957/attachment.htm>