Thanks for all the suggestions. I got sidetracked and wasn't able to look into them much until now.
Jan, I'll have multiple clients asking for temperatures. One of them is time critical and I could have it trigger the conversions at the right time so that it never has to wait. However, other clients will have to wait if they happen to query owserver during the conversion/read. I was thinking that if a conversion or read is in process and the cached value hasn't expired that owserver could immediately return the cached value instead of making the client wait. That way no client would ever have to wait as long as something is triggering conversions. That would keep things relatively simple. Colin, Stefano, Those are good ideas. I do want to keep it as simple as possible and redis or memcached may be best for that. I'm looking into them. Thanks for all the suggestions, Alex On 9/23/2015 12:24 PM, Jan Kandziora wrote: > Am 23.09.2015 um 20:14 schrieb Colin Reese: >> Is there a way to set the cache delay? >> > IIRC temperature values are cached as set in settings/timeout/volatile, > in seconds. > > >> There is the case where you >> don't want sensors read every second (for power consumption, load, or >> other reasons), but want values instantly. Setting the cache delay >> would address this, and the shell script could read this value and >> adjust accordingly. Also, is the time of the cache reading available? >> > I think there is a chance for misunderstanding here. > > When you start a simultaneous conversion, you create a valid sensor > value in all sensors after at most one second. Owlib remembers for each > sensor it has a valid conversion value inside. That means reading that > single sensor *once* will *never* trigger another conversion. > > So if you synchronize the simultaneous conversion and the readout > action, you don't need the cache ever. Same if you don't synchronize but > do the simultaneous conversion at least twice as often as the readout. > The cache is never used if these provisions are met. > > However, if you have owhttpd or similar as the client, you cannot be > sure if the readout is more often than that. That's the only reason you > need the cache in that setup. Set it's timeout to a value twice as long > as the simultaneous conversion cycle and you are fine. > > > >> The above are issues also solved with the database approach. >> > Sure, you could always build a secondary cache if you just want to get > rid of the delay. Then again, you could always change your client > program to do asynchronous reads and build the "cache" into the client > by doing so. > > I had the impression Alex wanted to avoid that. KISS, something like that. > > Kind regards > > Jan > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers > ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
