similar to: Many open green PRs in NUT, wanna merge?

Hello all, I think there was a very good reply about an Arduino-based controller for a DIY UPS here. The project you posted to, with an Arduino presenting as a Megatec protocol server, also seems interesting. Here I'd like to reply to one point not covered before - DMF. As a short and quick reply - unfortunately no, you can not use it with stock upstream NUT at the moment, and not for

Hello all, Now that I am subscribed to the list I can reply at last :) Kelly, thank you for the comprehensive write-up and pointers to sources and the Arduino lib and example. This took me into a rabbit hole and I've spent entirely too many hours browsing through the NUT sources and USB/HID/PowerDevice specs. Jim, thanks for the comprehensive write-up and all the work you do on NUT. This

Looks very great, thanks for writing this! I gather you'd port this to the Wiki page you've started, too? A couple of comments: > So I run a NUT server on a Raspberry PI which is connected via USB to my DIY-NAS Arduino. DIY-UPS? > See drivers/arduino-hid.c for the list of supported IDs... Since NUT v2.8.1 [PR #1369], the `usbhid-ups` driver allows the user to specify a

Ha! I got several on and off list requests for details, so I'll give a bunch of details here and then maybe I can move this to a wiki page others can help edit. WARNING! WARNING! WARNING! Be careful! My implementation required opening up high power components, and dealing with 120VAC mains power and high currents on 12VDC. If you decide to tackle any of this yourself, you need to understand

Hello all, Somewhat in relation to FOSDEM as a nice point on the calendar, and largely to address the lags we've had with publication of HCL and DDL information, and also as a side project of preparing for a new release (that should better list the currently known compatible hardware), the NUT website generation approach was changed. For the past years, https://networkupstools.org/ served

Hello all, Somewhat in relation to FOSDEM as a nice point on the calendar, and largely to address the lags we've had with publication of HCL and DDL information, and also as a side project of preparing for a new release (that should better list the currently known compatible hardware), the NUT website generation approach was changed. For the past years, https://networkupstools.org/ served

On 5/16/24 08:59, Jim Klimov via Nut-upsuser wrote: > I agree with earlier posters, such documentation can help future > tinkerers. There is probably more than just one to hold the hand and > walk through the ordeals :) > > Perhaps a new page at https://github.com/networkupstools/nut/wiki > <https://github.com/networkupstools/nut/wiki> can be a good location... >

I agree with earlier posters, such documentation can help future tinkerers. There is probably more than just one to hold the hand and walk through the ordeals :) Perhaps a new page at https://github.com/networkupstools/nut/wiki can be a good location... Jim On Thu, May 16, 2024 at 1:29?PM Bill Gee <bgee at campercaver.net> wrote: > Hi Kelly - > > As an Arduino nerd, I am

On June 11, 2017 8:58:11 AM GMT+02:00, Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote: >On 10 June 2017 23:26:47 EEST, Tim Dawson <tadawson at tpcsvc.com> wrote: >>Build from source, and done . . . wasting your time looking for a less >>out of date RPM is pointless. . . RPM, .deb, etc are almost always >>downrev. . . >> >>- Tim >>

On Wed, Jan 22, 2020 at 11:24 PM David Greene <greened at obbligato.org> wrote: > Christian Kühnel via llvm-dev <llvm-dev at lists.llvm.org> writes: > > >>> In Github pull requests there is always a git commit that you can just > >>> feed to the build server. And you can be sure of what really gets > merged. > >>> You review, build and test

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Krzysztof Parzyszek via llvm-dev > Sent: Monday, October 03, 2016 10:40 AM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Require PRs for XFAILing tests > > On 10/3/2016 12:21 PM, Robinson, Paul via llvm-dev wrote: > > As David Blaikie mentioned,

Hi Kelly - As an Arduino nerd, I am interested in this! I am sure others on the list would be interested. If nothing else, it would be nice to have some documentation in the archives. I assume you set it up as an online system rather than a standby system. Right? If true, then the choice of inverter is fairly critical. It has to be bomb-proof reliable. What did you choose for battery

Hello LLVM-Dev, The other day as I was digging through lldb’s test suite I noticed they support something kinda neat. In their python test harness, the attribute they use to denote expected failures supports a parameter for specifying the bug number. This got me thinking. I believe that any test that is marked XFAIL is a bug, and we can use LIT to enforce that. So I wrote a patch

Thanks again for all the suggestions. For now I've prepared draft PRs, mostly to map out where the changes are needed - based on my earlier work with the originally proposed terminology. Now that we know where to change it, should not be too great a hassle to replace again by some other choice... subordinate was a bit too long to type :) To make the election of team choice more simple, I

Thanks again for all the suggestions. For now I've prepared draft PRs, mostly to map out where the changes are needed - based on my earlier work with the originally proposed terminology. Now that we know where to change it, should not be too great a hassle to replace again by some other choice... subordinate was a bit too long to type :) To make the election of team choice more simple, I

> -----Original Message----- > From: Alex Bradbury [mailto:asb at asbradbury.org] > Sent: Saturday, October 01, 2016 1:06 PM > To: Robinson, Paul > Cc: Renato Golin; Chris Bieneman; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Require PRs for XFAILing tests > > On 28 September 2016 at 19:58, Robinson, Paul via llvm-dev > <llvm-dev at lists.llvm.org>

FYI: PR https://github.com/networkupstools/nut/pull/1328 adds handling of `PRIMARY` alias to `MASTER` on protocol side, hopefully completing the puzzle for issue #840. Reviews and testing would be welcome :) On Sun, Mar 14, 2021, 00:34 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Thanks again for all the suggestions. > > For now I've prepared draft PRs, mostly to map out

FYI: PR https://github.com/networkupstools/nut/pull/1328 adds handling of `PRIMARY` alias to `MASTER` on protocol side, hopefully completing the puzzle for issue #840. Reviews and testing would be welcome :) On Sun, Mar 14, 2021, 00:34 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Thanks again for all the suggestions. > > For now I've prepared draft PRs, mostly to map out

Hello, I found out about NUT just days ago while searching for a solution for my home setup. After some digging through the interwebs, I come to you with questions. I'm putting together a DIY 12V UPS, very similar to what this guy did: [1] https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html The objective is to keep a bunch of mini PCs and network gear

On Thu, 16 Jan 2020 at 19:10, David Blaikie <dblaikie at gmail.com> wrote: > Can you point to examples of that - where Phab links have been used to express non-mechanically-dependent patches? Not at the top of my head, but since that's not what we're talking about, I'll go to the next point. > Approval order isn't commit order - I'm more than happy to approve a