To start a recipe, I frequently have to run it a second time.
When restarting the brain (or the PFC) a long running recipe should start running again at the current time, it doesn't always do so.
I think the source of these problems is the environmental_data_point by_variable view we are using. I think the index/tree that couch keeps internally for that view is not optimized to find the recipe_start and recipe_end documents in the gigabytes of data which are mostly desired/measured actuator/sensor values.
Investigate adding a new map/reduce view to more quickly return recipe_start and recipe_end from the environmental_data_point DB.
A less desirable solution would be to also write the recipe state to a new DB. But @Spaghet feels that this goes against the original design intentions of the brain/doc db.
test the query speed using the existing by_variable view (after my recent DB/view compaction/cleanup the existing query is pretty quick, so maybe this is now a moot point?)
To start a recipe, I frequently have to run it a second time. When restarting the brain (or the PFC) a long running recipe should start running again at the current time, it doesn't always do so.
I think the source of these problems is the environmental_data_point by_variable view we are using. I think the index/tree that couch keeps internally for that view is not optimized to find the recipe_start and recipe_end documents in the gigabytes of data which are mostly desired/measured actuator/sensor values.
Investigate adding a new map/reduce view to more quickly return recipe_start and recipe_end from the environmental_data_point DB.
A less desirable solution would be to also write the recipe state to a new DB. But @Spaghet feels that this goes against the original design intentions of the brain/doc db.