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

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>

>   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?

I'd say one problem would be relative inefficiency and overheads: you have
one process talking to the device to extract data, save it into a file,
another process to regularly fopen() and read it and tell `upsd` to update
its model data points. Depending on OS, file access may be expensive (flush
to write, audit, RBAC and all that) so avoiding it makes sense, especially
in a loop. Since you have dealt with the hard part - talking to a device,
it should not be easy to plug that into the skeleton driver (or another if
that is a closer match to start from) to `dstate_setinfo()` instead of
preparing lines to write into a file :)

Regarding RAM-based FS, on one hand there is no benefit to storing these
files persistently, and any persistent storage I/O just takes longer. Flash
wearing is also a problem, although it may be relaxed due to caching and
later flushing large writes (e.g. might happen with logs, if not every line
is forcefully synced to storage). Older flash techs also had more
write-cycles (by orders of magnitude) than the faster but more fragile
current devices which throw smarter caching and more redundant transistors
at the problem. So if your Pi's were writing logs "for years" they
might
just use earlier-generation SD/MMC devices that lacked finesse but were
sturdier.

Regarding dummy-ups looping, note that NUT v2.8.0 introduced a separation
of mode to `dummy-once` (default for `*.dev` files to be slurped once) and
`dummy-loop` (default for all others to be re-read, e.g. `*.seq` files or
your use-case). Previously it behaved like a `dummy-loop` for all.

The driver sleeps a hard-coded 1 second between looped file reads. Also the
file contents may include a `TIMER <NUM>` line to add a delay, whether
before further lines (e.g. when preparing tests - report on-battery, wait
10 sec, report on-line again) or as the last line to slow down the loop.

Hope this helps,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230220/986e3be3/attachment.htm>