[Nut-upsdev] apcsmart and #311678 feature request thoughts

[Michal Soltys]

On 2012-10-29 22:02, Arnaud Quette wrote:

> 
> I'm not sure to fully understand your proposition, but it's probably 
> time for me to have some rest...
> 
> I recently tried to clarify the evolution of the ambient collection:
> http://www.networkupstools.org/docs/user-manual.chunked/apcs01.html#_ambient_conditions_from_external_probe_equipment
> 
> in light of this, could you please send your proposal of variable mapping?
> that's the best way to see which command will be mapped to what NUT data...
> 

For example, on my in-testing driver I have:

        { "ambient.humidity",0          , 'h',  APC_POLL|APC_F_PERCENT },
        { "ambient.0.humidity",0        , 'H',  APC_POLL|APC_PACKED|APC_F_PERCENT },
        { "ambient.0.humidity.high",0   , '{',  APC_PACKED|APC_F_PERCENT },
        { "ambient.0.humidity.low",0    , '}',  APC_PACKED|APC_F_PERCENT },
        { "ambient.temperature",0       , 't',  APC_POLL|APC_F_CELSIUS },
        { "ambient.0.temperature",0     , 'T',  APC_POLL|APC_PACKED|APC_F_CELSIUS },
        { "ambient.0.temperature.high",0, '[',  APC_PACKED|APC_F_CELSIUS },
        { "ambient.0.temperature.low",0 , ']',  APC_PACKED|APC_F_CELSIUS },


'T' sends something like "23.11,45.55"

It gets parsed into 23.11 and 45.55 and assigned/polled as
ambient.1.temperature and ambient.2.temperature respectively; missing
values are added as N/A, so ",45.55" would end as N/A and 45.55;
ambient.0.temperature variant is not added (just a tab entry). Similarly
'H' for humidity data.

BUT

'[' and other .high/.low are also enumerable - so in addition to the
above, also ambient.0.temperature.high is added to be easily
settable by e.g. upsrw.

The "problematic" parts:

- I can't test it (no hardware exposing such commands on my side)
- I'm not 100% sure about enumeration in this case; supposedly '-' and '+'
  are used to cycle through values - so I assume single values are
  returned during capability check
- previous point implies that only 2 values are possible in practice;
  currently I split into up to 9 values, but it makes no sense then

So in this context, supporting 2 values seem most reasonable (or most compatible).