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

[Arnaud Quette]

Hi Michal,

sorry for the lag...

2012/10/29 Michal Soltys <soltys at ziu.info>

> 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).
>

well, do you best to make this fit in the namespace, as described in
nut-names.txt...

cheers,
Arnaud
-- 
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121126/31b1a01f/attachment.html>