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 <g...@lexort.com> wrote:

> Tom via Nut-upsuser <nut-upsuser@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@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Reply via email to