[Nut-upsuser] Building a Custom UPS with NUT Compatibility

[Jim Klimov]

Cheers,

Welcome on board, and adding to what Charles said, a few more thoughts:

If you get hold of effectively an embeddable third-party UPS which does its
magic with its firmware and talks USB HID to your part of the system,
https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-usbhid-subdriver.sh
can help you map data points it provides. Beware that some USB protocol
implementations are sloppy and provide invalid Report Descriptors which we
have to chizel around with variable success (notably LogMin/LogMax encoding
problems you can find in our github issues, and some more complicated cases
handled in e.g. apc-hid.c and cps-hid.c subdrivers). Also some USB chips
(device interface and hubs along the path) too often cut corners elsewhere,
e.g. regarding their own reset-ability, reacting to resets issued to
someone else on the bus, powersave mode bringing them offline, etc. Some
USB UPSes in issue tracker are more notorious than others for going AWOL
and getting grabbed by kernel as they re-appear, and being problematic for
the running unprivileged NUT driver process to grab back. To the point that
people are using separate USB hubs made really to the spec, so they can
reset or power-cycle individual ports to trigger a complete reconnection as
if cable was re-plugged, and restart a NUT driver with additional scripting.

* Anecdotally, many of the same problems plagued home-storage rigs with USB
HDDs that occasionally just disappeared, causing hurt for RAIDs. Not
because USB per se is bad, but because not everyone follows the rules yet
claims they made an USB compliant chip/hub nonetheless. Even some SATA
server backplanes were notorious for bringing down dozens of disks to reset
one. But hey, it's cheap, and someone got a bonus!

If you're making a fully embedded project, where a separate USB chip to
talk USB HID internally is overkill (and not exposed externally, to serve
physically as an USB HID UPS to outsiders), writing a custom NUT driver
using media and protocol suitable for your hardware is also an option.

For example, PiSupply make a HAT with battery for Raspberries, connected
via the usual pin array and having some smarts of its own to power on/off
etc., and they wrote abd contributed an i2c NUT driver as one of the
options for any Linux based OS on the Pi to talk to it
https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c

...one limitation being that I think currently only Linux i2c is supported
by NUT framework or libs it pulls, so if you go for some other embedded OS
(some BSD?) you might want internal serial/usb/pci/isa/... bus after all.

Possibly something is possible with ACPI (like querying/managing a laptop
battery) but I'm not aware of NUT drivers doing that. Probably OS gets it
first and holds on to it harder than it does for USB devices, and wherever
such NUT battery drivers might exist, they are OS-specific hooks to tap to
kernel facilities for it (and vice-versa to expose an external UPS as a
fake internal battery). In embedded case, where you control the OS and HW,
it might be an option however.

For some reason, many vendors implement dialects of Megatec Qx (x is a
digit) protocols over serial or USB links. I do not really know the reason
- maybe easier licensing or earlier experience of the OEMs?.. There are a
number of those dialects and quirks in NUT codebase, now focusing in
nutdrv_qx. So on one hand it can give a head start to your development, but
on another it can be a PITA for programming maintenance, just looking at
all those subdrivers :)

A large problem in the field (not related to protocol per se) is that many
cheap USB QX-speaking device makers usually do not bother getting unique
IDs for the chips (vendor/product) and report as 0000, 0001, ffff or
similar utterly non-random values, with same generic strings for
manufacturer names as well. Guessing who it is then (or which protocol they
talk - not all are even QX compatible) is quite difficult.

Currently NUT community seems to lack a regular expert contributor about QX
however (vacancy open!) but recent contributions to look at for inspiration
include
https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx_ablerex.c
and
https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx_hunnox.c
(plus some methods/data in main
https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx.c
driver code).

Finally, as a probably simplest but also least functional connection you
might look at contact-closure to signal a few states with no smarts:
https://github.com/networkupstools/nut/blob/master/docs/man/genericups.txt

Hope this helps,
Jim Klimov

On Fri, Sep 16, 2022, 22:09 Joshua Quesenberry via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> Good Afternoon,
>
>
>
> I’m part of team that’s been tasked with building an embedded system that
> does, among other things, battery management, including behaving like a
> UPS. We’d like to take full advantage of integrating with NUT and hopefully
> also it offers some support for running custom queries of the device? Can
> some point me in a good direction for writing firmware that works
> seamlessly with NUT? Are there any existing firmware frameworks that are
> open source that I can look at? We haven’t selected a
> microcontroller/microprocessor yet, but we’re familiar with Microchip and
> NXP, so if one of those would provide a shorter path to results or you have
> a 3rd recommendation to consider, please let me know.
>
>
>
> Thanks!
>
>
>
> Josh Q
>
>
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220917/c11d28a7/attachment-0001.htm>