tim.o
2024-Apr-24 19:45 UTC
[Nut-upsuser] CyberPower CST150UC: Question re: battery.runtime.low configuration settings
> Unfortunately, the SUCCESS response is just saying that upsrw was able to send that request to upsd (i.e. the username/password were correct). As you saw, the real proof is in what you read back from upsc.Ah, gotcha.> Have you tried any other values? 3600 is hex 0xe10, and 16 is 0x10, so it is quite possible the UPS is using an 8-bit field to store battery.runtime.low. I'm guessing the maximum is going to be 255.I am not sure I follow. Would you mind unpacking this for me? When I initially issued 'upsrw' this is what was returned. What does the value '300' indicate, if not seconds; and attempting to change it to '3600' sets it two '16'. Is this what you mean when you're referring to a '8-bit field'? upsrw CST150UC ??? ??? ??? [battery.runtime.low] ?? ???? ??? Remaining battery runtime when UPS switches to LB (seconds) ?? ???? ??? Type: STRING ?? ???? ??? Maximum length: 10 ?? ???? ??? Value: 300 In my research I found that editing 'ups.conf' may allow to change the 'battery.runtime.low' as well, but I haven't tested it yet. I figured using the supported UPS variables may be the way to go first. mcedit /etc/nut/ups.conf [cyberpower] ??? driver = usbhid-ups ??? port = auto ??? desc = "ups" ??? offdelay = 20 ??? ondelay = 0 ??? ignorelb ??? override.battery.runtime.low = 20 ??? override.battery.runtime.low = 40 ??? pollinterval = 15 Thank you, Charles On 4/24/24 04:19, Charles Lepple wrote:>> On Apr 23, 2024, at 3:51?PM, tim.o via Nut-upsuser<nut-upsuser at alioth-lists.debian.net> wrote: >> >> The value changed to battery.runtime.low: 16, instead of 3600. I don't understand why, because executing the command resulted in SUCCESS. > Unfortunately, the SUCCESS response is just saying that upsrw was able to send that request to upsd (i.e. the username/password were correct). As you saw, the real proof is in what you read back from upsc. > > Have you tried any other values? 3600 is hex 0xe10, and 16 is 0x10, so it is quite possible the UPS is using an 8-bit field to store battery.runtime.low. I'm guessing the maximum is going to be 255. > > This is not entirely surprising - we have a GitHub issue label specific to CPS for issues with their USB HID protocol implementation. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240424/bab4f37b/attachment.htm>
Charles Lepple
2024-Apr-25 01:06 UTC
[Nut-upsuser] CyberPower CST150UC: Question re: battery.runtime.low configuration settings
On Apr 24, 2024, at 3:45?PM, tim.o via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote:>> Have you tried any other values? 3600 is hex 0xe10, and 16 is 0x10, so it is quite possible the UPS is using an 8-bit field to store battery.runtime.low. I'm guessing the maximum is going to be 255. >> > I am not sure I follow. Would you mind unpacking this for me? > When I initially issued 'upsrw' this is what was returned. What does the value '300' indicate, if not seconds;Confirmed, it's seconds. (The maximum length for that field is just the number of digits that the driver is prepared to accept as a string, but it just converts them to a number to send to the UPS.)> and attempting to change it to '3600' sets it two '16'. Is this what you mean when you're referring to a '8-bit field'?Yes, sorry, I missed the default of 300, and I was mixing bits and hexadecimal. At least 9 bits are needed to represent 300 decimal. Let's say the UPS stores the runtime in 9 bits, and consider what would happen if you send 3600: 3600 decimal = 1110 0001 0000 binary Low 9 bits = ___0 0001 0000 binary = 16 decimal (note that 0 and -1 may have special meaning to the UPS, but this will probably hold true for other values) My guess is that if you sent 520, upsc would return 8 (for a revised maximum of 511 seconds). If not, the UPS is even weirder than most :-) As you found, the ignorelb option is available to work around limitations in the UPS shutdown logic. -- Charles Lepple clepple at gmail