Nut upsuser - Sep 2022 - Building a Custom UPS with NUT Compatibility

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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220916/4722c6e9/attachment.htm>

Hi Josh,

I'm not finding this Microchip firmware example online at the moment, but
there was once a PIC sample project that implemented USB HID PDC, which is the
protocol the NUT usbhid-ups driver speaks. I think the OpenUPS product (somewhat
misleadingly named IMHO; the firmware is not open source, as far as I know) has
similar HID descriptors to that example project, and it is one of the models
with custom variables.

https://networkupstools.org/docs/man/usbhid-ups.html

https://github.com/networkupstools/nut/blob/v2.8.0/drivers/openups-hid.c

As long as you have a good USB HID vendor example project to work from, you
should be good to go. HID PDC is fairly straightforward, just with a lot of
different names and variables. For basic system shutdown, there are just a few
bits in UPS.PowerSummary.PresentStatus that need to be implemented.

Related: I haven't followed ESR's "upside" project in a while,
so not sure if it will provide a good starting point. If nothing else, there
might be some good UPS engineering information in the wiki:
https://gitlab.com/esr/upside

-- 
Charles Lepple
clepple at gmail
> On Sep 16, 2022, at 3:34 PM, 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
>  
> 
P.S. please subscribe to the list using the URL below. Gmail allows you to
easily create filters for list traffic, and once you are subscribed, you can
turn off delivery (or change to daily digest mode), but in any event, emails
from subscribers won't need to be manually approved.
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

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>

On Fri, 16 Sep 2022, Joshua Quesenberry via Nut-upsuser wrote:
> 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?
Hello Josh, When you say "integrating with NUT" do you mean

  1) At the low level, i.e. microcode which talks to a driver in NUT's upsd.

  2) At high level, i.e. with NUT's upsd integrated into your system.

Roger