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

[Greg Troxel]

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.