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

Greg:

Thanks for your inputs...
>That makes sense.  So you'll have input voltage, output voltage, and
>output current I would guess.  You might consider a nodemcu (ESP8266)
>publishing via MQTT to reduce power and use of unobtainium.
Yes, that is exactly what I was planning to instrument.  Maybe battery
voltage too if I can access it.  I thought it might be useful to be able to
see the open circuit battery voltage while charging, I dunno.

I'll look into this.  I have no experience with nodemcu's, and never
heard
of MQTT until your message, but I am always willing to learn
something new.  Has NUT been deployed on a nodemcu?  It looks like these do
not run traditional operating systems?




On Mon, Feb 20, 2023 at 11:43 AM Greg Troxel <gdt at lexort.com> wrote:
> Tom via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes:
>
> > 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.
>
> That makes sense.  So you'll have input voltage, output voltage, and
> output current I would guess.  You might consider a nodemcu (ESP8266)
> publishing via MQTT to reduce power and use of unobtainium.
>
> > 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...
>
> It doesn't feel right to me because
>
>   dummy is documented for testing and you aren't testing
>
>   there is not, as far as I can tell, a path to write variables and
>   perform instant commands
>
> That doesn't mean it won't work.
>
> > 4.  Logging, etc.  Perhaps...  My 'c' or 'Python' code
that performs the
> > smart UPS functionality can log information, at least during debug.
>
> What I meant is that I log voltage in, power use, battery voltage,
> reported runtime always, in Home Assistant and this is useful to
> understand behavior.  Without a manufacturer determined mapping from
> battery voltage and load to remaining runtime you have to do that.
> Keeping those logs will let you figure it out.  My experience is pretty
> much every time I log something about the world and look at them I learn
> something.
>
> > 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.
>
> Sure, but among the set of DIY people, sharing results is nice.
>
> > 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.
>
> Yes, although NUT is based on "LB" to trigger shutdown.  But
that's easy
> to synthesize.
>
> > 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.
>
> So 1.9A, which seems fine.  I just thought 3.5A was high -- but I guess
> you agree.
>
> Thanks for the link - that site looks like it has lots of interesting
> things.  You should hook up a wind turbine to charge the battery...
>
> > 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).
>
> Where I live has a much higher ratio of trees that can fall on lines to
> electric customers so I get outages more than an hour once a year or so,
> depending on storms and 12h+ every 5-10 years.  But, I didn't mean to
> question your motivation for this setup -- it makes a lot of sense and
> is not so different functionally than the hour+ UPS I have on my router.
> I just like to know right away when the power is out, even though that
> is not actually useful vs 30s later.  And I want to be notified of 2s
> outages.  These are not that rare when a fault happens and a recloser
> opens and closes and by the time it closes some other protection device
> has opened and thus the main distribution line doesn't see the fault.
>
> _______________________________________________
> 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/20230220/386003d2/attachment.htm>

Tom via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes:
>>That makes sense.  So you'll have input voltage, output voltage, and
>>output current I would guess.  You might consider a nodemcu (ESP8266)
>>publishing via MQTT to reduce power and use of unobtainium.
>
> Yes, that is exactly what I was planning to instrument.  Maybe battery
> voltage too if I can access it.  I thought it might be useful to be able to
> see the open circuit battery voltage while charging, I dunno.
Actually, given that the output is a DC-DC converter, you really will
want to have some way to measure battery voltage so you can get
SOC/runtime.  I would suggest writing to their support and tell them
what you want.  From the site, they have higher than usual odds of being
cooperative.
> I'll look into this.  I have no experience with nodemcu's, and
never heard
> of MQTT until your message, but I am always willing to learn
> something new.  Has NUT been deployed on a nodemcu?  It looks like these do
> not run traditional operating systems?
This would not run NUT or unix -- it's an arduino-class CPU.  I was
assuming you have another computer on that will and the RPI was just to
drive the i2c.

Basically:

  ESP8266: very small/low-power/cheap ($7?) arduino-ish dev board with
  wifi and GPIO/i2c/etc.

  nodemcu: software that lets you write in lua for the esp8266/esp32.
  Or you can write raw arduino code.

  MQTT: message bus for IOT where you have a broker and then some device
  writes values to a topic.  This lets you decouple the IO and the
  processing.

I have a python program that watches nut on a system and publishes a
json dictionary to an MQTT topic.  I have a remote Home Assistant that
ingests this and does display/logging/alerting.


So basically I am suggesting making a UPS that interfaces via MQTT and
an MQTT driver.  A lot more work that what you are proposing; I am
thinking the long game, which is not necessarily what you want to or
should do  -- but it's what I do....


If you don't have a machine that can run nut as part of the always on,
then your RPI0W approach makes a lot of sense.