[Nut-upsdev] Fwd: [networkupstools/nut] Support for MicroLink APC UPSs (Issue #1426)

[Jim Klimov]

I guess that issue can indeed get closed, especially as there was no
pushback feature-wise about any DOA code. Usually there is an (un)weeding
season in the issue tracker as a yet another release date comes up.

I've added a cross-link to PR #2663 for posterity; I can't elaborate on why
the author chose to pull it down - just don't know. Maybe he worked
somewhere that partnered with APC or had an NDA, and that could be legally
vulnerable compared to a random John Doe making a "more provably"
clean-room implementation.

BTW, I saw your great post summarizing APC models and protocols on apcupsd
list recently - may I scrape that thread into NUT Wiki (or even ask you to
do so more expertly)? :)

Jim

On Thu, Jul 9, 2026, 09:23 Ted Mittelstaedt via Nut-upsdev <
nut-upsdev at alioth-lists.debian.net> wrote:

>
> Almost 2 years Oct 17 2024 ago a PR was proposed to add MicroLink to
> NUT.  That was open for 1 week then closed with a cryptic comment that
> the proposer was talking to the NUT maintainers.
>
> Then a few months ago another PR was proposed with an experimental
> MicroLink driver which was merged:
>
> https://github.com/networkupstools/nut/pull/3406
>
> My question to the list is why is the original PR 1426 still open?
>
> I put a reference to 3406 in 1426 so maybe that will help - but - am I
> correct in that we have so many open issues in NUT these days that
> people who open new issues are NOT bothering to verify if their issue
> was already opened?
>
> In a word, has the issues in NUT's github gotten ....completely overgrown?
>
> Take for an example, an issue that is 13 years old - still open:
>
> https://github.com/networkupstools/nut/issues/20
>
> Last touched by Jim 3 years ago and left open.  But, isn't it completed?
>
> Other repo's have notifications that go out on PRs that go stale.  If
> the original PR has no activity on it then it closes.
>
> I have a hard time believing there's over 900 unique issues in the NUT
> github.
>
> I'm familiar with common ways of coalescing PRs in repos - how would it
> be best done here?
>
> Ted
>
> On 5/20/2022 11:21 AM, Eetu Rasilainen via Nut-upsdev wrote:
> > Hi there,
> >
> > I am the user who opened the GitHub issue regarding APC-MicroLink UPS
> > support.
> >
> > On 5/14/2022 Ted Mittelstaedt wrote:
> >
> > > I'll ask the obvious which is wouldn't it be easier to write a driver
> > > for NUT that would exec python code (or other scripting languages)
> > > that talked to the UPS?
> >
> > official support for Python-based drivers sounds like a great idea. If
> > this was somehow supported I would instantly start working on a
> > MicroLink-driver based on the awesome reverse engineering work
> > provided by GitHub user klaasdc.
> >
> > Shouldn't this be pretty straightforward? I have also tried to start
> > working on a C version, but I failed miserably. This is really not my
> > environment. I guess a good starting point could be Python's "ctypes"
> > module, which allows for calling C routines. Does anybody have any
> > experience with that?
> >
> > And as Ted mentioned, Python bindings for drivers would open up the
> > world for web scrapers and all those fancy things. What are the
> > general thoughts about Python driver bindings?
> >
> > On the other hand I can see that you guys want to keep NUT as small
> > and clean as possible. And especially APC's new MicroLink protocol is
> > rather trivial so technically there is no hard requirement to use a
> > full-blown scripting language for this. It's more of a strategic
> > question whether you'd like to encourage more users to write drivers
> > quickly.
> >
> > So the questions are:
> >
> > #1 Does anybody see Python drivers (or external drivers in general) as
> > a realistic option in the future?
> >
> > #2 Or is anybody willing to work on a native MicroLink driver with my
> > assistance? As I have already mentioned I am not familiar with C, so
> > what I could do is rewrite the current Python MicroLink implementation
> > to match the data structures and data flows expected by NUT. This
> > means I could create a driver.py which contains Python functions like
> > "upsdrv_initinfo", "upsdrv_updateinfo", "instcmd", "setvar", etc. Then
> > somebody would only need to do the 1:1 porting to C.
> >
> > #3 Or is there actually anybody who is accepting the challenge of
> > porting the current MicroLink Python implementation on his/her own? I
> > could still help with testing in that case of course.
> >
> > I have also already thought of using "dummyups" with a file generated
> > by a standalone Python driver, which regularly writes values to a text
> > file. The issue with that is that NUT cannot send any commands to the
> > UPS that way. But the "dummyups" could probably also serve as a hook
> > for external drivers if only it would support setvar/instcmd hooks for
> > those external drivers.
> >
> >
> > Kind regards,
> > Eetu
> >
> > _______________________________________________
> > Nut-upsdev mailing list
> > Nut-upsdev at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
> _______________________________________________
> 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/20260711/2ad920e6/attachment.htm>