December 2016

252627282930 31

Style Credit

Expand Cut Tags

No cut tags
Sunday, October 11th, 2015 06:57 pm
As the part of the code rework in v1.5 I changed the way how watering logs are stored and visualized.

Initially in v1.0 I was using essentially the Sprinklers_pi visualization model, just changing back-end to be file-based instead of MySql, however I found two problems with the v1.0 implementation. First of all I found the UI to be inconvenient, because it shows logs by-zone. But for all practical purposes irrigation is scheduled based on "Schedules", and then the schedule includes one or more zones. Most of the time you don't have to track individual zones - usually I would like to know if particular schedules ran and when, and then I might go into details to see which specific zones were running and for how long. However this is not now Sprinklers_pi logs UI was organized.

Second problem was logs rendering performance on systems with large number of zones configured. My v1.0 backend implementation was using one file per zone, and to render complete view the MCU had to read and process dozens of files. On a low-power MCU like Arduino it takes few seconds.

For v1.5 firmware I changed the model. First of all Schedules became the primary top-level logging construct. Logs UI now shows the list of schedules that ran, and details (when, duration etc). This view is extremely fast (backend specifically optimizes for it). Also I added "Details" logs view, that shows the list of schedules as collapsed items, and when you click on any logged schedule it will open up to show details (which zones were running etc).

Backend implementation also changed, by optimizing storage structure. Now watering logs are stored in two types of files:

- Schedule logs. This file has one record per schedule run, as well as top-level information (date/time, duration etc). One file per year.
- Detailed watering information (down to zones detailization), one file per month.

When rendering default Schedules log view, backend needs to read the first file. This is pretty fast process, because this file has one record per schedule run. Rendering will become a bit slower when reaching the end of the year, but based on simple calculations it should be still pretty fast (and I can move it to per-month files if necessary).

When rendering "Details" log view, backend reads appropriate per-month file, depending on the dates range it may be one or few files. Because default dates range is up to one month, typically backend will need to read one or two files - which is also reasonably fast.

Default "Schedules" logs view:

"Schedules" log view

"Details" log view:

"Details" log view

And of course it is still possible to view and download actual watering log files, they are in CSV and can be easily opened using Excel or other programs (for data analysis etc).

I still need to rework graphics log visualization. I'm not happy with the current visualization, it does not really give much meaningful details of the watering history (e.g. it shows watering by time of the day or day of the week, but it is not very useful). I'm thinking to change it to show historical water usage (by dates), and to show water usage detailization by zone - to easily see which zones are consuming more water than others.