Tom via Nut-upsuser <nut-upsuser@alioth-lists.debian.net> writes: > I am working on setting up a 12V DC UPS that will power a NAS and a router > for a few hours. It contains some lithium-ion batteries, and a BMS to > control charging. Since it is just a dumb box with batteries, it has no > intelligence to inform the NAS of its status. This is where NUT comes in...
I don't follow. "no status" but you are reading voltages. Are you using an ADC wired up to e.g. i2c, so you have added monitoring ability? How are you measuring current? > I would like to incorporate a Raspberry Pi NUT server into this scheme. > The Rpi can measure input voltage, and output voltage & current to > determine the status of this simple UPS. > > With some of the excellent documentation online, I have gotten a NUT server > running on the Rpi, and my NAS (a Qnap) has been able to read the status. > I used the 'dummy-ups' driver for testing this and it worked great. I am not sure you are really missing anything, but I would suggest: You are doing two things. One is finishing the job of building a UPS that report status from the battery system you have. The second is making an interface from that to NUT. Think about it in two parts. Build and debug it in two parts. dummy doesn't feel right because this is a real UPS, not a test setup. I wonder if any of the existing drivers has a generic UPS protocol that is written to be simple. By that I mean a protocol designed to be written and read with minimal code, rather than NUT authors having to cope with what the hardware people thought was good. json comes to mind. I don't think the NUT RFC specifies this part at all. Having thought this far I can see why you ended up at dummy as writing a file with variables and values is exactly what the generic protocol ought to do. You definitely want logging of values to a db/etc. so that you can understand the relationships among voltage, current, runtime, SOC. But that's not really about NUT. As for > Now, for the real business - Since this is entirely homebrew, there is > not an appropriate driver available. I read about creating my own > driver using 'skel.c' as a template. But, nobody else would have any > interest in my very specialized driver. I don't follow. Surely others might want to buy the battery thing, and use the ADC etc., and replicate this. > ups.mfr: Tom > ups.model: My Contraption > battery.charge: 100 > ups.status: OL > input.voltage: 1.02 > battery.voltage: 11.5 > output.voltage: 11.2 > output.current: 3.4 > battery.runtime: 1000 > I write this file periodically (maybe every 15-60 seconds) and the Rpi NUT > server would be none the wiser and just keep supplying the > constantly updated contents of this file to the NAS. I don't follow how much of this you think is real. Battery.charge is tough to estimate and your input.voltage does not make sense. And the output current seems high for what you described, but maybe your NAS uses a lot. I have 37W output from a UPS (AC) powering a router, a RPI3, a POE ethernet switch, and an access point on the switch. I guess that's the equivalent of 3A at 12V, assuming 100% efficiency so 3.4 with a NAS with disks is not implausible. I would urge you to only write actual data and just leave out things you don't know. I suspect after a test run you will have a good curve *for the load you actually have* mapping battery voltage to runtime. Also to charge. So you can have some actual data and some synthetic data, just like a real UPS :-) I don't know how often dummy does stat(2) to check if the file has changed but I would expect often and maybe it's the usual pollinterval. As an example, I get a notification within seconds if my input voltage drops below 100V (vs 125 nominal and 122-127 almost always). Usually it has gone to 0V. There's a 1s poll interval, and then a python program watching NUT sends this over MQTT, and then Home Assistant sends xmpp. I have two concerns: one is that I want to know about even brief outages and the second is that I want to know about them as they happen, not a minute later. If in a ramdisk (which seems necessary anyway) you could just write it every second, and you could also write it once a minute OR if anything has changed in an interesting way. Interesting is at least any ups.status change and any transition from input voltage being in the ok range to being not in the ok range or back. _______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser