Setting input.transfer.high/low fails on CP1500PFCLCD but reports OK

[dacarson]

I was having trouble setting input.transfer.low and high values.
Using the script called out here:
jimklimov@4be9a31

I found that input.transfer.high only allows values between 136 and 141 and input.transfer.low only allows values between 88 and 78.

Without checking the code, I am wondering if you could you try setting the value, and then read the value back. If the value didn't change, return a fail code rather than OK.

[dacarson]

Similarly, using the same script to test battery.charge.low, it always returns 'OK' but I found that you can not change it from 10%.
battery.runtime.low has a range of 600 and 0.

[jimklimov]

Looking at related subjects lately. I wonder if new "tracking" abilities would help here? Did you try with -w arguments to wait for operation completion? Does it still say "OK" then despite factually ignoring the input?

I believe by default (no wait) its "OK" means that the command was successfully queued. With async interactions involved (e.g. drivers looping in their state machine and only seeing news every second or five), this is very loosely related to actually seeing and handling that command, and the upsrw/upscmd/... client is long dead by then.

[dacarson]

I don't see the -w argument shown when I do upsrw or upscmd, however, I attempted to use it anyway.
When I attempt to set the value to something that I know fails, I still get OK:

~ $ upsrw -s input.transfer.low=70 UPS@10.0.1.153 -w
Username (pi): command
Password: 
OK

If the command is queued, then couldn't we say so. Rather than returning OK, return Queued or Requested or Command Issued. Or to not break existing scripts, keep the OK, but add -v command line parameter and have it return that it is queued.

FYI, my setup is UPS attached via USB to a ReadyNAS file server. The ReadyNAS file server says that it is running:
Network UPS Tools upsd 2.7.4 and I have little control over that software as it is part of the file server image.
I am running commands via RPi 4, it is running Network UPS Tools upsrw 2.7.4

[jimklimov]

Ok, that last revelation may explain a bit: TRACKING feature and so waits for status arrived after 2.7.4 (which is old).

[jimklimov]

But notably, even if we were to add a -v (probably -D though to stay in same style), or any other fix, your server won't see it until the NUT package is updated in the image.

[dacarson]

I understand that my server may not see a fix until the NUT package is updated. Though a fix would still be great for this.

[jimklimov]

Well, here it splits into several logical branches:

• does the particular subdriver's command handler report success or failure using that command (something TRACKING and -w CLI option would reveal in NUT 2.8.0 already); and on top of that:
• did original value change?
• did requested value appear? e.g. if the firmware limits delays to multiples of 30 or 60 seconds, is it a failed request when you had 0, asked for 59 and got 30? or if changing one thing causes the specific device to change a lot more and feed back into the original request's area before you check the new value/state (no idea in particular, maybe something like power-cycle that outlet, and expect that it is specifically on or off at the random later moment you check)

[dacarson]

These are great questions that I had not thought about. As I only have one UPS, I don't feel that I am in a position to answer behavior questions.