<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><div class="gmail_default">Greg:</div><div class="gmail_default"><br></div><div class="gmail_default">1.  Yes, I plan to use a Raspberry Pi Zero W with an I2C interface wired to it which can monitor multiple channels of voltage and current.  Here is an example I am considering:</div><div class="gmail_default"><a href="https://www.amazon.com/Comimark-INA3221-Triple-Channel-Current-Voltage/dp/B07X524KSK" target="_blank">https://www.amazon.com/Comimark-INA3221-Triple-Channel-Current-Voltage/dp/B07X524KSK</a><br></div><div class="gmail_default">It is based on the TI INA3221.</div><div class="gmail_default"><br></div><div class="gmail_default">2.  Yes, definitely 2 parts to this - Designing my own add-on to instrument a UPS and make it 'smart', and the interfacing with NUT</div><div class="gmail_default"><br></div><div class="gmail_default">3.  Although 'dummy' doesn't feel right, why not?  It could allow me to just use NUT right out of the box without having to muck with it.  I will look at other drivers (you mention JSON).  Maybe there is something else that can work straight out of the box...</div><div class="gmail_default"><br></div><div class="gmail_default">4.  Logging, etc.  Perhaps...  My 'c' or 'Python' code that performs the smart UPS functionality can log information, at least during debug.</div><div class="gmail_default"><br></div><div class="gmail_default">5.  Perhaps there could be some general interest, but most just buy a UPS and don't want to gin up extra add-ons / interfaces.  They just want to plug & Play.  If I like the result, I could consider writing it up if there is some general interest.  Of course right now, Raspberry pi's are virtually non-existent due to supply chain issues.</div><div class="gmail_default"><br></div><div class="gmail_default">6.  My example .dev file was totally fake and I used it just to test my concept of using 'dummy'.  On the other hand, I feel like it is a reasonable set of parameters that I wll strive to provide.  Certainly the voltages and current.  The capacity and runtime will take more work, but they are really not required just to inform the NAS when line power has failed and it needs to consider shutting down.<br></div><div class="gmail_default"><br></div><div class="gmail_default">8.  Realistic numbers? - I have a Qnap TS233 which is quite power-efficient.  I have measured the input current and when fully running it draws between 0.8 and 1.0 amps.  My router is about 0.7A, so this is a grand total of ~ 20 Watts.  The Battery Backup unit is this:</div><div class="gmail_default"><a href="https://cuttingedgepower.com/en-at/products/mini-ups?variant=42778989691115" target="_blank">https://cuttingedgepower.com/en-at/products/mini-ups?variant=42778989691115</a></div><div class="gmail_default">It is rated at 75 Watt Hours so I should be good for 3+ hours with the 20 watt load.</div><div class="gmail_default"><br></div><div class="gmail_default">9.  My motivation here is this - Our power grid is excellent here.  I don't think we have had an outage greater than an hour since we have lived here (10 years).  We do have (a few times per year) momentary outages (less than a minute).  So, for 99.9% of the time, the battery will seamlessly keep the NAS running and it will glide through the short outage.  So the status doesn't need to be very fast.  This is mostly to ensure the NAS can shut down safely when there is an outage that lasts more than a couple hours (data protection rather than extended operation).</div><div class="gmail_default"><br></div><div class="gmail_default">Thanks for all your inputs...  I can report back as this progresses.  It will take a while before I get all the pieces in hand and work through the integration...</div><div class="gmail_default"><br></div><div class="gmail_default">-Tom</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 19, 2023 at 9:29 AM Greg Troxel <<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.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">Tom via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net" target="_blank">nut-upsuser@alioth-lists.debian.net</a>> writes:<br>
<br>
> I am working on setting up a 12V DC UPS that will power a NAS and a router<br>
> for a few hours.  It contains some lithium-ion batteries, and a BMS to<br>
> control charging.  Since it is just a dumb box with batteries, it has no<br>
> intelligence to inform the NAS of its status.  This is where NUT comes in...<br>
<br>
I don't follow.  "no status" but you are reading voltages.  Are you<br>
using an ADC wired up to e.g. i2c, so you have added monitoring ability?<br>
How are you measuring current?<br>
<br>
> I would like to incorporate a Raspberry Pi NUT server into this scheme.<br>
> The Rpi can measure input voltage, and output voltage & current to<br>
> determine the status of this simple UPS.<br>
><br>
> With some of the excellent documentation online, I have gotten a NUT server<br>
> running on the Rpi, and my NAS (a Qnap) has been able to read the status.<br>
> I used the 'dummy-ups' driver for testing this and it worked great.<br>
<br>
<br>
<br>
I am not sure you are really missing anything, but I would suggest:<br>
<br>
  You are doing two things.  One is finishing the job of building a UPS<br>
  that report status from the battery system you have.  The second is<br>
  making an interface from that to NUT.  Think about it in two parts.<br>
  Build and debug it in two parts.<br>
<br>
  dummy doesn't feel right because this is a real UPS, not a test setup.<br>
<br>
  I wonder if any of the existing drivers has a generic UPS protocol<br>
  that is written to be simple.  By that I mean a protocol designed to<br>
  be written and read with minimal code, rather than NUT authors having<br>
  to cope with what the hardware people thought was good.  json comes to<br>
  mind.  I don't think the NUT RFC specifies this part at all.<br>
<br>
  Having thought this far I can see why you ended up at dummy as writing<br>
  a file with variables and values is exactly what the generic protocol<br>
  ought to do.<br>
<br>
  You definitely want logging of values to a db/etc. so that you can<br>
  understand the relationships among voltage, current, runtime, SOC.<br>
  But that's not really about NUT.<br>
<br>
As for<br>
<br>
> Now, for the real business - Since this is entirely homebrew, there is<br>
> not an appropriate driver available.  I read about creating my own<br>
> driver using 'skel.c' as a template.  But, nobody else would have any<br>
> interest in my very specialized driver.<br>
<br>
I don't follow.   Surely others might want to buy the battery thing, and<br>
use the ADC etc., and replicate this.<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<br>
> server would be none the wiser and just keep supplying the<br>
> constantly updated contents of this file to the NAS.<br>
<br>
I don't follow how much of this you think is real.  Battery.charge is<br>
tough to estimate and your input.voltage does not make sense.  And the<br>
output current seems high for what you described, but maybe your NAS<br>
uses a lot.  I have 37W output from a UPS (AC) powering a router, a<br>
RPI3, a POE ethernet switch, and an access point on the switch.  I guess<br>
that's the equivalent of 3A at 12V, assuming 100% efficiency so 3.4 with<br>
a NAS with disks is not implausible.<br>
<br>
I would urge you to only write actual data and just leave out things you<br>
don't know.   I suspect after a test run you will have a good curve *for<br>
the load you actually have* mapping battery voltage to runtime.  Also to<br>
charge.  So you can have some actual data and some synthetic data, just<br>
like a real UPS :-)<br>
<br>
I don't know how often dummy does stat(2) to check if the file has<br>
changed but I would expect often and maybe it's the usual pollinterval.<br>
As an example, I get a notification within seconds if my input voltage<br>
drops below 100V (vs 125 nominal and 122-127 almost always).  Usually it<br>
has gone to 0V.  There's a 1s poll interval, and then a python program<br>
watching NUT sends this over MQTT, and then Home Assistant sends xmpp.<br>
I have two concerns: one is that I want to know about even brief outages<br>
and the second is that I want to know about them as they happen, not a<br>
minute later.<br>
<br>
If in a ramdisk (which seems necessary anyway) you could just write it<br>
every second, and you could also write it once a minute OR if anything<br>
has changed in an interesting way.  Interesting is at least any<br>
ups.status change and any transition from input voltage being in the ok<br>
range to being not in the ok range or back.<br>
<br>
<br>
<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div></div>