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 <clep...@gmail.com> wrote: > > 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
