Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
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 wrote: > Tom via Nut-upsuser 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
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
> 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 wrote: > Tom via Nut-upsuser 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
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
Tom via Nut-upsuser 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
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
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 wrote: > Tom via Nut-upsuser 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
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
Tom via Nut-upsuser 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
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
Jim: > Regarding dummy-ups looping, note that NUT v2.8.0 introduced a separation of mode to >`dummy-once` (default for `*.dev` files to be slurped once) and `dummy-loop` (default for > others to be re-read, e.g. `*.seq` files or your use-case). Previously it behaved like a >`dummy->loop` for all. Interesting... I was using the latest doc's, but what I installed was from the released raspberry pi distro's (v2.7.4). I did use a .dev file but it was looping. I guess this explains it. One reason I hesitate to do my own build is not that I can't do it, but I prefer to use the released distro's because that way, the normal update process keeps me 'current' (well, maybe a step or-two behind). If I have my own build, I know I will likely never touch it again and will eventually fall way behind the current versions. >I'd say one problem would be relative inefficiency and overheads: you have one process > talking to the device to extract data, save it into a file, another process to regularly > fopen() and read it and tell `upsd` to update its model data points. Depending on OS, file > access may be expensive (flush to write, audit, RBAC and all that) so avoiding it makes > sense, especially in a loop. Since you have dealt with the hard part - talking to a device, it > should not be easy to plug that into the skeleton driver (or another if that is a closer > match to start from) to `dstate_setinfo()` instead of preparing lines to write into a file :) Although I completely understand this argument, part of me feels like this 'inefficiency and overhead' is utterly trivial in this case. We are talking about 10's of bytes, not even kilobytes, and updates are seconds, not milliseconds. Yes, OS 'overheads' apply too, and if this were a performance limited application then I could better accept the argument. If I felt that what I was doing would apply to a wider audience, I would be more inclined to incorporate it in a way that could perhaps contribute to the community. My thought is that this is more of a one-of. -Tom On Mon, Feb 20, 2023 at 8:14 AM Jim Klimov wrote: > > Do you think there could be some merit in either embellishing > dummy-ups or deriving a new driver from it that is sanctioned as a > 'file-based' interface for NUT? > > I'd say one problem would be relative inefficiency and overheads: you have > one process talking to the device to extract data, save it into a file, > another process to regularly fopen() and read it and tell `upsd` to update > its model data points. Depending on OS, file access may be expensive (flush > to write, audit, RBAC and all that) so avoiding it makes sense, especially > in a loop. Since you have dealt with the hard part - talking to a device, > it should not be easy to plug that into the skeleton driver (or another if > that is a closer match to start from) to `dstate_setinfo()` instead of > preparing lines to write into a file :) > > Regarding RAM-based FS, on one hand there is no benefit to storing these > files persistently, and any persistent storage I/O just takes longer. Flash > wearing is also a problem, although it may be relaxed due to caching and > later flushing large writes (e.g. might happen with logs, if not every line > is forcefully synced to storage). Older flash techs also had more > write-cycles (by orders of magnitude) than the faster but more fragile > current devices which throw smarter caching and more redundant transistors > at the problem. So if your Pi's were writing logs "for years" they might > just use earlier-generation SD/MMC devices that lacked finesse but were > sturdier. > > Regarding dummy-ups looping, note that NUT v2.8.0 introduced a separation > of mode to `dummy-once` (default for `*.dev` files to be slurped once) and > `dummy-loop` (default for all others to be re-read, e.g. `*.seq` files or > your use-case). Previously it behaved like a `dummy-loop` for all. > > The driver sleeps a hard-coded 1 second between looped file reads. Also > the file contents may include a `TIMER ` line to add a delay, whether > before further lines (e.g. when preparing tests - report on-battery, wait > 10 sec, report on-line again) or as the last line to slow down the loop. > > Hope this helps, > Jim Klimov > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
> Do you think there could be some merit in either embellishing dummy-ups or deriving a new driver from it that is sanctioned as a 'file-based' interface for NUT? I'd say one problem would be relative inefficiency and overheads: you have one process talking to the device to extract data, save it into a file, another process to regularly fopen() and read it and tell `upsd` to update its model data points. Depending on OS, file access may be expensive (flush to write, audit, RBAC and all that) so avoiding it makes sense, especially in a loop. Since you have dealt with the hard part - talking to a device, it should not be easy to plug that into the skeleton driver (or another if that is a closer match to start from) to `dstate_setinfo()` instead of preparing lines to write into a file :) Regarding RAM-based FS, on one hand there is no benefit to storing these files persistently, and any persistent storage I/O just takes longer. Flash wearing is also a problem, although it may be relaxed due to caching and later flushing large writes (e.g. might happen with logs, if not every line is forcefully synced to storage). Older flash techs also had more write-cycles (by orders of magnitude) than the faster but more fragile current devices which throw smarter caching and more redundant transistors at the problem. So if your Pi's were writing logs "for years" they might just use earlier-generation SD/MMC devices that lacked finesse but were sturdier. Regarding dummy-ups looping, note that NUT v2.8.0 introduced a separation of mode to `dummy-once` (default for `*.dev` files to be slurped once) and `dummy-loop` (default for all others to be re-read, e.g. `*.seq` files or your use-case). Previously it behaved like a `dummy-loop` for all. The driver sleeps a hard-coded 1 second between looped file reads. Also the file contents may include a `TIMER ` line to add a delay, whether before further lines (e.g. when preparing tests - report on-battery, wait 10 sec, report on-line again) or as the last line to slow down the loop. Hope this helps, Jim Klimov ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
Charles: Thank you, I will take a look at the i2c drivers you mention as well as your notes. As I noted in my previous post, I currently like the looks of the ina3221 i2c device. It has a 16-bit ADC, can measure 12+ volts directly, it has 3 channels, and it can sense current. Although I probably don't need information beyond (OL,OB,LB), I like to have visibility beyond these especially during integration. I am curious about the advice to put the .dev file on a ram-based file system. Is this a worry about corruption of the SD after long-term use? I have some raspberry pi's that have been logging data for years to the SD, and have not experienced any corruption issues. Maybe I am just lucky ! I have not dabbled with a ram-disk but I'm sure it is pretty simple and probably prudent. I was pleased when I found that dummy-ups seemed to fit my use-case, even though it is touted for use as 'test'. Do you think there could be some merit in either embellishing dummy-ups or deriving a new driver from it that is sanctioned as a 'file-based' interface for NUT? -Tom On Sun, Feb 19, 2023 at 9:05 PM Charles Lepple wrote: > > On Feb 19, 2023, at 8:18 AM, Tom via Nut-upsuser < > nut-upsuser@alioth-lists.debian.net> wrote: > > > > Good Morning, > > > > 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 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. > > > > 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. > > You'd be surprised, especially if you are using a more common battery > management chip. > > > Plus - it seems overwhelming to me when I attempt to understand how to > build NUT and I fear getting totally bogged down in all the minutiae of > that. > > While it looks somewhat intimidating at first glance, we do have > instructions for building a version of NUT from source that matches a lot > of the paths that are in the Raspbian (Debian) package: > https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu > > > But, it occurred to me - Why can't I just use 'dummy-ups' for this > as-is? I can have a simple 'c' or Python program to read my values (to > determine status) and then just write a few relevant lines into a '.dev' > file to be served out to the LAN with the factory NUT server tools? My > file would contain something like this: > > For what it's worth, I think using dummy-ups for prototyping is a good > idea, especially if you put the .dev file on a RAM-based filesystem (as > Greg suggested), like /run or /dev/shm. (I forget whether Raspbian usually > puts /tmp on the SD card.) > > There are also a few i2c-based drivers in the NUT tree, such as > https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c and > https://github.com/networkupstools/nut/blob/master/drivers/asem.c > > I have some notes on interfacing to an i2c-based battery pack from a few > years ago: https://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html The > code is pretty old, and the rest of NUT has been updated since then, but > it's probably helpful for estimating the scope of converting a standalone > C-based i2c program into a NUT driver. (I ended up not merging that driver > into NUT.) > > > > > 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 think the NAS is probably only looking at ups.status (OL/OB/LB) to > trigger shutdown (barring any custom "shut down when variable X gets below > a threshold), but it certainly can't hurt to publish the other values if > you have something to log them. > > -- > Charles Lepple > clepple@gmail > > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
> On Feb 19, 2023, at 8:18 AM, Tom via Nut-upsuser > wrote: > > Good Morning, > > 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 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. > > 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. You'd be surprised, especially if you are using a more common battery management chip. > Plus - it seems overwhelming to me when I attempt to understand how to > build NUT and I fear getting totally bogged down in all the minutiae of that. While it looks somewhat intimidating at first glance, we do have instructions for building a version of NUT from source that matches a lot of the paths that are in the Raspbian (Debian) package: https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu > But, it occurred to me - Why can't I just use 'dummy-ups' for this as-is? I > can have a simple 'c' or Python program to read my values (to determine > status) and then just write a few relevant lines into a '.dev' file to be > served out to the LAN with the factory NUT server tools? My file would > contain something like this: For what it's worth, I think using dummy-ups for prototyping is a good idea, especially if you put the .dev file on a RAM-based filesystem (as Greg suggested), like /run or /dev/shm. (I forget whether Raspbian usually puts /tmp on the SD card.) There are also a few i2c-based drivers in the NUT tree, such as https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c and https://github.com/networkupstools/nut/blob/master/drivers/asem.c I have some notes on interfacing to an i2c-based battery pack from a few years ago: https://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html The code is pretty old, and the rest of NUT has been updated since then, but it's probably helpful for estimating the scope of converting a standalone C-based i2c program into a NUT driver. (I ended up not merging that driver into NUT.) > > 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 think the NAS is probably only looking at ups.status (OL/OB/LB) to trigger shutdown (barring any custom "shut down when variable X gets below a threshold), but it certainly can't hurt to publish the other values if you have something to log them. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
Greg: 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. 2. Yes, definitely 2 parts to this - Designing my own add-on to instrument a UPS and make it 'smart', and the interfacing with NUT 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... 4. Logging, etc. Perhaps... My 'c' or 'Python' code that performs the smart UPS functionality can log information, at least during debug. 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. 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. 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. 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). Thanks for all your inputs... I can report back as this progresses. It will take a while before I get all the pieces in hand and work through the integration... -Tom On Sun, Feb 19, 2023 at 9:29 AM Greg Troxel wrote: > Tom via Nut-upsuser 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
Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...
Tom via Nut-upsuser 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
