<div dir="ltr">Making progress on this PR. I have question about storing and checking state in a subdriver<br>HID Power Devices can a "UPS.PowerSummary.CapacityMode" value. According to the spec, the values are:<br>0: maH<div>1: mwH <div>2: percent (%) </div><div>3: Boolean support only (OK or failed) <br><br>Grep'ing the source, nothing makes use of this now (some subdrivers have it mapped to unmapped.ups.powersummary.capacitymode or something similar) and many of the HID UPS drivers assume CapacityMode 2 (they interpret RemainingCapacity, WarningCapacityLimit, RemainingCapacityLimit as percent). My application (and the original sample sketch for the Arduino project also does this, so I'm fine with that.<br><br>But, I was wondering if anyone could point out the right way in a NUT subdriver to have a function that handles RemainingCapacity do different things based on CapacityMode. I think I understand how to write my own function to handle values in arduino-hid.c, but I don't know how to check the state of a previously parsed value, especially one that doesn't have a place to be stored in the normal nut names variable hierarchy.<br><br>Or maybe this is too much trouble and I'll just assume CapacityMode = 2.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 13, 2023 at 7:41 AM Kelly Byrd <<a href="mailto:kbyrd@memcpy.com" target="_blank">kbyrd@memcpy.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 dir="ltr">oh! Ok, I'll go look at all the HID objects reported by the sample code @abratchik has on top-of-tree of his repo and see what makes sense to add to NUT. PR coming this week.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 12, 2023 at 2:38 PM Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank">jimklimov+nut@gmail.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 dir="auto">Well, the intention generally is to use it as a driver, so the more abilities the merrier (PR would be welcome) :)<div dir="auto"><br></div><div dir="auto">Per comments to initial PR that added it, <a href="https://github.com/networkupstools/nut/pull/1044" target="_blank">https://github.com/networkupstools/nut/pull/1044</a> : </div><div dir="auto"><br></div><div dir="auto">> The idea of introducing this driver is to enable creation and
prototyping of smart UPS based on Arduino, which is inexpensive
versatile platform very much suitable for custom fully open-source UPS
development.<br></div><div dir="auto"><br></div><div dir="auto">I don't think it was supposed to end and be finished work at that point, but distractions happen...</div><div dir="auto"><br></div><div dir="auto">It might be worth asking @abratchik if he has something tinkered over this time and ready to upstream, as well.</div><div dir="auto"><br></div><div dir="auto">Jim Klimov</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 12, 2023, 22:46 Kelly Byrd <<a href="mailto:kbyrd@memcpy.com" target="_blank">kbyrd@memcpy.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 dir="ltr">I posted earlier on this list about getting an Arduino Pro Micro using <a href="https://github.com/abratchik/HIDPowerDevice" rel="noreferrer" target="_blank">https://github.com/abratchik/HIDPowerDevice</a> in a simple sketch to monitor a DIY UPS I have built. With the changes from that thread (I had a PR merged), I was able to get usbhid-ups to recognize my device and could setup NUT the rest of the way. My intended configuration is to run NUT on a Raspberry Pi, have that device be master and then have clients of that NUT install take action when ACPresent goes from true to false.<div><br></div><div>The problem I ran into is `upsc diyups@locahost` was always showing ups.status as "OB". I ran tests and confirmed the raw reports included "UPS.PowerSummary.PresentStatus.ACPresent correctly showing 1 and 0 as appropriate as well as correctly reporting the UPS.PowerSummary.PresentStatus.Charging and UPS.PowerSummary.PresentStatus.Discharging bitfields. <br><br>I traced the problem down to drivers/arduino.c. Apparently the Arduino subdriver doesn't have an entry for "UPS.PowerSummary.PresentStatus.ACPresent" in it's arduino_hid2nut[] definition. The only sections present are commented as: <br>/* USB HID PDC defaults */<br><br>I my local source tree, I made changes to these entries copied from another USB HID-based subdriver, to add:<br> /* USB HID UPS Status*/<br> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Charging", NULL, NULL, HU_FLAG_QUICK_POLL, charging_info},<br> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.Discharging", NULL, NULL, HU_FLAG_QUICK_POLL, discharging_info},<br> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.NeedReplacement", NULL, NULL, 0, replacebatt_info},<br> {"BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.ACPresent", NULL, NULL, HU_FLAG_QUICK_POLL, online_info},<br><br>and now everything works as expected! My question for this list is why there were not included in the Arduino subdriver already? AFAICT, the author of the HIDPowerDevice Arduino library added the Arduino subdriver via a PR a few years ago along with basic support for the common Arduino VID:PID combinations in other parts of the code. But, that same library definitely reports more than<br>UPS.PowerSummary.DelayBeforeShutdown, UPS.PowerSummary.DelayBeforeStartup, etc. <br>and the example code he gives primarily demonstrates how to report ACPresent, Charging, and also remaining run time. <br><br>Am I missing something? Is there a runtime config based way to instruct NUT how to map ACPresent, Charging, etc HID statuses to NUT's specific structure? Over on the GitHub for the other project, others have reported success with NUT and Arduinos using that library, but I don't know what "success" means to them. I can't see how it's actually useful without the addition of the above lines. I'm probably missing the original intent.<br><br>Any insight or advice is appreciated. If I'm on the right track, I'll do another PR to add the above status flags (and others you all think are important) to Arduino.c</div><div><br></div></div>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" rel="noreferrer" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>