Understand the anatomy of AppDaemon apps

Hi, it has been a few days that I have started with writing AppDaemon apps and there are a few areas on which am a little confused and that is why not able to take some design decisions for the automations. This confusion mostly revolves around timers and listeners.

  • I have an app which has run_every or run_at timers setup in the callback methods of listen_state, note that it is not in the initialize method

    • Now, is this design acceptable or I should avoid using such design techniques?

      • The idea here is that I want to start a run_every only when one of the sensors reaches a state of on.
    • Consider that a timer is already running after the sensor triggered the run_every scheduler, what happens if HA restarts or AD restarts? Will the timer pick up from where it left off or the timer will be canceled because AD reinitialized the app after a restart?

      • Reasons could be many, one of them may be a power failure
    • Another scenario, I am listening to the door state of open and in the callback, starting a timer, run_every just like the above point and then going ahead and canceling the timer when the door state is off. Now here what will happen if I quickly opened and closed the door lets say 5 times. Will the previous instances get terminated or its gonna be a chain of events lined up and waiting for execution?

There are few more scenarios which I want to highlight but will do it ones there is an explanation to the above points, I want to rethink them based on suggestions and see if they are even valid now or not.

Any pointers will be really appreciated.

thats perfectly valid design, if you make sure the run_every gets cancelled correct before a new one is started. i noticed that most people (including me) use run_in loops instead, but thats a design choice.

it depends on your app settings.

  1. if AD restarts then all code is canceled and restarted. (AD doesnt have a memoery (yet))
  2. if HA restarts your app will be reinitialised by default. that means it is stopped incl. all schedulars that are in the callback. if you dont want the app to be reinitialised when HA is restarted then add plugin: None to the YAML from that app

it depends if you did correct coding. if you cancel the timer correct when the door goes to off, it is cancelled, so the callback from that timer wont run. so nothing happens.