I am writing an AppDaemon script that does some scheduled stuff. It’s run when triggered by a state change, turns on some stuff, and then uses run_once() to set up another callback to turn the stuff back off at a later time.
I’d like to have a front-end switch to turn the script on and off, so I set up an input boolean constraint. The problem it seems is that the constraint turns off not only the initial state change callback but also an already-scheduled run_once() callback. The result is that if I turn off the switch in between, the stuff never gets turned off, which is not the desired behavior. The desired behavior is for it to turn off, and then not turn back on again.
Now, I am sure I can fix this programmatically in the python code, by having the initial routine check for the switch being in the off state, but that seems clunky when the constraint mechanism is already present. Is there any way to have the constraint mechanism allow already-scheduled callbacks only, rather than disallowing all callbacks?
constraints are actual input for listen_state (or run_daily, or listen_event, or …)
but if you look really close i think they are kwargs also, i believe (i dont go looking into the code that much)
sorry i dont understand what you want with it.
its a constraint. so at the moment the listen_state gets triggered (so if a state change takes place) it checks if the boolean is on, and if not the callback from listen_state isnt called.
there are also constraints for time, weekdays, input_selects, etc.
you wanted to use the constraints to start and stop the listener instead of the callback?
there is not really a point for that because even if you dont have listen_state the state change will still be noticed.
all you do with listen_state is connect a callback to something that is happening anyway.
The only benefit would be a reduced load on the system. That’s why I was wondering if the attribute was part of the function or kwarg. If it was part of the function, appdaemon would likely turn the trigger off.
i dont know how its handled on the background.
i leave that to Andrew.
if there is a way it could make AD better he probably knows about it, and if not you can check the code and see if there is a way to make it better. im sure he will appreciate that.
i am just the super user, who helps out others with the functionality and helps Andrew with making things better on the none coding level. the coding i leave to him.
That’s why I was asking you! There clearly are functions in AD that I do not know about and at this point I’m trying to learn them all to help others in a more ‘appdeamon’ way.
