Now we have validated that Grocy meets the requirements set out in the first post this a good point to review the progress made so far.
Starting with a quick reminder of the criteria that the system had to meet in order to be useful. These were pretty light. Firstly, the system had to be barcode-based and usable from a mobile device (ie phone) and, secondly, it had to be able to track stock levels and, using re-order limits, automatically generate shopping lists. The availability of both of these features were confirmed by the test installation.
However, Grocy is quite a bit more powerful than that; it is able to work forward from a menu plan and, given the associated recipes, examine available stocks to generate a shopping list; it can be used to track prices and nutritional information for individual items or meals; and monitor the expiry dates of the food stocks dependent on how they are stored or consumed.
As the required functionality of Grocy has been confirmed. The next step is to perform an operational trial to make sure that A) the system is stable, B) all the users of the system are comfortable with using it and, C) that the system is useful in the day-to-day real world.
There are two questions to answer for the first of these points:
In the case of a hardware failure, can the system be brought back into operation?
In the case of a software failure, is it possible to correct or recover from it?
As installed the system is an ecosystem of collaborating programs, all of them open-source.
- The Home Assistant (HA) server.
- The Grocy HA server implementation of the base Grocy system.
- The Grocy Android app.
At the moment the HA and Grocy servers are run on a virtual machine (VM) and, as such, a complete back up of the first and second software installations is simply a matter of rebooting the server from a stored VM image of the whole system. But, if it is brought into full operation, it will not stay on a VM moving forward as it will need to be moved to a dedicated always-on server. The Android app is an interface for the Grocy server so, in the case of hardware failure, a re-installation of the app and re-entry of the API access keys should suffice.
In order to look at specific back-up strategies for each software arm we'll need to investigate each software system in a little more detail. That task is probably better completed over a series of posts rather than trying to shoehorn it into this one.
To answer the second question of what happens in a software failure we are looking at two situations again. In the case of a software corruption fault, re-installation from a back-up would be necessary, which would be covered by the strategies developed for hardware failure. For a software malfunction or bug the answer, in the case of commercial software, is to report the issue and cross your fingers while you wait for a patch or update to be forthcoming from the developer. Sometimes companies also have workarounds that their tech support can help with. In the case of open-source software waiting for an update or patch is still a viable option, as is looking for tech support, only in this case it is almost certainly going to come from the community using the software. One extra option you have with open-source software is to pop the hood and fix it yourself, depending on how competent you are and how bad the bug is. As the Grocy suite of software is all open-source time spent curating the available discussion boards and software archives should form part of a back-up strategy in case of problems.
The second step for an operational trial is ensuring that all the users of the system are agreed that it is something worth trialling and that they will take the trouble to work with the system during setup and during the trial. In my case this meant; getting buy-in from two other members of the household; getting agreement that products wouldn't escape "round the edges" of the system by stuff not being scanned on entry or disposal; and agreeing a limited selection of products to be managed in the first instance, only introducing new ones when the products already on the system were under control. To limit the amount of new system stress, initially only I would be using the system with the others added if and when required.
Lastly, we need an approach for answering the question "is the system is useful in the day-to-day real world?" In this case it will be tackled subjectively, it is only grocery shopping after all. The pain point the system is meant to address is stock tracking of the kitchen cupboards. I have no interest in going into a time-and-motion study on the shopping procedures or monitoring waste or overstock before and after installation of the system in order to generate data for an objective analysis of the system's effectiveness. The answer to the question of whether the system is useful or not will have to rely solely on whether it 'feels' useful or not and a rough idea of how much extra work it causes once implemented versus that saved by it.
The next steps are now clear. An investigation of back-ups and community support available for each software package, followed by setting up a series of test cases to ensure that the system is performing as expected.
Comments
Post a Comment