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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20260324/b7f09e5e/attachment.htm>

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>