<div dir="ltr"><div>Hello Yvonne,</div><div><br></div><div>  Nice to hear from you again, and I've recently seen a similar question in the issue tracker, so would re-post the answer made there (I think this should get into the NUT FAQ and/or Wiki, if not yet covered there; but it may be worth collecting insights from other community members while we are here):</div><div><br></div><div>> 
Hello, our company is a manufacturer of UPS and would like to apply for 
inclusion in the NUT compatibility list.</div><div>> May I inquire about the process
 and required documentation for joining?

<br></div><div><br></div><div>Hello, and it is always great to hear such queries!<br><br>Being a loosely-knit online community around the software project, NUT currently has no bureaucratic routine or red tape - everyone can post GitHub Pull Requests to contribute to the source code (including the documentation and data related to the compatibility lists). What matters most for the community, where individual people and even companies come and go but the project continues for over 25 years, is functionality and maintainability - so a large part of the answer is having both NUT drivers to communicate with the devices, and documentation to verify and evolve them any time later.<br>* This includes the time-frame when UPS or similar power-management devices still work, but the original companies that created them no longer exist, or no longer publish relevant (old) versions of spec/protocol on their web sites after acquisitions or re-structuring.<br>* There were cases of same device identification used for completely unrelated devices (as far as communications are concerned), or of vendors only supporting their latest iteration while the boxes in the field can not be upgraded to newer firmware and have to work with their decade-old bugs.<br>* Notably, similar concerns apply to power-protection of still-running computers made by vendors now only known in history books, but where NUT ran at the time and new versions can still be built and used (so there are certain constraints on the source code).<br><br>Note that beside the "HCL" (Hardware Compatibility List) with a list of devices and matching drivers seen at <a href="https://networkupstools.org/stable-hcl.html">https://networkupstools.org/stable-hcl.html</a> we also have a "DDL" (Devices Dumps Library) shown and documented at <a href="https://networkupstools.org/ddl/">https://networkupstools.org/ddl/</a> with examples of device support across different NUT releases (as well as, to some extent, across device/firmware variants seen in the field over the years). When a NUT driver exists, a run of <a href="https://raw.githubusercontent.com/networkupstools/nut/master/tools/nut-ddl-dump.sh">https://raw.githubusercontent.com/networkupstools/nut/master/tools/nut-ddl-dump.sh</a> helps prepare a DDL report to be included into the library.<br><br>The HCL source at <a href="https://github.com/networkupstools/nut/blob/master/data/driver.list.in">https://github.com/networkupstools/nut/blob/master/data/driver.list.in</a> also summarizes the different levels of support our rendered tables on the NUT website report. They are a balance of as much NUT supporting the device, as the vendor supporting NUT to do so (e.g. providing actual protocol documentation to be used and re-published at <a href="https://networkupstools.org/ups-protocols.html">https://networkupstools.org/ups-protocols.html</a> instead of people making educated guesses about a black box, and devices to test the theory-vs-practice against).<br><br>For inclusion into the compatibility list as such, the device has to be, well, compatible - talking either a protocol NUT already supports, or by the vendor contributing a driver for a new protocol (directly, or enticing and sponsoring a developer perhaps via the NUT mailing list with at least a device to develop/test against), or enhancing an existing NUT driver if the device is mostly supported by one, but some interesting data points or instant commands are not yet handled.<br><br>The general approach to "Creating a new driver to support another device" can be seen at  <a href="https://networkupstools.org/docs/developer-guide.chunked/new-drivers.html">https://networkupstools.org/docs/developer-guide.chunked/new-drivers.html</a>, ending with particular examples for popular USB HID, SNMP and Megatec Q* dialect sub-drivers united by respective umbrella programs in NUT.<br><br>Ideally, someone from the vendor's team would actually remain in NUT orbit as a (co-)maintainer for that driver and a sort of liaison - as both the devices and NUT capabilities (e.g. the standard vocabulary of vendor-neutral data points maintained at <a href="https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt">https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt</a> and rendered at <a href="https://networkupstools.org/docs/developer-guide.chunked/nut-names.html">https://networkupstools.org/docs/developer-guide.chunked/nut-names.html</a>) evolve, someone should sync them. Perhaps as new revisions of the device protocol are published, that person could make sure that NUT UPS Protocols collection gets a copy and drivers are updated as needed. A common pain point is that different firmware versions seen in the field need different work-arounds for mistakes of the past, and it is beneficial when a NUT driver can differentiate the devices to apply the correct logic to each. This is something an UPS development team is better positioned to do, than random people blindly hot-fixing behaviors based on devices they have (so maybe breaking the driver for someone else with a different version of the device).</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Apr 17, 2025 at 9:31 AM Yvonne.Chen <<a href="mailto:Yvonne.Chen@cyberenergy.com">Yvonne.Chen@cyberenergy.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg3768416665366749816">





<div lang="ZH-TW" style="overflow-wrap: break-word;">
<div class="m_3768416665366749816WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Hi Jim:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif">We have a customer whose manufacturer is listed with an orange support level legend (based on fragments of publicly available protocol) on the Hardware Compatibility List. What
 kind of information does the customer need to provide in order to upgrade the support level legend from orange (based on fragments of publicly available protocol) to green (vendor provided protocol and hardware)? Does this need to be submitted and requested
 directly by the manufacturer? Kindly confirm. Thank you!<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif"><a href="https://networkupstools.org/stable-hcl.html?utm_source=chatgpt.com" target="_blank">https://networkupstools.org/stable-hcl.html?utm_source=chatgpt.com</a><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Best regards<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Yvonne Chen<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Cyber Energy Co., Ltd.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Tel: +886-2-8792-9628 #605<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Fax: +886-2-8792-9626<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Email:
<a href="mailto:Yvonne.Chen@cyberenergy.com" target="_blank">Yvonne.Chen@cyberenergy.com</a><u></u><u></u></span></p>
</div>
</div>

</div></blockquote></div>