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 <g...@lexort.com> wrote: > Tom via Nut-upsuser <nut-upsuser@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@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