Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache calculated watering scale when using data from Dark Sky #71

Merged
merged 1 commit into from Jul 3, 2019

Conversation

Projects
None yet
3 participants
@Derpthemeus
Copy link
Member

commented Jul 3, 2019

No description provided.

@salbahra salbahra merged commit 94681e9 into OpenSprinkler:dev Jul 3, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@Derpthemeus Derpthemeus deleted the Derpthemeus:cache-watering-scale branch Jul 3, 2019

@rmloeb

This comment has been minimized.

Copy link

commented Jul 5, 2019

The existing server and these enhancements rely upon continuous device operation. If the machine fails or is rebooted for any reason, all accumulated data is lost. The consequence is that the water level gets set based on partial data. No server operates forever, and required security updates are appearing with increasing frequency. Simply installing a new version of the server results in losing data. Please consider (not for this release) the use of a persistent cache, which would allow for a reboot of the machine. That would also facilitate (at some future date) a water level calculation based on more than one day's data. This becomes more relevant with eTO, because watering is typically not performed daily and, in some jurisdictions, is restricted by statute or regulation. In the user isn't watering daily, then there's an (eventual) need to accumulate eTO. Something like node-persist would fulfill this requirement.

@Derpthemeus

This comment has been minimized.

Copy link
Member Author

commented Jul 5, 2019

Losing the cached data won't reduce the quality of data used for watering scale calculations. The reason we're caching isn't so we can use more data in the watering scale calculation, but rather to decrease the number of API calls we're making. We want to use Dark Sky as our primary WeatherProvider since its historic data should be more reliable than the forecast data provided by OWM, but we need to reduce the number of API calls we're making due to Dark Sky's higher costs. Since we're retrieving data for the previous calendar day, we can cache this data until the next day without affecting the result of the watering scale calculation. We request the data from Dark Sky anytime there is a cache miss, so losing the cache due to server restarts won't have any effect on the returned watering scale.

@rmloeb

This comment has been minimized.

Copy link

commented Jul 5, 2019

That's true of the DarkSky data, and I understand the requirement, but losing the accumulated data for a local PWS does result in an inaccurate water level calculation. I'm generalizing forward regarding a probable request pertaining to eTO.

@Derpthemeus

This comment has been minimized.

Copy link
Member Author

commented Jul 5, 2019

We're only caching data from Dark Sky.

When we move forward towards a full water balancing system with ETo, we'll probably store the data on the controller itself. If we do decide to cache it on the server, we'll switch over to a persistent cache.

@rmloeb

This comment has been minimized.

Copy link

commented Jul 5, 2019

Understood. I'm attempting to modify the existing server code to persistently cache the accumulated PWS data because I run on a production Linux server that requires frequent security updates (and an occasional update to an application). I can avoid this by moving the weather server to a Raspberry Pi, but this seemed like a way to force myself to learn a little node.js and understand promises.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.