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

Tom via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes:
> 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 don't follow.  "no status" but you are reading voltages.  Are
you
using an ADC wired up to e.g. i2c, so you have added monitoring ability?
How are you measuring current?
> 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.


I am not sure you are really missing anything, but I would suggest:

  You are doing two things.  One is finishing the job of building a UPS
  that report status from the battery system you have.  The second is
  making an interface from that to NUT.  Think about it in two parts.
  Build and debug it in two parts.

  dummy doesn't feel right because this is a real UPS, not a test setup.

  I wonder if any of the existing drivers has a generic UPS protocol
  that is written to be simple.  By that I mean a protocol designed to
  be written and read with minimal code, rather than NUT authors having
  to cope with what the hardware people thought was good.  json comes to
  mind.  I don't think the NUT RFC specifies this part at all.

  Having thought this far I can see why you ended up at dummy as writing
  a file with variables and values is exactly what the generic protocol
  ought to do.

  You definitely want logging of values to a db/etc. so that you can
  understand the relationships among voltage, current, runtime, SOC.
  But that's not really about NUT.

As for
> 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.
I don't follow.   Surely others might want to buy the battery thing, and
use the ADC etc., and replicate this.

> 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 don't follow how much of this you think is real.  Battery.charge is
tough to estimate and your input.voltage does not make sense.  And the
output current seems high for what you described, but maybe your NAS
uses a lot.  I have 37W output from a UPS (AC) powering a router, a
RPI3, a POE ethernet switch, and an access point on the switch.  I guess
that's the equivalent of 3A at 12V, assuming 100% efficiency so 3.4 with
a NAS with disks is not implausible.

I would urge you to only write actual data and just leave out things you
don't know.   I suspect after a test run you will have a good curve *for
the load you actually have* mapping battery voltage to runtime.  Also to
charge.  So you can have some actual data and some synthetic data, just
like a real UPS :-)

I don't know how often dummy does stat(2) to check if the file has
changed but I would expect often and maybe it's the usual pollinterval.
As an example, I get a notification within seconds if my input voltage
drops below 100V (vs 125 nominal and 122-127 almost always).  Usually it
has gone to 0V.  There's a 1s poll interval, and then a python program
watching NUT sends this over MQTT, and then Home Assistant sends xmpp.
I have two concerns: one is that I want to know about even brief outages
and the second is that I want to know about them as they happen, not a
minute later.

If in a ramdisk (which seems necessary anyway) you could just write it
every second, and you could also write it once a minute OR if anything
has changed in an interesting way.  Interesting is at least any
ups.status change and any transition from input voltage being in the ok
range to being not in the ok range or back.

Greg:

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:
https://www.amazon.com/Comimark-INA3221-Triple-Channel-Current-Voltage/dp/B07X524KSK
It is based on the TI INA3221.

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

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...

4.  Logging, etc.  Perhaps...  My 'c' or 'Python' code that
performs the
smart UPS functionality can log information, at least during debug.

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.

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.

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:
https://cuttingedgepower.com/en-at/products/mini-ups?variant=42778989691115
It is rated at 75 Watt Hours so I should be good for 3+ hours with the 20
watt load.

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).

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...

-Tom

On Sun, Feb 19, 2023 at 9:29 AM Greg Troxel <gdt at lexort.com> wrote:
> Tom via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes:
>
> > 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 don't follow.  "no status" but you are reading voltages. 
Are you
> using an ADC wired up to e.g. i2c, so you have added monitoring ability?
> How are you measuring current?
>
> > 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.
>
>
>
> I am not sure you are really missing anything, but I would suggest:
>
>   You are doing two things.  One is finishing the job of building a UPS
>   that report status from the battery system you have.  The second is
>   making an interface from that to NUT.  Think about it in two parts.
>   Build and debug it in two parts.
>
>   dummy doesn't feel right because this is a real UPS, not a test
setup.
>
>   I wonder if any of the existing drivers has a generic UPS protocol
>   that is written to be simple.  By that I mean a protocol designed to
>   be written and read with minimal code, rather than NUT authors having
>   to cope with what the hardware people thought was good.  json comes to
>   mind.  I don't think the NUT RFC specifies this part at all.
>
>   Having thought this far I can see why you ended up at dummy as writing
>   a file with variables and values is exactly what the generic protocol
>   ought to do.
>
>   You definitely want logging of values to a db/etc. so that you can
>   understand the relationships among voltage, current, runtime, SOC.
>   But that's not really about NUT.
>
> As for
>
> > 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.
>
> I don't follow.   Surely others might want to buy the battery thing,
and
> use the ADC etc., and replicate this.
>
>
> > 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 don't follow how much of this you think is real.  Battery.charge is
> tough to estimate and your input.voltage does not make sense.  And the
> output current seems high for what you described, but maybe your NAS
> uses a lot.  I have 37W output from a UPS (AC) powering a router, a
> RPI3, a POE ethernet switch, and an access point on the switch.  I guess
> that's the equivalent of 3A at 12V, assuming 100% efficiency so 3.4
with
> a NAS with disks is not implausible.
>
> I would urge you to only write actual data and just leave out things you
> don't know.   I suspect after a test run you will have a good curve
*for
> the load you actually have* mapping battery voltage to runtime.  Also to
> charge.  So you can have some actual data and some synthetic data, just
> like a real UPS :-)
>
> I don't know how often dummy does stat(2) to check if the file has
> changed but I would expect often and maybe it's the usual pollinterval.
> As an example, I get a notification within seconds if my input voltage
> drops below 100V (vs 125 nominal and 122-127 almost always).  Usually it
> has gone to 0V.  There's a 1s poll interval, and then a python program
> watching NUT sends this over MQTT, and then Home Assistant sends xmpp.
> I have two concerns: one is that I want to know about even brief outages
> and the second is that I want to know about them as they happen, not a
> minute later.
>
> If in a ramdisk (which seems necessary anyway) you could just write it
> every second, and you could also write it once a minute OR if anything
> has changed in an interesting way.  Interesting is at least any
> ups.status change and any transition from input voltage being in the ok
> range to being not in the ok range or back.
>
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230219/2a2d43e5/attachment-0001.htm>