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

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>