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

[Ted Mittelstaedt]

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