A week ago I argued that UPSes suck and need to be disrupted. The response to that post was astonishing. Apparently I tapped into a deep vein of private discontents – people who had been frustrated and pissed off with UPS gear for years or decades but never quite realized it wasn’t only their problem.
Many people expressed an active desire to contribute to a kickstarter aimed at this problem. I got one offer from someone actually willing to hire an engineer to work on it. Intelligent feature suggestions – often framed as gripes about the deficiencies of what you can buy out there – came flooding in.
Perhaps most remarkably, the outlines of a coherent design began to emerge. We identified a battery technology we could buy COTS that would improve on the performance and lifetime of lead-acid but without the explosion risk of lithium-ion. The way that safety and regulatory requirements would require a partition between low- and- high-power electronics became clearer. A feature list solidified. We took in good ideas and rejected some not-so-good ones.
Therefore, even though we don’t yet have a lead hardware engineer, I have initiated Project UPSide. There’s no code or schematics yet; we’re still developing requirements and architecture. By “architecture” I mean, for example, what specific kinds of information the hardware subsystems need to exchange.
All interested parties are welcome to browse the wiki and apply for write access. Roles we are especially looking for:
* Lead hardware engineer – needs to be able to do overall design and systems integration.
* Someone who knows how to program USB endpoints. (It will land on me to learn this if we can’t find someone with experience.)
* Someone who understands battery-state modeling. (Again, I’ll learn this if nobody steps up.)
My own job is, basically, product manager – keeper of the requirements list and recruiter of talent.
UPDATE: If you want to request features or changes to the design wiki, the best way to do that is by opening an issue in the tracker. That way the discussion stays on record for later viewers.
PM? I though you will use some kind of project management style like Scrum.
>PM? I though you will use some kind of project management style like Scrum.
I said product manager, mot project manger – I dunno if we’ll have a PM in the normal sense. Anyway Scrum doesn’t work well if your team seldom or never meets FTF.
Eric, I am volunteering to be your hardware engineer. I will email you my current contract information.
>Eric, I am volunteering to be your hardware engineer. I will email you my current contract information.
Very cool! Glad to have you, man!
(The rest of you: Eric Baskin was a good FTF friend of mine before he moved to another state. He’s an expert power and signals engineer and as stand-up a guy as you could ever hope to meet. This is about the best possible news for the project.)
Is the technology scalable in principle? A former employer is so impressed with his small-datacenter-UPS that it’s been sitting idle for several years. (He should have put it on ebay)
Some day, when he’s got over his snit. he might want a real UPS.
–dave
>High end network switches and routers take DC direct or AC. With optional DC output, you get telecoms as customers.
I repeat my question: are the voltages and connectors for these DC feeds fully standardized across vendors? If not, I doubt this is worth chasing.
There is a standard for telco DC power – 48 V DC with a standard connector. It is a telco-industry standard, to my knowledge.
Other than that I have a bunch of boxes in a data center that run off them, I don’t know the gory details.
An example “standard” PSU I found with a couple minutes with Google:
https://www.powerstream.com/DC-PC-48V.htm
You might be able to interoperate with (or leverage engineering/parts from) the Open Compute Project’s work. This is a (mostly) user consortium of major datacenter users (Google, Facebook, Fidelity) trying to simplify/standardize whitebox PC servers that they can procure on a massive scale.
http://www.opencompute.org/wiki/Open_Rack/SpecsAndDesigns
As others have pointed out, standard DC is -48V. The system design is really simple and reliable and the voltage is low enough you don’t need to worry about electrocution when handling wires. The biggest drawback with the big DC plants is the size of wire you have to use between the frames (racks) to cut down on resistance (we usually used #8 or #4, which is about as thick as your thumb), but since we’re talking about a self-contained unit that would likely be located in the same rack as the equipment it’s powering, that shouldn’t be a problem.
That said, you _do_ get the bonus of being able to use DC Generators which are readily available for DC data center power and saves you the 8-10% loss (and cost) of a high-end inverter to get back to AC.
What I’d recommend, if you want to go this way, is to use -48V (It’s referred to as -48 because the color standard on the wires is for “red” to be on the negative, and “black” to be on the positive pole) for the batteries (e.g. 4 12V lead acid batteries in series). This also synchronizes nicely with other DC inputs like Solar Panels, etc. for off-grid applications. As long as the input from the Gen-set or Photo-voltaics are just a little higher voltage than the batteries, current will be drawn from them rather than from the batteries and the batteries will take in a charge (the system we used had a float-voltage on the rectifiers of 51VDC, so as long as we put power to the rectifiers, they’d hold the load AND charge the batteries at the same time). If you use something like LiFe batteries, you’ll still need a charge controller to prevent damage, but that shouldn’t be a big deal.
Also, thanks very much for including the fail-to-bypass. As I said before, that’s the killer deal for me and has been for a long time.
Good luck on making UPSes suck less!
>Is the technology scalable in principle?
Sort of. The main problem in large installations seems to be the mass of the battery packs required to support long dwell times. I don’t see any reason the control electronics needs to be different, but perhaps a domain expert will correct me.
Scalability will depend on the current capacity of the system design. All your switches, wiring, chargers, etc. are going to be designed for a maximum load, so the system will only scale up to that load level. You can add battery packs until the cows come home, but that maximum amperage rating on both the input and output will always be your limiting factor.
And it’s important to remember (as I’m sure you engineer will know) that you input MUST be greater than the sum of the maximum output load + the maximum charger load. The faster you recharge your batteries, the greater you input capacity must be in relation to our output. On the big Lieberts, the charger is usually about 10% of the maximum output, so it will take 10X as long to recharge the batteries (a little more, actually) as it does to discharge them. That’s why in a DC you don’t go off a generator until mains-power has been stable for 5-10 minutes. 2 or 3 hits in quick succession can cause your UPS to fail to carry the load until gen-set restart. That’s a no-no. :)
Will there be any way to suggest features?
My biggest complaint with current UPSs is that they only have a single USB interface — when I have 3 computers right next to each other in my office, I’d love to have a single big UPS and multiple interfaces to inform them to shut down gracefully when power fails.
just USB-connect to one, and have it send a network packet to the others.
>Will there be any way to suggest features?
Open an issue on the UPSide tracker.
>when I have 3 computers right next to each other in my office, I’d love to have a single big UPS and multiple interfaces to inform them to shut down gracefully when power fails.
Thank you, that was already useful. We’re currently looking at using the RPi as the device’s forebrain, though that might change because SD cards are a serious reliability problem. That’d be 4 USB ports. However, note that trying to power multiple computers is going to badly hurt dwell time and is probably best avoided.
> We’re currently looking at using the RPi as the device’s forebrain, though that might change because SD cards are a serious reliability problem.
One could potentially have just a read-only bootloader on the SD card, with the actual OS on a USB-attached drive using a more reliable technology. My experience is that most SD card failures involve the card silently failing to accept writes, resulting in corruption due to inconsistent state. If the card is never written after initially being imaged, this failure mode is avoided. This scheme would eat a USB port, but should improve reliability a fair bit.
Other than that, maybe some disgusting kludge of a bridge device to make a SATA drive speak SD over a cable with SD contacts at one end?
>One could potentially have just a read-only bootloader on the SD card, with the actual OS on a USB-attached drive using a more reliable technology.
That would be physically messy and kludgy. Are we going to hang a thumb drive off an external port? Patch-wire one of the ports for internal use and epoxy-fill the connector? Not happy with either plan.
On the other hand, there are some RPi workalikes with onboard RAM – the Banana and Orange Pis, in particular. That bootloader scheme would be more plausible on one of those.
FWIW, the Raspberry Pi “Compute Modules” are targeted at this sort of industrial/embedded use and come in a DIMM form-factor with either 4GB eMMC or pinouts for eMMC/SD. That could significantly increase the tools required and/or hassle of building a single unit, though, depending on how integrated the system ends up being.
If you mean something like the Raspberry Pi 2/3,
it’s overkill for this specific device in my opinion.
So
How about the CP2102 Module (ESP8266) is small
and can read pin inputs too.
Or the Raspberry Pi Zero.
(See https://www.raspberrypi.org/products/#buy-now-modal)
>If you mean something like the Raspberry Pi 2/3, it’s overkill for this specific device in my opinion.
No. No it isn’t.
The fact that you think so tells me you’re over-focusing on hardware BOM and underweighting the time and complexity costs of software development. You may even be getting the hardware-cost calculation wrong; a Pi-class SBC bundles several ports that a cheaper device like a CP2102-based module doesn’t have, so you get to pay for those separately if you need them (and we will).
I’m not a low-level hardware expert, but I’m not bad at systems engineering and complexity analysis. One of the ways you get not-bad at this is by having your nose repeatedly rubbed in the failure modes of poor complexity analysis. One of these – which I think you’ve just fallen into – is to optimize away easy-to-estimate costs like the part price for the forebrain in ways that raise costs that are less visible and harder to estimate – like the friction cost of hard-core embedded software development. It’s really difficult to get volunteers to do that, and there aren’t many qualified to begin with.
If you’re a smart systems engineer, as much as possible you want systems-integration costs and risks to be someone else’s problem – especially when the someone else has domain knowledge you don’t. That’s why a Pi-class SBC is right here even though from a BOM and required-compute-power perspective it is indeed overkill.
>Other than that, maybe some disgusting kludge of a bridge device to make a SATA drive speak SD over a cable with SD contacts at one end?
Hello, complexity creep. No, if the RPi isn’t good enough we should find a better forebrain.
>An RFC exists:
…and is going on the References page.
Recent RaspPi’s can be made to boot without involving any SD card at all (or, at worst, with a tiny FAT-formatted SD card containing a firmware file only – hence potentially opening up the use of highly reliable MMC media and making user servicing easier – even if the card dies, the user just has to swap in a FAT-formatted card with the magic file bootcode.bin in it), at least once the appropriate OTP bit(s) are flipped inside the individual RaspPi unit. See this documentation from the RaspPi foundation.
>hence potentially opening up the use of highly reliable MMC media and making user servicing easier
What is MMC media and how do you mate it to a Pi? Links to documentation, please.
Since no one more knowledgable has answered, as I understand it:
MMC is actually an older variant of the SD electrical/protocol standard; eMMC is a specific physical packaging of this (in a ball-grid-array chip) which was the dominant standard for persistent storage in cellphones, tablets, etc.. until very recently (and is still quite common in inexpensive devices).
I don’t think it’s *inherently* more reliable than SD-card packaging, but there’s a *lot* of crap SD-cards out there, and eMMC chips sold mostly in volume to hardware manufacturers unsurprisingly seem to have much better reliability.
“Is It Not So?” that the RPi “SD card reliability problem” is due to them having issues with insufficient power causing corruption on write?
That had been my impression from reading about it when doing general RPi research, though I can’t find hard confirmation that that is the case.
(Certainly I’m not aware of SD cards being per se unreliable in and of themselves, any more than any other flash-based storage.
They’ve had big problems in the RPi-specific context, but AFAICT it all seems to boil down to either marginally-sufficient power while running or unplugging it before it’s done writing.
Equally, not sure the UPS context even needs a writeable filesystem most of the time anyway… which would certainly reduce SD problems.)
No, all of the RPi SD failures I’ve run into have involved, from the point I discovered the failure, complete (but silent) failure of the card to accept any further writes on any system. If it were just crappy power, then the cards could be reimaged on a desktop and work fine till the next power sag. But when you try reimaging the card, nothing happens. dd will run to completion without errors, but when you try reading the card, you get the exact same data that was on it before you ran dd. I’ve also had an SD card fail in the same way in a phone, and several fail in dashcams (which is, of course, to be expected because the access pattern for dashcam storage is heavy usage, practically write only), so this failure mode isn’t unique to the Pi.
You need to buy some cheaper SD cards then. I used to get them from the local refurb shop in boxes of 20. I stopped doing that because they had awful service life in every device I used them in (smartphones, cameras, game consoles, NXP, TI, BCM, and PC devices). Sometimes you could dump a new system image or reformat them and they’d work for another month, then fail again.
The cards would work for a month or two–then flip a few bits, go read-only, drastically change capacity, return nothing but IO errors, hang the MMIO bus, or just not detect.
In recent years they seem to have improved–my most recent 4GB failure was last year, but it has been 10 years since the last 16GB SD card, and my 32GB and 64GB cards have been running uninterrupted since they were put into service (not too long after they became available).
It’s 2018. Connecting with anything other than ethernet (or ethernet with a wifi option) is very silly. USB tethers the device to a single computer.
I concur. USB might be ok for your (single) office desktop, but even THAT has an ethernet port these days, and almost any OS can be made to talk SNMP. Heck, practically every network printer on the market uses SNMP for notifications, to report low toner, for automagic configuration, etc. Why reinvent the wheel here?
Please hit me up if you need donations. I will send cash or parts.
I want this to exist, particularly if part of the goal is to use cheap, high-quality, high-availability 18650 batteries that are user-replaceable.
I lack the requisite expertise to contribute in a meaningful way other than being a tester. And that includes tester of prototype plans — a component list and wiring diagram that I could test your instructions soldering up or whatever.
>Please hit me up if you need donations. I will send cash or parts.
Thank you! Will bear in mind.
>particularly if part of the goal is to use cheap, high-quality, high-availability 18650 batteries
Not gonna fly. They’re lithium-ion, which is great for light weight and low current draw, but not in this application. The problem is the fire and explosion hazard. If you try to scale up to the wattage needed to drive, e.g., a 4K monitor the risk profile just ain’t pretty.
I have no technical skill but am willing to contribute money to this project. I have been fighting my APC BR1000G alarms recently (batteries are dying!).
>I have no technical skill but am willing to contribute money to this project.
Thanks.
Once I verify that we do in fact have a lead hardware engineer, I’ll put a PayPal button on the project overview that earmarks money dropped there to go to UPSide.
Probably the first thing we’ll buy with that money is a not-horrible midrange UPS which we will then do a formal teardown on to study how it’s built. I’m sure a sharp power-and-signals engineer can learn a lot from this, even if hardware-ignorant me couldn’t hope to.
Then of course there’s the parts budget for the prototype.
A quick search reveals that there are SNMP monitors for UPSs. Don’t know if there is an open standard yet or if it is all proprietary.
Either way, consider me marked down for writing a sub-sgent for this.
An RFC exists: https://tools.ietf.org/html/rfc1628
That solves a number of problems right off the bat. Including for the design of the core monitoring software since the MIB can be used as a checklist.
I noticed in the design wiki:
“One IEC C19 three-prong socket to be connected to mains power. Should accept 120 or 230V, 50 or 60 cycle. (We want C19 rather than C13 so as to be able to handle up to 20 watts.)”
Note that C13 and C19 are female (outlet) connectors. The corresponding male (inlet) connectors are called C14 and C20.
Formally we should refer to C13/14 and C19/20 to call out both male and female connections.
And we are looking for 2000W capability.
All of the references I’ve seen for IEC C19 say 16A max, not 20 (assuming that’s 20A and not 20W). I think it’s overkill to spec C19, as C13s are widely and cheaply available rated to 15A, which is 1800 W, plenty for the SOHO target we’re talking about here. The extra amp means making people buy a weird cable that inevitably means “much more expensive”.
When I read this, I thought about the Little Box Challenge that Google set up in the hopes that someone would design an inverter with a 50 watts per cubic inch power density. I’m a little dense at times, so I was stumped by why they would want to create a smaller inverter when what was really needed was a more power efficient inverter. Then I realized that an inverter that dense that didn’t melt would also have to be more efficient. The web site with the results of the contest doesn’t work, but as I recall the winning entrant was had a significantly higher power density than 50 watts per cubic inch. Current inverters for solar power applications have a power density of about 5 watts per cubic inch. If you could incorporate some of the ideas that the contest entrants figured out, you might wind up with a more efficient inverter and be able to use less expensive batteries or have a longer runtime.
I like the idea of using the SD card only to load a kernel and ramdrive. But I don’t like the Highlander implication (There can be only one each kernel and ramdrive per SD). I therefore propose a boot loader that can pick which kernel and ramdrive files to load out of a list of possible boot combinations. When a new kernel and/or ramdrive are written to the SD, the boot loader will note that they are not the ones listed in the
boot.cfg(or whatever) file. It will write to a “breadcrumb” file (with a name liketry-boot) a message like2018-02-26T15:46:48 K0003 R00012(but with no CR or LF) indicating what it tried to load. When the system initializes the last daemon and does some sanity checks to validate that it’s functioning correctly, it appends a status code and CR/LF (so people can easily read it in Notepad on their Windows machines if they need to) and updates
boot.cfgto reflect that kernel K0003 and ramdrive R00012 are the current choices to boot.It is assumed that ramdrives will be reconfigured much more frequently than kernels, unless some configuration info be written to a separate file on the SD card, in which case provision for
C00025might need to be added. There is a good case to be made that the ramdrive could actually be a read-only filesystem, and having a separate config file is cleaner.The only things ever written to the SD card are
K????,R?????, [C?????, ]try-boot, andboot.cfg, generally in that order. Whenever the boot loader sees that the K and R [and C] files match the highest-numbered on the filesystem, nothing at all is written. Old kernels and ramdrives are only deleted after a few successors have proven good.https://gitlab.com/esr/upside/wikis/external-interface# says at the bottom “You might want to read Transcendental strawman next.” but no such page exists. I can’t for the life of me figure out how to edit the page even after linking my Twitter account to get logged in.
>“You might want to read Transcendental strawman next.” but no such page exists.
Apologies. Transcendental Strawman was the first-cut design based on a Raspberry Pi. It’s been replaced by Inherent Strawman; I’ve fixed the link.
If you let me know your GitLab ID I’ll add you as a dev. The issues you’re raising in comments (shutown by hibernate, C19 is overkill) ought to go on our issue tracker.
@SumErgoMonstro is my Twitter handle, and appears to be what the ID is. There’s also a field that says User ID with “2057077” in it, so I’m not sure.
Here’s another issue: You reject multiple battery packs because they would either have to be connected in series or in parallel, but you’ve missed the alternative of the controller connecting one at a time. Since you call for a battery to not be further charged while it’s at max, all you need is the ability to sample the current voltage of all of the battery packs, and switching that can use the line power to (dis)charge one at any given time, allowing a pack that’s not currently (heh) engaged to be swapped out.
You reject capacitors as being inadequate to provide your 15-minute use case, but capacitors in series with batteries as a hybrid solution might be superior. The caps could help cover the switchover contemplated above, as well as provide the SOFTLANDER dwell, which we expect to be well under three minutes. The other use cases could treat the discharge of battery voltage below a certain threshold to be the signal to go to SOFTLANDER mode.
Also, caps are perfect for powering a starter motor for a generator when WINTERMUTE is in play. In that scenario, I’d say we engage the generator closer to the 5- or 10-minute mark. In my experience, an outright outage [as opposed to dirty power that the UPS doesn’t trust to run my electronics, so it runs off battery until the power cleans up] that lasts longer than 5 minutes is probably going to last a lot longer than that, as the automated resets on transformer breakers run through their max retries and give up in far less time.
>@SumErgoMonstro is my Twitter handle, and appears to be what the ID is.
You’re in.
A problem with supercapacitors is that they would add another consumable to the design. My understanding is that they degrade when actually discharged; correct me if that’s wrong. I’m reluctant to add that additional point of failure.
Caps slowly leak their charge. With use, caps lose something on the order of 20% of their capacitance, then weirdly start to gain some of it back. Therefore, designs should spec 125% of the actual requirement.
So long as the controller can detect fail[ing|ed] caps and adjust the point at which it switches from SUMMERTIDE to SOFTLANDER accordingly, it’s also an additional point of protection to have both caps and batteries.
I’ve made a few changes to the Use Cases page, adding the Suspend-to-Disk language (recognizing that where it is not available, clean shutdown should be used) some language in the SUMMERTIDE section indicating that when the battery life reaches a certain point, operation transitions to SOFTLANDER mode, and an elaboration of WINTERFALL getting value from both extra battery packs and integration with generators.
With this in mind, I think we should discuss the External Interface. You’ve spec’ed one power input for line power, but we might consider adding a second input to be connected to a generator or other power source. UPSide would always use the primary (grid) power when it’s available, but fail over to the secondary input.
Also, on the output, I think we should look at the potential for #2, instead of being shut down on battery power, it stays powered during the SUMMERTIDE phase, but when power drops to the SOFTLANDER level, UPSide would shut it off, reducing the power load during those precious final seconds to carry out the Suspend-to-Disk (or clean shutdown). The assumption here is that #2 is for the monitor and other accessories like a powered USB hub. If UPSide has good stats on power consumption on the #1 output, it can extend the SUMMERTIDE phase a bit farther than if it has to power both outputs during SOFTLANDER, but still give you the ability to work during medium-length outages.
>we might consider adding a second input to be connected to a generator or other power source.
Technically possible, but would put us in a regulatory category called “transfer device” that is much more stringent. Not happening in version 1.
>when power drops to the SOFTLANDER level, UPSide would shut it off,
Part of the plan is for those outlets to be software-controlled. Thus, if you want this policy, you add it as a rule in the manager daemon. I’ve added a note about the policy being software-configurable.
Your note needs to be edited. I can’t quite make out what you were trying to say to fix it myself.
WINTERMUTE was already out of scope for v1. Maybe the plan should be to keep the “transfer device” external, upstream of the power input, and consider what kinds of interfaces to those devices are appropriate for integration in later versions.
>Your note needs to be edited. I can’t quite make out what you were trying to say to fix it myself.
Which note? Here, or on the wki?
Can we go to communicating through the UPSide issue tracker? Multiple channels are confusing.
Another statement on the External Interface page:
“Unicode and locales would be sexy, but overly complex”
Unicode is probably too complex, but from what I’ve seen, 20×4 character displays typically have 256 different character codes defining a superset of ASCII containing the “European” accented characters. So we can fairly painlessly support localization by putting all our strings in a file on the SD card’s filesystem, allowing simple customization. It’s a common-enough practice in open-source that most programmers should be familiar with it.
>So we can fairly painlessly support localization by putting all our strings in a file on the SD card’s filesystem, allowing simple customization.
I had already thought of this, but am leaving it off the UPSide-1 fearure list for KISS reasons.
But that means you’ll be refactoring for v2, when it’s dead simple to write v1 with the strings already separated out.
Also, separating out the strings allows for them to be edited separately from the code, which can be good from a code-quality perspective.
Requests: Web page access to configure UPS, with networking options, and SNMP. Timer for testing, rebooting/power cycle, ability to turn off an outlet remotely for hung equipment, dashboard type page showing battery life, discharge, load, power in/out, etc. etc. All this data needs to be able to be accessible by a NMS, SNMP and JSON data. Available microSD slot for chip to save data and configuration backup for months or years, 64, 128 or 256GB chips.
Several separately switchable power outlets on the UPS would be very useful.
It would have several plus sides, for example:
1. Phased load throw-off can be implemented. For example devices that can recover well from a temporary power outage, could be switched off first, others depending on their needs later, and thus increasing the time that the power can be stabilized for the most important devices (that might need the longest to reach a clean state/clear their caches/park all heads and shut down).
2. Allows to remotely switch off/ power-cycle attached devices.
This is wonderful. I’d say “please, take my money” if this was a kickstarter.
I’m a retired EE with who spent many years programming embedded systems, and some recent hobby experience with Raspberry/Orange Pi. I don’t feel qualified to be doing the actual development for UPSide, but volunteer for hand assembly, debugging of hardware and software, or even documentation tasks.
Further: one hugely annoying feature of my current UPS is that it refuses to accept the output of my cheapo generator, as the frequency is 58 or 59Hz. There is no good reason to reject an AC power source based on frequency, as long as the frequency is stable. (I assume we’re not using iron transformers as input to the charger system, and even if we were, we only expect frequency deviation to be +/- a few percent, so transformer saturation isn’t an issue.)
>but volunteer for hand assembly, debugging of hardware and software, or even documentation tasks.
Where are you in meatspace?
I am a long time user of UPS technology. I have a few suggestions for the design:
1. “batteries in a bucket” design, that will collect and store all their vital juices, so that they will not leak out onto the floor. Sealed batteries are only sealed until they are not.
2. separate the battery and electronics into separate carry components to point of installation, so that the device may be carried up and down stairs easily
3. receptacles that are spaced far enough apart so as to allow multiple wall wart power adaptors and larger plugs to be used without requiring additional power strips
4. recessed button controls that can not be pressed inadvertently. Consider a “molly guard” or “end of pencil through a hole” to turn on or off. Curious guests and even the Roomba have caused outages for me.
5. some color integration in the display would be nice. My current UPS generation has a dark red display. Even a tri-color LED power ring would be better than what I have. Build upon the stop light method that I learned so many years ago.
6. please “over engineer”. My current generation of UPS equipment is all failing due to component failures (capacitors) on the circuit board. Don’t use “cheap parts”.
7. I have a smart home and relatively dumb UPS technology. I would like for them to become more integrated. I use openHAB and I know of many others.
8. regarding battery technology: I am currently in the sealed lead acid camp.
9. beeps have been addressed by others. I don’t like beeps. An alarm should warble.
>I am a long time user of UPS technology. I have a few suggestions for the design:
General request for everybody with this kind of RFE:
DON’T POST IT HERE!
The flood of requests is too much for me to deal with. Instead, go to
https://gitlab.com/esr/upside/issues/38
and add it to the issue thread.
forget I said anything
Sorry for that omission. I am in Central New Jersey, USA. I have a decent scope, soldering iron, meters, as well as more obscure test equipment.
>Sorry for that omission. I am in Central New Jersey, USA. I have a decent scope, soldering iron, meters, as well as more obscure test equipment.
That’s within reasonable driving distance of where we’re likely to do the first prototype build, at a PA Makerspace in Phoenixville PA.
I suggest getting a Gitlab ID, and telling me what it is so I can join you to the project. Then follow the discussion and add where you can pitch in. We might bring you in on the prototype build.
My gitlab id is wfdudley.
Hi Eric
I am willing to help with the design; hardware and low level drivers are my primary skills
Peter Smith
Hey Eric,
Awesome – I have messed about with UPSes for long enough to agree with you totally.
We recently had a fire alarm system installed, obviously this is similar in many ways to a UPS, with mains and battery power, relay contacts for fault/alarm etc.
Because I had arduino and wiznet network shields lying around, I decided to make a Prometheus metrics compatible server to monitor the alarm. Prometheus, suitable exporters and Grafana go together to make amazing near real time graphs. I use this setup for server monitoring, so putting them together seemed too good to miss. Adding on Alert Manager also means you can be notified of anything you care to write a query for. More info about these projects via the links in the github project readme: https://github.com/estechnical/alarm-monitor-server
This really was only a proof of concept, but it’s super simple and was a fun afternoon project that would easily plug onto UPSes.
I was already tempted to add something very similar to my dumb UPS, just to add the missing monitoring capabilities everyone seems to miss out on. Seems you may have given me a little push too :)
Ed