There is no such feature in my UPS. All it can do is report its status to a computer via USB, and the computer determines whether devices stay on or turn off. That’s where NUT comes in.
Even if NUT shuts down my RPi, the UPS continues to provide power until the battery dies or I turn it off manually to stop it from beeping.
Maybe it’s an option I turned off long ago, but I have no recollection of doing so. Even in the links you posted, there seems to be debate about it. My new UPS arrives next week, so I’ll take a closer look at the features.
Whatever the case may be, good luck finding what you need.
You can just run any (NUT) supported UPS and configure a shutdown of the system connected to either a NUT server or locally connected UPS (via NUT). You can configure your system to shutdown at a certain battery percentage of your UPS. That way you can:
Run your System(s) on Mains power thru the UPS when power is available
Run your system(s) on battery power via the UPS when main power is disrupted.
Keep running your system until power is restored, OR:
Gracely shutdown your system when UPS battery reports a predicted x minutes lifespan or percentage.
If the hardware you are running has the option to restart when power is restored it will come back up once the empty UPS is charging again (not RPIi);
If the battery on the UPS drains completey the RPi will start up again once power is restored. There is no way to get the RPi to powercycle if the UPS still has power left and providing current to the RPi without external hardware, triggers and timers wich all make it very dodgy.
I run an APC UPS for all my hardware and run a VM with NUT-Server that all my machine’s connect to so they are informed when to gracefully shutdown. Just make sure you inform yourself if the power goes out (you can create a rule in Openhab checking the UPS status and send a message out if power goes down, just make sure your router has UPS power aswell!)). If the power comes back in time send another message. If not, you know you have to do some manual powercycles.
Hi @Marty Thanks for your advice I understand the process explained by you. I am looking for APC ups as it’s available in my locality but the online chat of APC ups couldn’t help me with a model which has NUT capabilities.
Is it possible for you to share your APC model. Today I have call setup with APC sales team in case they don’t understand what is NUT since they are non technical I will refer your model.
Also Is it possible for you to refer any APC ups with NUT capabilities in a small form factor and lesser price I am not worried about backup time but need a grace full shutdown of my Pi
Your input will help me to refer the models to APC sales person
I’ve had a CyberPower UPS for a few years with a USB connection that the (openSUSE Tumbleweed) operating system can use to do a graceful shutdown when main power is lost. My main interest was survive short power outages and to protect the hardware from surges that often accompany outages. Graceful shutdown is a nice extra but in the end, I decided not to worry about it, because of the difficulty in guaranteeing that the system will reboot when power is restored. I just let the system continue to run until either 1) the power is restored before the battery goes dead, in which case the system continues to run, or 2) the battery goes dead, in which case the system has an ungraceful shutdown, but the power cutoff is clean so the hardware is protected, and the system will reboot after power is restored.
I have been using openHAB for only a few weeks, though, and it is not on the UPS. Is it particularly vulnerable to ungraceful shutdowns? Should I also be looking for a Raspberry Pi 4B UPS? Previously, I’ve only been worried about Linux file systems and MySQL/MariaDB, which are all pretty resilient, but maybe openHAB needs more careful handling?
openHAB itself? No, it’s not particularly vulnerable to ungraceful shutdowns, at least no more so than any other service that needs to write to disk.
Probably because flash memory is particularly vulnerable to ungraceful shutdowns. When writing to flash, all the stuff that is in a sector gets copied to a new sector with the changes to the file made. With wear leveling that means that parts of any files, even files that haven’t changed since the OS was installed, might be sharing that sector. If you pull the power during a write, you lose not only that file but everything sharing the sector with that file which could be a part of the kernel, an important file system table, etc.
I have an RPi 3 running CUPS that was attached to the same UPS as my openHAB RPi 4 for two years, and never crashed once. Last May, I moved it beside my 3D printer to run OctoPrint, but put off getting a UPS since it wasn’t critical.
Well, about 2-3 months ago, it just started crashing randomly. Sometimes OctoPrint wouldn’t load when I wanted to start a print, and sometimes it would crash in the middle of a 3D print. I wouldn’t be able to SSH in to the system, but it would always restart properly and work for awhile before crashing again. This is almost certainly SD corruption. Hard to say if it was caused by a power outage or just an aging SD card, but either way it’s annoying. I should have stopped being lazy and bought a second UPS.
I actually just received an AmazonBasics UPS (which is a rebranded CyberPower unit), and set it up last night with my RPi 3 and 3D printer. However, I realized this morning that I should have ordered a bigger one. When the 3D printer starts heating up, it draws a LOT of current and the UPS calculates that there’s only 2.5 minutes of battery time in the event of a power outage. This causes the UPS to freak out and start beeping madly to warn me.
I knew there would be a heavy draw from the 3D printer, and 2.5 minutes is actually long enough for the RPi 3 to turn off the 3D printer’s heaters and perform a graceful shutdown. But I didn’t think that through completely. If there’s a momentary power disruption, the RPi might trigger a shutdown when it shouldn’t. And since the goal is to protect the RPi, I don’t want to set the shutdown threshold too low. So for now, I’ve just taken the 3D printer off of the UPS. Oops.
When I was looking for a good UPS I found out that a lot of the UPS Pi hats aren’t any good at it. Many are just for being able to walk around with the Pi but don’t handle shutdown and reboot properly. On the other hand an external UPS with USB connection is often too large and costly.
I ended up with the X750 UPS hat (but I think it is no longer available) which came with some Python software and bash scripts. The jumper to allow it to automatically restart wasn’t any good either: if you shutdown the Pi to avoid draining the battery completely it will restart immediately thereby entering a restart - shutdown loop until the battery is completely empty.
I wrote some software myself that checks the current and battery capacity (this UPS does have a chip and I2C interface for this) that knows when the power is down and the battery capacity is dangerously low and then does a clean shutdown. I also added a bit of hardware to detect that the 5V input is present again and that activates a small reed relay connected to the jumper pins to give a startup pulse.
This UPS can run for several hours before the battery is too low, so mostly the shutdown is not activated. But with these additions it does function as it should, including a proper shutdown/restart.
The lesson is that you must be very critical with the hats for using them as a real UPS and you probably will have to do some hardware/software tweaking.
If you do get hold of a X750 or equivalent, of course I can share my knowledge.
It looks like a newer version of the x750 indeed. A RTC and buzzer has been added and the power-up delay also is new. This may indicate that they got a proper shutdown and restart working now. Else you probably still can use some extra hardware to get it started (involving a few transistors and a reed relay in my case - you will need to be able to solder these on a piece of breadboard).
Even the I2c address for the battery monitor is still the same (0x36), so it is probably the same chip also. Note that the documentation & SW only uses the voltage and capacity but the chip can also give the battery current (this was the easiest way to detect a power failure long before a battery voltage drop for the x750).
The software also looks almost the same.
Make sure you use the power jack, not the USB-C which only gives limited functionality. Also make sure you use unprotected batteries (protected batteries are larger and don’t fit) even though they are harder to find.
Hi @Peacock I haven’t ordered the item I would order based on your feedback. Since you said you have modified the hardware with IC’s can you share the entire circuit with parts details also if you can share link which battery you are using or you think it will work
I used Samsung ICR18650-26 batteries, bought at Conrad (a German e-store).
The circuit activates the relay for a short period when the +5Vin (the incoming 5V) switches from off to on, but not when the +5V (the battery backed up voltage powering the Pi) is still active
. The circuit also allows to power-down the Pi without automatically restarting when the +5Vin is still present (it can be started again by using the button in this case).
My system is built into a closed case, so J4 is a connector for a button switch on the case and CN1 is the connector on the X750 for connecting an external button (check the pin-out for the X728).
But the circuit may no longer be required as they claim to have full shutdown/restart functionality on the x728.
Very interesting. So, there are really two time frames one needs to worry about providing uninterruptible power: 1) the time required for graceful system shutdown (say, a few minutes, perhaps only several seconds), and 2) the time required to complete in-progress writes to flash (probably much less than a second). As I said earlier, I’m willing to trust Linux file systems for 1, but 2 is a different matter. I can understand how 2 would be a problem for a Raspberry Pi. By any chance, are there any flash drives (or, more likely, flash drive enclosures) that have the ability to sustain power to itself for long enough to prevent this type of corruption? In some ways, I’d rather boot from USB-attached storage that an SD card, anyway.
HHDs are mostly immune to this specific problem (of course you’d lose the actual files being written on power loss but at least it won’t take other files with it) and most SSDs will have some capacitors and buffers that make the power loss problem a little less severe. Any other flash type memory including SSDs and thumb drives will have this problem though.
Usually, part of a graceful shutdown is waiting for programs to stop writing (i.e. exit gracefully) before reaching the halt run level. You don’t have to account for the writes separately.
Agreed that a UPS will take care of both of my scenarios (graceful shutdown and flushing pending writes), but it does introduce the automatic reboot issue, and I’m less concerned about the graceful shutdown. That is, I’m willing to lose files that are currently being written, as long as corruption doesn’t affect other files (basically what one gets with HDDs).
