Nut upsdev - Oct 2012 - apcsmart and #311678 feature request thoughts

https://alioth.debian.org/tracker/?func=detail&atid=411544&aid=311678&group_id=30602

I wanted to do it somewhat more flexibly/elegantly, so this is what I've 
been thinking about (or rather sitting on mostly implemented piece, 
still needing some testing though):

- any variable that may include multiple data, would be (during runtime) 
split into appropriate *.N.* sets; for example instead of adding 'T' as 
ambient.1.temperature - which is in practice two (or possibly more 
depending on model ?) values - it would be split and added as 
ambient.1.temperature and ambient.2.temperature - in addition to already 
existing 't' as ambient.temperature

- additionally - any enumerable/writable value will also have *.0.* 
variant added, which must be used for the control. This one is always 
added verbatim - no nut <-> apc conversions, but this is in practice not 
a problem as all the interesting stuff in this context is defacto added 
without any conversions.

Is this reasonable approach ?

Hi Michal,

sorry for the lag...

2012/10/23 Michal Soltys <soltys at ziu.info>
> https://alioth.debian.org/**tracker/?func=detail&atid=**
>
411544&aid=311678&group_id=**30602<https://alioth.debian.org/tracker/?func=detail&atid=411544&aid=311678&group_id=30602>
>
> I wanted to do it somewhat more flexibly/elegantly, so this is what
I've
> been thinking about (or rather sitting on mostly implemented piece, still
> needing some testing though):
>
> - any variable that may include multiple data, would be (during runtime)
> split into appropriate *.N.* sets; for example instead of adding
'T' as
> ambient.1.temperature - which is in practice two (or possibly more
> depending on model ?) values - it would be split and added as
> ambient.1.temperature and ambient.2.temperature - in addition to already
> existing 't' as ambient.temperature
>
> - additionally - any enumerable/writable value will also have *.0.*
> variant added, which must be used for the control. This one is always added
> verbatim - no nut <-> apc conversions, but this is in practice not a
> problem as all the interesting stuff in this context is defacto added
> without any conversions.
>
> Is this reasonable approach ?
>
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...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) 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/20121029/0f1149ab/attachment.html>