What is the PiX10Hub?

[racerfern]

If you connect the UPS to your RPi via a USB cable you should be able to utilize a software shutdown service.

@bkenobi - I dl'd software for the tripplite and I have it set up to shutdown the pc.

How about for the raspberry Pi? I have three PIs,  one for the z-net, one for the zigbee board and one that I'm setting up as a plex server since deciding not to go the HG route.

In another room I have the main PC for the house and another z-net for which I will need another UPS.

[bkenobi]

IIRC when using the apcupsd it is possible to set up a second Linux machine that gets info from a second system connected to the UPS.  I know that can be done with the Windows software I run a second UPS on (Cyberpower I think).  If your app has something similar, you should be able to shut down multiple systems running on a single UPS using one as a master and the others clients.

[racerfern]

This project has become a monster. The Tripplite is not recognized by APCUPSD. So I set up the Tripplite software along with SYSLOG commands that should be sent to the various Pi units I have.

However, the Tripplite software consumes just over 30% CPU resources which is ridiculous for something that just sits there. I'm going to put the Tripplite as the UPS in another room and get an APC unit.

We don't have power outages very often and when we do they are extremely brief for the most part. Any APC recommendations?

[Convastor]

Perhaps the Alchemy Power Inc. - Pi-Zero-UpTime. UPS for Pi or other USB devices in a Pi-Zero size. Works with Pi Zero, Pi-3, Pi-2 etc. with 40 pin header on Amazon?  (I'd meant to post a link, but I'm not allowed.)

Thing is: Looks like you have to mount it directly to the RPiZW if you want power fail and low battery monitoring, so I don't know how you'd cleanly case the result, and the runtime appears to be a mere 45 minutes or so.

Re: "[Becoming] a monster": Agreed.  What sense needing a UPS that's more expensive than the board, and ten times the size, and requires a USB port multiplexer, and, and, and...?  Are these RPiZW's really that twitchy on power loss, that they have a high probability of trashing their SD cards?  If so: I suggest the design isn't useful as anything other than an educational device or toy.  I'm not certain I'd want to base my home automation on it.

[racerfern]

I don't have any Pi zeros. I have two Pi 3B+ and two Pi3. Regardless, on power loss any device of this type runs a real risk of corrupting the SD card.

[petera]

I don't have any Pi zeros. I have two Pi 3B+ and two Pi3. Regardless, on power loss any device of this type runs a real risk of corrupting the SD card.

That's why some users have switched to booting from USB stick or drive. A lot less susceptible to corruption on power loss.

[Convastor]

I don't have any Pi zeros. I have two Pi 3B+ and two Pi3. Regardless, on power loss any device of this type runs a real risk of corrupting the SD card.

That's why some users have switched to booting from USB stick or drive. A lot less susceptible to corruption on power loss.

Yeah, but the RPiZW has only the one USB port, and that's needed for the cm15a.

May have to rethink my plans.

[bkenobi]

I have not checked apcupsd resource usage recently, however I do not recall it consuming much resources.  IMO it should consume much less than 1% when idling.  I would not expect your UPS to work with the daemon unless it was listed in the docs and since it was designed for APC brand units, Tripplite is likely out of luck.

You could try NUT since it does list a few Tripplite models.

https://networkupstools.org/stable-hcl.html

[dhouston]

I don't have any Pi zeros. I have two Pi 3B+ and two Pi3. Regardless, on power loss any device of this type runs a real risk of corrupting the SD card.

That's why some users have switched to booting from USB stick or drive. A lot less susceptible to corruption on power loss.

Yeah, but the RPiZW has only the one USB port, and that's needed for the cm15a.

http://forums.x10.com/index.php?topic=30753.msg179923#msg179923

[Convastor]

I don't have any Pi zeros. I have two Pi 3B+ and two Pi3. Regardless, on power loss any device of this type runs a real risk of corrupting the SD card.

That's why some users have switched to booting from USB stick or drive. A lot less susceptible to corruption on power loss.

Yeah, but the RPiZW has only the one USB port, and that's needed for the cm15a.

http://forums.x10.com/index.php?topic=30753.msg179923#msg179923

Thanks, but I'm now thinking that, for my purposes, I'll just run something on my Linux server or NAS that are running all the time, anyway.  They both already have UPS', shut down gracefully, and will automatically start back up on power being restored.

That Alchemy Power "UPS" device is so close, but there's a no-go zone that will result in the RPiZW shutting down, but not starting back up w/o manual intervention.  Not so handy for an unattended device

[bkenobi]

IMO, if you already have a machine that is running 24/7 and being maintained to be reliable and is capable of running the HA software you choose including sufficient resources, you might as well run it there.  I switched to a RPi because AHP was terrible IMO and I wanted something that could sit next to the CM15A at my structured media box that would add effectively no extra maintenance cost (electricity etc).  If my file server was running Linux, I would probably have stayed using it.  Since it's on WinXP I was limited to what HA software I could use and my choice necessitated an RPi or similar.

[Tuicemen]

The Nice thing with HomeGenie is it will run on virtually any OS.
My main reason for going the PI route was for my off grid place.
However I do now have the PXH running on a pi ZeroW at my city place beside my Windows machine and plugged into that UPS.

Although my PC is on almost 24/7 I do like the idea of my HA running on a dedicated machine the Pi should run for days off the UPS, if the PC is shutdown.

[Convastor]

IMO, if you already have a machine that is running 24/7 and being maintained to be reliable and is capable of running the HA software you choose including sufficient resources, you might as well run it there.

That's the direction I'm looking into now.  But, rather than pollute this thread with that discussion, I'll start a new thread, elsewhere.

In the meantime I've suggested to the developer of that one RPiZW battery backup that he improve it in v2 with a board reset on restoration of power and a bit of battery charging, like a full-blown UPS would do.  (If I didn't have so many things on my plate I'd consider doing it, myself.  I haven't done any hardware design in ages.)

[bkenobi]

A battery backup should restore the unit to the same state it was in during power failure.  The apcupsd may be able to do that, but I'm not sure how.  As a result, if the RPi goes down, I do have to turn it back on when power returns.

[Convastor]

A battery backup should restore the unit to the same state it was in during power failure.  The apcupsd may be able to do that, but I'm not sure how.  As a result, if the RPi goes down, I do have to turn it back on when power returns.

The way the original APC daemon handled that was that, when the monitoring daemon determined it was time to shut down due to low battery, it'd send a power-down command to the UPS, then proceed to shut the system down.  The power-down command sent to the UPS had a configurable delay, which you had to set to what you expected your worst-case shutdown time would be.

Then, when power was restored, the UPS would, after a configurable charging period, re-apply power to the load, and the computer would come back up.

But, now that I think of it: I've never actually had that happen under the open source apcupsd.  I should probably pull the plug, some day, and make certain it actually works.  (Can't believe I've neglected to do that.)

As for the device to which I was referring: ISTM it would not be difficult to monitor the battery charge level after shutting the RPiZW down, and simply apply a reset to the board when it got back up to a suitable level.  (Of course not necessary during a power-on reset.)