So after my (continuing) HomeAssistant Supervised adventure, I am looking for a way to control HomeAssistant as part of the dietpi-services (stop / start / restart) script.
Is it possible to have dietpi-services as part of the ‘stop (all)’ to call a ‘pre’ script? and as part of the ‘restart (all)’ a post script or some other way to ‘hook’ commands?
Before services are stopped I want to (in my case) do a ‘ha core stop’ which will stop HomeAssistant gracefully, and after the services are restarted I want to do a ‘ha core restart’.
Now I have to do this manually to avoid HomeAssistant crashing and potentially getting corrupted.
I think having a way to ‘hook’ into the dietpi-services (and maybe other scripts as well) would be a nice addition.
Is this an idea, or is this something that is already possible (but that I missed from reading through the scripts?)
There is currently no such function. In the case of HA Supervised, it would probably best not to let DietPi control Docker anymore and set it to excluded within dietpi-services. This way you can create an own script to shutdown HA Supervised first, stop Docker and invoke dietpi-services to stop other services afterwards.
Hi @Joulinar thanks for followingup.
Yes, and that is what I have now: docker excluded.
but…
recently did a dietpi-upgrade and it turned out that although docker was exluded, it still crashed Home Assistant. I found out because the temperature in the house was rising and we could not connect to HA to turn it off (if turns on / off automatically using automation scripts)
So that is why I was thinking about this feature for DietPi: make it more open to the outside world using hooks that (in this case) I can hook into.
I think that will open up a lot of other use cases as well: more then happy to think along on this feature and to develop / test if there is something to work on.
But this can’t have any relation to DietPi own scripts update. It should keep Docker service online. What might happen was a Docker or Kernel package update via apt. But usually even this should not have an impact to running container. For this, a log would be needed.
well you are first one requesting this
You are more than welcome to supmit a PR on GitHub
no log available, my priority was getting it back up and running and when that was done: back to business as usual
As for the PR, I know I can do a PR but would like to discuss 1. if this is something that would be implemented, 2. technical ‘direction’ as there are more ways to do it: what would be the ‘DietPi approach’, based on that 3. do a PR
The above from lessons learned on other projects where a lot of time and effort was put in just to see it go down the proverbial drain
