<div dir="auto">Cheers, <div dir="auto"><br></div><div dir="auto">Welcome on board, and adding to what Charles said, a few more thoughts:</div><div dir="auto"><br></div><div dir="auto">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, <a href="https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-usbhid-subdriver.sh">https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-usbhid-subdriver.sh</a> 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.</div><div dir="auto"><br></div><div dir="auto">* 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!</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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  <a href="https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c">https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c</a></div><div dir="auto"><br></div><div dir="auto">...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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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 :)</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Currently NUT community seems to lack a regular expert contributor about QX however (vacancy open!) but recent contributions to look at for inspiration include <a href="https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx_ablerex.c">https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx_ablerex.c</a> and <a href="https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx_hunnox.c">https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx_hunnox.c</a> (plus some methods/data in main <a href="https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx.c">https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx.c</a> driver code).</div><div dir="auto"><br></div><div dir="auto">Finally, as a probably simplest but also least functional connection you might look at contact-closure to signal a few states with no smarts: <a href="https://github.com/networkupstools/nut/blob/master/docs/man/genericups.txt">https://github.com/networkupstools/nut/blob/master/docs/man/genericups.txt</a></div><div dir="auto"><br></div><div dir="auto">Hope this helps,</div><div dir="auto">Jim Klimov</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 16, 2022, 22:09 Joshua Quesenberry via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net">nut-upsuser@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word"><div class="m_820010876673735198WordSection1"><p class="MsoNormal">Good Afternoon,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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 3^rd recommendation to consider, please let me know.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thanks!<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Josh Q<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p></div></div>_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>