[Nut-upsdev] more on 2.0.3-pre

[Peter Selinger]

Alfred Ganz wrote:
> 
> Peter,
> 
> I have tested the three variables:
> 	input.transfer.low
> 	input.transfer.high
> 	battery.charge.warning
> for writeability. I found the following two:
> 	input.transfer.low
> 	input.transfer.high
> writeable, but not the last one:
> 	battery.charge.warning

Yes, this is also what I found.

> On your private comment about writeability under the development tree,
> I tried to modify the above three without the ST_FLAG_RW flag present,
> and I was NOT able to change them. 

Ah, yes, I think you are right. The driver (mistakenly) declares them
as writable, but later refuses to write to them.

> However, it looks to me like upsrw is broken, in that it shows ALL
> the available variables, whereas in the past it only showed
> writeable variables.

I have checked a bugfix into CVS; the latest version no longer has
this bug.  

For the experts: what happened is that newhidups (mistakenly) made all
variables writable that were declared as "data" by the UPS HID report
descriptor. The UPS HID specification distinguishes between variables
that are "data" and those that are "constant". The spec is a bit
ambiguous on this point, and one could read it to mean that "data" are
writable values and "constant" are read-only values.  However, I think
this interpretation is incorrect. Rather, "data" are changeable values
(including read-only changeable values such as physical measurements),
and "constant" are values that never changes. So in fact the
declaration of an item as "data" has no bearing on writability.

> Also, I thought in the past upsrw without a -s showed the current
> values. Who should be notified about this?

It is sufficient to notify this mailing list.

I have fixed this bug now in CVS. It is related to the ST_FLAG_STRING
flag I mentioned. Every writable variable must have it, because NUT
requires that writable variables are either strings (includes numbers,
by the way!) or ENUMs. It's a technicality, but without that flag,
upsrw was unable to print the current values. 

> On your comment about the ST_FLAG_STRING flag, I have removed this flag
> from the entries for battery.charge.low and battery.charge.high, and have 
> found no ill effects, so I think that for integer type things it is 
> indeed not needed.

Actually, the flag is necessary (but this was masked by the above bug
that is now fixed).
 
> I append the latest version of my patch. Now on to the REAL tests, soon
> I hope!

It's all fixed in CVS now, update to the latest version!

-- Peter