Parameters/args to AD classes

Third party integrations AppDaemon
1

I’m just getting started with AppDaemon - it took me a while to even grasp the concept. I got some well-deserved (but mild) abuse from Rene, the author of AppDaemon For Beginners..

I’m confused by the usage of parameters in AD classes. Now that I understand that AppDaemon apps run continuously (instead of being called like scripts like I originally thought), I’m trying to code something that will take arbitrary parameters. I’m still working with the “turn on a lightbulb” example.

The apps.yaml setup in the example shows an app & class setup like this:

some_light_on:  
  module: some_app  
  class: your_class_name  
  lightID: light.some_light  

some_other_light_on:  
  module: some_app  
  class: your_class_name  
  lightID: light.some_other_light

To me, that looks like two entries for two specific light entities. How do I configure the “param” (4th line) configuration in apps.yaml to take one of many entities?

I’m building a Harmony remote control with a bunch of icons and tap_action: call-serviceentries. In my AppDaemon code, I’m using listen_event to try and detect the clicks on the various icon “buttons”. Those buttons need to send various kinds of data back to AppDaemon. AppDaemon will then shuffle and sort the various arguments before sending the command to the Harmony system.

I know there’s the var1 = args["param1"] usage within the AppDaemon Python code, but I’m not clear on how it fits into the initialization statement, or whether or not those need to be defined in apps.yaml.

What I think I want to code in my UI YAML is something like this (pseudocode)

- script
  custom_remote:
  - service: turn_on_activity
    data: Watch TV

- script
      custom_remote:
      - service: turn_on_activity
        data: Play Xbox

— and —

- script
  custom_remote:
  - service: change_channel
    data: [3, 1, 7]

This kind of behavior is possible, isn’t it? I’m confused by those settings in apps.yaml and the use of args["params"].

Can someone help clarify?

Thanks.

2

Have you read the section on passing lists as parameters? Is that what you want?
https://appdaemon.readthedocs.io/en/latest/APPGUIDE.html#passing-arguments-to-apps

3

I’ve read it numerous times! Yes, it’s what I want, but I can’t put together the puzzle pieces` that read

  param1: spam
  param2: eggs

And then

param1 = self.args["param1"]
param2 = self.args["param2"]

Why do we define “param1” as “spam” and “param2” as “eggs”, if we can send in any values we want?

There’s also the issue of having parameters inside the initialize class statement (using **kwargs), which further confuses me: https://appdaemon.readthedocs.io/en/latest/APPGUIDE.html#user-arguments

self.listen_state(self.motion, "binary_sensor.drive", arg1="home assistant")

I can’t tell if there are multiple ways to get the user arguments, or just one, and it’s not clicking in my head. The entries in apps.yaml I really don’t get.

Sorry if this is a basic question that I’ve over-complicated… I’m just having a really hard time getting it. And I swear I’m a competent coder!

4

the process is quite simple.
its all about reusing code.

with the parameters we create a piece of code that we can use over and over.
for instance we have 10 motion detectors and we want them to trigger 10 different lights

def initialise(self):
  self.listen_state(self.cb,self.args["motion_detector"])
def cb(...):
  self.turn_on(self.args["light"}

thats its, now we can stop worrying about writing code and we can turn on any light with any motion detector we want just by adding some yaml
so we use

motion1:
  module:
  class:
  motion_detector: sensor.something
  light: light.a
motion2:
  module:
  class:
  motion_detector: sensor.somethingelse
  light: light.b

now about your harmony.
your button has some args for the service and you use a listen_event.
the app would be something like

def initialise(self):
  self.listen_event(self.cb,"call_service",param = self.args["param1"])
def cb(...):
  self.call_service(some_service,param=self.args["param2"])

now you can add the param1 to what you want to listen for and param2 to what it should do over and over.

5

Hi Rene! :smile:

So the names like “spam” and “eggs” are meaningless? They’re just placeholders for whatever values you want to send into AD?

And one other semi-related question… my Python code can contain multiple classes, right? As long as all the names are different, etc.

I really do appreciate your help.

6

right it could also have been example 1 and example2, or monkey and elefant :wink:

yup it can.
but i prefer to keep things seperate.
an app is a class that is declared in the yaml.
you can create 1 big py file with 100 different classes and 1 big yaml file with 100 classes declared.
but i think its easier to keep just an app as it is.

so most of the times i use
example.py with class example
example.yaml with

example1:
  module: example
  class: example
  some args: anything
example2:
  module: example
  class: example
  some args: something else

but if you prefer to do everything in 1 large file you are free to do so.