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

[Charles Lepple]

> 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