<div dir="ltr"><div class="gmail_default" style="font-size:small">Charles:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thank you,</div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">-Tom</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 19, 2023 at 9:05 PM Charles Lepple <<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On Feb 19, 2023, at 8:18 AM, Tom via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net" target="_blank">nut-upsuser@alioth-lists.debian.net</a>> wrote:<br>
> <br>
> Good Morning,<br>
> <br>
> 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...<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
<br>
You'd be surprised, especially if you are using a more common battery management chip.<br>
<br>
>   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.<br>
<br>
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: <a href="https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu</a><br>
<br>
> 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:<br>
<br>
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.)<br>
<br>
There are also a few i2c-based drivers in the NUT tree, such as <a href="https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c</a> and <a href="https://github.com/networkupstools/nut/blob/master/drivers/asem.c" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/blob/master/drivers/asem.c</a><br>
<br>
I have some notes on interfacing to an i2c-based battery pack from a few years ago: <a href="https://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html" rel="noreferrer" target="_blank">https://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html</a> 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.)<br>
<br>
> <br>
> ups.mfr: Tom<br>
> ups.model: My Contraption<br>
> battery.charge: 100<br>
> ups.status: OL<br>
> input.voltage: 1.02<br>
> battery.voltage: 11.5<br>
> output.voltage: 11.2<br>
> output.current: 3.4<br>
> battery.runtime: 1000<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
-- <br>
Charles Lepple<br>
clepple@gmail<br>
<br>
</blockquote></div>