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

[Tom]

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

This is definitely my scenario.
No other intelligence is involved so the Rpi was one-stop-shopping.

I had thought about an Rpi Pico, but again, it would not have been as
straight-forward to easily run NUT.  I had NUT running within maybe a half
hour on the Pi, and talking to the NAS.

I can see and appreciate your passion here.  I have to laugh because I
would feel like I was setting up an entire enterprise infrastructure just
to protect my scrawny little NAS from the occasional power spike !!  If you
have that infrastructure already (for whatever reason) then it is just a
small tweak to incorporate something new like this.


On Mon, Feb 20, 2023 at 1:55 PM Greg Troxel <gdt at lexort.com> wrote:

> 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.
>
> _______________________________________________
> 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/4ac1a5d3/attachment-0001.htm>