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

[Tom]

I forgot to mention...

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

The output of this thing is NOT a DC/DC converter.  It is just the raw
battery voltage (3 cells in series).  Thus, the output will start at about
12.6 and drop as low as 9.0 if fully discharged.  I do not intend for it to
ever go that low since I don't need a long run time, and I doubt the NAS
could operate there anyway, so I will be very conservative when arriving at
LB or similar status announcements.  I think I will be OK because the
discharge curves are pretty flat for a long stretch before falling
precipitously.  I will just shorten the run time / alarm settings
accordingly until I am comfortable that the NAS still will be OK.

I did contact Qnap to ask about acceptable input voltage range, and I got
absolutely nowhere.  They kept quoting that I needed to use a 12V power
adapter which was useless to my cause !


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/5f123c10/attachment.htm>