temperature_time is not that difficult. It could stored as a property in the
cache whenever the temperature is taken and would expire when the
temperature also expired.
It would be easiest to return an error for temperature_time if no
temperature is available although some special value is also possible.
Since reading two values (temperature and temperature_time) is not atomic,
it's possible that some synchronization error might occasionally be
manifest.
Regarding your other request, simultaneous temperature conversion. See:
http://old.nabble.com/How-to-Use-Simultaneous-td18425087.html
(Simultaneous converson won't make implementing temperature_time any
easier).
On Sat, Aug 6, 2011 at 6:36 PM, Mark Richards
<[email protected]>wrote:
> Regarding timestamps Paul Alfille mentions that "..the timestamp for the
> reading is kept in the cache hash table and isn't exposed to the rest of the
> program."
>
> I would like to either create a new owfs property (file) for timestamp or
> modify the timestamp mtime of each file that is updated. For example, when
> a temperature sensor is converted, a new file /ID/timestamp is created and
> contains the current unixtime (it will also have a ctime == the current
> unixtime).
>
> Is this a horror show to do?
>
> Why do this? For cached values it will be instructive to know the time the
> value was read. This is because certain calculations are time-critical.
> Even 15 seconds can make a difference when comparing temperatures between
> two points for, say, a differential temperature. So if I read a cached
> value timestamp for two values I wish to evaluate and find they are more
> than 10 seconds apart, my program will wish to read each one manually
> (/uncached) to get the reading time as close as possible. It is inefficient
> to do a manual reading every time for these sensors. The same is true for
> reading a counter where the counter is (another example) attached to a flow
> sensor. If I do not know the time the counter reading was done, yet assume
> it's "now", the value I report for "now" may be quite different if the
> reading was taken 30 seconds ago.
>
> Does someone have a template or description of how things are glued
> together, so when I add this functionality I hit all the bases?
>
> Or other suggestion?
>
> --
>
> On the subject of my example where two temperature sensors need to be read,
> let's say these are on the same one wire segment. It would be sweet, in
> cases where I have to manually read these sensors, if there's a command or
> other technique that causes a 1-wire global conversion to be issued for all
> temperature sensors on the given segment. This way we hit both at the same
> time.
>
> Perhaps this is already done - when I read one sensor manually, all
> temperature sensors on the same segment convert, too? This would be sweet
> if so.
>
> /m
>
>
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
