Hi Michal, sorry for the lag...
2012/10/29 Michal Soltys <[email protected]> > 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
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
