Nut upsuser - Feb 2023 - Using 'dummy.ups' for a real application, not just testing...

> On Feb 19, 2023, at 8:18 AM, Tom via Nut-upsuser <nut-upsuser at
alioth-lists.debian.net> wrote:
> 
> Good Morning,
> 
> I am working on setting up a 12V DC UPS that will power a NAS and a router
for a few hours.  It contains some lithium-ion batteries, and a BMS to control
charging.  Since it is just a dumb box with batteries, it has no intelligence to
inform the NAS of its status.  This is where NUT comes in...
> 
> I would like to incorporate a Raspberry Pi NUT server into this scheme. 
The Rpi can measure input voltage, and output voltage & current to determine
the status of this simple UPS.
> 
> With some of the excellent documentation online, I have gotten a NUT server
running on the Rpi, and my NAS (a Qnap) has been able to read the status.  I
used the 'dummy-ups' driver for testing this and it worked great.
> 
> Now, for the real business - Since this is entirely homebrew, there is not
an appropriate driver available.  I read about creating my own driver using
'skel.c' as a template.  But, nobody else would have any interest in my
very specialized driver.
You'd be surprised, especially if you are using a more common battery
management chip.
>   Plus - it seems overwhelming to me when I attempt to understand how to
build NUT and I fear getting totally bogged down in all the minutiae of that.
While it looks somewhat intimidating at first glance, we do have instructions
for building a version of NUT from source that matches a lot of the paths that
are in the Raspbian (Debian) package:
https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu
> But, it occurred to me - Why can't I just use 'dummy-ups' for
this as-is?  I can have a simple 'c' or Python program to read my values
(to determine status) and then just write a few relevant lines into a
'.dev' file to be served out to the LAN with the factory NUT server
tools?  My file would contain something like this:
For what it's worth, I think using dummy-ups for prototyping is a good idea,
especially if you put the .dev file on a RAM-based filesystem  (as Greg
suggested), like /run or /dev/shm. (I forget whether Raspbian usually puts /tmp
on the SD card.)

There are also a few i2c-based drivers in the NUT tree, such as
https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c and
https://github.com/networkupstools/nut/blob/master/drivers/asem.c

I have some notes on interfacing to an i2c-based battery pack from a few years
ago: https://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html The code is
pretty old, and the rest of NUT has been updated since then, but it's
probably helpful for estimating the scope of converting a standalone C-based i2c
program into a NUT driver. (I ended up not merging that driver into NUT.)
> 
> ups.mfr: Tom
> ups.model: My Contraption
> battery.charge: 100
> ups.status: OL
> input.voltage: 1.02
> battery.voltage: 11.5
> output.voltage: 11.2
> output.current: 3.4
> battery.runtime: 1000
> 
> I write this file periodically (maybe every 15-60 seconds) and the Rpi NUT
server would be none the wiser and just keep supplying the constantly updated
contents of this file to the NAS.
I think the NAS is probably only looking at ups.status (OL/OB/LB) to trigger
shutdown (barring any custom "shut down when variable X gets below a
threshold), but it certainly can't hurt to publish the other values if you
have something to log them.

-- 
Charles Lepple
clepple at gmail

Charles:

Thank you,
I will take a look at the i2c drivers you mention as well as your notes.
As I noted in my previous post,  I currently like the looks of the ina3221
i2c device.  It has a 16-bit ADC, can measure 12+ volts directly, it has 3
channels, and it can sense current.  Although I probably don't need
information beyond (OL,OB,LB), I like to have visibility beyond these
especially during integration.

I am curious about the advice to put the .dev file on a ram-based file
system.  Is this a worry about corruption of the SD after long-term use? I
have some raspberry pi's that have been logging data for years to the SD,
and have not experienced any corruption issues.  Maybe I am just lucky !  I
have not dabbled with a ram-disk but I'm sure it is pretty simple and
probably prudent.

I was pleased when I found that dummy-ups seemed to fit my use-case, even
though it is touted for use as 'test'.  Do you think there could be some
merit in either embellishing dummy-ups or deriving a new driver from it
that is sanctioned as a 'file-based' interface for NUT?

-Tom

On Sun, Feb 19, 2023 at 9:05 PM Charles Lepple <clepple at gmail.com>
wrote:
> > On Feb 19, 2023, at 8:18 AM, Tom via Nut-upsuser <
> nut-upsuser at alioth-lists.debian.net> wrote:
> >
> > Good Morning,
> >
> > I am working on setting up a 12V DC UPS that will power a NAS and a
> router for a few hours.  It contains some lithium-ion batteries, and a BMS
> to control charging.  Since it is just a dumb box with batteries, it has no
> intelligence to inform the NAS of its status.  This is where NUT comes
in...
> >
> > I would like to incorporate a Raspberry Pi NUT server into this
scheme.
> The Rpi can measure input voltage, and output voltage & current to
> determine the status of this simple UPS.
> >
> > With some of the excellent documentation online, I have gotten a NUT
> server running on the Rpi, and my NAS (a Qnap) has been able to read the
> status.  I used the 'dummy-ups' driver for testing this and it
worked great.
> >
> > Now, for the real business - Since this is entirely homebrew, there is
> not an appropriate driver available.  I read about creating my own driver
> using 'skel.c' as a template.  But, nobody else would have any
interest in
> my very specialized driver.
>
> You'd be surprised, especially if you are using a more common battery
> management chip.
>
> >   Plus - it seems overwhelming to me when I attempt to understand how
to
> build NUT and I fear getting totally bogged down in all the minutiae of
> that.
>
> While it looks somewhat intimidating at first glance, we do have
> instructions for building a version of NUT from source that matches a lot
> of the paths that are in the Raspbian (Debian) package:
>
https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu
>
> > But, it occurred to me - Why can't I just use 'dummy-ups'
for this
> as-is?  I can have a simple 'c' or Python program to read my values
(to
> determine status) and then just write a few relevant lines into a
'.dev'
> file to be served out to the LAN with the factory NUT server tools?  My
> file would contain something like this:
>
> For what it's worth, I think using dummy-ups for prototyping is a good
> idea, especially if you put the .dev file on a RAM-based filesystem  (as
> Greg suggested), like /run or /dev/shm. (I forget whether Raspbian usually
> puts /tmp on the SD card.)
>
> There are also a few i2c-based drivers in the NUT tree, such as
> https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c and
> https://github.com/networkupstools/nut/blob/master/drivers/asem.c
>
> I have some notes on interfacing to an i2c-based battery pack from a few
> years ago: https://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html The
> code is pretty old, and the rest of NUT has been updated since then, but
> it's probably helpful for estimating the scope of converting a
standalone
> C-based i2c program into a NUT driver. (I ended up not merging that driver
> into NUT.)
>
> >
> > ups.mfr: Tom
> > ups.model: My Contraption
> > battery.charge: 100
> > ups.status: OL
> > input.voltage: 1.02
> > battery.voltage: 11.5
> > output.voltage: 11.2
> > output.current: 3.4
> > battery.runtime: 1000
> >
> > I write this file periodically (maybe every 15-60 seconds) and the Rpi
> NUT server would be none the wiser and just keep supplying the constantly
> updated contents of this file to the NAS.
>
> I think the NAS is probably only looking at ups.status (OL/OB/LB) to
> trigger shutdown (barring any custom "shut down when variable X gets
below
> a threshold), but it certainly can't hurt to publish the other values
if
> you have something to log them.
>
> --
> Charles Lepple
> clepple at gmail
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230220/87788b39/attachment-0001.htm>