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

Inform the user that 1h delay exists after backup is made before starting the updates #11

Open
devtekve opened this issue Jun 25, 2024 · 6 comments

Comments

@devtekve
Copy link

devtekve commented Jun 25, 2024

Sorry I hit enter and early sent this without writing the description..

My proposal

Add to the description of the "full backup" toggle that a 1h delay will happen after the backup is created.

Why?

Some of us want to test the automation before forgetting it's doing magic for us, in my case, I had it configured nicely but I wasn't expecting it to be delayed 1h because of the full backup. Which is not a problem at all on a day to day basis, but because I wanted to manually test-run it first and check if everything was going according to plan, I was sitting there trying to figure out what did I misconfigure because nothing was being updated... So probably the description hint would've helped me realize it quicker.

Here's the place where the delay is defined

@devtekve devtekve changed the title Inform the user that 1h delay exists after backup is made before starting the updats Inform the user that 1h delay exists after backup is made before starting the updates Jun 25, 2024
@edwardtfn
Copy link
Owner

In fact, some backup solutions will provide a sensor indicating when the backup finished. Maybe we should use the 1h only when no sensor is selected.
I will look at this.

@eimirae
Copy link

eimirae commented Aug 22, 2024

+1, I was just getting into debugging exactly what was happening and why my updates were not starting within the 30 min schedule I had set up, and this post helped me figure out what the problem was.

@edwardtfn
Copy link
Owner

I think that delay should be removed. I'm quite busy those days, but will try to look at this next week.

@edwardtfn
Copy link
Owner

I've updated the Blueprint to be compatible to the latest Home Assistant (mainly the replacement of Services by Actions, but also introduced the collapsible sections to make it cleaner) and HACS changes (which now supports update entities.
I've also added this timeout as an input, so it is more clear to users (and also selectable).
Please let me know your thoughts.

@devtekve
Copy link
Author

devtekve commented Oct 5, 2024

I think it looks simpler and easier now. I don't see any explicit warning that due to the backup, the update process might be delayed, but I don't know if that's still a thing. Nonetheless, the current way of setting up feels extremely simple and intuitive, excellent job @edwardtfn

@devtekve
Copy link
Author

devtekve commented Oct 5, 2024

@edwardtfn sorry for the ping, I know this is not strictly the same as the issue defined here but I think its somewhat related: Is it possible that you could make a more prominent warning when the user creates the schedule that clarifies:

  1. The schedule window MUST cover the whole process of checking for updates + performing the backup and its wait time (you mention this already on the Backup wait time)
  2. That if the shedule is not ON, no matter how much you run the automation manually it will not perform any updates. (maybe an entry on the logbook saying "skipping update due to being outside of schedule" would help
  3. Clarify what happens if the update window is too big or too narrow. (I dont know what happens if the schedule is set to 4 hours every day. Does it keep checking for updates on a loop? does it check only once the trigger becomes "on", etc)

Mentioning those as they were my pain points today trying to set this up again :D again thanks for the lovely work <3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants