There are trade offs between convenience and flexibility. I have done some amazing things with AppDaemon, it has brought threading to a novice coder like myself, and I’m glad it is an open and flexible platform.
um… ok. I’ve done plenty of cool stuff with appdaemon as well, but that is neither here nor there when it comes to this function being way too primitive, and being incredibly poorly documented.
what does the blank “, ,” even mean there? Is it a typo?
Why the strange nomenclature for this function where you provide the function_name, delay_time, and only then the args?
What would seem more typical would be:
self.run_in(self.turn_off("light.mylight"), 20)
and lets not forget the worthless error messages when you wrap anything in run_in. Thanks for providing an actual line number python. And, for the record 0 positional arguments were given, but whatever.
2019-09-05 21:58:05.018637 WARNING AppDaemon: ------------------------------------------------------------
2019-09-05 21:58:05.018897 WARNING AppDaemon: Unexpected error in worker for App livingroom_av:
2019-09-05 21:58:05.019059 WARNING AppDaemon: Worker Ags: {'name': 'livingroom_av', 'id': UUID('6ee454ae-67df-4c2e-8510-47af6d4e99e9'), 'type': 'timer', 'function': <bound method AutoAV.select_sources of <auto_av.AutoAV object at 0x7f43245f75f8>>, 'kwargs': {}}
2019-09-05 21:58:05.019188 WARNING AppDaemon: ------------------------------------------------------------
2019-09-05 21:58:05.019454 WARNING AppDaemon: Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 586, in worker
funcref(self.sanitize_timer_kwargs(app, args["kwargs"]))
TypeError: select_sources() takes 1 positional argument but 2 were given
2019-09-05 21:58:05.019588 WARNING AppDaemon: ------------------------------------------------------------
Can you please show the code, which gives you this error? I’m almost sure that your code provides 2 positional arguments and not that python spits out wrong errors.
Can you please also show the config yaml for the below app? Because this works fine for me.
def future_off(self, kwargs):
entity=kwargs["entity_id"]
self.log("Turning off {}".format(entity))
self.turn_off(entity)
How should the run_in method know that in the first case it should turn off entity_id and in the second case it should hand over the entity_id to the callback? Like this, you would need to include all possible methods with all their required arguments inside the run_in wrapper.
I just wanna do what I wanna do, I’m not really that interested in python and the more I use it the less I am interested. Give me ruby any day.
as for run_in, I guess I still just don’t get why run_in would pass both positional arguments to the call back when one of them is the name of the callback itself, and the other is the number of seconds in the future to execute?
Neither of these are useful to my callback so I don’t quite understand why its getting them.
And to explicitly answer this question, appdaemon provides a lot of builtins that work in a particular way and do exactly what you want them to do. run_in seems syntactically and functionally different than most of the provided functions.
Yes it provides a lot of builtins that work, but it is still python. In my opinion you need to understand the basics of python otherwise it will lead to frustrating situations like this one.
I don’t know what is so hard to understand about the run_in method.
self.run_in(callback you want to execute after delay, delay, additional keyword arguments you want to provide to the callback)
E.g.
self.run_in(turn_light_off_delayed_cb, 60, name = “kitchen lights”, entity_id =“light.mylight”)
turn_light_off_delayed_cb is the callback you want to call
60 is the desired delay
name and entity_id are additional keyword arguments
def turn_light_off_delayed_cb (self, kwargs):
name = kwargs["name"]
entity=kwargs["entity_id"]
self.log("Turning off {}".format(name))
self.turn_off(entity)
Well your example is basically what I ended up doing.
Tthere are 2 cases that I always seem to run into-
One is where I’ve already written a function where I want to run it both with and without run_in. I seem to have to modify the function definition to use only (self, kwargs) for it to work with run_in. I can’t define a function as my_func(self), or my_func(self, **kwargs), or my_func(self, arg, arg2).
The second is the example I gave above where I want to run the same function both as:
self.run_in(turn_light_off_delayed_cb, 60, name = “kitchen lights”, entity_id =“light.mylight”)
and:
self.run_in(turn_light_off_delayed_cb, 60, name = “kitchen lights”, entity_id=self.args["kitchen"])
I still don’t quite understand why the latter example doesn’t work.
If you want to run the same callback with and without run_in you have to do it this way or create another callback for the delayed execution, which will call the other function.
Can you show the config yaml for the below? This works for me without issues, I assume you config is wrong.
self.run_in(turn_light_off_delayed_cb, 60, name = “kitchen lights”, entity_id =“light.mylight”)
and:
self.run_in(turn_light_off_delayed_cb, 60, name = “kitchen lights”, entity_id=self.args["kitchen"])