> On Feb 19, 2023, at 8:18 AM, Tom via Nut-upsuser > <nut-upsuser@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@gmail _______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
