From gdt at lexort.com  Wed May  1 01:10:53 2024
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 30 Apr 2024 20:10:53 -0400
Subject: [Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to
 support host-colon-port (as single token)
In-Reply-To: <D22A1725-BBE3-40F7-96D7-B1DC77755C46@tpcsvc.com> (Tim Dawson's
 message of "Tue, 30 Apr 2024 11:43:19 -0400")
References: <CAJYg8vK8d+CRrYJikAGKNg+uwD95wLB9ZT8wwB8v05JPq3_0XQ@mail.gmail.com>
 <rmiplu8pcz2.fsf@s1.lexort.com>
 <CAJYg8vJ2f0bFBHAvH+Fjdp+yJDhc8W2QGwJTQyY+Q_Uhrarefg@mail.gmail.com>
 <rmijzkgnvkf.fsf@s1.lexort.com>
 <D22A1725-BBE3-40F7-96D7-B1DC77755C46@tpcsvc.com>
Message-ID: <rmizftagzn6.fsf@s1.lexort.com>

Tim Dawson <tadawson at tpcsvc.com> writes:

> LISTEN 1.2.3.4 2.3.4.5 987 
>
> is a mess . . . You either need to specify the default port number, or

agreed that this method is a mess!

But we have "just use multiple listen statements" which is
straightforward.

I am not really averse to having a format that is a more familiar idiom.
What I don't like is having two ways to do it over the long term, so I'd
want one to be deprecated and throw a warning and have a grace period.
Then the quesion is if making everybody change over those perhaps 2
years is worth the gain in clarity for the other people over the
indefinite glorious future.  That's a tough case to make either way.

Before doing this, I'd want to see a survey of the config grammers of
many other daemons to find out what is really common.

As an example, postfix lets you specify interfaces to listen on, and
then has ports in a different file.   So you can't have arbitrary
addr/port pairs; you have a list of addrs and a list of ports and you
get the crossproduct, it seems.   And then check out nginx:

        listen          443 ssl;
        listen          [::]:443 ssl;

which is spectacular in its implicit INADDR_ANY and : while having it
manifest for v6.


From nut-list-postkasten at 21347.de  Thu May  2 08:05:26 2024
From: nut-list-postkasten at 21347.de (Alexander Hofmann)
Date: Thu, 2 May 2024 09:05:26 +0200
Subject: [Nut-upsuser] Possibility to set NUT drivers to "monitor only"?
Message-ID: <04fa16a2-28ab-42da-8bb2-2cde63c19341@21347.de>

Dear all,

I might have a somewhat strange question (which might arise from my 
[rather unusual?] use case, see below): Is it possible to put the 
"blazer_usb" driver (or NUT in general) to something like a "read only" 
or "monitor only" mode in respect to the communication with the 
hardware? The idea would be to not allow NUT to switch off the power at 
the UPS at all.

Currently, I disabled the "KILLPOWER" switch, so that "upsdrvctl 
shutdown" is not called when the monitoring system is shut down (that's 
what I read in all the guides I could find online, and the only thing 
related in the manpages AFAIK). But I'm not sure what else to disable or 
change. So I though, if there's the ability to disable "control" to the 
UPS entirely at driver level, this would be the most "permanent" 
solution to make sure no "accident" occurs?


If you have another Idea, here's the "real" problem:

I'm monitoring a UPS (FSP "Clipper", working with driver blazer_usb) 
that's controlling power to a inert-gas glovebox-system in a laboratory, 
with some additional "support" hardware. The goal is to record power 
usage and lifetime data of the UPS 1st, shutdown on power loss 2nd. The 
system actually has no means to be "safely shutdown" in an automated 
way, so most of the usual "protocols" to follow for servers or storage 
or... do not apply to the system itself. I can of course control other 
devices or shutdown stuff that's not mandatory to reduce power usage. 
Thus: I might issue shutdown commands to PCs, power strips etc. powering 
measurement equipment, or the monitoring system, but will keep the "main 
thing" running as long as the UPS hardware can handle it (at that time, 
all other "intelligent" devices are already off, including NUT itself, 
at least that's the plan). Such an event occurs maybe once a year, if at 
all...

So far, I think disabling UPS shutdown at system shutdown is the only 
thing I really need, but as the system is rather crucial to our 
workflow, I wanted to make sure. The more changes I have to make to the 
"default" configuration, the more to check at each update...

Thank you for your patience in reading my story :-)


Best regards,

Alex




From jimklimov+nut at gmail.com  Thu May  2 10:57:22 2024
From: jimklimov+nut at gmail.com (Jim Klimov)
Date: Thu, 2 May 2024 11:57:22 +0200
Subject: [Nut-upsuser] Possibility to set NUT drivers to "monitor only"?
In-Reply-To: <04fa16a2-28ab-42da-8bb2-2cde63c19341@21347.de>
References: <04fa16a2-28ab-42da-8bb2-2cde63c19341@21347.de>
Message-ID: <CAJYg8vJ8WyRJjbU+hu_BGW1SNDRckmLseXhHtCEH6XWz=oEW2w@mail.gmail.com>

Hello, and welcome to the NUT community! :)

  On one hand, it would generally help to read up the documentation about
NUT architecture, seeing as it is a crucial part of your systems' uptime
and data integrity.

  On another hand, for this particular use-case: it is quite possible to
set up monitoring-only systems which only inform you if some *other* NUT
data server has had interesting situations, or mixed-monitoring systems for
that matter.

  The software part of NUT responsible for actually shutting down a
computer is typically the `upsmon` client, whose `SHUTDOWNCMD` setting (in
`upsmon.conf`) defines how to go about the routine. NUT drivers do interact
with devices (and can send power-off commands to supported UPSes in case of
`killpower` flag being processed), but they do not make the decision to do
so - the `upsmon` client running on that box does, based on it being the
primary (ex-master) system for the UPS meaning it has the physical media to
talk to the device (serial/USB/networked/...). An `upsmon` client running
in "primary/master" mode on the system that can actually talk to the UPS
would have a `MONITOR` line with specification of how many PSUs of this
server that UPS feeds (1 or more) and a `MINSUPPLIES` line to specify how
many PSUs (1+) should be fed to consider the server capable of running
indefinitely as far as having power is the question. On redundant servers
you can have something like "1 of 2 is okay", or "1..3 out of 4" depending
on the blade chassis population, etc. When the situation gets critical, a
"primary" `upsmon` client would set the local `KILLPOWER` flag which would
cause the OS late-shutdown scripts (where supported) to run a driver
instance talk to the UPS again and tell it to power off and recycle when
safe to do so (and thus avoid the "power race condition" where the wall
power comes back while half of your rack is already down, so it sits for
days waiting for someone to power all servers back on).

  As far as monitoring-only clients are concerned, you can set the argument
to the MONITOR line un `upsmon.conf`, that the tracked (and often
"secondary") UPS feeds zero (0) power sources of this particular monitoring
box, which makes sense if it sits in a different building for example.
Orthogonally to that, you can also specify `MINSUPPLIES 0` to a purely
monitoring system, impacting the trigger for its own shutdown (as long as
that many PSUs are fed, all is okay). In a mixed system, having its own
UPS(es) and monitoring some remote NUT data servers, you would have a mix
of "local" MONITOR lines with a non-zero count of PSUs fed (summing up to
your MINSUPPLIES for a healthy uptime) and other MONITOR lines with the
zero amount of fed PSUs.

Hope this helps,
Jim Klimov


On Thu, May 2, 2024 at 9:22?AM Alexander Hofmann via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> Dear all,
>
> I might have a somewhat strange question (which might arise from my
> [rather unusual?] use case, see below): Is it possible to put the
> "blazer_usb" driver (or NUT in general) to something like a "read only"
> or "monitor only" mode in respect to the communication with the
> hardware? The idea would be to not allow NUT to switch off the power at
> the UPS at all.
>
> Currently, I disabled the "KILLPOWER" switch, so that "upsdrvctl
> shutdown" is not called when the monitoring system is shut down (that's
> what I read in all the guides I could find online, and the only thing
> related in the manpages AFAIK). But I'm not sure what else to disable or
> change. So I though, if there's the ability to disable "control" to the
> UPS entirely at driver level, this would be the most "permanent"
> solution to make sure no "accident" occurs?
>
>
> If you have another Idea, here's the "real" problem:
>
> I'm monitoring a UPS (FSP "Clipper", working with driver blazer_usb)
> that's controlling power to a inert-gas glovebox-system in a laboratory,
> with some additional "support" hardware. The goal is to record power
> usage and lifetime data of the UPS 1st, shutdown on power loss 2nd. The
> system actually has no means to be "safely shutdown" in an automated
> way, so most of the usual "protocols" to follow for servers or storage
> or... do not apply to the system itself. I can of course control other
> devices or shutdown stuff that's not mandatory to reduce power usage.
> Thus: I might issue shutdown commands to PCs, power strips etc. powering
> measurement equipment, or the monitoring system, but will keep the "main
> thing" running as long as the UPS hardware can handle it (at that time,
> all other "intelligent" devices are already off, including NUT itself,
> at least that's the plan). Such an event occurs maybe once a year, if at
> all...
>
> So far, I think disabling UPS shutdown at system shutdown is the only
> thing I really need, but as the system is rather crucial to our
> workflow, I wanted to make sure. The more changes I have to make to the
> "default" configuration, the more to check at each update...
>
> Thank you for your patience in reading my story :-)
>
>
> Best regards,
>
> Alex
>
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240502/bac34ed2/attachment.htm>

From jimklimov+nut at gmail.com  Thu May  2 10:59:44 2024
From: jimklimov+nut at gmail.com (Jim Klimov)
Date: Thu, 2 May 2024 11:59:44 +0200
Subject: [Nut-upsuser] Possibility to set NUT drivers to "monitor only"?
In-Reply-To: <CAJYg8vJ8WyRJjbU+hu_BGW1SNDRckmLseXhHtCEH6XWz=oEW2w@mail.gmail.com>
References: <04fa16a2-28ab-42da-8bb2-2cde63c19341@21347.de>
 <CAJYg8vJ8WyRJjbU+hu_BGW1SNDRckmLseXhHtCEH6XWz=oEW2w@mail.gmail.com>
Message-ID: <CAJYg8vLDut=dkEAduowMQAQ0OVwbtCvOmiC+PgNFSosA5S=FFA@mail.gmail.com>

FWIW, added this to Wiki:
https://github.com/networkupstools/nut/wiki/Monitoring%E2%80%90only-NUT-clients

On Thu, May 2, 2024 at 11:57?AM Jim Klimov <jimklimov+nut at gmail.com> wrote:

> Hello, and welcome to the NUT community! :)
>
>   On one hand, it would generally help to read up the documentation about
> NUT architecture, seeing as it is a crucial part of your systems' uptime
> and data integrity.
>
>   On another hand, for this particular use-case: it is quite possible to
> set up monitoring-only systems which only inform you if some *other* NUT
> data server has had interesting situations, or mixed-monitoring systems for
> that matter.
>
>   The software part of NUT responsible for actually shutting down a
> computer is typically the `upsmon` client, whose `SHUTDOWNCMD` setting (in
> `upsmon.conf`) defines how to go about the routine. NUT drivers do interact
> with devices (and can send power-off commands to supported UPSes in case of
> `killpower` flag being processed), but they do not make the decision to do
> so - the `upsmon` client running on that box does, based on it being the
> primary (ex-master) system for the UPS meaning it has the physical media to
> talk to the device (serial/USB/networked/...). An `upsmon` client running
> in "primary/master" mode on the system that can actually talk to the UPS
> would have a `MONITOR` line with specification of how many PSUs of this
> server that UPS feeds (1 or more) and a `MINSUPPLIES` line to specify how
> many PSUs (1+) should be fed to consider the server capable of running
> indefinitely as far as having power is the question. On redundant servers
> you can have something like "1 of 2 is okay", or "1..3 out of 4" depending
> on the blade chassis population, etc. When the situation gets critical, a
> "primary" `upsmon` client would set the local `KILLPOWER` flag which would
> cause the OS late-shutdown scripts (where supported) to run a driver
> instance talk to the UPS again and tell it to power off and recycle when
> safe to do so (and thus avoid the "power race condition" where the wall
> power comes back while half of your rack is already down, so it sits for
> days waiting for someone to power all servers back on).
>
>   As far as monitoring-only clients are concerned, you can set the
> argument to the MONITOR line un `upsmon.conf`, that the tracked (and often
> "secondary") UPS feeds zero (0) power sources of this particular monitoring
> box, which makes sense if it sits in a different building for example.
> Orthogonally to that, you can also specify `MINSUPPLIES 0` to a purely
> monitoring system, impacting the trigger for its own shutdown (as long as
> that many PSUs are fed, all is okay). In a mixed system, having its own
> UPS(es) and monitoring some remote NUT data servers, you would have a mix
> of "local" MONITOR lines with a non-zero count of PSUs fed (summing up to
> your MINSUPPLIES for a healthy uptime) and other MONITOR lines with the
> zero amount of fed PSUs.
>
> Hope this helps,
> Jim Klimov
>
>
> On Thu, May 2, 2024 at 9:22?AM Alexander Hofmann via Nut-upsuser <
> nut-upsuser at alioth-lists.debian.net> wrote:
>
>> Dear all,
>>
>> I might have a somewhat strange question (which might arise from my
>> [rather unusual?] use case, see below): Is it possible to put the
>> "blazer_usb" driver (or NUT in general) to something like a "read only"
>> or "monitor only" mode in respect to the communication with the
>> hardware? The idea would be to not allow NUT to switch off the power at
>> the UPS at all.
>>
>> Currently, I disabled the "KILLPOWER" switch, so that "upsdrvctl
>> shutdown" is not called when the monitoring system is shut down (that's
>> what I read in all the guides I could find online, and the only thing
>> related in the manpages AFAIK). But I'm not sure what else to disable or
>> change. So I though, if there's the ability to disable "control" to the
>> UPS entirely at driver level, this would be the most "permanent"
>> solution to make sure no "accident" occurs?
>>
>>
>> If you have another Idea, here's the "real" problem:
>>
>> I'm monitoring a UPS (FSP "Clipper", working with driver blazer_usb)
>> that's controlling power to a inert-gas glovebox-system in a laboratory,
>> with some additional "support" hardware. The goal is to record power
>> usage and lifetime data of the UPS 1st, shutdown on power loss 2nd. The
>> system actually has no means to be "safely shutdown" in an automated
>> way, so most of the usual "protocols" to follow for servers or storage
>> or... do not apply to the system itself. I can of course control other
>> devices or shutdown stuff that's not mandatory to reduce power usage.
>> Thus: I might issue shutdown commands to PCs, power strips etc. powering
>> measurement equipment, or the monitoring system, but will keep the "main
>> thing" running as long as the UPS hardware can handle it (at that time,
>> all other "intelligent" devices are already off, including NUT itself,
>> at least that's the plan). Such an event occurs maybe once a year, if at
>> all...
>>
>> So far, I think disabling UPS shutdown at system shutdown is the only
>> thing I really need, but as the system is rather crucial to our
>> workflow, I wanted to make sure. The more changes I have to make to the
>> "default" configuration, the more to check at each update...
>>
>> Thank you for your patience in reading my story :-)
>>
>>
>> Best regards,
>>
>> Alex
>>
>>
>>
>> _______________________________________________
>> Nut-upsuser mailing list
>> Nut-upsuser at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240502/e3c75ba6/attachment-0001.htm>

From kiril.zyapkov at gmail.com  Wed May 15 21:47:26 2024
From: kiril.zyapkov at gmail.com (Kiril Zyapkov)
Date: Wed, 15 May 2024 23:47:26 +0300
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort but maximum
 gain
Message-ID: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>

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 online for as
long as the battery lasts and then provide a mechanism for a graceful
shutdown of my NAS and other appliances for which cutting power would not
be healthy. The project above is missing the "connected" part. I want to
get mine to play with NUT nicely. Other prior art is this project:

[2] https://github.com/xm381/Raspberry-Pi-UPS

Mentioned in a previous thread here:

[3]
https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html

A valid approach -- emulates an existing protocol on an arduino.

Are there other similar projects that you know of? I found plenty of "DIY
UPS" projects, but none were "smart".

I am able to put together firmware for some micro which will take care of
measuring voltages, currents, possibly also turn on/off loads, serial or
USB or IP are options. Not sure yet what hardware features I'll put
together, but this depends somewhat on the approach for getting this thing
integrated with NUT. PSUs and batteries are already on the way, and my junk
drawers have most other parts I may need.

So, options found so far:

* Use genericups. Least favorite option, very limited features

* Use the same approach as [2]. If I were to go that route -- which is the
best protocol to pick for emulation? I'm looking for something simple,
extensible/flexible and well-documented.

But what I really wish was possible was the ability to describe my device
in some format, feed it to a generic driver in NUT and profit. I see some
efforts have been made in this direction, most notably:

[4] https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)

What is the state there? Is it usable for USB HID? Or, how hard would it be
to make it usable? Even a modbus description will do -- implementing the
modbus server (yes, server, I'm being politically-correct) over serial or
even TCP is easy, if only there was a way to dump a CSV with register
descriptions in some magical driver...

And yet another approach which comes to mind is to implement my driver as
an external executable. This may be completely unfeasible and stupid, and
please let me know if it is. But, from what I gather, drivers run in their
own process and talk to the daemon via a UNIX socket. Why not make it
possible for the driver to be just any executable, built/deployed outside
of the NUT codebase? The socket protocol seems simple enough, and this will
allow for ... creativity. It could be implemented in any language
(including scripting languages) and need not depend on anything
NUT-specific, other than maybe some common CLI interface and/or
configuration.

I'm hoping the NUT masters will have some insight. Thanks for working on
this!

Cheers,
Kiril
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240515/221351ca/attachment.htm>

From kbyrd at memcpy.com  Thu May 16 02:11:58 2024
From: kbyrd at memcpy.com (Kelly Byrd)
Date: Wed, 15 May 2024 18:11:58 -0700
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort but
 maximum gain
In-Reply-To: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
References: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
Message-ID: <CAFwg=jAFjRHaRUuYMfgnWiazA5Ng+ad3cZ5gpL+3xsBfYhZwEg@mail.gmail.com>

I put together my own DIY UPS,  it's a RV charger/converter, an inverter,
and some batteries. I use an Arduino and the HIDPowerDevice library (
https://github.com/abratchik/HIDPowerDevice) to get it to talk to NUT. Been
working great for months!

The Arduino is connected to two modules:
* AC detection circuit to measure mains power on/off
* Voltage divider and an external ADC to get a reasonably good DC voltage
level for the battery which I turn into the a charge percentage.

This uses the USBHID driver in NUT and "just works" as long as you're using
NUT 2.8.2 or later. I used the example code in the HIDPowerDevice library
as a starting point for running on my Arduino.

I can share more specifics about the Arduino side of things off list if you
want, the NUT side of things is pretty boring and normal.

On Wed, May 15, 2024 at 3:27?PM Kiril Zyapkov via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> 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 online for
> as long as the battery lasts and then provide a mechanism for a graceful
> shutdown of my NAS and other appliances for which cutting power would not
> be healthy. The project above is missing the "connected" part. I want to
> get mine to play with NUT nicely. Other prior art is this project:
>
> [2] https://github.com/xm381/Raspberry-Pi-UPS
>
> Mentioned in a previous thread here:
>
> [3]
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
>
> A valid approach -- emulates an existing protocol on an arduino.
>
> Are there other similar projects that you know of? I found plenty of "DIY
> UPS" projects, but none were "smart".
>
> I am able to put together firmware for some micro which will take care of
> measuring voltages, currents, possibly also turn on/off loads, serial or
> USB or IP are options. Not sure yet what hardware features I'll put
> together, but this depends somewhat on the approach for getting this thing
> integrated with NUT. PSUs and batteries are already on the way, and my junk
> drawers have most other parts I may need.
>
> So, options found so far:
>
> * Use genericups. Least favorite option, very limited features
>
> * Use the same approach as [2]. If I were to go that route -- which is the
> best protocol to pick for emulation? I'm looking for something simple,
> extensible/flexible and well-documented.
>
> But what I really wish was possible was the ability to describe my device
> in some format, feed it to a generic driver in NUT and profit. I see some
> efforts have been made in this direction, most notably:
>
> [4] https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
>
> What is the state there? Is it usable for USB HID? Or, how hard would it
> be to make it usable? Even a modbus description will do -- implementing the
> modbus server (yes, server, I'm being politically-correct) over serial or
> even TCP is easy, if only there was a way to dump a CSV with register
> descriptions in some magical driver...
>
> And yet another approach which comes to mind is to implement my driver as
> an external executable. This may be completely unfeasible and stupid, and
> please let me know if it is. But, from what I gather, drivers run in their
> own process and talk to the daemon via a UNIX socket. Why not make it
> possible for the driver to be just any executable, built/deployed outside
> of the NUT codebase? The socket protocol seems simple enough, and this will
> allow for ... creativity. It could be implemented in any language
> (including scripting languages) and need not depend on anything
> NUT-specific, other than maybe some common CLI interface and/or
> configuration.
>
> I'm hoping the NUT masters will have some insight. Thanks for working on
> this!
>
> Cheers,
> Kiril
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240515/07d3c2ef/attachment.htm>

From bgee at campercaver.net  Thu May 16 12:13:03 2024
From: bgee at campercaver.net (Bill Gee)
Date: Thu, 16 May 2024 06:13:03 -0500
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort but
 maximum gain
In-Reply-To: <CAFwg=jAFjRHaRUuYMfgnWiazA5Ng+ad3cZ5gpL+3xsBfYhZwEg@mail.gmail.com>
References: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
 <CAFwg=jAFjRHaRUuYMfgnWiazA5Ng+ad3cZ5gpL+3xsBfYhZwEg@mail.gmail.com>
Message-ID: <806d09dc-8ef9-4d07-bfb8-74530f9a46d2@campercaver.net>

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 voltage?  What is the power capacity of 
the inverter?

Which Arduino did you use?  All of my Arduino projects use the Pro Mini, 
though it would be quite easy to get some other model for this.

Thanks -
===============
Bill Gee

On 5/15/24 20:11, Kelly Byrd wrote:
> I put together my own DIY UPS,? it's a RV charger/converter, an 
> inverter, and some batteries. I use an Arduino and the HIDPowerDevice 
> library (https://github.com/abratchik/HIDPowerDevice 
> <https://github.com/abratchik/HIDPowerDevice>) to get it to talk to NUT. 
> Been working great for months!
> 
> The Arduino is connected to two modules:
> * AC detection circuit to measure mains power on/off
> * Voltage divider and an external ADC to get a reasonably?good DC 
> voltage level for the battery which I turn into the a charge percentage.
> 
> This uses the USBHID driver in NUT and "just works" as long as you're 
> using NUT 2.8.2 or later. I used the example code in the HIDPowerDevice 
> library as a starting point for running on my Arduino.
> 
> I can share more specifics about the Arduino side of things off list if 
> you want, the NUT side of things is pretty boring and normal.
> 
> On Wed, May 15, 2024 at 3:27?PM Kiril Zyapkov via Nut-upsuser 
> <nut-upsuser at alioth-lists.debian.net 
> <mailto:nut-upsuser at alioth-lists.debian.net>> wrote:
> 
>     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 <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 online
>     for as long as the battery lasts and then provide a mechanism for a
>     graceful shutdown of my NAS and other appliances for which cutting
>     power would not be healthy. The project above is missing the
>     "connected" part. I want to get mine to play with NUT nicely. Other
>     prior art is this project:
> 
>     [2] https://github.com/xm381/Raspberry-Pi-UPS
>     <https://github.com/xm381/Raspberry-Pi-UPS>
> 
>     Mentioned in a previous thread here:
> 
>     [3]
>     https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html <https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html>
> 
>     A valid approach -- emulates an existing protocol on an arduino.
> 
>     Are there other similar projects that you know of? I found plenty of
>     "DIY UPS" projects, but none were "smart".
> 
>     I am able to put together firmware for some micro which will take
>     care of measuring voltages, currents, possibly also turn on/off
>     loads, serial or USB or IP are options. Not sure yet what hardware
>     features I'll put together, but this depends somewhat on the
>     approach for getting this thing integrated with NUT. PSUs and
>     batteries are already on the way, and my junk drawers have most
>     other parts I may need.
> 
>     So, options found so far:
> 
>     * Use genericups. Least favorite option, very limited features
> 
>     * Use the same approach as [2]. If I were to go that route -- which
>     is the best protocol to pick for emulation? I'm looking for
>     something simple, extensible/flexible and well-documented.
> 
>     But what I really wish was possible was the ability to describe my
>     device in some format, feed it to a generic driver in NUT and
>     profit. I see some efforts have been made in this direction, most
>     notably:
> 
>     [4]
>     https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
>     <https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)>
> 
>     What is the state there? Is it usable for USB HID? Or, how hard
>     would it be to make it usable? Even a modbus description will do --
>     implementing the modbus server (yes, server, I'm being
>     politically-correct) over serial or even TCP is easy, if only there
>     was a way to dump a CSV with register descriptions in some magical
>     driver...
> 
>     And yet another approach which comes to mind is to implement my
>     driver as an external executable. This may be completely unfeasible
>     and stupid, and please let me know if it is. But, from what I
>     gather, drivers run in their own process and talk to the daemon via
>     a UNIX socket. Why not make it possible for the driver to be just
>     any executable, built/deployed outside of the NUT codebase? The
>     socket protocol seems simple enough, and this will allow for ...
>     creativity. It could be implemented in any language (including
>     scripting languages) and need not depend on anything NUT-specific,
>     other than maybe some common CLI interface and/or configuration.
> 
>     I'm hoping the NUT masters will have some insight. Thanks for
>     working on this!
> 
>     Cheers,
>     Kiril
>     _______________________________________________
>     Nut-upsuser mailing list
>     Nut-upsuser at alioth-lists.debian.net
>     <mailto:Nut-upsuser at alioth-lists.debian.net>
>     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>     <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> 
> 
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser


From jimklimov+nut at gmail.com  Thu May 16 13:59:21 2024
From: jimklimov+nut at gmail.com (Jim Klimov)
Date: Thu, 16 May 2024 14:59:21 +0200
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort but
 maximum gain
In-Reply-To: <806d09dc-8ef9-4d07-bfb8-74530f9a46d2@campercaver.net>
References: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
 <CAFwg=jAFjRHaRUuYMfgnWiazA5Ng+ad3cZ5gpL+3xsBfYhZwEg@mail.gmail.com>
 <806d09dc-8ef9-4d07-bfb8-74530f9a46d2@campercaver.net>
Message-ID: <CAJYg8vJvurgRACRt+Yu2ovEAKQWETT2-esEFdj5daFVV8QY6_Q@mail.gmail.com>

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 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 voltage?  What is the power capacity of
> the inverter?
>
> Which Arduino did you use?  All of my Arduino projects use the Pro Mini,
> though it would be quite easy to get some other model for this.
>
> Thanks -
> ===============
> Bill Gee
>
> On 5/15/24 20:11, Kelly Byrd wrote:
> > I put together my own DIY UPS,  it's a RV charger/converter, an
> > inverter, and some batteries. I use an Arduino and the HIDPowerDevice
> > library (https://github.com/abratchik/HIDPowerDevice
> > <https://github.com/abratchik/HIDPowerDevice>) to get it to talk to
> NUT.
> > Been working great for months!
> >
> > The Arduino is connected to two modules:
> > * AC detection circuit to measure mains power on/off
> > * Voltage divider and an external ADC to get a reasonably good DC
> > voltage level for the battery which I turn into the a charge percentage.
> >
> > This uses the USBHID driver in NUT and "just works" as long as you're
> > using NUT 2.8.2 or later. I used the example code in the HIDPowerDevice
> > library as a starting point for running on my Arduino.
> >
> > I can share more specifics about the Arduino side of things off list if
> > you want, the NUT side of things is pretty boring and normal.
> >
> > On Wed, May 15, 2024 at 3:27?PM Kiril Zyapkov via Nut-upsuser
> > <nut-upsuser at alioth-lists.debian.net
> > <mailto:nut-upsuser at alioth-lists.debian.net>> wrote:
> >
> >     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
> <
> 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 online
> >     for as long as the battery lasts and then provide a mechanism for a
> >     graceful shutdown of my NAS and other appliances for which cutting
> >     power would not be healthy. The project above is missing the
> >     "connected" part. I want to get mine to play with NUT nicely. Other
> >     prior art is this project:
> >
> >     [2] https://github.com/xm381/Raspberry-Pi-UPS
> >     <https://github.com/xm381/Raspberry-Pi-UPS>
> >
> >     Mentioned in a previous thread here:
> >
> >     [3]
> >
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> <
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> >
> >
> >     A valid approach -- emulates an existing protocol on an arduino.
> >
> >     Are there other similar projects that you know of? I found plenty of
> >     "DIY UPS" projects, but none were "smart".
> >
> >     I am able to put together firmware for some micro which will take
> >     care of measuring voltages, currents, possibly also turn on/off
> >     loads, serial or USB or IP are options. Not sure yet what hardware
> >     features I'll put together, but this depends somewhat on the
> >     approach for getting this thing integrated with NUT. PSUs and
> >     batteries are already on the way, and my junk drawers have most
> >     other parts I may need.
> >
> >     So, options found so far:
> >
> >     * Use genericups. Least favorite option, very limited features
> >
> >     * Use the same approach as [2]. If I were to go that route -- which
> >     is the best protocol to pick for emulation? I'm looking for
> >     something simple, extensible/flexible and well-documented.
> >
> >     But what I really wish was possible was the ability to describe my
> >     device in some format, feed it to a generic driver in NUT and
> >     profit. I see some efforts have been made in this direction, most
> >     notably:
> >
> >     [4]
> >     https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
> >     <https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
> >
> >
> >     What is the state there? Is it usable for USB HID? Or, how hard
> >     would it be to make it usable? Even a modbus description will do --
> >     implementing the modbus server (yes, server, I'm being
> >     politically-correct) over serial or even TCP is easy, if only there
> >     was a way to dump a CSV with register descriptions in some magical
> >     driver...
> >
> >     And yet another approach which comes to mind is to implement my
> >     driver as an external executable. This may be completely unfeasible
> >     and stupid, and please let me know if it is. But, from what I
> >     gather, drivers run in their own process and talk to the daemon via
> >     a UNIX socket. Why not make it possible for the driver to be just
> >     any executable, built/deployed outside of the NUT codebase? The
> >     socket protocol seems simple enough, and this will allow for ...
> >     creativity. It could be implemented in any language (including
> >     scripting languages) and need not depend on anything NUT-specific,
> >     other than maybe some common CLI interface and/or configuration.
> >
> >     I'm hoping the NUT masters will have some insight. Thanks for
> >     working on this!
> >
> >     Cheers,
> >     Kiril
> >     _______________________________________________
> >     Nut-upsuser mailing list
> >     Nut-upsuser at alioth-lists.debian.net
> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
> >     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> >     <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> >
> >
> > _______________________________________________
> > Nut-upsuser mailing list
> > Nut-upsuser at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240516/8a4d2f83/attachment-0001.htm>

From gheskett at shentel.net  Thu May 16 18:42:23 2024
From: gheskett at shentel.net (gene heskett)
Date: Thu, 16 May 2024 13:42:23 -0400
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort
 butmaximum gain
In-Reply-To: <CAJYg8vJvurgRACRt+Yu2ovEAKQWETT2-esEFdj5daFVV8QY6_Q@mail.gmail.com>
References: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
 <CAFwg=jAFjRHaRUuYMfgnWiazA5Ng+ad3cZ5gpL+3xsBfYhZwEg@mail.gmail.com>
 <806d09dc-8ef9-4d07-bfb8-74530f9a46d2@campercaver.net>
 <CAJYg8vJvurgRACRt+Yu2ovEAKQWETT2-esEFdj5daFVV8QY6_Q@mail.gmail.com>
Message-ID: <49275515-9eb6-4110-9bc6-feea9660fafb@shentel.net>

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...
> 
> Jim
> 
Great Idea Jim.
> 
> On Thu, May 16, 2024 at 1:29?PM Bill Gee <bgee at campercaver.net 
> <mailto:bgee at campercaver.net>> wrote:
> 
>     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 voltage?? What is the power capacity of
>     the inverter?
> 
>     Which Arduino did you use?? All of my Arduino projects use the Pro
>     Mini,
>     though it would be quite easy to get some other model for this.
> 
>     Thanks -
>     ===============
>     Bill Gee
> 
>     On 5/15/24 20:11, Kelly Byrd wrote:
>      > I put together my own DIY UPS,? it's a RV charger/converter, an
>      > inverter, and some batteries. I use an Arduino and the
>     HIDPowerDevice
>      > library (https://github.com/abratchik/HIDPowerDevice
>     <https://github.com/abratchik/HIDPowerDevice>
>      > <https://github.com/abratchik/HIDPowerDevice
>     <https://github.com/abratchik/HIDPowerDevice>>) to get it to talk to
>     NUT.
>      > Been working great for months!
>      >
>      > The Arduino is connected to two modules:
>      > * AC detection circuit to measure mains power on/off
>      > * Voltage divider and an external ADC to get a reasonably?good DC
>      > voltage level for the battery which I turn into the a charge
>     percentage.
>      >
>      > This uses the USBHID driver in NUT and "just works" as long as
>     you're
>      > using NUT 2.8.2 or later. I used the example code in the
>     HIDPowerDevice
>      > library as a starting point for running on my Arduino.
>      >
>      > I can share more specifics about the Arduino side of things off
>     list if
>      > you want, the NUT side of things is pretty boring and normal.
>      >
>      > On Wed, May 15, 2024 at 3:27?PM Kiril Zyapkov via Nut-upsuser
>      > <nut-upsuser at alioth-lists.debian.net
>     <mailto:nut-upsuser at alioth-lists.debian.net>
>      > <mailto:nut-upsuser at alioth-lists.debian.net
>     <mailto:nut-upsuser at alioth-lists.debian.net>>> wrote:
>      >
>      >? ? ?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 <https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html> <https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html <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
>     online
>      >? ? ?for as long as the battery lasts and then provide a mechanism
>     for a
>      >? ? ?graceful shutdown of my NAS and other appliances for which
>     cutting
>      >? ? ?power would not be healthy. The project above is missing the
>      >? ? ?"connected" part. I want to get mine to play with NUT nicely.
>     Other
>      >? ? ?prior art is this project:
>      >
>      >? ? ?[2] https://github.com/xm381/Raspberry-Pi-UPS
>     <https://github.com/xm381/Raspberry-Pi-UPS>
>      >? ? ?<https://github.com/xm381/Raspberry-Pi-UPS
>     <https://github.com/xm381/Raspberry-Pi-UPS>>
>      >
>      >? ? ?Mentioned in a previous thread here:
>      >
>      >? ? ?[3]
>      >
>     https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html <https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html> <https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html <https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html>>
>      >
>      >? ? ?A valid approach -- emulates an existing protocol on an arduino.
>      >
>      >? ? ?Are there other similar projects that you know of? I found
>     plenty of
>      >? ? ?"DIY UPS" projects, but none were "smart".
>      >
>      >? ? ?I am able to put together firmware for some micro which will take
>      >? ? ?care of measuring voltages, currents, possibly also turn on/off
>      >? ? ?loads, serial or USB or IP are options. Not sure yet what
>     hardware
>      >? ? ?features I'll put together, but this depends somewhat on the
>      >? ? ?approach for getting this thing integrated with NUT. PSUs and
>      >? ? ?batteries are already on the way, and my junk drawers have most
>      >? ? ?other parts I may need.
>      >
>      >? ? ?So, options found so far:
>      >
>      >? ? ?* Use genericups. Least favorite option, very limited features
>      >
>      >? ? ?* Use the same approach as [2]. If I were to go that route --
>     which
>      >? ? ?is the best protocol to pick for emulation? I'm looking for
>      >? ? ?something simple, extensible/flexible and well-documented.
>      >
>      >? ? ?But what I really wish was possible was the ability to
>     describe my
>      >? ? ?device in some format, feed it to a generic driver in NUT and
>      >? ? ?profit. I see some efforts have been made in this direction, most
>      >? ? ?notably:
>      >
>      >? ? ?[4]
>      >
>     https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
>     <https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)>
>      >   
>      ?<https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF) <https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)>>
>      >
>      >? ? ?What is the state there? Is it usable for USB HID? Or, how hard
>      >? ? ?would it be to make it usable? Even a modbus description will
>     do --
>      >? ? ?implementing the modbus server (yes, server, I'm being
>      >? ? ?politically-correct) over serial or even TCP is easy, if only
>     there
>      >? ? ?was a way to dump a CSV with register descriptions in some
>     magical
>      >? ? ?driver...
>      >
>      >? ? ?And yet another approach which comes to mind is to implement my
>      >? ? ?driver as an external executable. This may be completely
>     unfeasible
>      >? ? ?and stupid, and please let me know if it is. But, from what I
>      >? ? ?gather, drivers run in their own process and talk to the
>     daemon via
>      >? ? ?a UNIX socket. Why not make it possible for the driver to be just
>      >? ? ?any executable, built/deployed outside of the NUT codebase? The
>      >? ? ?socket protocol seems simple enough, and this will allow for ...
>      >? ? ?creativity. It could be implemented in any language (including
>      >? ? ?scripting languages) and need not depend on anything
>     NUT-specific,
>      >? ? ?other than maybe some common CLI interface and/or configuration.
>      >
>      >? ? ?I'm hoping the NUT masters will have some insight. Thanks for
>      >? ? ?working on this!
>      >
>      >? ? ?Cheers,
>      >? ? ?Kiril
>      >? ? ?_______________________________________________
>      >? ? ?Nut-upsuser mailing list
>      > Nut-upsuser at alioth-lists.debian.net
>     <mailto:Nut-upsuser at alioth-lists.debian.net>
>      >? ? ?<mailto:Nut-upsuser at alioth-lists.debian.net
>     <mailto:Nut-upsuser at alioth-lists.debian.net>>
>      >
>     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>     <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
>      >   
>      ?<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>>
>      >
>      >
>      > _______________________________________________
>      > Nut-upsuser mailing list
>      > Nut-upsuser at alioth-lists.debian.net
>     <mailto:Nut-upsuser at alioth-lists.debian.net>
>      >
>     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>     <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> 
>     _______________________________________________
>     Nut-upsuser mailing list
>     Nut-upsuser at alioth-lists.debian.net
>     <mailto:Nut-upsuser at alioth-lists.debian.net>
>     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>     <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> 
> 
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis



From kbyrd at memcpy.com  Thu May 16 21:52:06 2024
From: kbyrd at memcpy.com (Kelly Byrd)
Date: Thu, 16 May 2024 13:52:06 -0700
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort
 butmaximum gain
In-Reply-To: <49275515-9eb6-4110-9bc6-feea9660fafb@shentel.net>
References: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
 <CAFwg=jAFjRHaRUuYMfgnWiazA5Ng+ad3cZ5gpL+3xsBfYhZwEg@mail.gmail.com>
 <806d09dc-8ef9-4d07-bfb8-74530f9a46d2@campercaver.net>
 <CAJYg8vJvurgRACRt+Yu2ovEAKQWETT2-esEFdj5daFVV8QY6_Q@mail.gmail.com>
 <49275515-9eb6-4110-9bc6-feea9660fafb@shentel.net>
Message-ID: <CAFwg=jCBxoECHOtJjNFiYTHQgZg279oBSfJpGKKC1NEROaq_RQ@mail.gmail.com>

Ok, my super long reply is waiting on moderation. In the meantime, I have
started:
https://github.com/networkupstools/nut/wiki/DIY-UPS-with-and-Arduino



On Thu, May 16, 2024 at 10:59?AM gene heskett via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> 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...
> >
> > Jim
> >
> Great Idea Jim.
> >
> > On Thu, May 16, 2024 at 1:29?PM Bill Gee <bgee at campercaver.net
> > <mailto:bgee at campercaver.net>> wrote:
> >
> >     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 voltage?  What is the power capacity
> of
> >     the inverter?
> >
> >     Which Arduino did you use?  All of my Arduino projects use the Pro
> >     Mini,
> >     though it would be quite easy to get some other model for this.
> >
> >     Thanks -
> >     ===============
> >     Bill Gee
> >
> >     On 5/15/24 20:11, Kelly Byrd wrote:
> >      > I put together my own DIY UPS,  it's a RV charger/converter, an
> >      > inverter, and some batteries. I use an Arduino and the
> >     HIDPowerDevice
> >      > library (https://github.com/abratchik/HIDPowerDevice
> >     <https://github.com/abratchik/HIDPowerDevice>
> >      > <https://github.com/abratchik/HIDPowerDevice
> >     <https://github.com/abratchik/HIDPowerDevice>>) to get it to talk to
> >     NUT.
> >      > Been working great for months!
> >      >
> >      > The Arduino is connected to two modules:
> >      > * AC detection circuit to measure mains power on/off
> >      > * Voltage divider and an external ADC to get a reasonably good DC
> >      > voltage level for the battery which I turn into the a charge
> >     percentage.
> >      >
> >      > This uses the USBHID driver in NUT and "just works" as long as
> >     you're
> >      > using NUT 2.8.2 or later. I used the example code in the
> >     HIDPowerDevice
> >      > library as a starting point for running on my Arduino.
> >      >
> >      > I can share more specifics about the Arduino side of things off
> >     list if
> >      > you want, the NUT side of things is pretty boring and normal.
> >      >
> >      > On Wed, May 15, 2024 at 3:27?PM Kiril Zyapkov via Nut-upsuser
> >      > <nut-upsuser at alioth-lists.debian.net
> >     <mailto:nut-upsuser at alioth-lists.debian.net>
> >      > <mailto:nut-upsuser at alioth-lists.debian.net
> >     <mailto:nut-upsuser at alioth-lists.debian.net>>> wrote:
> >      >
> >      >     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
> <
> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html>
> <
> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html
> <
> 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
> >     online
> >      >     for as long as the battery lasts and then provide a mechanism
> >     for a
> >      >     graceful shutdown of my NAS and other appliances for which
> >     cutting
> >      >     power would not be healthy. The project above is missing the
> >      >     "connected" part. I want to get mine to play with NUT nicely.
> >     Other
> >      >     prior art is this project:
> >      >
> >      >     [2] https://github.com/xm381/Raspberry-Pi-UPS
> >     <https://github.com/xm381/Raspberry-Pi-UPS>
> >      >     <https://github.com/xm381/Raspberry-Pi-UPS
> >     <https://github.com/xm381/Raspberry-Pi-UPS>>
> >      >
> >      >     Mentioned in a previous thread here:
> >      >
> >      >     [3]
> >      >
> >
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> <
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html>
> <
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> <
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> >>
> >      >
> >      >     A valid approach -- emulates an existing protocol on an
> arduino.
> >      >
> >      >     Are there other similar projects that you know of? I found
> >     plenty of
> >      >     "DIY UPS" projects, but none were "smart".
> >      >
> >      >     I am able to put together firmware for some micro which will
> take
> >      >     care of measuring voltages, currents, possibly also turn
> on/off
> >      >     loads, serial or USB or IP are options. Not sure yet what
> >     hardware
> >      >     features I'll put together, but this depends somewhat on the
> >      >     approach for getting this thing integrated with NUT. PSUs and
> >      >     batteries are already on the way, and my junk drawers have
> most
> >      >     other parts I may need.
> >      >
> >      >     So, options found so far:
> >      >
> >      >     * Use genericups. Least favorite option, very limited features
> >      >
> >      >     * Use the same approach as [2]. If I were to go that route --
> >     which
> >      >     is the best protocol to pick for emulation? I'm looking for
> >      >     something simple, extensible/flexible and well-documented.
> >      >
> >      >     But what I really wish was possible was the ability to
> >     describe my
> >      >     device in some format, feed it to a generic driver in NUT and
> >      >     profit. I see some efforts have been made in this direction,
> most
> >      >     notably:
> >      >
> >      >     [4]
> >      >
> >     https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
> >     <https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
> >
> >      >
> >       <
> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF) <
> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)>>
> >      >
> >      >     What is the state there? Is it usable for USB HID? Or, how
> hard
> >      >     would it be to make it usable? Even a modbus description will
> >     do --
> >      >     implementing the modbus server (yes, server, I'm being
> >      >     politically-correct) over serial or even TCP is easy, if only
> >     there
> >      >     was a way to dump a CSV with register descriptions in some
> >     magical
> >      >     driver...
> >      >
> >      >     And yet another approach which comes to mind is to implement
> my
> >      >     driver as an external executable. This may be completely
> >     unfeasible
> >      >     and stupid, and please let me know if it is. But, from what I
> >      >     gather, drivers run in their own process and talk to the
> >     daemon via
> >      >     a UNIX socket. Why not make it possible for the driver to be
> just
> >      >     any executable, built/deployed outside of the NUT codebase?
> The
> >      >     socket protocol seems simple enough, and this will allow for
> ...
> >      >     creativity. It could be implemented in any language (including
> >      >     scripting languages) and need not depend on anything
> >     NUT-specific,
> >      >     other than maybe some common CLI interface and/or
> configuration.
> >      >
> >      >     I'm hoping the NUT masters will have some insight. Thanks for
> >      >     working on this!
> >      >
> >      >     Cheers,
> >      >     Kiril
> >      >     _______________________________________________
> >      >     Nut-upsuser mailing list
> >      > Nut-upsuser at alioth-lists.debian.net
> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
> >      >     <mailto:Nut-upsuser at alioth-lists.debian.net
> >     <mailto:Nut-upsuser at alioth-lists.debian.net>>
> >      >
> >     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> >     <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> >      >
> >       <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>>
> >      >
> >      >
> >      > _______________________________________________
> >      > Nut-upsuser mailing list
> >      > Nut-upsuser at alioth-lists.debian.net
> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
> >      >
> >     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> >     <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> >
> >     _______________________________________________
> >     Nut-upsuser mailing list
> >     Nut-upsuser at alioth-lists.debian.net
> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
> >     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> >     <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> >
> >
> > _______________________________________________
> > Nut-upsuser mailing list
> > Nut-upsuser at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
> Cheers, Gene Heskett, CET.
> --
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240516/4e22cef6/attachment-0001.htm>

From kbyrd at memcpy.com  Thu May 16 19:55:59 2024
From: kbyrd at memcpy.com (Kelly Byrd)
Date: Thu, 16 May 2024 11:55:59 -0700
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort
 butmaximum gain
In-Reply-To: <49275515-9eb6-4110-9bc6-feea9660fafb@shentel.net>
References: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
 <CAFwg=jAFjRHaRUuYMfgnWiazA5Ng+ad3cZ5gpL+3xsBfYhZwEg@mail.gmail.com>
 <806d09dc-8ef9-4d07-bfb8-74530f9a46d2@campercaver.net>
 <CAJYg8vJvurgRACRt+Yu2ovEAKQWETT2-esEFdj5daFVV8QY6_Q@mail.gmail.com>
 <49275515-9eb6-4110-9bc6-feea9660fafb@shentel.net>
Message-ID: <CAFwg=jC3y=Mwg2nUmhwAXCBy_uLOxUSw2SD48t5kbNJJEVBuhw@mail.gmail.com>

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 how to do
this safely, size components appropriately, etc.

My goal is to keep a home Internet connection available during a power
outage. This doesn't happen that often, but it bugged me when it did and I
like playing with power-related things, so this became a fun project to
tackle. I guess I should mention that my home network gear is in a rack in
the garage. "modem", router, switch, wifi APs powered over PoE from the
switch, NAS, and typically a Raspberry Pi or two doing whatever "always on"
things I want. I also previously built a substantial portable battery box
that will power other appliances like TVs and computers, but the networking
gear is all in the garage and I can't power both at once without some very
long extension cables snaking through the house.

I noticed a few years ago that my Internet connection stayed up during a
couple of different neighborhood power outages, assuming I could power the
gear on my side. I guess the equipment on the ISP side is far enough away
that it isn't affected? For a few years, I did this with a 12V inverter
connected to an EV (an electric car). It turns out the 12V system in many
EVs will provide 12V power through a DC step-down from the main traction
battery. I really only need like 15A and previous testing made me confident
I could safely do this as long as the main battery had capacity left. So, I
did that for a while, but earlier this year we sold the EV and became a
one-car household. So...what do I do? I had an inverter, if I could get
batteries and a way to charge them, I should be most of my way toward a DIY
UPS, right?

Specs/Requirements
* AC power needed is typically about 150W, I typically use 300W as a value
for max surge. If I turn off my NAS, the load is only about 50-55W AC. I
was aiming for 2-3 days of power for this load, and can live without the
NAS during an outage, so I need 2.8-4.3kWh of capacity with the NAS off.

* While I do want this to work, this is a fun personal project. Mucking
with it is part of the goal. I had some hobby money to spend, but not
infinite. I wanted to reuse things I had on hand or could get easily for
v1. I also get to decide how reliable it needs to be.

The system is:
* AIMS Pure Sine 12V 600W Inverter. I had it already. Having this inverter
on hand drove the decision for 12V vs 24/48V. Also, power needs are
relatively low so 12V doesn't lead to more than 55A of current, and that's
only when charging from a deep discharge.

* RV Converter/Charger: PowerMax PM4 55A 12V. This is a lead acid battery
charger that will also provide power after batteries are charged. Many
battery chargers are not designed to be run 24/7, this one is.

* Two 12V 200Ah Renology AGM deep cycle batteries wired in parallel. Got a
deal on these. I decided I was ok with 75%-80% DoD even though these are
lead acid. This gives me about 3.5kWh of usable AC capacity.

* Batteries and charger are wired up with 4AWG, the inverter is something
smaller, I think 6AWG?


What I have built is a double conversion online system. The inverter is
powering the AC load all the time. There's no transfer switch. There's
lower efficiency when power is on because the normal power path is always
AC->DC->AC. I did this because I wasn't confident in my ability to find a
transfer switch that would transfer fast enough and it was one more thing
to figure out and buy. In my head, this online architecture is simpler, but
I may change it in the next version. I worry a bit about the inverter being
ok running full time, but since it is rated for 600W and I use only 150W
all the time, I decided it's ok. When it fails, I'll figure out something
else.

I chose lead acid deep-cycle batteries because if you're willing to
discharge them to 70-80% they're very cost effective vs LiFePO4 or other
lithium types. I know this will shorten the number of cycles I get from
them. I'm ok with that. In this application, they sit at 100% for all but
maybe a few hours to a few days a year. They may see one or two deep
discharges a year. If I get five years out of them, that's great!

I calculated roughly 3.5kWh of usable capacity for these two wired in
parallel. Running with the NAS off is maybe 5A from the DC side of things,
which is a really low load for a 400Ah battery bank. They are very heavy,
but I already had a heavy duty storage rack next to the load, so that's not
a problem in this case. Also, the voltage range for 12V lead acid batteries
is still better supported than LiFePO4. Right now, there are still more
(and lower cost) chargers and inverters that assume a lead acid voltage
range. As an example, my inverter will shut down if it sees over about
14.6V.

So, how does this fit into NUT? One key aspect of my capacity planning was:
"normal load is ~150W, but if the NAS turns off, I can make that 50-60W.".
My NAS is a QNAP, it has NUT installed. Before this DIY UPS, I was using an
APC consumer UPS connected to the NAS via USB so it would turn off 5 min
after mains power went off. That's the behavior I wanted for my DIY UPS.

So how did I do this?

Gear:
* Arduino Pro Micro clone. It has a micro USB port built in and is commonly
used for "make an Arduino appear to be some USB device" projects. It can be
powered over USB, or by 5VDC directly to pins.

* AC detection module: https://www.amazon.com/gp/product/B082PWV586. Gives
me an opto-isolated "is the mains AC present" signal the Arduino can read.

* Raspberry Pi running NUT. I wish I didn't need this, but I do for now.
While building and debugging the Arduino code, I needed to modify the NUT
code. Those patches made it in v2.8.1 and v2.8.2 NUT releases, but I still
don't think my QNAP NAS has v2.8.2 available. I eventually plan to remove
this.

I put the AC detection module and the Arduino inside the PowerMax
converter/charger enclosure, on a little 3D printed mount. The AC module
connect to the AC input terminals inside the PowerMax and then the signal
side connects to a pin on the Arduino and pulls it high (or low, I forget)
when the AC is gone. I run a USB cable out of the PowerMax case which
connects to the RPi running NUT. The RPi is powered by the inverter, and it
powers the Arduino over USB. The RPi stays on during a power outage.

So now I can write some Arduino code that loops and checks the status of a
digital pin. How do I pretend to be a UPS in a way NUT will recognize?

Some googling led me to the HIDPowerDevice project.
https://github.com/abratchik/HIDPowerDevice. That is a library for Arduino
MCUs that does all the protocol for getting an Arduino device to be
recognized as a HID compliant UPS device over USB. You use it by
periodically calling a `sendReport` function with various flags set. Ex:
PowerDevice.sendReport(HID_PD_REMAININGCAPACITY, &iRemaining,
sizeof(iRemaining));
PowerDevice.sendReport(HID_PD_PRESENTSTATUS, &iPresentStatus,
sizeof(iPresentStatus));

`iPresentStatus` is a bit field with a ton of info in it, like:
PRESENTSTATUS_ACPRESENT, PRESENTSTATUS_DISCHARGING, PRESENTSTATUS_CHARGING,
etc. See the project for full details.

So, now my Arduino code loop does this:
Check status of AC on/off pin.
Set/clear PRESENTSTATUS_ACPRESENT and set
PRESENTSTATUS_CHARGING/PRESENTSTATUS_DISCHARGING accordingly.
Call `sendReport` from the HIDPowerDevice library.
Sleep a second, loop.

In reality, my loop does a little bit more than this. It loops every
second, but only sends a report if some status changed but waits no more
than every 5 seconds between reports in any case. NUT (and Windows, and
MacOS) seem to expect this.

So, assuming I can get NUT to recognize the Arduino Micro as a UPS, this
should work. I had two problems getting NUT to recognize the Arduino:
1) Will NUT recognize the default Arduino vendor and product id (vid:pid)?
The answer is YES! There is an Arduino subdriver for usbhid in NUT. It
looks like the HIDPowerDevice project author added this originally a few
years ago! See drivers/arduino-hid.c for the list of supported IDs. If you
end up with an Arduino device that has another vid/pid combo, it would need
to be added there.

2) When using the HIDPowerDevice library, the Arduino Micro presents as a
composite HID device, so it is more than one HID type at once. AFAICT, real
world examples of composite devices are rare, but it is in the HID spec. In
this exact case the Arduino presents as both serial/comm interface
(typically used for debug output when running code from the Arduino IDE)
and as a HID Power Device (the HID term for UPS status over USB). This all
works now as of NUT 2.8.2.

Note that the Arduino subdriver is not as full featured as something like
the APC subdriver. I don't think it allows for NUT to set values on the
Arduino HID device. I don't know if the Arduino HIDPowerDevice library
supports this either. I have only tested the send-a-report-periodically
code path.

NUT config
What I really wanted was for my NAS to shut down when mains power goes
away. My QNAP NAS runs NUT, but I needed 2.8.2 and getting a new version on
there was more than I wanted to tackle, especially since my PRs weren't in
a release version of NUT at that time. So I run a NUT server on a Raspberry
PI which is connected via USB to my DIY-NAS Arduino. The RPi does not react
to changes in the UPS at all. It  makes them available over the network to
the NUT instance running on the QNAP NAS. The QNAP NAS is then configured
to poll the RPi NUT instance for UPS status and set to shut down if AC
power is out for 5 min. I would rather not deal with this extra RPi in the
setup, but it was the easiest way forward for me. Once NUT 2.8.2 is
available for my QNAP NAS. I'll get rid of it.


Optional Upgrade
DC voltage sensing to give an idea of remaining runtime or remaining
capacity. Since this is too long already, I'll try to be brief. One thing I
did a month or so after the initial install was add DC voltage detection to
the Arduino side of things:

Gear:
* 0-25VDC voltage sensor (https://www.amazon.com/gp/product/B01HTC4XKY).
It's a voltage divider, let's my code sense the DC voltage.

* External ADC: ADS1115 board. I wanted higher resolution DC voltage
detection.

My code then changed to take readings from the ADS1115 and convert that
into a rough "50-100% capacity remaining" that I can report to NUT. It took
a while to get right and it's only "accurate enough", not "trust this to a
millivolt level of accuracy". For now it's just nice to have and I enjoyed
having to learn about ADC measuring on Arduino enough to get this accurate
enough to report with 1% differences in capacity.

Future
I've been researching designing a PCB and doing an "all-in-one" UPS. I'll
talk more about that on the wiki page as well.

I guess I should share my Arduino code on GitHub too.

On Thu, May 16, 2024 at 10:59?AM gene heskett via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> 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...
> >
> > Jim
> >
> Great Idea Jim.
> >
> > On Thu, May 16, 2024 at 1:29?PM Bill Gee <bgee at campercaver.net
> > <mailto:bgee at campercaver.net>> wrote:
> >
> >     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 voltage?  What is the power capacity
> of
> >     the inverter?
> >
> >     Which Arduino did you use?  All of my Arduino projects use the Pro
> >     Mini,
> >     though it would be quite easy to get some other model for this.
> >
> >     Thanks -
> >     ===============
> >     Bill Gee
> >
> >     On 5/15/24 20:11, Kelly Byrd wrote:
> >      > I put together my own DIY UPS,  it's a RV charger/converter, an
> >      > inverter, and some batteries. I use an Arduino and the
> >     HIDPowerDevice
> >      > library (https://github.com/abratchik/HIDPowerDevice
> >     <https://github.com/abratchik/HIDPowerDevice>
> >      > <https://github.com/abratchik/HIDPowerDevice
> >     <https://github.com/abratchik/HIDPowerDevice>>) to get it to talk to
> >     NUT.
> >      > Been working great for months!
> >      >
> >      > The Arduino is connected to two modules:
> >      > * AC detection circuit to measure mains power on/off
> >      > * Voltage divider and an external ADC to get a reasonably good DC
> >      > voltage level for the battery which I turn into the a charge
> >     percentage.
> >      >
> >      > This uses the USBHID driver in NUT and "just works" as long as
> >     you're
> >      > using NUT 2.8.2 or later. I used the example code in the
> >     HIDPowerDevice
> >      > library as a starting point for running on my Arduino.
> >      >
> >      > I can share more specifics about the Arduino side of things off
> >     list if
> >      > you want, the NUT side of things is pretty boring and normal.
> >      >
> >      > On Wed, May 15, 2024 at 3:27?PM Kiril Zyapkov via Nut-upsuser
> >      > <nut-upsuser at alioth-lists.debian.net
> >     <mailto:nut-upsuser at alioth-lists.debian.net>
> >      > <mailto:nut-upsuser at alioth-lists.debian.net
> >     <mailto:nut-upsuser at alioth-lists.debian.net>>> wrote:
> >      >
> >      >     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
> <
> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html>
> <
> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html
> <
> 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
> >     online
> >      >     for as long as the battery lasts and then provide a mechanism
> >     for a
> >      >     graceful shutdown of my NAS and other appliances for which
> >     cutting
> >      >     power would not be healthy. The project above is missing the
> >      >     "connected" part. I want to get mine to play with NUT nicely.
> >     Other
> >      >     prior art is this project:
> >      >
> >      >     [2] https://github.com/xm381/Raspberry-Pi-UPS
> >     <https://github.com/xm381/Raspberry-Pi-UPS>
> >      >     <https://github.com/xm381/Raspberry-Pi-UPS
> >     <https://github.com/xm381/Raspberry-Pi-UPS>>
> >      >
> >      >     Mentioned in a previous thread here:
> >      >
> >      >     [3]
> >      >
> >
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> <
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html>
> <
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> <
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> >>
> >      >
> >      >     A valid approach -- emulates an existing protocol on an
> arduino.
> >      >
> >      >     Are there other similar projects that you know of? I found
> >     plenty of
> >      >     "DIY UPS" projects, but none were "smart".
> >      >
> >      >     I am able to put together firmware for some micro which will
> take
> >      >     care of measuring voltages, currents, possibly also turn
> on/off
> >      >     loads, serial or USB or IP are options. Not sure yet what
> >     hardware
> >      >     features I'll put together, but this depends somewhat on the
> >      >     approach for getting this thing integrated with NUT. PSUs and
> >      >     batteries are already on the way, and my junk drawers have
> most
> >      >     other parts I may need.
> >      >
> >      >     So, options found so far:
> >      >
> >      >     * Use genericups. Least favorite option, very limited features
> >      >
> >      >     * Use the same approach as [2]. If I were to go that route --
> >     which
> >      >     is the best protocol to pick for emulation? I'm looking for
> >      >     something simple, extensible/flexible and well-documented.
> >      >
> >      >     But what I really wish was possible was the ability to
> >     describe my
> >      >     device in some format, feed it to a generic driver in NUT and
> >      >     profit. I see some efforts have been made in this direction,
> most
> >      >     notably:
> >      >
> >      >     [4]
> >      >
> >     https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
> >     <https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
> >
> >      >
> >       <
> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF) <
> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)>>
> >      >
> >      >     What is the state there? Is it usable for USB HID? Or, how
> hard
> >      >     would it be to make it usable? Even a modbus description will
> >     do --
> >      >     implementing the modbus server (yes, server, I'm being
> >      >     politically-correct) over serial or even TCP is easy, if only
> >     there
> >      >     was a way to dump a CSV with register descriptions in some
> >     magical
> >      >     driver...
> >      >
> >      >     And yet another approach which comes to mind is to implement
> my
> >      >     driver as an external executable. This may be completely
> >     unfeasible
> >      >     and stupid, and please let me know if it is. But, from what I
> >      >     gather, drivers run in their own process and talk to the
> >     daemon via
> >      >     a UNIX socket. Why not make it possible for the driver to be
> just
> >      >     any executable, built/deployed outside of the NUT codebase?
> The
> >      >     socket protocol seems simple enough, and this will allow for
> ...
> >      >     creativity. It could be implemented in any language (including
> >      >     scripting languages) and need not depend on anything
> >     NUT-specific,
> >      >     other than maybe some common CLI interface and/or
> configuration.
> >      >
> >      >     I'm hoping the NUT masters will have some insight. Thanks for
> >      >     working on this!
> >      >
> >      >     Cheers,
> >      >     Kiril
> >      >     _______________________________________________
> >      >     Nut-upsuser mailing list
> >      > Nut-upsuser at alioth-lists.debian.net
> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
> >      >     <mailto:Nut-upsuser at alioth-lists.debian.net
> >     <mailto:Nut-upsuser at alioth-lists.debian.net>>
> >      >
> >     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> >     <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> >      >
> >       <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>>
> >      >
> >      >
> >      > _______________________________________________
> >      > Nut-upsuser mailing list
> >      > Nut-upsuser at alioth-lists.debian.net
> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
> >      >
> >     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> >     <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> >
> >     _______________________________________________
> >     Nut-upsuser mailing list
> >     Nut-upsuser at alioth-lists.debian.net
> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
> >     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> >     <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> >
> >
> > _______________________________________________
> > Nut-upsuser mailing list
> > Nut-upsuser at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
> Cheers, Gene Heskett, CET.
> --
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240516/5e821874/attachment-0001.htm>

From jimklimov+nut at gmail.com  Fri May 17 13:42:29 2024
From: jimklimov+nut at gmail.com (Jim Klimov)
Date: Fri, 17 May 2024 14:42:29 +0200
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort
 butmaximum gain
In-Reply-To: <CAFwg=jC3y=Mwg2nUmhwAXCBy_uLOxUSw2SD48t5kbNJJEVBuhw@mail.gmail.com>
References: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
 <CAFwg=jAFjRHaRUuYMfgnWiazA5Ng+ad3cZ5gpL+3xsBfYhZwEg@mail.gmail.com>
 <806d09dc-8ef9-4d07-bfb8-74530f9a46d2@campercaver.net>
 <CAJYg8vJvurgRACRt+Yu2ovEAKQWETT2-esEFdj5daFVV8QY6_Q@mail.gmail.com>
 <49275515-9eb6-4110-9bc6-feea9660fafb@shentel.net>
 <CAFwg=jC3y=Mwg2nUmhwAXCBy_uLOxUSw2SD48t5kbNJJEVBuhw@mail.gmail.com>
Message-ID: <CAJYg8vKaxxJA5iT_=EWf5_BRSMd-BnEY3t+wrUgzxNSXtuFQmQ@mail.gmail.com>

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 `subdriver` in config - to use the specific mapping for the
specified vendorid:productid (and/or other matching options involved),
allowing for IDs not yet known to NUT (built into any driver) or to use a
different subdriver than the one associated with those IDs (some vendors
historically have same IDs used for significantly different products).
Either way, while it is ideally preferable to test and post PRs with
correct out-of-the-box detection of devices handled by this or that code,
the specimens seen roaming in the wild keep eluding any pre-created
matchers that are set in stone for the particular build of (packaged) NUT.
This feature allows for at least some more tweaks and experiments in the
field.

Hope this helps,
Jim Kl.imov



On Fri, May 17, 2024 at 1:05?PM Kelly Byrd <kbyrd at memcpy.com> wrote:

> 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 how to do
> this safely, size components appropriately, etc.
>
> My goal is to keep a home Internet connection available during a power
> outage. This doesn't happen that often, but it bugged me when it did and I
> like playing with power-related things, so this became a fun project to
> tackle. I guess I should mention that my home network gear is in a rack in
> the garage. "modem", router, switch, wifi APs powered over PoE from the
> switch, NAS, and typically a Raspberry Pi or two doing whatever "always on"
> things I want. I also previously built a substantial portable battery box
> that will power other appliances like TVs and computers, but the networking
> gear is all in the garage and I can't power both at once without some very
> long extension cables snaking through the house.
>
> I noticed a few years ago that my Internet connection stayed up during a
> couple of different neighborhood power outages, assuming I could power the
> gear on my side. I guess the equipment on the ISP side is far enough away
> that it isn't affected? For a few years, I did this with a 12V inverter
> connected to an EV (an electric car). It turns out the 12V system in many
> EVs will provide 12V power through a DC step-down from the main traction
> battery. I really only need like 15A and previous testing made me confident
> I could safely do this as long as the main battery had capacity left. So, I
> did that for a while, but earlier this year we sold the EV and became a
> one-car household. So...what do I do? I had an inverter, if I could get
> batteries and a way to charge them, I should be most of my way toward a DIY
> UPS, right?
>
> Specs/Requirements
> * AC power needed is typically about 150W, I typically use 300W as a value
> for max surge. If I turn off my NAS, the load is only about 50-55W AC. I
> was aiming for 2-3 days of power for this load, and can live without the
> NAS during an outage, so I need 2.8-4.3kWh of capacity with the NAS off.
>
> * While I do want this to work, this is a fun personal project. Mucking
> with it is part of the goal. I had some hobby money to spend, but not
> infinite. I wanted to reuse things I had on hand or could get easily for
> v1. I also get to decide how reliable it needs to be.
>
> The system is:
> * AIMS Pure Sine 12V 600W Inverter. I had it already. Having this inverter
> on hand drove the decision for 12V vs 24/48V. Also, power needs are
> relatively low so 12V doesn't lead to more than 55A of current, and that's
> only when charging from a deep discharge.
>
> * RV Converter/Charger: PowerMax PM4 55A 12V. This is a lead acid battery
> charger that will also provide power after batteries are charged. Many
> battery chargers are not designed to be run 24/7, this one is.
>
> * Two 12V 200Ah Renology AGM deep cycle batteries wired in parallel. Got a
> deal on these. I decided I was ok with 75%-80% DoD even though these are
> lead acid. This gives me about 3.5kWh of usable AC capacity.
>
> * Batteries and charger are wired up with 4AWG, the inverter is something
> smaller, I think 6AWG?
>
>
> What I have built is a double conversion online system. The inverter is
> powering the AC load all the time. There's no transfer switch. There's
> lower efficiency when power is on because the normal power path is always
> AC->DC->AC. I did this because I wasn't confident in my ability to find a
> transfer switch that would transfer fast enough and it was one more thing
> to figure out and buy. In my head, this online architecture is simpler, but
> I may change it in the next version. I worry a bit about the inverter being
> ok running full time, but since it is rated for 600W and I use only 150W
> all the time, I decided it's ok. When it fails, I'll figure out something
> else.
>
> I chose lead acid deep-cycle batteries because if you're willing to
> discharge them to 70-80% they're very cost effective vs LiFePO4 or other
> lithium types. I know this will shorten the number of cycles I get from
> them. I'm ok with that. In this application, they sit at 100% for all but
> maybe a few hours to a few days a year. They may see one or two deep
> discharges a year. If I get five years out of them, that's great!
>
> I calculated roughly 3.5kWh of usable capacity for these two wired in
> parallel. Running with the NAS off is maybe 5A from the DC side of things,
> which is a really low load for a 400Ah battery bank. They are very heavy,
> but I already had a heavy duty storage rack next to the load, so that's not
> a problem in this case. Also, the voltage range for 12V lead acid batteries
> is still better supported than LiFePO4. Right now, there are still more
> (and lower cost) chargers and inverters that assume a lead acid voltage
> range. As an example, my inverter will shut down if it sees over about
> 14.6V.
>
> So, how does this fit into NUT? One key aspect of my capacity planning
> was: "normal load is ~150W, but if the NAS turns off, I can make that
> 50-60W.". My NAS is a QNAP, it has NUT installed. Before this DIY UPS, I
> was using an APC consumer UPS connected to the NAS via USB so it would turn
> off 5 min after mains power went off. That's the behavior I wanted for my
> DIY UPS.
>
> So how did I do this?
>
> Gear:
> * Arduino Pro Micro clone. It has a micro USB port built in and is
> commonly used for "make an Arduino appear to be some USB device" projects.
> It can be powered over USB, or by 5VDC directly to pins.
>
> * AC detection module: https://www.amazon.com/gp/product/B082PWV586.
> Gives me an opto-isolated "is the mains AC present" signal the Arduino can
> read.
>
> * Raspberry Pi running NUT. I wish I didn't need this, but I do for now.
> While building and debugging the Arduino code, I needed to modify the NUT
> code. Those patches made it in v2.8.1 and v2.8.2 NUT releases, but I still
> don't think my QNAP NAS has v2.8.2 available. I eventually plan to remove
> this.
>
> I put the AC detection module and the Arduino inside the PowerMax
> converter/charger enclosure, on a little 3D printed mount. The AC module
> connect to the AC input terminals inside the PowerMax and then the signal
> side connects to a pin on the Arduino and pulls it high (or low, I forget)
> when the AC is gone. I run a USB cable out of the PowerMax case which
> connects to the RPi running NUT. The RPi is powered by the inverter, and it
> powers the Arduino over USB. The RPi stays on during a power outage.
>
> So now I can write some Arduino code that loops and checks the status of a
> digital pin. How do I pretend to be a UPS in a way NUT will recognize?
>
> Some googling led me to the HIDPowerDevice project.
> https://github.com/abratchik/HIDPowerDevice. That is a library for
> Arduino MCUs that does all the protocol for getting an Arduino device to be
> recognized as a HID compliant UPS device over USB. You use it by
> periodically calling a `sendReport` function with various flags set. Ex:
> PowerDevice.sendReport(HID_PD_REMAININGCAPACITY, &iRemaining,
> sizeof(iRemaining));
> PowerDevice.sendReport(HID_PD_PRESENTSTATUS, &iPresentStatus,
> sizeof(iPresentStatus));
>
> `iPresentStatus` is a bit field with a ton of info in it, like:
> PRESENTSTATUS_ACPRESENT, PRESENTSTATUS_DISCHARGING,
> PRESENTSTATUS_CHARGING, etc. See the project for full details.
>
> So, now my Arduino code loop does this:
> Check status of AC on/off pin.
> Set/clear PRESENTSTATUS_ACPRESENT and set
> PRESENTSTATUS_CHARGING/PRESENTSTATUS_DISCHARGING accordingly.
> Call `sendReport` from the HIDPowerDevice library.
> Sleep a second, loop.
>
> In reality, my loop does a little bit more than this. It loops every
> second, but only sends a report if some status changed but waits no more
> than every 5 seconds between reports in any case. NUT (and Windows, and
> MacOS) seem to expect this.
>
> So, assuming I can get NUT to recognize the Arduino Micro as a UPS, this
> should work. I had two problems getting NUT to recognize the Arduino:
> 1) Will NUT recognize the default Arduino vendor and product id (vid:pid)?
> The answer is YES! There is an Arduino subdriver for usbhid in NUT. It
> looks like the HIDPowerDevice project author added this originally a few
> years ago! See drivers/arduino-hid.c for the list of supported IDs. If you
> end up with an Arduino device that has another vid/pid combo, it would need
> to be added there.
>
> 2) When using the HIDPowerDevice library, the Arduino Micro presents as a
> composite HID device, so it is more than one HID type at once. AFAICT, real
> world examples of composite devices are rare, but it is in the HID spec. In
> this exact case the Arduino presents as both serial/comm interface
> (typically used for debug output when running code from the Arduino IDE)
> and as a HID Power Device (the HID term for UPS status over USB). This all
> works now as of NUT 2.8.2.
>
> Note that the Arduino subdriver is not as full featured as something like
> the APC subdriver. I don't think it allows for NUT to set values on the
> Arduino HID device. I don't know if the Arduino HIDPowerDevice library
> supports this either. I have only tested the send-a-report-periodically
> code path.
>
> NUT config
> What I really wanted was for my NAS to shut down when mains power goes
> away. My QNAP NAS runs NUT, but I needed 2.8.2 and getting a new version on
> there was more than I wanted to tackle, especially since my PRs weren't in
> a release version of NUT at that time. So I run a NUT server on a Raspberry
> PI which is connected via USB to my DIY-NAS Arduino. The RPi does not react
> to changes in the UPS at all. It  makes them available over the network to
> the NUT instance running on the QNAP NAS. The QNAP NAS is then configured
> to poll the RPi NUT instance for UPS status and set to shut down if AC
> power is out for 5 min. I would rather not deal with this extra RPi in the
> setup, but it was the easiest way forward for me. Once NUT 2.8.2 is
> available for my QNAP NAS. I'll get rid of it.
>
>
> Optional Upgrade
> DC voltage sensing to give an idea of remaining runtime or remaining
> capacity. Since this is too long already, I'll try to be brief. One thing I
> did a month or so after the initial install was add DC voltage detection to
> the Arduino side of things:
>
> Gear:
> * 0-25VDC voltage sensor (https://www.amazon.com/gp/product/B01HTC4XKY).
> It's a voltage divider, let's my code sense the DC voltage.
>
> * External ADC: ADS1115 board. I wanted higher resolution DC voltage
> detection.
>
> My code then changed to take readings from the ADS1115 and convert that
> into a rough "50-100% capacity remaining" that I can report to NUT. It took
> a while to get right and it's only "accurate enough", not "trust this to a
> millivolt level of accuracy". For now it's just nice to have and I enjoyed
> having to learn about ADC measuring on Arduino enough to get this accurate
> enough to report with 1% differences in capacity.
>
> Future
> I've been researching designing a PCB and doing an "all-in-one" UPS. I'll
> talk more about that on the wiki page as well.
>
> I guess I should share my Arduino code on GitHub too.
>
> On Thu, May 16, 2024 at 10:59?AM gene heskett via Nut-upsuser <
> nut-upsuser at alioth-lists.debian.net> wrote:
>
>> 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...
>> >
>> > Jim
>> >
>> Great Idea Jim.
>> >
>> > On Thu, May 16, 2024 at 1:29?PM Bill Gee <bgee at campercaver.net
>> > <mailto:bgee at campercaver.net>> wrote:
>> >
>> >     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 voltage?  What is the power
>> capacity of
>> >     the inverter?
>> >
>> >     Which Arduino did you use?  All of my Arduino projects use the Pro
>> >     Mini,
>> >     though it would be quite easy to get some other model for this.
>> >
>> >     Thanks -
>> >     ===============
>> >     Bill Gee
>> >
>> >     On 5/15/24 20:11, Kelly Byrd wrote:
>> >      > I put together my own DIY UPS,  it's a RV charger/converter, an
>> >      > inverter, and some batteries. I use an Arduino and the
>> >     HIDPowerDevice
>> >      > library (https://github.com/abratchik/HIDPowerDevice
>> >     <https://github.com/abratchik/HIDPowerDevice>
>> >      > <https://github.com/abratchik/HIDPowerDevice
>> >     <https://github.com/abratchik/HIDPowerDevice>>) to get it to talk
>> to
>> >     NUT.
>> >      > Been working great for months!
>> >      >
>> >      > The Arduino is connected to two modules:
>> >      > * AC detection circuit to measure mains power on/off
>> >      > * Voltage divider and an external ADC to get a reasonably good DC
>> >      > voltage level for the battery which I turn into the a charge
>> >     percentage.
>> >      >
>> >      > This uses the USBHID driver in NUT and "just works" as long as
>> >     you're
>> >      > using NUT 2.8.2 or later. I used the example code in the
>> >     HIDPowerDevice
>> >      > library as a starting point for running on my Arduino.
>> >      >
>> >      > I can share more specifics about the Arduino side of things off
>> >     list if
>> >      > you want, the NUT side of things is pretty boring and normal.
>> >      >
>> >      > On Wed, May 15, 2024 at 3:27?PM Kiril Zyapkov via Nut-upsuser
>> >      > <nut-upsuser at alioth-lists.debian.net
>> >     <mailto:nut-upsuser at alioth-lists.debian.net>
>> >      > <mailto:nut-upsuser at alioth-lists.debian.net
>> >     <mailto:nut-upsuser at alioth-lists.debian.net>>> wrote:
>> >      >
>> >      >     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
>> <
>> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html>
>> <
>> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html
>> <
>> 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
>> >     online
>> >      >     for as long as the battery lasts and then provide a mechanism
>> >     for a
>> >      >     graceful shutdown of my NAS and other appliances for which
>> >     cutting
>> >      >     power would not be healthy. The project above is missing the
>> >      >     "connected" part. I want to get mine to play with NUT nicely.
>> >     Other
>> >      >     prior art is this project:
>> >      >
>> >      >     [2] https://github.com/xm381/Raspberry-Pi-UPS
>> >     <https://github.com/xm381/Raspberry-Pi-UPS>
>> >      >     <https://github.com/xm381/Raspberry-Pi-UPS
>> >     <https://github.com/xm381/Raspberry-Pi-UPS>>
>> >      >
>> >      >     Mentioned in a previous thread here:
>> >      >
>> >      >     [3]
>> >      >
>> >
>> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
>> <
>> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html>
>> <
>> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
>> <
>> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
>> >>
>> >      >
>> >      >     A valid approach -- emulates an existing protocol on an
>> arduino.
>> >      >
>> >      >     Are there other similar projects that you know of? I found
>> >     plenty of
>> >      >     "DIY UPS" projects, but none were "smart".
>> >      >
>> >      >     I am able to put together firmware for some micro which will
>> take
>> >      >     care of measuring voltages, currents, possibly also turn
>> on/off
>> >      >     loads, serial or USB or IP are options. Not sure yet what
>> >     hardware
>> >      >     features I'll put together, but this depends somewhat on the
>> >      >     approach for getting this thing integrated with NUT. PSUs and
>> >      >     batteries are already on the way, and my junk drawers have
>> most
>> >      >     other parts I may need.
>> >      >
>> >      >     So, options found so far:
>> >      >
>> >      >     * Use genericups. Least favorite option, very limited
>> features
>> >      >
>> >      >     * Use the same approach as [2]. If I were to go that route --
>> >     which
>> >      >     is the best protocol to pick for emulation? I'm looking for
>> >      >     something simple, extensible/flexible and well-documented.
>> >      >
>> >      >     But what I really wish was possible was the ability to
>> >     describe my
>> >      >     device in some format, feed it to a generic driver in NUT and
>> >      >     profit. I see some efforts have been made in this direction,
>> most
>> >      >     notably:
>> >      >
>> >      >     [4]
>> >      >
>> >     https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
>> >     <
>> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)>
>> >      >
>> >       <
>> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF) <
>> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)>>
>> >      >
>> >      >     What is the state there? Is it usable for USB HID? Or, how
>> hard
>> >      >     would it be to make it usable? Even a modbus description will
>> >     do --
>> >      >     implementing the modbus server (yes, server, I'm being
>> >      >     politically-correct) over serial or even TCP is easy, if only
>> >     there
>> >      >     was a way to dump a CSV with register descriptions in some
>> >     magical
>> >      >     driver...
>> >      >
>> >      >     And yet another approach which comes to mind is to implement
>> my
>> >      >     driver as an external executable. This may be completely
>> >     unfeasible
>> >      >     and stupid, and please let me know if it is. But, from what I
>> >      >     gather, drivers run in their own process and talk to the
>> >     daemon via
>> >      >     a UNIX socket. Why not make it possible for the driver to be
>> just
>> >      >     any executable, built/deployed outside of the NUT codebase?
>> The
>> >      >     socket protocol seems simple enough, and this will allow for
>> ...
>> >      >     creativity. It could be implemented in any language
>> (including
>> >      >     scripting languages) and need not depend on anything
>> >     NUT-specific,
>> >      >     other than maybe some common CLI interface and/or
>> configuration.
>> >      >
>> >      >     I'm hoping the NUT masters will have some insight. Thanks for
>> >      >     working on this!
>> >      >
>> >      >     Cheers,
>> >      >     Kiril
>> >      >     _______________________________________________
>> >      >     Nut-upsuser mailing list
>> >      > Nut-upsuser at alioth-lists.debian.net
>> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
>> >      >     <mailto:Nut-upsuser at alioth-lists.debian.net
>> >     <mailto:Nut-upsuser at alioth-lists.debian.net>>
>> >      >
>> >
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>> >     <
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
>> >      >
>> >       <
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser <
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>>
>> >      >
>> >      >
>> >      > _______________________________________________
>> >      > Nut-upsuser mailing list
>> >      > Nut-upsuser at alioth-lists.debian.net
>> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
>> >      >
>> >
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>> >     <
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
>> >
>> >     _______________________________________________
>> >     Nut-upsuser mailing list
>> >     Nut-upsuser at alioth-lists.debian.net
>> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
>> >
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>> >     <
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
>> >
>> >
>> > _______________________________________________
>> > Nut-upsuser mailing list
>> > Nut-upsuser at alioth-lists.debian.net
>> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>> Cheers, Gene Heskett, CET.
>> --
>> "There are four boxes to be used in defense of liberty:
>>   soap, ballot, jury, and ammo. Please use in that order."
>> -Ed Howdershelt (Author, 1940)
>> If we desire respect for the law, we must first make the law respectable.
>>   - Louis D. Brandeis
>>
>>
>> _______________________________________________
>> Nut-upsuser mailing list
>> Nut-upsuser at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240517/c85c1933/attachment-0001.htm>

From kbyrd at memcpy.com  Fri May 17 15:06:47 2024
From: kbyrd at memcpy.com (Kelly Byrd)
Date: Fri, 17 May 2024 07:06:47 -0700
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort
 butmaximum gain
In-Reply-To: <CAJYg8vKaxxJA5iT_=EWf5_BRSMd-BnEY3t+wrUgzxNSXtuFQmQ@mail.gmail.com>
References: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
 <CAFwg=jAFjRHaRUuYMfgnWiazA5Ng+ad3cZ5gpL+3xsBfYhZwEg@mail.gmail.com>
 <806d09dc-8ef9-4d07-bfb8-74530f9a46d2@campercaver.net>
 <CAJYg8vJvurgRACRt+Yu2ovEAKQWETT2-esEFdj5daFVV8QY6_Q@mail.gmail.com>
 <49275515-9eb6-4110-9bc6-feea9660fafb@shentel.net>
 <CAFwg=jC3y=Mwg2nUmhwAXCBy_uLOxUSw2SD48t5kbNJJEVBuhw@mail.gmail.com>
 <CAJYg8vKaxxJA5iT_=EWf5_BRSMd-BnEY3t+wrUgzxNSXtuFQmQ@mail.gmail.com>
Message-ID: <CAFwg=jBMHdcOTjgGvaBEQucBV48OjOb5+NjU9thB9yufHbQUWw@mail.gmail.com>

Re "DIY-NAS", that was a typo. I did mean "DIY-UPS" as you suspected.

Re: Using custom vid:pid while specifying the arduino subdriver, I didn't
know that! So if someone finds a particular board that doesn't match, they
could still move forward without needing to patch NUT. Nice!



On Fri, May 17, 2024 at 5:42?AM Jim Klimov <jimklimov+nut at gmail.com> wrote:

> 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 `subdriver` in config - to use the specific mapping for the
> specified vendorid:productid (and/or other matching options involved),
> allowing for IDs not yet known to NUT (built into any driver) or to use a
> different subdriver than the one associated with those IDs (some vendors
> historically have same IDs used for significantly different products).
> Either way, while it is ideally preferable to test and post PRs with
> correct out-of-the-box detection of devices handled by this or that code,
> the specimens seen roaming in the wild keep eluding any pre-created
> matchers that are set in stone for the particular build of (packaged) NUT.
> This feature allows for at least some more tweaks and experiments in the
> field.
>
> Hope this helps,
> Jim Kl.imov
>
>
>
> On Fri, May 17, 2024 at 1:05?PM Kelly Byrd <kbyrd at memcpy.com> wrote:
>
>> 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 how to do
>> this safely, size components appropriately, etc.
>>
>> My goal is to keep a home Internet connection available during a power
>> outage. This doesn't happen that often, but it bugged me when it did and I
>> like playing with power-related things, so this became a fun project to
>> tackle. I guess I should mention that my home network gear is in a rack in
>> the garage. "modem", router, switch, wifi APs powered over PoE from the
>> switch, NAS, and typically a Raspberry Pi or two doing whatever "always on"
>> things I want. I also previously built a substantial portable battery box
>> that will power other appliances like TVs and computers, but the networking
>> gear is all in the garage and I can't power both at once without some very
>> long extension cables snaking through the house.
>>
>> I noticed a few years ago that my Internet connection stayed up during a
>> couple of different neighborhood power outages, assuming I could power the
>> gear on my side. I guess the equipment on the ISP side is far enough away
>> that it isn't affected? For a few years, I did this with a 12V inverter
>> connected to an EV (an electric car). It turns out the 12V system in many
>> EVs will provide 12V power through a DC step-down from the main traction
>> battery. I really only need like 15A and previous testing made me confident
>> I could safely do this as long as the main battery had capacity left. So, I
>> did that for a while, but earlier this year we sold the EV and became a
>> one-car household. So...what do I do? I had an inverter, if I could get
>> batteries and a way to charge them, I should be most of my way toward a DIY
>> UPS, right?
>>
>> Specs/Requirements
>> * AC power needed is typically about 150W, I typically use 300W as a
>> value for max surge. If I turn off my NAS, the load is only about 50-55W
>> AC. I was aiming for 2-3 days of power for this load, and can live without
>> the NAS during an outage, so I need 2.8-4.3kWh of capacity with the NAS off.
>>
>> * While I do want this to work, this is a fun personal project. Mucking
>> with it is part of the goal. I had some hobby money to spend, but not
>> infinite. I wanted to reuse things I had on hand or could get easily for
>> v1. I also get to decide how reliable it needs to be.
>>
>> The system is:
>> * AIMS Pure Sine 12V 600W Inverter. I had it already. Having this
>> inverter on hand drove the decision for 12V vs 24/48V. Also, power needs
>> are relatively low so 12V doesn't lead to more than 55A of current, and
>> that's only when charging from a deep discharge.
>>
>> * RV Converter/Charger: PowerMax PM4 55A 12V. This is a lead acid battery
>> charger that will also provide power after batteries are charged. Many
>> battery chargers are not designed to be run 24/7, this one is.
>>
>> * Two 12V 200Ah Renology AGM deep cycle batteries wired in parallel. Got
>> a deal on these. I decided I was ok with 75%-80% DoD even though these are
>> lead acid. This gives me about 3.5kWh of usable AC capacity.
>>
>> * Batteries and charger are wired up with 4AWG, the inverter is something
>> smaller, I think 6AWG?
>>
>>
>> What I have built is a double conversion online system. The inverter is
>> powering the AC load all the time. There's no transfer switch. There's
>> lower efficiency when power is on because the normal power path is always
>> AC->DC->AC. I did this because I wasn't confident in my ability to find a
>> transfer switch that would transfer fast enough and it was one more thing
>> to figure out and buy. In my head, this online architecture is simpler, but
>> I may change it in the next version. I worry a bit about the inverter being
>> ok running full time, but since it is rated for 600W and I use only 150W
>> all the time, I decided it's ok. When it fails, I'll figure out something
>> else.
>>
>> I chose lead acid deep-cycle batteries because if you're willing to
>> discharge them to 70-80% they're very cost effective vs LiFePO4 or other
>> lithium types. I know this will shorten the number of cycles I get from
>> them. I'm ok with that. In this application, they sit at 100% for all but
>> maybe a few hours to a few days a year. They may see one or two deep
>> discharges a year. If I get five years out of them, that's great!
>>
>> I calculated roughly 3.5kWh of usable capacity for these two wired in
>> parallel. Running with the NAS off is maybe 5A from the DC side of things,
>> which is a really low load for a 400Ah battery bank. They are very heavy,
>> but I already had a heavy duty storage rack next to the load, so that's not
>> a problem in this case. Also, the voltage range for 12V lead acid batteries
>> is still better supported than LiFePO4. Right now, there are still more
>> (and lower cost) chargers and inverters that assume a lead acid voltage
>> range. As an example, my inverter will shut down if it sees over about
>> 14.6V.
>>
>> So, how does this fit into NUT? One key aspect of my capacity planning
>> was: "normal load is ~150W, but if the NAS turns off, I can make that
>> 50-60W.". My NAS is a QNAP, it has NUT installed. Before this DIY UPS, I
>> was using an APC consumer UPS connected to the NAS via USB so it would turn
>> off 5 min after mains power went off. That's the behavior I wanted for my
>> DIY UPS.
>>
>> So how did I do this?
>>
>> Gear:
>> * Arduino Pro Micro clone. It has a micro USB port built in and is
>> commonly used for "make an Arduino appear to be some USB device" projects.
>> It can be powered over USB, or by 5VDC directly to pins.
>>
>> * AC detection module: https://www.amazon.com/gp/product/B082PWV586.
>> Gives me an opto-isolated "is the mains AC present" signal the Arduino can
>> read.
>>
>> * Raspberry Pi running NUT. I wish I didn't need this, but I do for now.
>> While building and debugging the Arduino code, I needed to modify the NUT
>> code. Those patches made it in v2.8.1 and v2.8.2 NUT releases, but I still
>> don't think my QNAP NAS has v2.8.2 available. I eventually plan to remove
>> this.
>>
>> I put the AC detection module and the Arduino inside the PowerMax
>> converter/charger enclosure, on a little 3D printed mount. The AC module
>> connect to the AC input terminals inside the PowerMax and then the signal
>> side connects to a pin on the Arduino and pulls it high (or low, I forget)
>> when the AC is gone. I run a USB cable out of the PowerMax case which
>> connects to the RPi running NUT. The RPi is powered by the inverter, and it
>> powers the Arduino over USB. The RPi stays on during a power outage.
>>
>> So now I can write some Arduino code that loops and checks the status of
>> a digital pin. How do I pretend to be a UPS in a way NUT will recognize?
>>
>> Some googling led me to the HIDPowerDevice project.
>> https://github.com/abratchik/HIDPowerDevice. That is a library for
>> Arduino MCUs that does all the protocol for getting an Arduino device to be
>> recognized as a HID compliant UPS device over USB. You use it by
>> periodically calling a `sendReport` function with various flags set. Ex:
>> PowerDevice.sendReport(HID_PD_REMAININGCAPACITY, &iRemaining,
>> sizeof(iRemaining));
>> PowerDevice.sendReport(HID_PD_PRESENTSTATUS, &iPresentStatus,
>> sizeof(iPresentStatus));
>>
>> `iPresentStatus` is a bit field with a ton of info in it, like:
>> PRESENTSTATUS_ACPRESENT, PRESENTSTATUS_DISCHARGING,
>> PRESENTSTATUS_CHARGING, etc. See the project for full details.
>>
>> So, now my Arduino code loop does this:
>> Check status of AC on/off pin.
>> Set/clear PRESENTSTATUS_ACPRESENT and set
>> PRESENTSTATUS_CHARGING/PRESENTSTATUS_DISCHARGING accordingly.
>> Call `sendReport` from the HIDPowerDevice library.
>> Sleep a second, loop.
>>
>> In reality, my loop does a little bit more than this. It loops every
>> second, but only sends a report if some status changed but waits no more
>> than every 5 seconds between reports in any case. NUT (and Windows, and
>> MacOS) seem to expect this.
>>
>> So, assuming I can get NUT to recognize the Arduino Micro as a UPS, this
>> should work. I had two problems getting NUT to recognize the Arduino:
>> 1) Will NUT recognize the default Arduino vendor and product id
>> (vid:pid)? The answer is YES! There is an Arduino subdriver for usbhid in
>> NUT. It looks like the HIDPowerDevice project author added this originally
>> a few years ago! See drivers/arduino-hid.c for the list of supported IDs.
>> If you end up with an Arduino device that has another vid/pid combo, it
>> would need to be added there.
>>
>> 2) When using the HIDPowerDevice library, the Arduino Micro presents as a
>> composite HID device, so it is more than one HID type at once. AFAICT, real
>> world examples of composite devices are rare, but it is in the HID spec. In
>> this exact case the Arduino presents as both serial/comm interface
>> (typically used for debug output when running code from the Arduino IDE)
>> and as a HID Power Device (the HID term for UPS status over USB). This all
>> works now as of NUT 2.8.2.
>>
>> Note that the Arduino subdriver is not as full featured as something like
>> the APC subdriver. I don't think it allows for NUT to set values on the
>> Arduino HID device. I don't know if the Arduino HIDPowerDevice library
>> supports this either. I have only tested the send-a-report-periodically
>> code path.
>>
>> NUT config
>> What I really wanted was for my NAS to shut down when mains power goes
>> away. My QNAP NAS runs NUT, but I needed 2.8.2 and getting a new version on
>> there was more than I wanted to tackle, especially since my PRs weren't in
>> a release version of NUT at that time. So I run a NUT server on a Raspberry
>> PI which is connected via USB to my DIY-NAS Arduino. The RPi does not react
>> to changes in the UPS at all. It  makes them available over the network to
>> the NUT instance running on the QNAP NAS. The QNAP NAS is then configured
>> to poll the RPi NUT instance for UPS status and set to shut down if AC
>> power is out for 5 min. I would rather not deal with this extra RPi in the
>> setup, but it was the easiest way forward for me. Once NUT 2.8.2 is
>> available for my QNAP NAS. I'll get rid of it.
>>
>>
>> Optional Upgrade
>> DC voltage sensing to give an idea of remaining runtime or remaining
>> capacity. Since this is too long already, I'll try to be brief. One thing I
>> did a month or so after the initial install was add DC voltage detection to
>> the Arduino side of things:
>>
>> Gear:
>> * 0-25VDC voltage sensor (https://www.amazon.com/gp/product/B01HTC4XKY).
>> It's a voltage divider, let's my code sense the DC voltage.
>>
>> * External ADC: ADS1115 board. I wanted higher resolution DC voltage
>> detection.
>>
>> My code then changed to take readings from the ADS1115 and convert that
>> into a rough "50-100% capacity remaining" that I can report to NUT. It took
>> a while to get right and it's only "accurate enough", not "trust this to a
>> millivolt level of accuracy". For now it's just nice to have and I enjoyed
>> having to learn about ADC measuring on Arduino enough to get this accurate
>> enough to report with 1% differences in capacity.
>>
>> Future
>> I've been researching designing a PCB and doing an "all-in-one" UPS. I'll
>> talk more about that on the wiki page as well.
>>
>> I guess I should share my Arduino code on GitHub too.
>>
>> On Thu, May 16, 2024 at 10:59?AM gene heskett via Nut-upsuser <
>> nut-upsuser at alioth-lists.debian.net> wrote:
>>
>>> 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...
>>> >
>>> > Jim
>>> >
>>> Great Idea Jim.
>>> >
>>> > On Thu, May 16, 2024 at 1:29?PM Bill Gee <bgee at campercaver.net
>>> > <mailto:bgee at campercaver.net>> wrote:
>>> >
>>> >     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 voltage?  What is the power
>>> capacity of
>>> >     the inverter?
>>> >
>>> >     Which Arduino did you use?  All of my Arduino projects use the Pro
>>> >     Mini,
>>> >     though it would be quite easy to get some other model for this.
>>> >
>>> >     Thanks -
>>> >     ===============
>>> >     Bill Gee
>>> >
>>> >     On 5/15/24 20:11, Kelly Byrd wrote:
>>> >      > I put together my own DIY UPS,  it's a RV charger/converter, an
>>> >      > inverter, and some batteries. I use an Arduino and the
>>> >     HIDPowerDevice
>>> >      > library (https://github.com/abratchik/HIDPowerDevice
>>> >     <https://github.com/abratchik/HIDPowerDevice>
>>> >      > <https://github.com/abratchik/HIDPowerDevice
>>> >     <https://github.com/abratchik/HIDPowerDevice>>) to get it to talk
>>> to
>>> >     NUT.
>>> >      > Been working great for months!
>>> >      >
>>> >      > The Arduino is connected to two modules:
>>> >      > * AC detection circuit to measure mains power on/off
>>> >      > * Voltage divider and an external ADC to get a reasonably good
>>> DC
>>> >      > voltage level for the battery which I turn into the a charge
>>> >     percentage.
>>> >      >
>>> >      > This uses the USBHID driver in NUT and "just works" as long as
>>> >     you're
>>> >      > using NUT 2.8.2 or later. I used the example code in the
>>> >     HIDPowerDevice
>>> >      > library as a starting point for running on my Arduino.
>>> >      >
>>> >      > I can share more specifics about the Arduino side of things off
>>> >     list if
>>> >      > you want, the NUT side of things is pretty boring and normal.
>>> >      >
>>> >      > On Wed, May 15, 2024 at 3:27?PM Kiril Zyapkov via Nut-upsuser
>>> >      > <nut-upsuser at alioth-lists.debian.net
>>> >     <mailto:nut-upsuser at alioth-lists.debian.net>
>>> >      > <mailto:nut-upsuser at alioth-lists.debian.net
>>> >     <mailto:nut-upsuser at alioth-lists.debian.net>>> wrote:
>>> >      >
>>> >      >     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
>>> <
>>> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html>
>>> <
>>> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html
>>> <
>>> 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
>>> >     online
>>> >      >     for as long as the battery lasts and then provide a
>>> mechanism
>>> >     for a
>>> >      >     graceful shutdown of my NAS and other appliances for which
>>> >     cutting
>>> >      >     power would not be healthy. The project above is missing the
>>> >      >     "connected" part. I want to get mine to play with NUT
>>> nicely.
>>> >     Other
>>> >      >     prior art is this project:
>>> >      >
>>> >      >     [2] https://github.com/xm381/Raspberry-Pi-UPS
>>> >     <https://github.com/xm381/Raspberry-Pi-UPS>
>>> >      >     <https://github.com/xm381/Raspberry-Pi-UPS
>>> >     <https://github.com/xm381/Raspberry-Pi-UPS>>
>>> >      >
>>> >      >     Mentioned in a previous thread here:
>>> >      >
>>> >      >     [3]
>>> >      >
>>> >
>>> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
>>> <
>>> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html>
>>> <
>>> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
>>> <
>>> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
>>> >>
>>> >      >
>>> >      >     A valid approach -- emulates an existing protocol on an
>>> arduino.
>>> >      >
>>> >      >     Are there other similar projects that you know of? I found
>>> >     plenty of
>>> >      >     "DIY UPS" projects, but none were "smart".
>>> >      >
>>> >      >     I am able to put together firmware for some micro which
>>> will take
>>> >      >     care of measuring voltages, currents, possibly also turn
>>> on/off
>>> >      >     loads, serial or USB or IP are options. Not sure yet what
>>> >     hardware
>>> >      >     features I'll put together, but this depends somewhat on the
>>> >      >     approach for getting this thing integrated with NUT. PSUs
>>> and
>>> >      >     batteries are already on the way, and my junk drawers have
>>> most
>>> >      >     other parts I may need.
>>> >      >
>>> >      >     So, options found so far:
>>> >      >
>>> >      >     * Use genericups. Least favorite option, very limited
>>> features
>>> >      >
>>> >      >     * Use the same approach as [2]. If I were to go that route
>>> --
>>> >     which
>>> >      >     is the best protocol to pick for emulation? I'm looking for
>>> >      >     something simple, extensible/flexible and well-documented.
>>> >      >
>>> >      >     But what I really wish was possible was the ability to
>>> >     describe my
>>> >      >     device in some format, feed it to a generic driver in NUT
>>> and
>>> >      >     profit. I see some efforts have been made in this
>>> direction, most
>>> >      >     notably:
>>> >      >
>>> >      >     [4]
>>> >      >
>>> >
>>> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
>>> >     <
>>> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)>
>>> >      >
>>> >       <
>>> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF) <
>>> https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)>>
>>> >      >
>>> >      >     What is the state there? Is it usable for USB HID? Or, how
>>> hard
>>> >      >     would it be to make it usable? Even a modbus description
>>> will
>>> >     do --
>>> >      >     implementing the modbus server (yes, server, I'm being
>>> >      >     politically-correct) over serial or even TCP is easy, if
>>> only
>>> >     there
>>> >      >     was a way to dump a CSV with register descriptions in some
>>> >     magical
>>> >      >     driver...
>>> >      >
>>> >      >     And yet another approach which comes to mind is to
>>> implement my
>>> >      >     driver as an external executable. This may be completely
>>> >     unfeasible
>>> >      >     and stupid, and please let me know if it is. But, from what
>>> I
>>> >      >     gather, drivers run in their own process and talk to the
>>> >     daemon via
>>> >      >     a UNIX socket. Why not make it possible for the driver to
>>> be just
>>> >      >     any executable, built/deployed outside of the NUT codebase?
>>> The
>>> >      >     socket protocol seems simple enough, and this will allow
>>> for ...
>>> >      >     creativity. It could be implemented in any language
>>> (including
>>> >      >     scripting languages) and need not depend on anything
>>> >     NUT-specific,
>>> >      >     other than maybe some common CLI interface and/or
>>> configuration.
>>> >      >
>>> >      >     I'm hoping the NUT masters will have some insight. Thanks
>>> for
>>> >      >     working on this!
>>> >      >
>>> >      >     Cheers,
>>> >      >     Kiril
>>> >      >     _______________________________________________
>>> >      >     Nut-upsuser mailing list
>>> >      > Nut-upsuser at alioth-lists.debian.net
>>> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
>>> >      >     <mailto:Nut-upsuser at alioth-lists.debian.net
>>> >     <mailto:Nut-upsuser at alioth-lists.debian.net>>
>>> >      >
>>> >
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>> >     <
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
>>> >      >
>>> >       <
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser <
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>>
>>> >      >
>>> >      >
>>> >      > _______________________________________________
>>> >      > Nut-upsuser mailing list
>>> >      > Nut-upsuser at alioth-lists.debian.net
>>> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
>>> >      >
>>> >
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>> >     <
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
>>> >
>>> >     _______________________________________________
>>> >     Nut-upsuser mailing list
>>> >     Nut-upsuser at alioth-lists.debian.net
>>> >     <mailto:Nut-upsuser at alioth-lists.debian.net>
>>> >
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>> >     <
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
>>> >
>>> >
>>> > _______________________________________________
>>> > Nut-upsuser mailing list
>>> > Nut-upsuser at alioth-lists.debian.net
>>> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>
>>> Cheers, Gene Heskett, CET.
>>> --
>>> "There are four boxes to be used in defense of liberty:
>>>   soap, ballot, jury, and ammo. Please use in that order."
>>> -Ed Howdershelt (Author, 1940)
>>> If we desire respect for the law, we must first make the law respectable.
>>>   - Louis D. Brandeis
>>>
>>>
>>> _______________________________________________
>>> Nut-upsuser mailing list
>>> Nut-upsuser at alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>
>> _______________________________________________
>> Nut-upsuser mailing list
>> Nut-upsuser at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240517/fa78b460/attachment-0001.htm>

From jimklimov+nut at gmail.com  Sat May 18 18:09:42 2024
From: jimklimov+nut at gmail.com (Jim Klimov)
Date: Sat, 18 May 2024 19:09:42 +0200
Subject: [Nut-upsuser] Supporting a DIY UPS with minimal effort but
 maximum gain
In-Reply-To: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
References: <CANhGMAPyugyWdTobyVghjQ=G8yq891Lm=0Nj9OiVzGLO3EuunA@mail.gmail.com>
Message-ID: <CAJYg8vL6THJ8BAhmqC_WvuA_G-8AHt8J0S9KGV7DX4dCjKcOQQ@mail.gmail.com>

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 USB when customized code is involved. That
said, it is a long-term hope that one day this would be possible. Each
recent NUT release milestone had some work that chipped away the technical
barriers to including DMF into the main project.

  For a longer version: DMF was designed and developed, fairly well tested
and then a bit abandoned in the 42ITy fork of NUT, which went back to using
upstream NUT for their appliances. The developed code base however for a
long time acts as the source of backports for features and vendor device
nuances into upstream NUT to benefit everyone. That codebase is available
in the FTY branch, including DMF along with many other changes (thousands
of commits) so separating them into cleanly visible and revisable
increments, and digesting in the upstream code, aligning with protocol and
other changes that happened over the years, style and tests/quality gates,
is quite an effort. Conversely, merging back the upstream NUT into the FTY
codebase (to achieve green CI survival) was an effort that took a few
years, since the baseline was NUT v2.7.4 and codebases diverged
significantly in some spots - so there were quite a few warnings found that
needed addressing. Currently the FTY branch is relatively recently
synchronised with NUT, at least buildable and passes CI tests, including
the DMF aspect. And since the codebases converged again recently - now as
stuff gets upstreamed here and there, a mere resync and `git diff
FTY..master` helps see how much is left, what commits were missed or typos
added, and what can be picked up next :)

  DMF per se is an effort to separate the binary driver from data mappings,
in cases where logic remains the same and just the data points differ from
device to device (e.g. SNMP OIDs to query for information about different
aspects of UPS or ePDU state). This should well apply to USB HID and maybe
to nutdrv_qx; a recently added concept of `hwmon` driver (talking to sysfs
nodes) is also a good candidate.

  Initial development in the 42ITy project provided a separate library for
DMF general foundations, and build-time changes to the snmp-ups driver (and
nut-scanner snmp mode) to use mappings from XML files rather than built
into the driver binary once and forever until a rebuild. This allows for
smaller binaries on one hand, and for field-maintainable mappings (edit
XML, add another) to support new devices without changing NUT packages and
programs (of course, PRs would be welcome to add such changes to the
upstream library to be included in future releases). In fact, the few
differences for the core driver are hidden by `ifdef` (so there are two
binary builds, with built-in mappings and with DMF support), and the
`nut-scanner` tool is dually-capable in the same build. In fact, to test
the theory, NUT codebase in the branch provides scripts that convert
`*-mib.c` tables into equivalent DMF XML files, so a copy of `snmp-ups-dmf`
driver program with the bunch of text resource files is equivalent out of
the box to a monolithic `snmp-ups` binary built from same codebase, but
more extensible in the field afterwards.

  Part of "abandonment" of this approach was the uncertainty of how correct
the big wad of new code it is (hard to guarantee with that older NUT
baseline which naturally had thousands of warnings so lots of diagnostic
noise) and suspicions that it had memory leaks so maybe had issues with
long-term stability (not proven to be definitely the root cause of some
issues, as far as I am aware). Those were issues entangled with
semi-commercial project priorities (rush to market - pick the lowest
hanging fruits, backlog the rest) so it was left on a backburner, awaiting
a revival in upstream NUT.

  Another part was more technical, a sort of stalemate in design: many
mapping tables in NUT involve data conversions (e.g. date formats,
temperature units, integer milliVolts to floating-point Volts, text labels
for numeric enum values, etc.) for data transfers from a device or writes
back to it. In the current C codebase (*-mib.c, *-hid.c) there are helper
methods to which we can point from the tables. An equivalent for DMF, with
mappings conveyed by text files, involved adding LUA scripts with a LUA-C
bridge to pass the data from binary driver to scripting context and back.
This worked reasonably well; the problem was having two potentially
different implementations of the helpers (C and LUA) for mappings provided
with NUT - and no good way (at least back then) to either compare that they
behave identically or to eliminate one (likely the native C... but then add
LUA as a requirement for NUT builds everywhere and provide the LUA
implementations of helpers via files or built-in strings). This aspect
stalled in discussions - not an insurmountable problem, but no single
apparently good solution (at least fitting the commercial project's
constraints) was finalized.

  Probably a good way forward here is to track the C helper methods in the
NUT codebase in separate files (or wrapped by macros) so that scripting can
identify their existence. Then we can make sure the same set of code is
available in LUA, and that all of these are covered by unit tests. This
part seems fairly easy to automate, and can lead to a decent library of
helper implementations provided by NUT with DMF-capable releases. Probably
some duplicate efforts can also be identified this way. Note also that the
"problem" originally concerns the subdrivers provided by NUT as C mapping
tables *and* the requested ability to provide functionally identical DMF
clones. Discrepancies of C and LUA behaviors are not a problem for drivers
where DMF resource files are the only code base that defines the device
interactions.

  On the other hand, if we end up with a well defined library of C
implementations of popular/common helpers for the mappings, maybe it would
be viable to (re-)use known C method names from LUA with minimal one-line
scripts (or specially processed XML tags) pointing to the C library methods
built into a driverbinary right away - also simplifying the field support
for new devices that rely on same concepts as something that was already
handled earlier.

  To summarize - currently we have a branch (which is not yet upstreamed,
but finally is relatively close to that) with the core DMF library that can
store and process the mappings and LUA helpers, and a consumer of that
library for SNMP mapping purposes, further used by snmp-ups driver and
nut-scanner tool, and scripts that convert C mapping tables to DMF XML
files. There are some nuances about ensuring and testing their equivalence.
Once the approach is deemed unambiguously good, further sets of consumers
can be added for several other categories of drivers where logic is cleanly
separable from data mappings - most of these are largely C tables already.

Hope this helps,
Jim Klimov


On Thu, May 16, 2024 at 12:27?AM Kiril Zyapkov via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> 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 online for
> as long as the battery lasts and then provide a mechanism for a graceful
> shutdown of my NAS and other appliances for which cutting power would not
> be healthy. The project above is missing the "connected" part. I want to
> get mine to play with NUT nicely. Other prior art is this project:
>
> [2] https://github.com/xm381/Raspberry-Pi-UPS
>
> Mentioned in a previous thread here:
>
> [3]
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
>
> A valid approach -- emulates an existing protocol on an arduino.
>
> Are there other similar projects that you know of? I found plenty of "DIY
> UPS" projects, but none were "smart".
>
> I am able to put together firmware for some micro which will take care of
> measuring voltages, currents, possibly also turn on/off loads, serial or
> USB or IP are options. Not sure yet what hardware features I'll put
> together, but this depends somewhat on the approach for getting this thing
> integrated with NUT. PSUs and batteries are already on the way, and my junk
> drawers have most other parts I may need.
>
> So, options found so far:
>
> * Use genericups. Least favorite option, very limited features
>
> * Use the same approach as [2]. If I were to go that route -- which is the
> best protocol to pick for emulation? I'm looking for something simple,
> extensible/flexible and well-documented.
>
> But what I really wish was possible was the ability to describe my device
> in some format, feed it to a generic driver in NUT and profit. I see some
> efforts have been made in this direction, most notably:
>
> [4] https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
>
> What is the state there? Is it usable for USB HID? Or, how hard would it
> be to make it usable? Even a modbus description will do -- implementing the
> modbus server (yes, server, I'm being politically-correct) over serial or
> even TCP is easy, if only there was a way to dump a CSV with register
> descriptions in some magical driver...
>
> And yet another approach which comes to mind is to implement my driver as
> an external executable. This may be completely unfeasible and stupid, and
> please let me know if it is. But, from what I gather, drivers run in their
> own process and talk to the daemon via a UNIX socket. Why not make it
> possible for the driver to be just any executable, built/deployed outside
> of the NUT codebase? The socket protocol seems simple enough, and this will
> allow for ... creativity. It could be implemented in any language
> (including scripting languages) and need not depend on anything
> NUT-specific, other than maybe some common CLI interface and/or
> configuration.
>
> I'm hoping the NUT masters will have some insight. Thanks for working on
> this!
>
> Cheers,
> Kiril
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240518/622461d3/attachment.htm>